Does Linux block USART6 early debug output when starting?

[DMårt]

I have an issue were the Linux kernel is booting, then it just stops printing out messages from USART6.

Meanwhile, optee, u-boot and TF-a is printing out messages from USART6. But not Linux after a while.

What can have caused this?

My processor is: STM32MP257F.

[Erwan SZYMANSKI]

Hello @DMårt ,
Are you sure you don't have a firmware running on M33 that uses or just reconfigure the USART6 instance ? The fact that you have the logs at the beginning but disappear after some time let me think about a such possibility.

[Edit: if not, the USART6 is certainly well configured in earliest boot stages, and Linux does not keep a good configuration on it, but maybe more logs could help to understand exactly where does it disappear]

Kind regards,
Erwan.

[DMårt]

Hi @Erwan SZYMANSKI 

Here is the log.

As you can see

vddio2: disabling
vddio3: disabling
vddio4: disabling
vddcore: disabling
v1v8: disabling
v3v3: disabling

I don't know why this is happening inside Linux. 

[Erwan SZYMANSKI]

Hello @DMårt ,
I think you have a misalignment between your kernel version and your other OpenSTLinux BSP components.

I just felt on this issue by pure chance when working on another topic. It was due to my BSP on OpenSTLinux v6.2 (OP-TEE, TF-A, U-Boot), while my kernel was in OSTL 6.1.

Please double check this.

The blocking point is not the USART at all, but in your complete log, you see the RCC probe is broken:

[ 6.578092] stm32mp25_rcc 44200000.clock-controller: Can't register clk 2: -17
[ 6.583185] stm32 clock failed to initialize
[ 6.587482] stm32mp25_rcc: probe of 44200000.clock-controller failed with error -17

Kind regards,
Erwan.

This is usually not Linux blocking USART6, but a console switch issue during boot.
Early stages (TF-A, U-Boot, OP-TEE) use USART6, but Linux may switch to another console.
Check your bootargs (console=) to ensure it matches USART6.
Also verify the device tree stdout-path and UART driver configuration.
You can check result online to confirm where the kernel output stops.