Japanese Translation:

このプロジェクトは、Lenovo IdeaPad Duet タブレット（コードネーム：kukui-krane）を標準の ChromeOS ファームウェアでは以前不可能だった重大な起動障壁を克服し、完全に機能する Linux デバイスへと成功裏に変換しました。核心的な成果は、破損した ChromeOS/postmarketOS セットアップを置き換え、Depthcharge という独自のチェーンローディングされたブート機構を用いて eMMC にカスタム構築された Ubuntu をインストールすることです。これはネイティブの EFI サポートをバイパスするものです。主な決定的な進展には、U-Boot と Coreboot 間の重要なアラインメントミスマッチを解決するために AI アシストされたフレームバッファースタブを生成したことがあり、UART ログのデバッグによりパネル初期化の問題が修正されました。初期のアプローチはネイティブ EFI サポートの不備とメモリアレイアウトのエラーのために失敗しましたが、カスタム shim ローダーを埋め込むことでこれらのソフトウェアコンポーネント間の橋渡しに成功しました。現時点では Bluetooth の接続には mainline カーネルをサポートするためのパッチが必要ですが、今後の作業はこれらの修正の維持と、潜在的に Linux コミュニティ全体への解決策の上流化（アップストリーミング）に焦点を当てます。結局のところ、これはデベロッパーモードを持つユーザーがネイティブの Ubuntu をインストールできるようにし、追加のハードウェアコストなしでローカルの開発ワークフローを解放し、公式の ChromeOS の制限のみへの依存を解消します。

Lenovo IdeaPad Duet Chromebook: postmarketOS から Ubuntu への移植と U-Boot ハッキング

Lenovo IdeaPad Duet Chromebook（2-in-1 ARM64 タブレット）を所有しています。元は ChromeOS を使用し、後で postmarketOS に移行したところ、突然動作しなくなりました。そこで、Ubuntu の動作を試すため、ファームウェアのハッキングや U-Boot 導入など、大幅な改修を行いました。

1. デバイスと初期状況

device 概要

型名: Lenovo IdeaPad Duet (コード名:
```
kukui-krane
```
)
画面: 10.1 インチ (1920x1200)、プラグアンドプレイ対応のdetachable キーボード付。
SoC: MediaTek MT8183 (ARM64)。
メモリ: 4GiB。

導入経緯と課題

購入背景: 大学在学中に安価な中古品（約 100 ユーロ）として購入。携帯性を重視してタブレット型 PC を欲しがっていたが、ChromeOS のパフォーマンスは期待以下で放置していました。
postmarketOS への移行: Alpine Linux ベースで Android アプリも動作し、真の Linux 環境が得られると知って導入しました。
- インストールは Wiki とガイドに従えば簡単（開発者モード → USB/内部ストレージから起動 → eMMC へのインストール）。
- しかし、GNOME はリソースを多く消費し、低性能なデバイスでは動作が遅く、ミニマリスト志向には不向きでした。
破綻したアップデート:
```
postmarketOS 25.12
```
で起動できたものが、
```
26.06
```
へのアップデートで内部ストレージからの起動が失敗しました。ルートファイルシステム（rootfs）の起動プログラムに問題があったことが判明し、これを Ubuntu による rootfs 置換に変更しようと試みました。

2. Ubuntu への移植とブートフローの理解

インストールアプローチ

方法: postmarketOS (
```
25.12
```
) の USB スティックから chroot し、eMMC 上のルートパーティションを Ubuntu の rootfs に書き換える。
カーネルの変更:
- 最初は postmarketOS カーネル（
```
6.12.87-mt81
```
  ）で試したが、Wi-Fi が動作しなかったためファームウェアをコピーする対処が必要でした。
- より完全な対応のため、Ubuntu の標準パッケージ
```
linux-generic
```
  をインストールし、Kernel と DTB を
```
/boot
```
  パーティションにコピーしました。
驚異的な起動: ブートローダー知識がなくても起動成功しました。ただし、ブートローダー設定不足やカーネルコマンドラインの問題により、直後の動作には不具合がありました。

ブートフローのメカニズム解明

Chromebook の起動フローは複雑で、以下の順序で実行されます：

ブート ROM: FSBL を含み、Coreboot をロード。
Coreboot: ARM Trusted Firmware → Depthcharge (ChromeOS ブートローダー) をロード。
Depthcharge:
- 「開発者モード」メニューを表示（USB/内部ストレージ選択）。
- 内部ストレージの
```
/boot
```
  パーティションを読み取り、そこに FIT イメージ（カーネル + initrd + DTB）を探します。

問題点：EFI 環境の必要性

Depthcharge は FIT イメージから直接カーネルをロードしますが、Ubuntu カーネルは UEFI 経由での起動のみ可能です。
したがって、UEFI 対応のファームウェアが必要です。U-Boot が EDK2 より扱いやすく、MT8183 SoC へのサポートもあるため選択しました。

ターゲット：Depthcharge → U-Boot → Grub → Ubuntu

Depthcharge から U-Boot にチェーンロードし、UEFI 環境を実現します。
その上で Grub を起動し、Ubuntu カーネルを読み込みます。

3. U-Boot のハッキングと最適化

タスクの難易度

現状: Depthcharge が直接パネルを制御する「revival ハック」を使っていたため、カーネルはディスプレイ設定をやり直す必要があり不具合が起きがちでした。
目標: 本物の U-Boot を導入し、U-Boot でパネル制御を引き継ぐ。フレームバッファのハックを廃止する。

ハッキングプロセス（27 回の試行）

