MCUbootを知らねばならぬようだ
2024/07/05
前回(1, 2)に引き続き、ncs v2.6で評価ボードnRF5340 MDBT53-1Mモジュールピッチ変換基板を自分でビルドすると立ち上がらない件の調査である。
今のところ分かっていること：
- ncs v2.4.0 と v2.5.3 では動作したが v2.6.0 と v2.6.1 では動作していない
- ncs v2.6.0 から MCUboot リポジトリを fork したらしい
- ブートローダの途中で止まっている
loader.c の比較
v2.5.3もv2.6.0もncs/vX.Y.Z/bootloader/mcuboot/boot/bootutil/src/loader.cというファイルは同じだったので、HALTしている付近を比較した。左がv2.6.0、右がv2.5.3である。
v2.5.3ではassert()でしかflash_area_open()の戻り値をチェックしていなかったのを v2.6.0 ではif文でチェックするようになっただけ？
ncs だか zepher だかのassert()の挙動はわからんが、NDEBUGマクロが定義されていたら何もしない。
そしてassert()を通り越してif文の中まで進んでいることを考えるとNDEBUGありでビルドされているのではなかろうか。
v2.5.3まではif文でのチェックがないのでスルーして進んでいるだけ？
if文をコメントアウト
ならば、v2.6.0 でif文をコメントアウトしてスルーしたらどうなるだろうか？
・・・動いた。動いてしまったよ。
では、v2.5.3 にif文を追加してみる。
・・・動かなかった。デバッガで見るとFIH_PANICで止まっていたので、現象は同じだ。
もしかしたら v2.4.0 では動いていたのかも、とif文を追加したが、やはり止まる。
ということは、昔からエラーが出たけどスルーして動いているだけなのか。
感想
これはどう考えると良いのだろうか。。。
assert()だけで済ませるのはあまりよろしくないと思う。NDEBUGで#ifdefしておくのがよいだろう。
しかし問題はそこではない。
flash_area_open()がエラーになるのが問題なのか、そもそもflash_area_open()を通るのが問題なのか。
そこら辺を把握するにはMCUbootを深く知らないと無理な気がする。
MCUbootはここが本家のようだ。 こういう時代なので、アップデートしやすくしておくのと同時に不正なファームウェアを焼かれるのを防がないとダメなのだろう。
MCUboot自体はzepher用とかARM用とかいうものではなさそうだ。 zepherのMCUbootのドキュメントはあるので、そこら辺からつかんでいくのがよいか。
if文はいつ追加されたのか
本家MCUbootのリポジトリを見ると、if文が追加されたのは2023年9月くらいのようだ。
ncs v2.5.3 だとリポジトリはnrfconnect/sdk-mcubootで、使われているのはこのcommitだった。
if文が追加されたcommitはこれ。
v2.6.0 は fork したとか書いてあったがリポジトリはnrfconnect/sdk-mcubootのままだ。本家からforkしたのではなく、v2.5までで使われていたブランチから枝分かれしたという意味なのかな？
使われているのはこのcommit。
README.mdを見たが、ncs v2.5.3 の MCUbootは “version 1.11.0-dev”ベース、v2.6.0 は “version 2.1.0-dev”ベースだった。
メジャーバージョンが違うから、いろいろ挙動も違うのかもしれん。
関係ないけど
Toolchain がアップデートされていた。ncs v2.7 の準備なのかな？ ncs v2.7 はまだ experimental な感じがする。
アップデートしたが、ncs の動作に関係があるわけではない。
ncs v2.7.0
と思ったら ncs v2.7.0 は正式リリースだった。7月11日にwebinarがあるそうだ。
試しに v2.7.0 で blinky を動かしましたがダメでした。
ブートローダに関する設定が何かあるんだろうなと思いつつ、まだ全然分かっていないのであった。