CM4 LPUART makes Core M4 stop working when kernel starts running on Colibri IMX8X

Hi there,

I’m working with a custom carrier board with almost all UART ports accessible. There are four ADMA subsystem UARTs plus the correspondant to Cortex M4 core.

I have developing code using JTAG debugging through a Segger J-link, using CM4 UART as logging.

Now I have to start working in A35, and when kernel starts, the code from M4 core stops running.

When I started with IMX8 time ago, I had the same issue with ADMA UARTS, and I managed to solved it recompiling the device tree source.

Since there is no trace of CM4 UART in device tree files, I’m not sure how to perform this operation and I feel a little lost.

I have digged more, in case the any of the pins were shared and could enter in conflict with other peripheral. But there is only a mention in “imx8x-colibri.dtsi” to one of these pins.

Any idea where I can investigate further?

I have a suspicion and some worries about this problem may come from the system image itself, specifically something related to the SCU firmware.

It’s pretty critical that I be able to use all ports in my development, so any help would be very appreciated.

Here is more info of my setup…

Model: Toradex Colibri iMX8 QuadXPlus 2GB Wi-Fi / BT IT V1.0D, Serial# 06899692
Loading DeviceTree: imx8qxp-colibri-eval-v3.dtb
Linux colibri-imx8x-06899692 5.4.129-5.4.0+git.cb88cc157bfb #1 SMP PREEMPT Wed Sep 29 18:17:21 UTC 2021 aarch64 GNU/Linux

Thank you in advace

It’s been a week and still no response… Please… Come on…

I’ve done more researching by my own, but I can’t achieved to make it work.

Pins used for M4 UART are SC_P_SCU_GPIO0_00 and SC_P_SCU_GPIO0_01 respectively, according to Toradex Pinout Designer. My assumption is that the conflict lies there, more than with the UART itself.

Since SCU Firmware seems to organize the hardware in partitions assigning usage priorities, I have digged more in that. I’ve tried to compile it with modifications, but I could not understand well how it is possible to obtain what I want.

My purpose is to keep blocked SC_P_SCU_GPIO0_00 and SC_P_SCU_GPIO0_01 only for M4 Core UART use. In such a way that they cannot be used by the A35 or other one in any way.

In theory, in “board.c” file of SCW sources it can be created a “MCU0” partition for the M4 core. I think it can be done by changing “alt_config” to “SC_TRUE”.

By default there is this:

static const sc_pad_t pad_list[8U] =

That it is used as argument of this instruction:

/* Create partition */
BRD_ERR(rm_partition_create(pt_boot, &pt_m4_0, SC_FALSE,
rsrc_list, ARRAY_SIZE(rsrc_list),
pad_list, ARRAY_SIZE(pad_list),
mem_list, ARRAY_SIZE(mem_list)));

SC_P_ADC_IN1 and SC_P_ADC_IN2, are also used to map M40_UART. I’ve changed this, but again, when linux kernel starts, M4 stops working.

My objective is to use M40_UART for debuging , while code is running in both M4 and A35.

Seriusly, please, help.

Hi @Eduardo,

I haven’t tried any iMX8 yet, but from VF61 and iMX7D experience, there’s a number of ways Linux may break Cortex-M and Cortex-M may break Linux.

IMO it is less likely SCU than Linux, which is just switching off unused clocks. If adding clk_ignore_unused to U-Boot defargs variable doesn’t help, then still there could be something like eCSPI (not sure if you have it), which driver enables bunch of clocks (all “unused” parent clocks) before transfer and disables the same bunch of clocks after transfer. This was the case on iMX7D. Perhaps you have something like this on iMX8M. Please inspect /sys/kernel/debug/clk/clk_summary, perhaps your parent clock of Cortex-M gets disabled. Then you should look for which modules have common parent clocks… Hmm, no direct route from here, but you have an idea.

Do you have any means to start your Cortex-M FW after Linux boots? imxfwloader? remoteproc? Chances are, it could run happily booting after Linux.


Hi @Edward,

No luck with the argument “clk_ignore_unused”

I’m very interested in know how to start Cortex-M FW after Linux. Do you know how can I get information? Maybe it will be useful for other purposes too.

I’ll investigate a little more about any possible clock conflict.
[EDIT] File “/sys/kernel/debug/clk/clk_summary” is empty.

