Armadilloフォーラム

搭載SoC(i.MX7D)の個体差によって、ごくまれにDRAMからReadするデータが化ける個体がある件について

atsu-k

2024年7月4日 15時43分

お世話になっております。

標題の件についてですが、U-Boot v2016.07-at24以前 (2024年2月のリリース以前)を使用している/していない 以外で
"搭載SoC(i.MX7D)の個体差"を判別する方法は御座いますでしょうか?
例えば製造年月日やシリアル番号等でU-Bootをアップデートする必要があるか無いかを絞れないかと。

以上、よろしくお願いいたします

コメント

申し訳ございません。
実際に起動するか否か以外での判別方法は存在していません。

基本的に条件に該当する場合は、起動の時点でリセットされるため、
現時点でとくに支障なく起動している機材については、これからも問題無いとは思います。

現時点で起動させたことのない機材については、基本的にすべてアップデートを
することを推奨いたします。お手数おかけして申し訳ございません。

溝渕です。

結論としては、全個体についてアップデートを推奨する事で変わり無いのですが、

> 現時点でとくに支障なく起動している機材については、これからも問題無いとは思います。

この問題は、特に低温環境下で顕著に発生します。その為、常温で正常動作していても、低温環境化で問題が発生する可能性があります。

その為、全個体についてアップデートを推奨しております。

再びすみません。

本件のアップデートを行う上で、台数が多い為現象が発生している、もしくは発生したことがあるものから
優先してアップデートを行おうと考えているのですが、
この現象で再起動が起きたということはsyslogなどから判断できるのでしょうか?
判断できるログやログの見方などがあれば教えて頂けないでしょうか。

> この現象で再起動が起きたということはsyslogなどから判断できるのでしょうか?
> 判断できるログやログの見方などがあれば教えて頂けないでしょうか。

本件についてはLinuxの起動が完了する前にデータ化けで起動自体が失敗しリセット
するという事象が観察されているため、ログを残す処理に到達せずログを残すこと
ができません。
(rebootコマンドは正しく終了処理をしますが、本件の場合のようにデータ化けに
よって起動処理を維持できずに”リセット”した場合は、急に電源を引き抜いたのと
同様に終了処理ができません)

そのため、”ログが残らないこと”自体で確認できます。そもそも、意図して
スクリプトや設定等でreboot等で再起動させている場合は、タイミングは
自明ですしrebootさせている以上正しく終了と起動のログが残ります。

それ以外で起動ログ”だけ”が残るのであれば、意図しないリセットだと考えれば良いです。
ただし、電源が瞬停した場合や、日常的に電源ラインを引き抜くことでOFFしている場合は
区別できません。