初期失敗: ファーストフラッシュで画面が真っ暗。デバッグ手段なし。
デバッグ戦略: 各ステップで画面に色付きバンドを表示し、問題箇所を特定。
配置整合性の問題発見と解決:
- Depthcharge はペイロードの固定オフセット（0x40）から起動コードを受け取る。
- U-Boot は位置独立コードとして 4096 バイト境界にエントリーポイントを要求する。
- 解決策: シャムローダー（シムローダー）を作成し、Depthcharge が望むアドレスで制御を受け渡し、そこから U-Boot にジャンプさせる構成に変更しました。

コンソールとキーボードの確立

初期は画面がポートレート向きだったが、キーボード接続のためランドスケープ設定 (
```
rot=3
```
) を追加。
USB キーボード対応: ポゴピン経由で USB データラインを伝導。U-Boot コンソールでの入力を可能にしました。
スクロール修正: アップストリームパッチのバグによりスクロールが不安定だったが、1 つの文字変化で解決（
```
rot=1/3
```
時）。

グルーブ（Grub）への移行

```
bootefi bootmgr
```
コマンドを実行し、EFI ブートマネージャを起動。
Grub をインストール・設定し、ポートレート表示だったメニューをランドスケープに変更。
問題: U-Boot と Grub の間、Grub と eMMC の間でハンドオフに失敗し、アクセスエラーが発生していました。これを解消し、クリーンな起動を実現しました。

4. パネルドライバの実装とカーネル起動

ハードウェアの完全制御

Coreboot からのフレームバッファ再利用を廃止し、本物のパネルドライバを実装しました。
- MT8183 ディスプレイパイプライン: MIPI DSI ホスト + PHY + BOE TV101WUM-NL6 パネル。
SuzyQ アダプタの活用: U-Boot シリアルサポートを引き上げることで、デバッグログを見ながらパネルドライバの初期化エラー（NULL ポインタ参照など）を修正できました。

カーネル起動における問題解決

Ubuntu 7.2 カーネルで起動を試みると、

initrd

でのフリーズが発生しました。

依存関係の問題: initrd に
```
mtk_pmic_wrap
```
,
```
mt6397
```
,
```
mt6358_regulator
```
モジュールが必要だったため、ビルトイン (
```
y
```
) として設定または initramfs で強制的にロード。
メモリアドレスの不一致:
- U-Boot では DRAM を 2GiB しか報告していない（Coreboot の予約領域）。
- カーネルはこれを通常メモリとして扱い、セキュリティ例外を引き起こしてフリーズ。
- 解決策: Coreboot テーブルから完全なメモリマップを抽出し、EFI メモリマップに欠けていた領域を考慮する修正パッチを作成し、4 度目のフラッシュで解決しました。

5. U-Boot トリーのリファクタリングとアップストリーム化

リファクタリングの成果

元のコミット数は 43 個に達していたため、リファクタリングにより 20 個 に整理しました。
以下の機能を実装：
- MT8183 SoC クロック/GPIO ドライバー追加。
- MIPI DSI ホスト・PHY ドライバー実装。
- BOE パネル用のパネルドライバ実装。
- シリアルコンソール安定化、メモリアドレス修正など。

アップストリーム化の検討事項

以下のカテゴリに分類してパッチを作成・送信しています：

アップストリーム共通バグ: 回転表示時のスクロール不具合、カーセル損傷報告、EFI コンソール同期など。
MediaTek (MT8183) 特定修正: シリアルボーレート設定、DMA エンジンアドレス制限（32 ビット）、xhci ドライバー改善など。
ボード固有パッチ (krane):
```
defconfig
```
の定義、DSI パイプラインの統合、メモリマップ調整など。

注記: AI が生成したコードは品質が高く敵対的レビューでも耐性がありますが、最終的な判断（どのパッチをアップストリームにするか）は人間が行う必要があります。

6. 結論と考察

ブルートゥースの制限

アップストリームカーネルではブルートゥースが動作せず、postmarketOS 用の特殊なパッチが必要になります。これがメインライン化されるまでには時間がかかります。

ブート可能イメージの作成

Canonical の RISC-V ボード導入時の知見を応用し、修正された U-Boot と Depthcharge ペイロードを埋め込んだ ブート可能 Ubuntu イメージ を作成しました。
- USB スティックに書き込み、「開発者モード」→「USB 起動」を選択すれば直ちに本物の Ubuntu が起動します。
- GNOME は RAM 不足により低速ですが、機能は完全に動作しています。

AI を活用したハードウェア導入の限界と可能性

AI の役割: 起動フローの理解、デバッグ（色バンド表示など）、コード生成に非常に有効です。参入障壁を劇的に下げました。
- ただし、「ワンショット」で完全なサポートは得られませんでした（27 回の試行や数週間の日数が必要）。
重要な課題: AI が生成したパッチが、メンテナンスコミュニティによって受け入れられるかどうかが鍵です。未維持のカーネルをさらに増やすのではなく、アップストリーム化を目指す必要があります。
人間性の必要性: ハードウェアの背景知識（起動フローなど）を持つことが必須です。AI だけでは「なぜ動かないか」を判断できないためです。

次のステップ

アップストリーム化: U-Boot とカーネルパッチをオープンソースコミュニティに提出し、一般ユーザも利用可能にする。
Depthcharge メニューの削除: 新しい Coreboot イメージで Depthcharge を置き換え、メニューレスでの起動を目指す（SuzyQ アダプタを利用）。

GitHub リポジトリ: vhaudiquet/krane

修正済み U-Boot パッチ、シャムローダー、ブート可能イメージなどが公開されています。
※公式 Ubuntu イメージとは無関係です（自由時間のプロジェクト）。

レノボ・アイデアパッドデュートでUbuntu を動作させる方法