Embed M7 firmware in TorizonCore and load it automatically on Verdin iMX8M-Mini

Hi @hfranco.tx,
I really appreciate your help and your hard job on thbis topic.
Now I think everything is almost clear.
Great that you’ve been able to patch and rebuild u-boot.
For my level of experience, I see it as a difficult job, and so I prefer not to go in that direction.

I decided to use UART1 as debug console for M7, and this works quite easily (patching board.h, clock_config.c and pin_mux.c in the hello_world example only - no changes to u-boot).
In this scenario, UART2 (which is reserved to Cortex-A) can be safely used as general-purpose UART for Cortex-A application.
Maybe, this can be given as an advice to other Verdin iMX8M-Plus users.

As a bonus track :wink: I add that I’ve been able to overwrite RDC_PDAP105 configuration from U-Boot (on the fly), with the command

Verdin iMX8MP # mw.l 0x303d05a4 0xff

After I didi it, I was able to run the hello_world example using UART2, without patching and rebuilding u-boot.
As expected, at the next boot RDC_PDAP105 has been restored as 0x00000003.

I was satisfied about the result, but I’m curious, and I’d like understanding what happened.
I didn’t see any point in u-boot sources that sets that RDC_PDAPxx registers and I was confused.
So I opened a topic on NXP Community to ask their help, and the reason is inside ATF, in particular these lines inside imx8mp_bl31_setup.c.
I have a vagous idea of what ATF is, but I thinkl is somehow built inside u-boot.

Not it’s clear “where” the registers RDC_PDAPxxx are set, but not “why”.
But the answer in NXP Community helps:

Please make a note that uart2 is used for debug console in default BSP.

One needs to make changes to use another uart as A53 debug console.

I see taht in TorizonCore this debug console is UART3 (on the Plus), which is connected to UART_3 (of the Verdin).
@hfranco.tx do you know if Toradex decided to change this debug console (respect to what is in NXP reference design)?
Wouldn’t be better if on Verdin iMX8M-Plus SoM the UART2 had been connected to UART_3?
In this way, the Verdin debug console would be UART_3 (as the family), but internally the NXP-suggested UART2 is used.