長文のわりに一般性がないので、読みたくない人はスルーしてくれ

>あくまでも kernel 側の不具合
>そして極めつけは、コードを追って該当箇所を直したらRock64(RAM-4G)でも問題無し

大昔にATAカード（SDとかのフラッシュメディアの先祖）のドライバ開発をしたことがある
前任者のドライバが非常に出来が悪いということで、こちらに回ってきて（ATA仕様見た後
ドライバコード見て眩暈がして思わずゴミ箱に叩き込んで）ゼロから完全改修した

この時の解析結果を当てはめると、上記引用は納得がいく

SDみたいなデバイスは大抵ミリ秒単位でコマンドのキャッチボールをしなければならない
この際の時間調停にnanosleep()の類（OSにより微妙に異なる）のウエイト命令を使う
だがコレが曲者で、私がやった時は、OS標準関数内がただの空ループだった
OSのデフォルトがその状態で、恐らく開発に際してハードウェアクロックに接続するべきなのだろう
だがそこまでの開発権限がなくハード設計ももらえなかったんで、当時のハードでスペック計測して
ソフトでできるタイミングを限界いっぱいまで合わせた

勘が鋭い人はわかると思うけど、これってマルチタスクが干渉するだけでもタイミングが狂う
カーネルが変わったりすると、本来はその計測をやり直さなければならない

たとえばstretch（Debian9)の母体は汎用OSなので、タイミング調停関数が初期状態である可能性がある
また安いSBCは、クロックに関するハードAPIをそもそも持っていないかもしれない
そんな設計思想だと、仕様通りでも本体側のマージンができてしまい、SDのマージンに収まらないと不動

そんな感じで、どうしても相性というものがあり動かないものが発生してしまう
手間かけたくない人は、妥協して動くSDを探すしかないと思う