2ちゃんねる スマホ用 ■掲示板に戻る■ 全部 1- 最新50    

【PINE64】パイン64 part2【ROCK64】

311 :login:Penguin:2018/08/19(日) 16:34:10.70 ID:Zxn/Gs53.net
長文のわりに一般性がないので、読みたくない人はスルーしてくれ

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

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

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

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

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

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

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

222 KB
新着レスの表示

掲示板に戻る 全部 前100 次100 最新50
名前: E-mail (省略可) :

read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★