You could reproduce this issue very easy and quick, since I’m only using Hello World test example provided by NXP, adapting only the mentioned pins. They are accessible in Colibri Evaluation board for example.

In the other side Colibri-iMX8X_Reference-Minimal-Image-Tezi_5.4.0+build.11 is used as it comes, without any modification.

Thank you for your response. I look forward to hearing what you can find out.

I’ve research a little more, without success…

It is supposed to use NXP examples with MEK board, so I tried to understand what are the differences between your device tree and their.

There is a definition file called “imx8-ss-cm40.dtsi” which is included both, and have the information of CM4 resources. About that information it seems that the UART clock source is specific (assigned clocks, right?), I’m not sure it would be shared with another peripheral at all.

“cm40_lpuart” is only used in some “imx8dxl-evk” sources.

I tried to define an aditional Uart in device tree, with information given, and then “disable” it. After trying that “dtb”, behavior is still the same, Kernel starts and CM4 freezes…

Hope you can shed light on this soon.

I don’t know why clk_summary is empty. Is it missing or empty. This my first google result suggests enabling CONFIG_DEBUG_FS. So try checking with

zcat /proc/config.gz | grep CONFIG_DEBUG_FS

Indeed imx-m4fwloader seems not supporting iMX8.
GitHub - NXPmicro/imx-m4fwloader: Tool for loading firmware to M4 core on i.MX6SX and 7D

Linux CONFIG_IMX_REMOTEPROC driver imx_rproc.c seems supporting your variant and should allow launching Cortex-M after Linux boots, either automatically or by issuing command via SYSFS, auto or not is controlled via device tree. Here list of compatibles:

	{ .compatible = "fsl,imx7ulp-cm4", .data = &imx_rproc_cfg_imx7ulp },
	{ .compatible = "fsl,imx7d-cm4", .data = &imx_rproc_cfg_imx7d },
	{ .compatible = "fsl,imx6sx-cm4", .data = &imx_rproc_cfg_imx6sx },
	{ .compatible = "fsl,imx8mq-cm4", .data = &imx_rproc_cfg_imx8mq },
	{ .compatible = "fsl,imx8mm-cm4", .data = &imx_rproc_cfg_imx8mq },
	{ .compatible = "fsl,imx8mn-cm7", .data = &imx_rproc_cfg_imx8mn },
	{ .compatible = "fsl,imx8mp-cm7", .data = &imx_rproc_cfg_imx8mn },
	{ .compatible = "fsl,imx8qxp-cm4", .data = &imx_rproc_cfg_imx8qxp },
	{ .compatible = "fsl,imx8qm-cm4", .data = &imx_rproc_cfg_imx8qm },

Looking for files in /arch/arm64/boot/dts/freescale , containing substring “-cm” reveals several examples for device tree. You need to add status = "okay" to them and if things go well, then ls /sys/class/remoteproc should least at least one non empty directory. If it is, then you write your FW ELF file to /lib/firmware, specify FW file name via /sys/class/remoteproc/remoteproc0/firmware and launch FW with echo start > /sys/class/remoteproc/remoteproc0/state

Something like ^^ this is specified there
IMX8MMEVK: Remoteproc to reboot M4 from Linux - NXP Community

I see some issues with remoteproc, not sure is it GCC fault or remoteproc_elf_loader.c, they clearly disagree about ELF filesz and memsz properties, but there should be no problems launching small firmwares with remoteproc. Just try it. There are two very nice things about remoteproc. 1. You can assign clock to your Cortex M via DT and Linux won’t switch it off. 2. You may start / stop and choose another Cortex-M FW without rebooting whole Linux.


Adding cm40_lpuart and disabling it is the same like not adding it at all. Enabling it as I understand would trigger Linux driver for that lpuart. What does that driver do? Is it just marking those assigned-clocks as used and not touching lpuart registers at all, so that you are safe using this lpuart instance from CM4/7? That could be helpful, but I don’t know what that driver does. Speaking about clocks I mean Cortex-M source clock. Linux may shut down Cortex-M clock just because it is “not used”.

Before start my questions, device tree sources for “imx8qxp-colibri-eval-v3.dtb” are fundamentally these:

  • imx8qxp-colibri-eval-v3.dts

  • imx8x-colibri-eval-v3.dtsi

  • imx8qxp-colibri.dtsi

  • imx8x-colibri.dtsi

  • imx8qxp.dtsi

Please, correct me if I’m wrong.

