本記事にはアフィリエイト広告（Amazon アソシエイト）が含まれます。
実測日: Sat Aug 22 2026 09:00:00 GMT+0900 (Japan Standard Time)
手元の AirBox は Ubuntu 20.04 のまま 6 年が経っていた。 セキュリティ更新が届かない状態をどう解くか、26.04 まで進める道を調べた。 本記事は調査の記録で、実施はしていない。 結論を先に書くと、カーネルは動かせず、動かせるのはユーザー空間だけである。
いま動いているもの
| 部品 | 版 | 備考 |
|---|---|---|
| カーネル | 5.4.217（ベンダ版、2024 年 5 月ビルド） | dpkg の管理外。FIT イメージの中にある |
| TPU ランタイム | libsophon 0.5.0 | SDK V23.10.01 相当 |
| ffmpeg と opencv | sophon-mw 0.7.1 | ハードウェアコーデック対応 |
| TPU ドライバ | bmtpu、vpu、jpu の 3 本 | 樹外モジュール。libsophon の deb に同梱され、起動時に insmod される |
カーネルのソースは全量が公開されていた。 埋め込まれた commit を GitHub で照合すると、Radxa の公開ブランチの先頭と一致し、ベンダ本流に Radxa の 5 commit（AirBox 向けのデバイスツリーなど）を重ねたものだと判った。
メモリは 16 GB のうち Linux に約 3 GB だけが渡り、残りはデバイスツリーの予約領域から ION heap として確保される。 NPU 7168 MiB、VPU 2048 MiB、VPP 3072 MiB である。 TPU ランタイムのデバイスメモリ確保は、この ION heap 経由で行われる。 この一点が、以後の判断を支配した。
カーネルを動かせない理由
ION は Android 由来のメモリアロケータで、mainline では 2020 年に削除パッチが出て 5.11 で消えた。 後継は DMA-BUF heaps だが、TPU のドライバとランタイムは ION を前提に書かれている。
ベンダの側にも動きが無い。 2026 年 5 月の SDK v26.03.01 でもカーネルは 5.4.217 のままで、rootfs も Ubuntu 20.04 のままだった。 mainline には BM1684X のデバイスツリーもドライバも存在しない。 Radxa の AirBox 向けイメージも 20.04 ベースの 2 種類だけで、22.04 以降は確認できなかった。
つまり、新しいカーネルを待つ道も、mainline に乗り換える道も無い。 ベンダのパッチを新しいカーネルへ移植する道は、ION の置き換えを含む数人月の仕事で、TPU を失う危険が高い。
ユーザー空間だけなら動かせる
26.04 の systemd 259 は、カーネル 5.4 を最低ラインとして公式に支えている（v258 で cgroup v1 の削除と同時に下限を 5.4 に定めた）。 したがって「カーネルは 5.4 のまま、ユーザー空間だけ 26.04」は成立の余地がある。
ただし現行カーネルの設定には穴があった。
cgroup v2 に必要なコントローラ、namespace、seccomp、overlayfs、BPF の syscall は有効だが、CONFIG_CGROUP_BPF と CONFIG_BPF_JIT が無効である。
26.04 の systemd は cgroup v2 だけで動き、v2 ではデバイスのアクセス制御を cgroup BPF で実装する。
この設定のままでは、systemd の DeviceAllow は効かず、Docker のコンテナ作成も失敗すると推定した（機構からの推定で、実機では未検証）。
現行の 20.04 は cgroup v1 で動いているので、今は表面化していないだけである。
4 つの道の評価
| 道 | 追加で要るもの | 作業量 | TPU を失う危険 | 後戻り | 判定 |
|---|---|---|---|---|---|
| a. ベンダか Radxa の新 BSP を待つ | 存在しない | – | – | – | 不成立 |
| b-1. 26.04 のコンテナ | 無し | 小 | 無し | 容易 | 第一段 |
| b-2. rootfs の差し替え | 無し | 数週間 | 低から中 | SD からの全書きで可 | 条件付きの第二段 |
| c. ベンダのパッチを新カーネルへ移植 | 無し | 数人月 | 高 | 困難 | 不採用 |
| d. mainline と樹外ドライバ | 前提が無い | – | 確実に失う | – | 不採用 |
b-1 は、ホストをそのままにして 26.04 の arm64 コンテナに TPU のデバイスノード（/dev/bm-tpu0、/dev/bmdev-ctl、/dev/ion、/dev/vpu、/dev/jpu）と /opt/sophon を渡す形である。
Docker は既に稼働しており、ホストが cgroup v1 のままなので設定の穴は影響しない。
Radxa 自身が AirBox のアプリ群を Ubuntu ベースのコンテナとして配布しており、実績のある形でもある。
後戻りはコンテナの破棄だけで済む。
b-2 は、rootfs を 26.04 の arm64 に置き換える形で、成立条件が 3 つある。
CONFIG_CGROUP_BPF=y での同一版カーネルの再ビルドと 3 本のドライバの再ビルド、TPU のランタイム一式の 26.04 上での再ビルド、ベンダ rootfs 由来のサービスの選別移植である。
いずれも公開ソースと盤上の現物でまかなえるが、検証込みで数週間かかる。
推奨
第一段として 26.04 のコンテナを先行させる。 glibc、python、ツールチェーンの新しさはこれでほぼ満たせて、ホスト、TPU、ファン制御、稼働中のデモのどれにも触れない。 素の OS を 26.04 にすること自体が要件になった場合に限り、第二段の rootfs 差し替えへ進む。
「TPU スタックが入手できる」という前提の中身も確定した。 ドライバのソース、firmware、ランタイムのソースはすべて公開されているか盤上にある。 前提の実体は「ベンダから何かを入手すること」ではなく、「公開ソースを 26.04 向けに自前で再ビルドして検証する工数を払うこと」である。
この記事で扱った機材
Radxa Fogwise AirBox（SOPHON BM1684X）
BM1684X 搭載の小型 AI ボックス。Ubuntu 20.04 ベースの BSP で、glibc の古さが USB アクセラレータの制約になる。