iMX8 Nano Kernel updation from 5.15 to 6.18 Hi While porting the kernel from 5.15 to 6.18 for the A53 core. facing an issue with rpmsg. # dmesg -T | grep -Ei 'rpmsg|rproc' [Tue Oct 8 15:42:28 2024] imx rpmsg driver is registered. [Tue Oct 8 15:42:29 2024] imx-rproc imx8mn-cm7: error -ENOENT: Failed to enable clock [Tue Oct 8 15:42:29 2024] imx-rproc imx8mn-cm7: probe with driver imx-rproc failed with error -2 [Tue Oct 8 15:42:29 2024] remoteproc remoteproc0: releasing imx-rproc I am getting this error.When i searched this error online i was asked to add dummy clock in the dts as below imx8mn-cm7 { compatible = "fsl,imx8mn-cm7"; rsc-da = <0xb8000000>; clocks = <&clk IMX8MN_CLK_DUMMY>; mbox-names = "tx", "rx", "rxdb"; mboxes = <μ 0 1 μ 1 1 μ 3 1>; memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>; status = "okay"; } Could u please let me is this the only the change required. What is the reason for this change. Regards Yadunath R Re: iMX8 Nano Kernel updation from 5.15 to 6.18 No — I would not treat clocks = <&clk IMX8MN_CLK_DUMMY>; as the only required change. It may be enough to get past the immediate -ENOENT: Failed to enable clock probe failure, but for i.MX8M Nano the important requirement is that the Cortex-M7 root clock must remain enabled when Linux loads/starts the M7 firmware.
Reason:
The imx-rproc node is expected to have a clock entry; AN5317 shows the i.MX8M remoteproc DTS node with compatible = "fsl,imx8mn-cm7" and a clocks = <...> property, plus mailbox and memory-region entries.
Your error means the kernel 6.18 imx-rproc driver tried to get/enable the clock from that node and the clock lookup failed with -ENOENT , so probe aborted before remoteproc0 stayed registered.
NXP’s AMP guidance says: “For i.MX 8M platforms, the root clock for M7/M4 must be kept always enabled by Linux to load the firmware code and start Cortex M7/M4.” It also says NXP Linux BSP keeps this root clock enabled when the M core is started from U-Boot; otherwise, if the M core is first started from Linux boot, drivers/clk/imx/clk-composite-8m.c must be updated to skip gate registration for the M core clock.
So the change has two possible meanings:
Dummy clock as compatibility workaround If kernel 6.18 imx-rproc requires a clocks property but the real M7 clock is intentionally not controlled through common clock framework, adding IMX8MN_CLK_DUMMY can satisfy the driver’s clock handle requirement and avoid -ENOENT .
Real clock-control fix If Linux is actually responsible for loading/starting the M7, a dummy clock alone may hide the probe error but not guarantee the M7 clock is enabled. In that case you must ensure the M7/M4 root clock is kept on, either by the NXP BSP clock-driver handling or by the clk-composite-8m.c change described in AN5317.
Also verify the rest of the remoteproc/rpmsg DTS, not only the clock line:
imx8mn-cm7 {
compatible = "fsl,imx8mn-cm7";
rsc-da = <...>;
clocks = <&clk IMX8MN_CLK_DUMMY>; /* or the correct M7 clock used by your BSP */
mbox-names = "tx", "rx", "rxdb";
mboxes = <μ 0 1>, <μ 1 1>, <μ 3 1>;
memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;
status = "okay";
};
The memory-region list is important because AN5317 states that this property must contain the memory sections used by the firmware ELF so remoteproc can reload it from sysfs.
Recommended check path:
If you start M7 from U-Boot , use the NXP flow such as prepare_mcore / bootaux , then boot Linux; AN5317 says this is the path where the BSP keeps the M core root clock enabled.
If you start M7 from Linux remoteproc , confirm your 6.18 clock driver includes the NXP handling to keep the M core root clock always enabled; otherwise the dummy clock may only fix probe, not runtime start/load.
Compare your DTS against the NXP imx8mn-*-rpmsg.dts for the same BSP release, especially clocks , mboxes , rsc-da , and reserved-memory layout.
The dummy clock explains the immediate -ENOENT probe failure, but the real design requirement is to keep the i.MX8MN M7 root clock enabled; whether DTS alone is sufficient depends on whether your 6.18 BSP clock driver already preserves that clock.
查看全文
