Google Tensor G5を搭載するPixel 10シリーズの基本対応が、Linux 7.4への取り込みに向けて進展した。2026年10月5日、SoC担当メンテナーのKrzysztof Kozlowskiが、Google向けの新たなアーキテクチャ区分「ARCH_GOOGLE」と、3機種のハードウェア定義を含む取り込み依頼を送った。対象はPixel 10、Pixel 10 Pro、Pixel 10 Pro XLである。
上流Linuxで起動するための土台は整いつつあるが、現時点で確認されているのは、メモリ上の最小環境を起動し、コマンドを実行できる段階までだ。端末を認識して起動できることと、画面表示や通信機能を使って日常的に利用できることの間には、まだ多くの実装と検証が残っている。
ARCH_GOOGLEが示すSoC設計の変化
従来のTensorを支えるLinuxの分類は、SamsungのSoC系統に属していた。Kozlowskiは取り込み依頼の中で、初期のGoogle GS101がSamsung由来の設計だったため、その系統にまとめられていたと説明している。
一方、Tensor G5、開発コード名「Laguna」は、従来とは異なる設計へ移行した。そこで、Google設計のSoCを扱う「ARCH_GOOGLE」を新設し、端末構成を記述するファイルもGoogle専用のディレクトリに置く。
この変更が示しているのは、LinuxがTensor G5をどのSoC系統として扱うかである。新たなCPU命令セットが導入されたわけではない。追加されるハードウェア定義には、Arm Cortex-X4が1基、Cortex-A725が5基、Cortex-A520が2基と記されている。GoogleがSoCを独自設計していることと、CPUを含むすべての回路を自社で一から設計していることは分けて考える必要がある。
USB対応の開発資料を見ると、この違いがより具体的に分かる。GoogleのRoy Luoは2025年10月のUSB対応提案で、Tensor G5もSynopsysのUSB回路を利用すると説明している。
ただし、その回路をSoCへ組み込む方法が変わったため、クロックやリセットの制御、レジスターへのアクセス方法、初期化手順も従来とは異なる。そのため、ドライバーやハードウェア定義を追加する必要があるという。
つまり、部品として同じIP、すなわち再利用可能な回路設計を採用していても、Linuxから同じ方法で制御できるとは限らない。ARCH_GOOGLEの新設は、こうしたSoC全体の構成の変化に対応するためのものだ。
ただし、USBの資料はその背景を示す過去の提案であり、今回の取り込み依頼によってUSB機能まで一括して利用できるようになるという意味ではない。
起動できる範囲と、まだ確認できないこと
開発者が起動確認に使っているのは、initramfs上のBusyBoxシェルである。initramfsは、起動時にメモリ上へ展開される初期ファイルシステムで、BusyBoxは基本的なコマンドをまとめた小規模なツール群だ。
この環境を使えば、内蔵ストレージから通常のOS環境を立ち上げる前でも、カーネルが起動し、コマンドを実行できるかどうかを確認できる。
今回追加される中心的なファイルは、「Device Tree」と呼ばれるハードウェア構成の記述である。Linuxの公式文書では、Device TreeをOSが読み取れるハードウェア情報のデータ構造として説明している。
CPUや割り込み線、周辺回路の接続関係などをデータとして渡すことで、カーネルは端末ごとの構成に応じたドライバーを利用できる。ただし、ハードウェア構成を記述することと、各回路を実際に動かすドライバーがそろうことは別の話である。
9月18日にPeter Griffinが提出したDevice Treeの第4版と、起動条件を記した提案文から、今回追加される範囲を機能別に整理すると次のようになる。
| 機能の層 | 今回の記述・報告から確認できること | ここからは確認できないこと |
|---|---|---|
| 機種の識別 | FrankelはPixel 10、BlazerはPixel 10 Pro、MustangはPixel 10 Pro XLとして定義 | Pixel 10 Pro Foldなど、列挙されていない端末への対応 |
| CPUと起動の基盤 | CPU構成、待機状態、割り込みコントローラー、タイマーを記述 | 端末全体の電池持ちや、スリープからの復帰の完成度 |
| 文字の入出力 | UARTによるシリアルコンソールを定義し、メモリ上のシェルまで起動したと報告 | 本体画面への表示、タッチ操作、デスクトップ環境 |
| 障害解析 | 再起動後の調査に使うログ用の予約メモリを確保 | 内蔵ストレージから通常のOS環境を起動すること |
| 日常利用に必要な周辺機能 | 今回のDevice Tree変更では、画面・通信・AI処理などの接続定義は追加されていない | カメラ、通話、TPUによるAI処理などの実用動作 |
9月18日の提案と10月5日の取り込み依頼を照らし合わせると、今回の追加内容の中心は端末識別、CPU起動、ログ取得であり、画面、ストレージ、通信、AI処理などを実用的に使える状態になったことまでは確認できない。
この表は、第4版に含まれる端末定義、CPU関連の記述、UART、ログ用メモリを分類し、10月5日の取り込み依頼に含まれる変更一覧と照合したものだ。途中では、Device Treeの検査警告を修正する変更も加えられている。
USBなどについては別の対応提案も存在するため、この表だけを見て、上流Linuxに関連ドライバーが存在しないと判断することはできない。
文字コンソールにも端末側の条件がある。Device TreeではUARTを無効な状態で記述し、コンソールを使う設定にした場合にブートローダーが有効化する。通信速度もブートローダー側で設定する仕組みだ。
また、クラッシュ後の調査に使う「ramoops」の領域や、ブートローダーのログを保存するためのメモリ領域も予約している。これは、起動に失敗した原因を調べながら対応を積み上げていくための準備でもある。
CPUの待機状態が記述されていることも、そのまま電池持ちの改善を意味するわけではない。CPUが休止するための仕組みに加え、画面や周辺回路を含む端末全体が適切に消費電力を抑え、正常に復帰できるかを検証して初めて、スマートフォンとしての省電力性能を評価できる。
差分の扱いをめぐる議論と、ブートローダー側の条件
初期提案は2025年11月にさかのぼる。取り込みに至るまでに変わったのは、対応する機能だけではない。端末ごとの差分をLinuxへどのように渡すかという方法も変更された。
当初は、共通のDevice Treeに機種ごとの差分を重ねる「オーバーレイ」を使っていたが、この方式をめぐって議論が続いていた。
Griffinは2026年7月の第2版でオーバーレイを取り除き、3機種それぞれに個別のファイルを用意する、一般的な上流Linuxの構成へ変更した。9月18日の提案文では、オーバーレイをめぐる問題と、Laguna／Pixel 10の初期対応の取り込みを切り分けたいと説明している。
共通のSoC定義を各機種のファイルから参照する形にすれば、記述の重複を抑えながら、機種ごとの構成を個別に表現できる。
この構成へ改めた第4版について、Kozlowskiは9月29日に4件のパッチを採用したと通知。その後、検査警告の修正を加えた一連の変更が、10月5日にLinux 7.4向けの取り込み依頼として送られた。
メンテナーのツリーへ取り込まれる段階と、Linuxの正式版に統合されてリリースされる段階は同じではない。今回のニュースとして確実に言えるのは、Linux 7.4への統合に向けた取り込み依頼まで進んだという点である。
一方、上流Linuxで受け入れられるDevice Treeの定義と、既存の端末で実際に起動できる定義との間には、互換性上の問題も残っている。
9月18日の提案には、内蔵ストレージ向けのUFSに使う「ufs0」という別名と空のノードを削除したところ、当時のブートローダーが、その別名が存在しないことを致命的なエラーとして扱うという注記がある。
開発者は、新しいブートローダーを待つ間、Linaroのビルド支援ツール「pixelscripts」で必要なノードを補うと説明している。上流側のDevice Treeには不要な記述を残さず、端末側の起動条件に必要な情報をビルド時に加えるという対応だ。
ただし、これは9月18日時点で示された回避策であり、現在もすべての端末で必要かどうかは別途確認する必要がある。また、空のノードを追加できること自体は、UFSを使ったストレージの読み書きが完成したことを意味しない。
Androidのアップデートとは別に、上流Linuxへ対応を積み上げる意味
Androidではすでに、共通カーネルと端末固有の実装を分ける仕組みが整えられている。GoogleのGeneric Kernel Image（GKI）公式説明によると、GKIはAndroid Common Kernelから構築され、SoCや基板固有の機能は、読み込み可能なベンダーモジュールとして分離される。
カーネルとモジュールの接続仕様を安定させ、それぞれを独立して更新しやすくする設計である。
そのため、製品版Androidでハードウェアが動作しているからといって、そのまま素の上流Linuxでも同じ機能が使えるとは限らない。ベンダーモジュールなどが担っている制御を、上流Linuxで利用できるドライバーやハードウェア定義として整備する作業が必要になる。
今回の対応も、Pixel 10のAndroidがLinux 7.4へ更新されるという話ではなく、端末のサポート期間が延長されるという発表でもない。
それでも、追加ドライバーや各種対応を積み上げるための共通の土台が、正式な開発系統へ近づいた意味は大きい。3機種を識別し、起動するための構成を共通の基準として使えるようになれば、その先の対応を周辺機能ごとに進めやすくなる。
オーバーレイをめぐる議論を切り離し、まず初期対応を取り込む判断も、進められる部分から合意を作っていくという開発方針に沿っている。
Pixel 10を上流Linuxで日常的に使える段階まで進めるには、内蔵ストレージからの起動や画面操作に加え、通信機能や省電力動作についても実機で確認する必要がある。端末ごとのブートローダー条件を含め、それらを再現可能な形で確認できるようになれば、開発者はメモリ上の最小検証環境から、継続して使えるOS環境へと作業を進められる。
