私も同様のプロジェクトに取り組んでいます。SO、この質問を完全に明確にする必要があります。NXP エンジニアの回答は完全に間違っているように見えますが、正解としてマークされているのは NXP エンジニアの回答ではないため、誰が正しいのか少し混乱しています。SO、誰の答えが正しいのでしょうか？私たちは、NXP のエンジニアの方がコードに精通しているだろうと信頼する傾向があります。
https://community.nxp.com/t5/i-MX-Processors/dtsi-for-imx8mm-single-core/td-p/2165973
また、説明も知りたいです。
推奨される方法は、Linux デバイス ツリーから対応するノードを削除することです。
U-Boot はチップ モデルとその利用可能な機能を検出できますが、デバイス ツリー内のノードを無効にすると、Linux カーネルがサポートされていないコンポーネントにアクセスしないようにすることができます。投稿で言及されているソースはカーネルではなく U-Boot に関連しているため、これが特に重要です。
@Chaviraあなたが言ったことを説明してください。
I have provided the appropriate recommendations tailored to your specific case.
Regarding the BSP, it is functioning as expected.1>> U-Boot does not modify the Linux Device Tree at runtime.
Once the Linux kernel is loaded, U-Boot no longer has control over the Device Tree.It seems there's some confusion here.
The Linux device tree and the U-Boot device tree are two distinct entities, each serving different purposes in the boot process. The document you're referring to specifically modifies the U-Boot device tree, not the one used by the Linux kernel.
Please double check your references, the U-Boot device tree is not the same as the Linux device tree, and changes made to one do not automatically apply to the other.こんにちは@hogole 、
あなたの具体的なCASEに合わせた適切な推奨事項を提供しました。
BSPに関しては期待通りに機能しています。
コミュニティは、経験に基づいたすべてのメンバーからの貢献を歓迎します。コミュニティで開発されたソリューションを、ニーズに合わせて変更および適応していただけます。
BSP に関して問題が発生した場合は、お気軽にフォーラムで新しいThreadを開いてください。弊社がさらにサポートさせていただきます。
よろしくお願いします、
チャビラ
当社ではすでに多くの 8MM 製品が導入されており、このコードは長期間存在し、最新の BSP リリースを一貫してサポートしています。8MM ヒューズに基づいて実行時にデバイス ツリーを自動的に変更することに問題がある場合は、現在の製品のアップグレードを検討する必要があります。これは非常に難しい決断であり、時間と費用がかかります。
したがって、明確な答えが必要です。NXP BSP リリースの BSP コードのこの部分には潜在的な問題があるのでしょうか?ヒューズに基づいて Linux デバイス ツリー コア数がこのように自動的に構成される場合でも、コンパイル時に Linux デバイス ツリーを変更する必要があるのはなぜですか?
https://github.com/nxp-imx/uboot-imx/blob/lf-5.10.72-2.2.3/arch/arm/mach-imx/imx8m/soc.c
static int disable_cpu_nodes(void *blob, u32 disabled_cores)
{
static const char * const nodes_path[] = {
"/cpus/cpu@1",
"/cpus/cpu@2",
"/cpus/cpu@3",
};
u32 i = 0;
int rc;
int nodeoff;
if (disabled_cores > 3)
return -EINVAL;
i = 3 - disabled_cores;
for (; i < 3; i++) {
nodeoff = fdt_path_offset(blob, nodes_path[i]);
if (nodeoff < 0)
continue; /* Not found, skip it */
debug("Found %s node\n", nodes_path[i]);
rc = fdt_del_node(blob, nodeoff);
if (rc < 0) {
printf("Unable to delete node %s, err=%s\n",
nodes_path[i], fdt_strerror(rc));
} else {
printf("Delete node %s\n", nodes_path[i]);
}
}これがあなたの提案です:
参照を再確認してください。U-Boot デバイス ツリーは Linux デバイス ツリーと同じではなく、一方に加えた変更が他方に自動的に適用されるわけではありません。
ここで、参照を二重に確認し、別の色を使用して強調表示します。
u-bootランタイムによるLinuxデバイス ツリーの変更 (dtb)
u-boot ランタイムによる Linux デバイス ツリーの変更 (dtb)
https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/u-boot-runtime-modify-Linux-device-tree-...
最初から今まで、u-boot が Linux デバイス ツリーをどのように変更するかについて説明してきましたが、u-boot 自体のデバイス ツリーについてはまったく説明していませんでした。
次のコードでも、u-boot を使用して Linux デバイス ツリーを変更します。
https://github.com/nxp-imx/uboot-imx/blob/lf-5.10.72-2.2.3/arch/arm/mach-imx/imx8m/soc.c
static int disable_cpu_nodes(void *blob, u32 disabled_cores)
{
static const char * const nodes_path[] = {
"/cpus/cpu@1",
"/cpus/cpu@2",
"/cpus/cpu@3",
};
u32 i = 0;
int rc;
int nodeoff;
if (disabled_cores > 3)
return -EINVAL;
i = 3 - disabled_cores;
for (; i < 3; i++) {
nodeoff = fdt_path_offset(blob, nodes_path[i]);
if (nodeoff < 0)
continue; /* Not found, skip it */
debug("Found %s node\n", nodes_path[i]);
rc = fdt_del_node(blob, nodeoff);
if (rc < 0) {
printf("Unable to delete node %s, err=%s\n",
nodes_path[i], fdt_strerror(rc));
} else {
printf("Delete node %s\n", nodes_path[i]);
}
}もう一度強調しますが、私は u-boot のデバイス ツリーについて一度も説明していません。
ここでは、u-boot デバイス ツリーの変更ではなく、u-boot による Linux デバイス ツリーの変更について説明します。
また、コードhttps://github.com/nxp-imx/uboot-imx/blob/lf-5.10.72-2.2.3/arch/arm/mach-imx/imx8m/soc.cは、u-boot fdt コマンドと同じことを行います。
u-boot ランタイムでは、Linux デバイス ツリー (dtb) を変更するために u-boot コマンドを使用して Linux デバイス ツリーを変更します。
8 ページから 11 ページにかけて、u-boot が Linux デバイス ツリーを変更し、Linux を起動することが明確に示されています。
こんにちは@hogole 、
ここで混乱が生じているようです。
Linux デバイス ツリーと U-Boot デバイス ツリーは 2 つの異なるエンティティであり、それぞれブート プロセスで異なる目的を果たします。あなたが参照しているドキュメントは、Linux カーネルで使用されるものではなく、U-Boot デバイス ツリーを具体的に変更するものです。
参照を再確認してください。U-Boot デバイス ツリーは Linux デバイス ツリーと同じではなく、一方に加えた変更が他方に自動的に適用されるわけではありません。
まだ混乱している点がいくつかあります。
チャビラさん、これがあなたの返事です:
1>> U-Boot は実行時に Linux デバイス ツリーを変更しません。
Linux カーネルがロードされると、U-Boot はデバイス ツリーを制御できなくなります。
u-boot が Linux デバイス ツリーを変更できないのは確かですか?
a. u-boot には、Linux デバイス ツリーを変更できる fdt コマンドがあります。
あなたの同僚もこれに関するドキュメントを持っています。
ここにその文書があります:
u-boot ランタイムによる Linux デバイス ツリーの変更 (dtb)
https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/u-boot-runtime-modify-Linux-device-tree-...
b. arch/arm/mach-imx/imx8m/soc.c は、u-boot fdt コマンドと同じ API を使用します。
c. u-boot は Linux ランタイム環境を準備するものですよね？ Linux デバイスツリーの変更を含むすべての操作は、Linux が起動する前に実行する必要があります。
u-boot が Linux デバイスをロードした後、Linux がまだ起動していない場合、Linux デバイス ツリーを変更することはできませんか?
最も簡単な質問は、「disable_cpu_nodes」API 関数は Linux の起動前ですか、それとも起動後ですか?
これらの問題は私たちが実際に実行しているプロジェクトに関係するため、NXP からの説明が本当に必要です。
ソースコードを確認していただけますか?
https://github.com/nxp-imx/uboot-imx/blob/lf-5.10.72-2.2.3/arch/arm/mach-imx/imx8m/soc.c
ここでのconst nodes_pathは Linux デバイス ツリー ノードですか?
static int disable_cpu_nodes(void *blob, u32 disabled_cores)
{
static const char * const nodes_path[] = {
"/cpus/cpu@1",
"/cpus/cpu@2",
"/cpus/cpu@3",
};
u32 i = 0;
int rc;
int nodeoff;
if (disabled_cores > 3)
return -EINVAL;
i = 3 - disabled_cores;
for (; i < 3; i++) {
nodeoff = fdt_path_offset(blob, nodes_path[i]);
if (nodeoff < 0)
continue; /* Not found, skip it */
debug("Found %s node\n", nodes_path[i]);
rc = fdt_del_node(blob, nodeoff);
if (rc < 0) {
printf("Unable to delete node %s, err=%s\n",
nodes_path[i], fdt_strerror(rc));
} else {
printf("Delete node %s\n", nodes_path[i]);
}
}
こんにちは@hogole 、
1>> U-Boot は実行時に Linux デバイス ツリーを変更しません。
Linux カーネルがロードされると、U-Boot はデバイス ツリーを制御できなくなります。
2>> U-Boot は SoC モデルを検出し、不足している CPU コア、GPU、NPU などの使用できないリソースの使用を回避します。この検出は、起動時のシステムの不安定性を防ぐのに役立ちます。
3>> Linux デバイス ツリーは、U-Boot のソース コードや動作に影響を与えません。
各環境は独自のデバイス ツリーを独立して使用します。
4>> Linux が使用するコアの数を調整するために、U-Boot のソースコードを変更する必要はありません。
U-Boot はシステムのブートローダーとして機能し、使用できないペリフェラルの使用を回避するための自動検出メカニズムを備えているため、ブート中の SoC の誤動作を防ぐのに役立ちます。ただし、Linux カーネルがロードされると、利用可能なハードウェア リソースを把握するためにデバイス ツリーに完全に依存します。
デバイス ツリーで 4 つの CPU コアが宣言されているが、ハードウェアには 1 つまたは 2 つしかない場合、Linux は存在しないコアでタスクを初期化してスケジュールしようとします。この不一致は、カーネル パニックやシステム クラッシュなどの深刻な問題を引き起こすCANがあります。したがって、Linux を起動する前に、デバイス ツリーが実際のハードウェア構成を正確に反映していることを確認することが重要です。
コア構成は、Linux カーネルに渡されるデバイス ツリーで直接処理する必要があります。
以前のように応答が予期せず消えてしまうことを防ぐために、このページのスナップショットを保存しました。
1.この問題は、U-Boot が実行時に Linux デバイス ツリーを変更することに関係しています。あなたが言及したブートプロセスは、現在議論しているトピックとは直接関係していないようですね。
2. U-Boot コードが、ヒューズによって示されたコアの数に基づいて実行時に Linux デバイス ツリーを既に自動的に更新している場合、コンパイル時にデバイス ツリーを変更する必要があるのはなぜですか?
3.コンパイル時に Linux デバイス ツリーを変更すると、U-Boot によるヒューズ設定に基づくコア数のランタイム調整が妨げられる可能性がありますか?
4. NXP がリリースした BSP の U-Boot コードには、ヒューズによって示されたコア数に応じて実行時に Linux デバイス ツリーを自動的に更新するロジックがすでに含まれているのに、なぜ NXP のサポート エンジニアは最初からこのことを私たちに伝えなかったのでしょうか。
これは、U-Boot コードのその部分に問題がある可能性があることを意味していますか?
今日は何かアップデートはありますか？問題の原因は見つかりましたか?私の返信が消えたのはなぜですか?CAN復元できますか？
ありがとう
こんにちは@hogole 、
チップ モデルの検出を担当する U-Boot コードは正常に機能しており、エラーは発生しません。したがって、U-Boot に変更を加えることは不要であるため、お勧めしません。
ただし、Linux カーネルは独立して動作するため、適切な構成を確保するために、機能していないことがわかっている CPU ノードを削除することをお勧めします。これにより、システムの潜在的な誤動作や不安定性を防ぐことができます。
このCASE、両方のアプローチが有効です。
ブートプロセスを理解するには、次のブロック図を参照してください。
よろしくお願いいたします。
チャビラ
あなたの答えは私をさらに混乱させました。コアの数を自動検出する BSP のコードが間違っているということでしょうか?コアノードを削除するには、DTS ファイルを変更する必要があるということですか?
コアの数を自動的に検出する BSP のコードが正しいのなら、なぜ NXP のエンジニアは DTS ファイルを変更してコア ノードを削除することを推奨するのでしょうか?
どちらが正しいでしょうか？
こんにちは@hogole 、
推奨される方法は、デバイス ツリーから対応するノードを削除することです。
U-Boot はチップ モデルとその利用可能な機能を検出できますが、デバイス ツリー内のノードを無効にすると、Linux カーネルがサポートされていないコンポーネントにアクセスしないようにすることができます。投稿で言及されているソースはカーネルではなく U-Boot に関連しているため、これが特に重要です。
これは誰でも自分の経験を共有できる公開コミュニティであることをご留意ください。ただし、安定性と互換性を確保するために、公式の推奨事項に従うことを強くお勧めします。
よろしくお願いします、
チャビラ
一週間が経ちました。現在取り組んでいる iMX8MM プロジェクトに自信を持てるよう、NXP は私の疑問に答えることを検討していただけますか?NXP の専門的なサポートが必要です。
このコミュニティの多くの人が私に同意してくれると信じています。私たちは皆、NXP エンジニアの回答を信じています。投票するなら、大多数の人は間違いなく NXP エンジニアの回答を考慮するでしょう。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
また、説明も知りたいです。
最終的な説明は何ですか？
最終的な説明は何ですか？
最終的な説明は何ですか？
最終的な結論は何ですか？