clk_summary info.txt (33.7 KB)
I’ve attached the information given by clk_summary.

There is only this mentions to CM4.

                                 enable  prepare  protect                                duty
   clock                          count    count    count        rate   accuracy phase  cycle
cm40_i2c_div                         0        0        0           0          0     0  50000
   cm40_lpcg_i2c_clk                 0        0        0           0          0     0  50000
cm40_ipg_clk                         0        0        0   132000000          0     0  50000
   cm40_lpcg_i2c_ipg_clk             0        0        0   132000000          0     0  50000

¿Is there any mention in device tree sources about this? I can find it.

I tried to understand how are configured the ADMA UARTS also.

For example, we have this for UART0:

   uart0_lpcg_ipg_clk                0        0        0   160000000          0     0  50000
uart0_clk                            0        0        0    80000000          0     0  50000
   uart0_lpcg_baud_clk               0        0        0    80000000          0     0  50000

The only I’ve found this…


&lpuart0 {
	status = "okay";


&lpuart0 {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_lpuart0>;
pinctrl_lpuart0: lpuart0grp {
			fsl,pins = <
				IMX8QXP_UART0_RX_ADMA_UART0_RX			0x06000020	/* SODIMM  36 */
				IMX8QXP_UART0_TX_ADMA_UART0_TX			0x06000020	/* SODIMM  38 */
				IMX8QXP_FLEXCAN0_RX_ADMA_UART0_RTS_B		0x06000020	/* SODIMM  34 */
				IMX8QXP_FLEXCAN0_TX_ADMA_UART0_CTS_B		0x06000020	/* SODIMM  32 */


	aliases {
		serial0 = &lpuart0;

And this is it. Nothing else apparently.

The only mention to the clock used by this uart, is in “imx8-ss-dma.dtsi”. As it was for CM4 UART in “imx8-ss-cm40.dtsi”

¿Why ADMA UART clocks are visible and why CM4 clock aren’t? I followed the same steps in order I could make CM4_UART clock working enabling this UART in linux only for understanding, but didn’t worked.

In file “imx8qxp.dtsi” there is a mention to which seems to be the primary clock sources.

clk: clock-controller {
			compatible = "fsl,imx8qxp-clk", "fsl,scu-clk";
			#clock-cells = <2>;
			clocks = <&xtal32k &xtal24m>;
			clock-names = "xtal_32KHz", "xtal_24Mhz";

I can’t follow more clues about clock sources are activated in device tree structure. Because of this, come to my mind more questions.

¿Are you sure that the issue lies in device tree configuration? I maintain some suspects about hardware partitioning made by SCU

¿Are you aware if someone has used M4UART with Colibri IMX8 before?

I really beg you to reproduce this issue from your side. I’m pretty sure that you can determine more quickly what is happenning.

I am running out of time and it is essential that I be able to use all the available UARTs of the Colibri IMX8. There aren’t so much sense that this will be possible by hardware, since you have routed to SODIMM pins and then it won’t be able using Linux on A35 side.

Thank you very much for the indications of how can be loaded M4 firmware from A35 side. I will investigate further about that topics. And if I can, I will try to run M4 firmware like that to check if M4_UART works. But please, take in consideration that is not a real solution to my main problem.

I look forward to more information, @Edward. Thank you.

Hi Eduardo

Well, iMX8X clk_summary is more cryptic and less informative than I expected. At one hand iMX8X clocking seems being less nested, perhaps this is why they removed parent clock slices etc from clk_summary making it more clean, but it makes it much more less informative. Like you I don’t see CM4 (root) clock mentioned, so clk_summary won’t help.

¿Are you sure that the issue lies in device tree configuration? I maintain some suspects about hardware partitioning made by SCU

Not at all. Linux disables all unused clocks by default. Even if clk_ignore_unused helps in some cases for some peripherals activated from M4, then there could be modules, whose drivers disable all unused parent clocks, which was the case on iMX7D with eCSPI. eCSPI driver was stopping M4… Perhaps this is less likely for iMX8X, which clocking scheme seems being less nested, but perhaps this scenario still can take place on iMX8X.

¿Are you aware if someone has used M4UART with Colibri IMX8 before?

Clearly this is doable, did someone like this before or not.

I really beg you to reproduce this issue from your side. I’m pretty sure that you can determine more quickly what is happenning.

Well, I’d love to put my fingers on iMX8X, but first I should get it somehow.

In your place I’d really would give rproc a chance. It should reliably solve all clocking issues, it will a) setup M4 clocking and b) it is very unlikely Linux will gate any clock you enable from your M4 FW. Rproc is not panacea, sometimes you may pick hairs why things are worse with rproc compared to u-boot bootaux. Indeed, did you try something simple like just LED blinking / pin toggling loop running on M4, without any interrupts or RTOS tasks? If simple loop stops, then it would confirm something is gating M4 clock. Of course Linux or some driver could reconfigure pin you used for this activity, so you need reenable the same pin from Linux as GPIO output to prove it wasn’t some joke with new pin mux or setting GPIO from out to in direction…

Let me look at device tree again. rproc for iMX8X is mentioned only in imx8x-mek.dtsi. So we need to try adding missing pieces to our imx8qxp-colibri-eval-v3.dts, or perhaps create new dts including everything from former:

#include "imx8qxp-colibri-eval-v3.dts"

/ {
	imx8x_cm4: imx8x_cm4@0 {
		compatible = "fsl,imx8qxp-cm4";
		rsc-da = <0x90000000>;
		mbox-names = "tx", "rx", "rxdb";
		mboxes = <&lsio_mu5 0 1
			  &lsio_mu5 1 1
			  &lsio_mu5 3 1>;
		mub-partition = <3>;
		memory-region = <&vdev0vring0>, <&vdev0vring1>, <&vdevbuffer>,
				<&vdev1vring0>, <&vdev1vring1>;
		core-index = <0>;
		core-id = <IMX_SC_R_M4_0_PID0>;
		status = "okay";
		power-domains = <&pd IMX_SC_R_M4_0_PID0>,
				<&pd IMX_SC_R_M4_0_MU_1A>;

hope it will compile, then boot and see if /sys/class/remoteproc is present or not. Check dmesg for remoteproc strings. If none, check kernel config, perhaps it is disabled there?

Yeah, SCU partitioning sounds complicated. But as I understand it, u-boot should have commands to partition things before Linux starts. Sorry for my ignorance, I may be wrong. Proper partitioning from u-boot could be another way to stop Linux disturbing your M4.


Now I realize you are not from Toradex Support… .:sweat_smile: is that so?

Sorry Edward in that case… and thank you very, very much for your support. Really appreciated.

I was expecting someone of Toradex could help, but they seem to be very busy then… That it’s why I insisted in if you could reproduce the issue. I hope someone from Toradex staff shows up at some point… :cry:

My focus over SCU was that if hardware is assigned from there, then Linux maybe won’t be able to disable it later. Anyway…

I tried to use “rproc” adding your code to device tree. It seems at first to be working but sadly when I launch M4 firmware it doesn’t run. Here you have more details.

This Hello_World firmware is a modification that uses an ADMA_UART instead of the CM4 one. In order “rproc” can be tested alone. This firmware can run normally launched from U-Boot script and it doesn’t stops when Linux Kernel starts.

Thank you again for your help, @Edward.

Yeah, I like to put my 2c to interesting threads.

My focus over SCU was that if hardware is assigned from there, then Linux maybe won’t be able to disable it later. Anyway…

I think the same, but that’s a lot of further reading and exercises to know it better…

From what you attached it seems like you are on the right track with rproc. Perhaps try something simpler like LED blinking or pin toggling to make sure driver message “is now up” is really up.

Hm, ADMA UART from M4. ADMA seems being used heavily from Linux (I could be wrong about iMX8X), which i fear you can’t do, I mean using ADMA from both M4 and Linux concurently. As well i doubt you need DMA at all from M4. UART usually is fine without DMA on something like 10MHz clocked MCU. You have 200+MHz M4.

Good luck


You are right, using the same resource from M4 and Linux looks very problematic. I hadn’t tried and this doesn’t come to my mind.

Maybe is my mistake explaining things or I don’t understand you well. When I refer to ADMA it is only the Subsystem where this peripheral belongs. Although you were right about simplifying the code, since “Hello_World” uses debug_console to print, which perhaps implies aditional layers or peripherals. I will check it.

I really need it, and help… :sweat_smile:

I hope I can return the favor sometime, @Edward. If you think it’s in my hands, don’t hesitate to ask me.

Hugh, ADMA stands for Audio DMA. Couldn’t they give a little less misleading name to that bunch of peripherals? I understand now what you meant.

Isn’t it just that Linux uses the same ADMA UART like you use in M4? OK, it would be more easy if you specified which UART are you using.

There are no such pads SC_P_SCU_GPIO0_00, there is SCU_GPIO0_00, which seem to be muxable to ADMA UART3, which DT doesn’t mux there, it uses different pads for UART3. The only place where any of SCU_GPIO0_00/01 are mentioned in DT is pinctr_hog_scfw, which seems to be not used. Hm, so did you use ADMA UART3 or indeed non-ADMA M4 UART? If UART3, then you need to disable it, … oops, it seems being main Linux console UART… Are you sure you are using SCU_GPIO0_00/01 with your UART?


Here is a brief clarification:

SC_P_UART0_RX/SC_P_UART0_TX → ADMA__LPUART0 (which is UART_B in device tree/Linux)

If you configure ADMA__LPUART0 and disable it in device tree, you can use in M4 firmware while Linux is running and doing its things.

Using CM4__LPUART while Linux is running it isn’t possible for me.

Main Linux console is mapped to UART A (ADMA__LPUART3)

For testing “rproc” I tried with firmware which uses ADMA__LPUART0 as first approach.

Thanks, I thing some former message was contrary to this.

Does CM4_LPUART work until Linux is started? Can you show your M4 code, which sets up CM4_LPUART pin muxing?

If you configure ADMA__LPUART0 and disable it in device tree, you can use in M4 firmware while Linux is running and doing its things.

Great! So it doesn’t seem to be M4 clocking issue. My first guess what could be wrong a) Linux for some reason is remuxing CM4_LPUART pins and UART seems stopping, b) Linux disables CM4_LPUART clock or reconfigures CM4_LPUART differently, c) Linux somehow cancels access to LPUART from M4.

You need to determine what’s going on. Dumping IOMUX, clocking, CM4-UART configuraion registers periodically over your working ADMA_LPUART0 should help figuring out what’s going wrong after Linux boots.

Hi @Eduardo and @Edward .

First of all, sorry for the lack of answer here. Really.

About Cortex-M support from Toradex, it is still being built and soon we will have some how-to articles about it.

Now, going straight to the question: running Linux and M4 (and allow M4 to use UART) - this is the question right?

From the M4 side, based on MCUXpresso examples (reference: FreeRTOS on the Cortex-M4 of a Colibri iMX8X | Toradex Developer Center), you need to correctly map the pinto the right function. The table is this one.

Changes on pin_mux.h

For the MCUXpresso (v2.9.0) hello-world example. these are the changes on boards/mekmimx8qx/demo_apps/hello_world/pin_mux.h

--- a/pin_mux.h
+++ b/pin_mux.h
@@ -18,7 +18,7 @@
 #define BOARD_INITPINS_FTDI_M40_UART0_RX_PERIPHERAL                   M40__UART0   /*!< Device name: M40__UART0 */
 #define BOARD_INITPINS_FTDI_M40_UART0_RX_SIGNAL                          uart_rx   /*!< M40__UART0 signal: uart_rx */
 #define BOARD_INITPINS_FTDI_M40_UART0_RX_PIN_NAME                        ADC_IN2   /*!< Pin name */
-#define BOARD_INITPINS_FTDI_M40_UART0_RX_PIN_FUNCTION_ID            SC_P_ADC_IN2   /*!< Pin function id */
+#define BOARD_INITPINS_FTDI_M40_UART0_RX_PIN_FUNCTION_ID            SC_P_SCU_GPIO0_00   /*!< Pin function id */
 #define BOARD_INITPINS_FTDI_M40_UART0_RX_LABEL               "FTDI_M40_UART0_RX"   /*!< Label */
 #define BOARD_INITPINS_FTDI_M40_UART0_RX_NAME                "FTDI_M40_UART0_RX"   /*!< Identifier name */

@@ -26,7 +26,7 @@
 #define BOARD_INITPINS_FTDI_M40_UART0_TX_PERIPHERAL                   M40__UART0   /*!< Device name: M40__UART0 */
 #define BOARD_INITPINS_FTDI_M40_UART0_TX_SIGNAL                          uart_tx   /*!< M40__UART0 signal: uart_tx */
 #define BOARD_INITPINS_FTDI_M40_UART0_TX_PIN_NAME                        ADC_IN3   /*!< Pin name */
-#define BOARD_INITPINS_FTDI_M40_UART0_TX_PIN_FUNCTION_ID            SC_P_ADC_IN3   /*!< Pin function id */
+#define BOARD_INITPINS_FTDI_M40_UART0_TX_PIN_FUNCTION_ID            SC_P_SCU_GPIO0_01   /*!< Pin function id */
 #define BOARD_INITPINS_FTDI_M40_UART0_TX_LABEL               "FTDI_M40_UART0_TX"   /*!< Label */
 #define BOARD_INITPINS_FTDI_M40_UART0_TX_NAME                "FTDI_M40_UART0_TX"   /*!< Identifier name */
Changes on pin_mux.c

For the MCUXpresso (v2.9.0) hello-world example. these are the changes on boards/mekmimx8qx/demo_apps/hello_world/pin_mux.c

--- a/pin_mux.c
+++ b/pin_mux.c
@@ -57,12 +57,12 @@ void BOARD_InitPins(sc_ipc_t ipc)                          /*!< Function assigne
   sc_err_t err = SC_ERR_NONE;

-  err = sc_pad_set_all(ipc, BOARD_INITPINS_FTDI_M40_UART0_RX_PIN_FUNCTION_ID, 1U, SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF, 0x0 ,SC_PAD_WAKEUP_OFF);/* IOMUXD_ADC_IN2 register modification value */
+  err = sc_pad_set_all(ipc, BOARD_INITPINS_FTDI_M40_UART0_RX_PIN_FUNCTION_ID, 2U, SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF, 0x0 ,SC_PAD_WAKEUP_OFF);/* IOMUXD_ADC_IN2 register modification value */
   if (SC_ERR_NONE != err)
-  err = sc_pad_set_all(ipc, BOARD_INITPINS_FTDI_M40_UART0_TX_PIN_FUNCTION_ID, 1U, SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF, 0x0 ,SC_PAD_WAKEUP_OFF);/* IOMUXD_ADC_IN3 register modification value */
+  err = sc_pad_set_all(ipc, BOARD_INITPINS_FTDI_M40_UART0_TX_PIN_FUNCTION_ID, 2U, SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF, 0x0 ,SC_PAD_WAKEUP_OFF);/* IOMUXD_ADC_IN3 register modification value */
   if (SC_ERR_NONE != err)

And, from the Linux side, you need to disable the following nodes (you can use it as an overlay):


	compatible = "toradex,colibri-imx8";

&cm40_lpuart {
	status = "disabled";

&cm40_uart_lpcg {
	status = "disabled";

You need to disable it because one resource can not be acquired more than once (AFAIK).

If you come back to the table, you will see that there are more pins that you need to correctly configure on pin_mux.h/pin_mux.c (in the case you need to use them on M4).

Also, in the end, you do not need to directly modify SCU for this, as the calls on M4 firmware (e.g. sc_pad_set_all) do the work for you and, from the Linux side, the device tree also “talks” to the SCFW under the hood.

I hope it helps you and, if you need more help, please let me know.

Best regards,

It seems I was very close to find the solution… :see_no_evil: So sad…

Apologies accepted. :slightly_smiling_face:

If you had answered earlier you would have saved me a lot of headaches, but I’m glad it finally works.

I still have doubts about how this is done. Since “cm40_lpuart” appears disabled by default in “imx8-ss-cm40.dtsi” but… it is working… is enough… no complaints.

Thank you all.

1 Like

Hi @Eduardo !

Glad to see that it helped you!

I would say that disabling cm40_lpuart is not needed as the original node is already disabled on imx8-ss-cm40.dtsi, BUT (from my point of view) doing so kind of makes the overlay “complete” for its purpose.

About cm40_uart_lpcg:

  • the original node does not explicitly defines the status property; and
  • not explicitly disabling it prevents Linux from booting (it tries to acquire this resource)

So, I would say that the default status is "okay" which certainly is what was preventing the system to work correctly.

Best regards,

You are right, “cm40_uart_lpcg” status is not defined. Maybe this was the cause.

I tried to enable both only to se if it could be view clk active in “clk_summary”. My guess is for that are needed further steps made with the correspondant driver, or that I suppose.

Seems to be more clear now. I hope not need to struggle like this for other untested peripherals in my M4 code. Luckily not hardware partitioning from SCU is needed…

Thank you again, @henrique.tx . Consider this topic solved.

1 Like