A little confused about dtsi for imx8mm single core

[hogole]

I'm working on a similar project, so I need to get this question completely clarified. I'm a little confused about who's right, because I see the NXP engineer's answer seems completely wrong, but the one marked as correct isn't from the NXP engineer. So, whose answer is correct? We tend to trust the NXP engineers to be more familiar with their code.

https://community.nxp.com/t5/i-MX-Processors/dtsi-for-imx8mm-single-core/td-p/2165973

[lucindaschatz]

thhhhhhhhhanks

[hogole]

I believe many people in this community would agree with me. We all trust the NXP engineer's answer. If we were to vote, the vast majority would definitely consider the NXP engineer's answer.

[hogole]

A week has passed. Could NXP consider responding to my doubts so that I can have confidence in the iMX8MM project I am currently working on? We need NXP's professional support.

[Chavira]

Hi @hogole,

The recommended approach is to delete the corresponding nodes from the device tree.
While U-Boot can detect the chip model and its available features, disabling the nodes in the device tree ensures that the Linux kernel does not attempt to access unsupported components. This is especially important since the sources mentioned in the post are related to U-Boot, not the kernel.

Please note that this is a public community where everyone is welcome to share their experiences. However, we strongly encourage following the official recommendations to ensure stability and compatibility.

Best regards,
Chavira

[hogole]

Your answer has left me even more confused. Are you saying that the code in the BSP that automatically detects the number of cores is wrong? Do you mean that I need to modify the DTS file to remove the core nodes?

If the code in the BSP that automatically detects the number of cores is correct, why would NXP engineers recommend modifying the DTS file to remove the core nodes?

Which one is correct?

[Chavira]

Hi @hogole,

The U-Boot code responsible for detecting the chip model is functioning correctly and does not exhibit any errors. Therefore, we do not recommend making any modifications to U-Boot, as they are unnecessary.

However, the Linux Kernel operates independently, and to ensure proper configuration, we recommend removing the CPU nodes that are known to be non functional. This helps prevent potential misbehavior or instability in your system.
In this case, both approaches are valid.

Please refer to this block diagram to understand the boot process:

Best Regards,

Chavira

[hogole]

Why did my post disappear? Could the community administrator please check what the issue is?

[hogole]

Are there any updates today? Have you found the cause of the problem? Why did my reply disappear? Can it be restored?

[hogole]

@Chavira 

1. This issue concerns U-Boot modifying the Linux device tree at runtime. The boot process you mentioned doesn’t seem directly related to the topic we’re currently discussing, does it?
2. If the U-Boot code already automatically updates the Linux device tree at runtime based on the number of cores indicated by the fuse, then why is it still necessary to modify the device tree at compile time?
3. If we modify the Linux device tree at compile time, could that interfere with U-Boot’s runtime adjustment of the core count based on the fuse settings?
4. Since the U-Boot code in NXP’s released BSP already includes logic to automatically update the Linux device tree at runtime according to the number of cores indicated by the fuse, why didn’t the NXP support engineer mention this to us from the start?
Does this imply there might be an issue with that part of the U-Boot code?

[Chavira]

HI @hogole,

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.

2>> U-Boot detects the SoC model to avoid using unavailable resources, such as missing CPU cores, GPU, NPU, etc. This detection helps prevent system instability during boot.

3>> The Linux Device Tree has no impact on U-Boot’s source code or behavior.
Each environment uses its own Device Tree independently.

4>> TThere’s no need to modify U-Boot’s source code to adjust the number of cores used by Linux.

U-Boot functions as the system’s bootloader and includes automatic detection mechanisms to avoid using unavailable peripherals, which helps prevent SoC malfunctions during boot. However, once the Linux kernel is loaded, it relies entirely on the Device Tree to understand which hardware resources are available.

If the Device Tree declares 4 CPU cores but the hardware only has 1 or 2, Linux will attempt to initialize and schedule tasks on non-existent cores. This mismatch can lead to serious issues such as a kernel panic or system crash. Therefore, it’s essential to ensure that the Device Tree accurately reflects the actual hardware configuration before booting Linux.
Core configuration should be handled directly in the Device Tree passed to the Linux kernel.

[hogole]

There are a few points that I am still confused about.

Chavira, this is your reply:
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.

Are you sure u-boot can't modify the Linux device tree?

a. u-boot has the fdt command that can modify the Linux device tree.
Your colleague also has documentation on this.
Here is the document:
u-boot runtime modify Linux device tree (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 uses the same API as the u-boot fdt command.
c. Isn't u-boot supposed to prepare the Linux runtime environment? Any operations, including modifying the Linux device tree, must occur before Linux boots.
After u-boot loads a Linux device, but Linux hasn't booted yet, can't it modify the Linux device tree?
The simplest question is: Isn the "disable_cpu_nodes" API function before or after Linux boots?

We really need clarification from NXP on these issues as this is relevant to the projects we are actually running.

Could you please review the source code?
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 here is Linux device tree node or not?

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]

@Chavira 

We already have many 8MM products deployed, and this code has existed for a long time, consistently supporting the latest BSP release. If there are issues with automatically modifying the device tree at runtime based on the 8MM fuse, then we need to consider upgrading our current products. This is a very difficult decision, both time-consuming and costly.

Therefore, we need a clear answer: Does this part of the BSP code in the NXP BSP release have any potential problems? Why, with this automatic configuration of the Linux device tree core count based on the fuse, is it still necessary to modify the Linux device tree at compile time?

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]);
		}
	}

[Chavira]

Hi @hogole,

I have provided the appropriate recommendations tailored to your specific case.
Regarding the BSP, it is functioning as expected.

Please note that the community is open to contributions from all members based on their experience. You are welcome to modify and adapt community-developed solutions to better suit your needs.

If you encounter any issues with our BSP, feel free to open a new thread in the forum so we can assist you further.

Best regards,
Chavira

[kawateb265]

@Chavira Please explain what you said.

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]

Also, I want to know the explaination.

[Chavira]

The recommended approach is to delete the corresponding nodes from the Linux device tree.

While U-Boot can detect the chip model and its available features, disabling the nodes in the device tree ensures that the Linux kernel does not attempt to access unsupported components. This is especially important since the sources mentioned in the post are related to U-Boot, not the kernel.

[Chavira]

Hi @hogole,

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 

This is your suggestion:

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.

Now I double check the reference and using different color to highlight:

u-boot runtime modify Linux device tree (dtb)

u-boot runtime modify Linux device tree (dtb)
https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/u-boot-runtime-modify-Linux-device-tree-...

[hogole]

@Chavira 

We discussing the u-boot modify the Linux device tree, not modify u-boot device tree.

And the code https://github.com/nxp-imx/uboot-imx/blob/lf-5.10.72-2.2.3/arch/arm/mach-imx/imx8m/soc.cdoes the same as u-boot fdt command does.

In the u-boot runtime modify Linux device tree (dtb) is using u-boot command to modify the Linux device tree. 

https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/u-boot-runtime-modify-Linux-device-tree-...

From page 8 to 11, It is clear shows the u-boot modify the Linux device tree and boot into Linux.

[hogole]

@Chavira 

From the beginning to now, we have been discussing how u-boot modifies the Linux device tree, and have never discussed the device tree of u-boot itself.

The following code also uses u-boot to modify the Linux device tree.

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]);
		}
	}

I emphasize again that I have never discussed the device tree of u-boot.