AirBox のカーネルの世代を進める。FIT の差し替え、Radxa 独自 DTB の移植、SPI flash には触らない

本記事にはアフィリエイト広告（Amazon アソシエイト）が含まれます。

実測日: Thu Aug 27 2026 09:00:00 GMT+0900 (Japan Standard Time)

Ubuntu を 20.04.6 にしたあと、カーネルと TPU のスタックを進めた。 系列は 5.4 のままで、世代だけを SDK v24.04.01 のものにする。 本記事は、FIT の差し替えと DTB の移植の手順、同時に動かすしかない部品の組、そして SPI flash に触らなかった理由を記録する。

更新の前後

Radxa の Model Zoo が要求する libsophon 0.5.0 以上、sophon-mw 0.7.3 以上、SDK v24.04.01 以上を、実体として満たす状態になった。 なお bm_version の先頭行は固定文字列で、更新後も v23.10.01 と表示する。 このスクリプトは deb の管理下なので書き換えていない。

stock の FIT には Radxa の DTB が無い

U-Boot は boot.scr.emmc の中で config-pcb<板種> を選ぶ。 この盤は config-pcb139 である。 stock の FIT にも config-pcb139 はあるが、中身は SM7M V1.0 基板用の DTB で、Radxa の IO Board 用ではない。 新旧の DTB を取り出して比べると、差は次のとおりだった。

ethernet と eMMC と PCIe が同一なので、stock の DTB でも起動して SSH は戻る見込みが立った。 それでも stock をそのまま使わなかったのは、NPU の領域が半分に縮み、LED と PWM の pinctrl が消えるからである。

1 枚だけ移植して組み直す

付属の memory_edit.sh は、-d で FIT を分解し、-e で組み直す機能を持つ。 その間に fdt-pcb139 の dts だけを Radxa 版に置き換えればよい。

古い FIT（Radxa、旧カーネル）  --分解-->  Radxa 版の dts新しい FIT（stock、新カーネル） --分解-->  stock 版の dts                                            ↑ 1 枚だけ上書き                                     --組み直し-->  新カーネル + Radxa DTB の FIT                                     --/boot へ-->  起動。古い FIT は .bak として保険に残す

落とし穴が 2 つあった。 -d と -e は /boot から再コピーせず、作業ディレクトリの控えを使う。 新しい FIT を扱う前に /boot の FIT と its を手で作業ディレクトリへ複製しないと、古い FIT を分解した結果が返る。 もう 1 つは dts の名前で、既定値は /proc/device-tree/info/file-name から取るが、その値（Radxa の名前）は FIT 内の格納名（SM7M の名前）と一致しないので、この盤では明示的に渡す必要がある。

組み直した FIT で起動すると、model は Radxa AICore BM1684x IO Board に戻り、LED の三色、pwmchip0、thermal zone が揃い、ION は NPU 7168 MiB、VPU 2048 MiB、VPP 3072 MiB を維持した。

TPU ドライバとカーネルは同時にしか動かせない

TPU のドライバ bmtpu.ko は libsophon の deb に同梱され、起動時に insmod される。 vermagic は、0.5.0 が旧カーネルのビルド、0.5.1 が新カーネルのビルドに固定されている。 片方だけを進めると、ドライバが載らず TPU が死ぬ。 カーネルと libsophon は 1 つの組として進める。

libsophon 0.5.1 の deb には癖があり、同じ版で上書き導入するまで libbmrt.so.1.0 の実体を欠いた状態になった。 dpkg -V で検出でき、同じ deb を再導入すれば直る。 症状は bmrt_test が共有ライブラリを見つけられない、という形で現れる。

SPI flash を対象から外した理由

ベンダの bsp_update.sh は、/boot のファイル群を置き換えたあと、最後に SPI flash を書く。 前者は、FIT の読み込みか bootm が失敗する範囲なら .bak へ自動で戻る。 後者は U-Boot 自身を書き換えるので、その保険の手前で止まる。 そこで /boot の置き換えと libsophon の更新までを手で実施し、SPI flash の書き込みは投入しなかった。 現行の U-Boot 2022.10 は新しい FIT をそのまま読めるので、支障は出ていない。

ここで 1 つ事故をした。 flash_update の -p を probe と読み違えて実行したところ、-p は write protection で、SoC がリセットして再起動した。 内容は無傷で復帰したが、知らないツールのオプションは strings で usage を読んでから使うべきだった。 -d による読み出しは安全で、リセットは起こさない。

もう 1 つ判ったのは、bsp_update.sh が自動で取るバックアップが 2 MiB しかなく、実際の flash の内容 5.4 MiB に足りないことである。 全域（6 MiB）を読み出して NVMe に保存した。 /boot/spi_flash.bin は焼いた元ファイルの控えに過ぎず、実機の内容とは 350 バイト目から違っていた。 実機に焼かれている内容の写しは、この全域ダンプが唯一である。