2395297_ja-JP

Yes

Android 16:なぜNXPはvendor_bootでデバイスツリーを処理する独自の方法を考案したのか

Android 16 1.4.0リリースに含まれていた最後のu-bootブートローダーを調べたところ、設定オプション「CONFIG_INCLUDE_DTB_TO_VENDOR_BOOT」がブートローダーに追加されていることがわかりました。

古いAndroidバージョンでは「dtbo」パーティションを使ってメインデバイスツリーを保存していたという問題が解決すると思っていました。私の理解ではそれは間違いでした。なぜなら、メインデバイスツリーは「vendor_boot」パーティション(少なくともvendor_boot v4では)に配置されるべきで、DTBOパーティションはデバイスツリーのオーバーレイで埋められ、それをメインデバイスツリーに適用してハードウェアバリアントをサポートするからです。

S32デバッグ・プローブのセットアップの詳細については、

https://source.android.com/docs/core/architecture/partitions/vendor-boot-partitions

文書化されているように、vendor_boot 内には 1 つのデバイスツリーのみが存在する必要があります。

しかし現在、NXPは「dtbo」パーティションを廃止し、vendor_boot内の「dt_table_header」構造体を使用して、複数の完全なデバイスツリーをvendor_bootに直接追加する実装を行っています。このヘッダーは通常、「dtbo」パーティション内で複数のデバイスツリーオーバーレイを整理するために使用されますが、「vendor_boot」内では使用されません。

このNXP特有のデバイスツリー処理方法は、DTBOからのメインデバイスツリーとデバイスツリーオーバーレイを使った標準的なAndroid方法と矛盾しています。これにより、デバイスツリーオーバーレイの概念を使ってAndroidポートを維持するユーザー(私のような)にとっては難しいです。

NXPはなぜデバイスツリーのバリアントをそのような方法で実装することを選んだのでしょうか？

この挙動をAndroidで記録されているやり方に戻す予定はありますか?

Android

Re: Android 16: Why has NXP invented an own way to handle device trees in vendor_boot

こんにちは、

Androidでは複数のデバイスツリーは必須ではありませんので、OSのアーキテクチャに必須の変更がない限り、これまで多くのバージョンでデフォルトとなっているため、BSPの提供方法に変化はないと思います。

また、デバイスツリーを選択するには、ブートローダーが以下のことを行う必要があることに注意してください。

1> SoCを識別し、対応する.dtbファイルをロードします。ストレージからメモリへ。
2> ボードを識別し、対応する.dtboファイルをロードします。ストレージからメモリへ。
3> .dtb を重ね合わせる.dtbo はマージされた DT になります。
4> マージされたDTのメモリアドレスを指定してカーネルを開始します。

そのため、同じハードウェアを使用し、異なる実装/デモンストレーションのためにわずかな変更を加えるだけなので、どちらのデバイスツリーを使用すべきかを識別する方法がありません。同じSOM（同じ基本構成のSoC+DDR+電源IC）を使用しながら異なるハードウェアを扱っている場合にのみ、これが役立つと思います。つまり、これは私たちの作業・ソフトウェアの提供方法に合わず、追加してもメリットが見当たりません。

よろしくお願いいたします。
アルド。