我正在做一个类似的项目，所以我需要彻底弄清楚这个问题。我有点搞不清楚谁是对的，因为我看到恩智浦工程师的答案似乎完全错了，但标注为正确的答案却不是恩智浦工程师的。那么，谁的答案是正确的呢？我们倾向于相信恩智浦的工程师更熟悉他们的代码。
https://community.nxp.com/t5/i-MX-Processors/dtsi-for-imx8mm-single-core/td-p/2165973
另外，我还想知道解释。
推荐的方法是从 Linux 设备树中删除相应的节点。
虽然 U-Boot 可以检测芯片型号及其可用功能，但禁用设备树中的节点可确保 Linux 内核不会尝试访问不支持的元器件。这尤其重要，因为帖子中提到的源与U-启动有关，而不是与内核有关。
@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、
我已根据您的具体情况提出了适当的建议。
关于电路板支持包，它正在按预期运行。
请注意，社区对所有成员开放，欢迎他们根据自己的经验做出贡献。欢迎您修改和调整社区开发的解决方案，以更好地满足您的需求。
如果您在使用我们的电路板支持包时遇到任何问题，请随时在论坛中打开新话题，以便我们进一步为您提供帮助。
致以最崇高的敬意，
Chavira
我们已经部署了许多 8MM 产品，并且该代码已经存在了很长时间，一直支持最新的电路板支持包。如果在运行时基于 8MM 熔丝 自动修改设备树时出现问题，那么我们需要考虑升级我们当前的产品。这是一个非常困难的决定，既费时又费钱。
因此，我们需要一个明确的答案：恩智浦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-启动 运行时修改 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 修改 Linux 设备树，而不是修改 u-boot 设备树。
而且 https://github.com/nxp-imx/uboot-imx/blob/lf-5.10.72-2.2.3/arch/arm/mach-imx/imx8m/soc.c 的代码与 启动 fdt 命令的作用相同。
在 u- 启动 运行时修改 Linux 设备树 (dtb) 是使用 u- 启动 命令修改 Linux 设备树。
从第 8 页到第 11 页，可以清楚地看到 u-boot 修改 Linux 设备树并启动到 Linux。
嗨，@hogole、
看来这里有些混乱。
Linux 设备树和 U-Boot 引导设备树是两个不同的实体，每个实体在启动过程中都有不同的用途。你所指的文档专门修改了 U-Boot 引导设备树，而不是 Linux 内核使用的设备树。
请仔细检查您的参考，U-Boot 设备树与 Linux 设备树不同，对其中一个设备树所做的更改不会自动应用于另一个。
有几点我仍然感到困惑。
Chavira，这是你的回复：
1>> U-启动 在运行时不会修改 Linux 设备树。
一旦加载 Linux 内核，U-Boot 就无法再控制设备树了。
你确定 u-boot 无法修改 Linux 设备树吗？
a. u-boot 有 fdt 命令可以修改 Linux 设备树。
您的同事也有这方面的文件。
以下是文档：
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 启动之前还是之后执行的？
我们确实需要恩智浦澄清这些问题，因为这与我们实际运行的项目相关。
能否请您查看一下源代码？
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-启动 检测 SoC 模型以避免使用不可用的资源，例如缺少 CPU 内核、GPU、NPU 等。此检测有助于防止系统在启动期间出现不稳定。
3 > > Linux 设备树对 U-Boot 的源代码或行为没有影响。
每个环境都独立使用自己的设备树。
4 > > t无需修改 U-启动 的源代码即可调整 Linux 使用的内核数量。
U-Boot 充当系统的引导加载程序，包括自动检测机制，以避免使用不可用的外围设备，这有助于防止 SoC 在启动期间出现故障。但是，一旦加载了 Linux 内核，它就完全依赖于设备树来了解哪些硬件资源可用。
如果设备树声明了 4 个 CPU 内核，但硬件只有 1 或 2 个，Linux 将尝试在不存在的内核上初始化和安排任务。这种不匹配可能导致内核慌乱或系统崩溃等严重问题。因此，在启动 Linux 之前，必须确保设备树准确反映实际的硬件配置。
核心配置应直接在传递给 Linux 内核的设备树中处理。
我保存了该页面的快照，以防止像以前那样，回复意外消失。
1.此问题涉及 U-Boot 在运行时修改 Linux 设备树。你提到的启动过程似乎与我们目前正在讨论的话题没有直接关系，对吗？
2。如果 U-Boot 启动代码已经在运行时根据熔丝指示的内核数量自动更新 Linux 设备树，那么为什么还需要在编译时修改设备树呢？
3.如果我们在编译时修改Linux设备树，这会干扰U-Boot根据熔丝设置对核心数量的运行时调整吗？
4。既然恩智浦发布的电路板支持包中的U-Boot代码已经包含了根据熔丝指示的内核数量在运行时自动更新Linux设备树的逻辑，那么为什么恩智浦支持工程师从一开始就没有向我们提及这一点呢？
这是否意味着 U-启动 代码的这一部分可能存在问题？
今天有更新吗？问题的原因找到了吗？为什么我的回复不见了？可以恢复吗？
谢谢
嗨，@hogole、
负责检测芯片型号的 U-启动 代码运行正常，没有任何错误。因此，我们不建议对 U-启动 进行任何修改，因为这些修改是不必要的。
不过，Linux 内核是独立运行的，为确保配置正确，我们建议移除已知无法运行的 CPU 节点。这有助于防止系统出现潜在的错误行为或不稳定性。
在这种情况下，两种方法都是有效的。
请参考以下方框图以了解启动过程：
顺祝商祺！
查维拉
你的回答让我更加困惑。你是说 BSP 中自动检测内核数量的代码是错误的吗？您的意思是我需要修改 DTS 文件以移除核心节点吗？
如果电路板支持包中自动检测内核数量的代码是正确的，恩智浦工程师为什么会建议修改DTS文件以删除核心节点？
哪一个是正确的？
嗨，@hogole、
推荐的方法是从设备树中删除相应的节点。
虽然 U-Boot 可以检测芯片型号及其可用功能，但禁用设备树中的节点可确保 Linux 内核不会尝试访问不支持的元器件。这尤其重要，因为帖子中提到的源与U-启动有关，而不是与内核有关。
请注意，这是一个公共社区，欢迎大家分享自己的经验。不过，我们强烈建议您遵循官方建议，以确保稳定性和兼容性。
致以最崇高的敬意，
Chavira
一周过去了。恩智浦能否考虑回答我的疑问，以便我对目前正在进行的 iMX8MM 项目充满信心？我们需要恩智浦的专业支持。
我相信这个社区的很多人都会同意我的观点。我们都相信恩智浦工程师的回答。如果让我们投票，绝大多数人肯定会考虑恩智浦工程师的答案。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
另外，我还想知道解释。
最终的解释是什么？
最终的解释是什么？
最终的解释是什么？
最后的结论是什么？