Loading article…
コンピューティング において、デバイスツリー（device treeとも表記される）は、特定のコンピュータのハードウェアコンポーネントを記述するデータ構造であり、オペレーティングシステムのカーネルが、 CPU、メモリ、バス、統合周辺機器などのコンポーネントを使用および管理できるようにするものです。
デバイスツリーは、Open Firmwareプロジェクトを通じてSPARCベースおよびPowerPCベースのコンピュータから派生したものです。現在のデバイスツリー仕様[ 1 ] は、小型システムおよび組み込みシステムを対象としていますが、一部のサーバークラスのシステム（例えば、Power Architecture Platform Referenceで説明されているもの）でも使用されています。
x86アーキテクチャのパーソナルコンピュータは、一般的にデバイスツリーを使用せず、代わりに各種自動構成プロトコル（ACPIなど）を使用してハードウェアを検出します。デバイスツリーを使用するシステムは通常、静的デバイスツリー（EEPROMに格納されている場合や、eUFSなどのNANDデバイスに格納されている場合など）をオペレーティングシステムに渡しますが、ブートの初期段階でデバイスツリーを生成することもできます。たとえば、Das U-Bootやkexecは、新しいオペレーティングシステムを起動する際にデバイスツリーを渡すことができます。デバイスツリーをサポートしないブートローダーを備えたシステムでは、オペレーティングシステムとともに静的デバイスツリーがインストールされる場合があります。Linuxカーネルはこのアプローチをサポートしています。
Devicetreeの仕様は現在、 devicetree.orgというコミュニティによって管理されており、このコミュニティはLinaroやArmなどと関連している。
デバイスツリーは、内部的には名前付きノードとプロパティのツリー構造になっているため、あらゆる種類のデータを保持できます。ノードにはプロパティと子ノードが含まれ、プロパティは名前と値のペアです。
デバイスツリーには、オペレーティングシステムが使用するバイナリ形式と、編集や管理を容易にするためのテキスト形式の両方があります。 [ 1 ]
正しいデバイスツリーがあれば、同じコンパイル済みカーネルで、より広いアーキテクチャファミリ内のさまざまなハードウェア構成をサポートできます。ARC 、 ARM 、 C6x 、 H8 /300、MicroBlaze、MIPS、NDS32、Nios II、OpenRISC、PowerPC、Power ISA、RISC-V、SuperH、およびXtensaアーキテクチャ用のLinuxカーネルはデバイスツリー情報を読み取ります。ARMでは、 2012年以降、すべての新しいSoCでデバイスツリーが必須となっています。[ 2 ]これは、これまで（わずかに）異なるARMボードをサポートするために作成されてきた膨大な数のフォーク（LinuxおよびDas U-Boot）に対する解決策と見なすことができます。目的は、ハードウェア記述の大部分をカーネルバイナリからコンパイル済みデバイスツリーブロブに移動することです。このデバイスツリーブロブはブートローダーによってカーネルに渡され、カーネル内のさまざまなボード固有のCソースファイルとコンパイル時オプションを置き換えます。 [ 2 ]
デバイスツリーは、デバイスツリーソースファイル（.dts）で指定され、デバイスツリーコンパイラ（DTC）によってデバイスツリーブロブまたはデバイスツリーバイナリ（.dtb）ファイル（フラット化されたデバイスツリーとも呼ばれる）[ 3 ]にコンパイルされます。デバイスツリーソースファイルには、デバイスツリーソースインクルードと呼ばれる他のファイルを含めることができます。[ 4 ] [ 1 ]
ARMベースのLinuxディストリビューションでは、 Raspberry PiやHackberry A10などの特定のボードに合わせてカスタマイズされたブートローダーが含まれるのが慣例でした。これにより、Linuxディストリビューションの作成者は、オペレーティングシステムの一部をボードのバリアントごとに個別にコンパイルしたり、新しいボードをサポートするために更新したりする必要があるため、問題が生じていました。しかし、一部の最新のSoC（たとえば、Freescale i.MX6）は、デバイスツリーを備えたベンダー提供のブートローダーをオペレーティングシステムとは別のチップに搭載しています。[ 5 ]
同様の目的で使用される独自の構成ファイル形式であるFEXファイル形式[ 6 ]は、 Allwinner SoCの間で事実上の標準となっています。
Devicetreeは、ARMベースのAndroidデバイスで広く使用されています。
Windows はここで説明されているような Devicetree (DTB ファイル) を使用しません。代わりに、ACPIを使用してデバイスを検出および管理します。[ 8 ]
iOS 、iPadOS、およびARM macOSの起動プロセスでは、ローレベルブートローダー（LLB）がAppleによって暗号化されたデバイスツリーをメインメモリにロードし、その後iBootをロードします。
corebootプロジェクトはデバイスツリーを利用していますが、Linuxカーネルで使用されているフラット化されたデバイスツリーとは異なります。[ 9 ]
デバイスツリーソース（DTS）フォーマットの例：
/dts-v1/ ;/ { soc { flash_controller : flash-controller @ 4001e000 { reg = < 0x4001e000 0x1000 > ; flash0 : flash @ 0 { label = "SOC_FLASH" ; erase-block = < 4096 > ; }; }; }; };上記の例では、その行はDTS構文のバージョン1を示しています。/dts-v1/;
このツリーには、/(ルートノード)、 (「システムオンチップ」socを表す) 、(フラッシュコントローラを使用するフラッシュのインスタンス) の 4 つのノードがあります。これらのノード名の他に、後者の 2 つのノードにはそれぞれラベルとが付いています。flash-controller@4001e000flash@0flash_controllerflash0
後者の 2 つのノードには、名前と値のペアを表すプロパティlabelがあります。プロパティは文字列型、プロパティerase-blockは整数型、プロパティは整数の配列 (32 ビット符号なし値) です。プロパティの値は、 phandleregによってデバイスツリー内の他のノードを参照できます。ラベルを持つノードの Phandle はと記述されます。Phandle も 32 ビット値です。flash0&flash0
ノード名の「at」記号（@）以降の部分はユニットアドレスです。ユニットアドレスは、親ノードのアドレス空間におけるノードのリソースアドレスを指定します。
上記のツリーは、標準の DTC コンパイラによってバイナリ DTB フォーマットまたはアセンブリにコンパイルできます。ただし、 Zephyr RTOSでは、DTS ファイルはC ヘッダー ファイル(.h) にコンパイルされ、ビルド システムによって特定のボード用のコードをコンパイルするために使用されます。[ 10 ]
{{cite book}}: CS1メンテナンス: 場所の発行元が見つかりません (リンク){{cite book}}: CS1メンテナンス: 場所の発行元が見つかりません (リンク)