STM32MP15 ECO 5.0.0 u-boot freeze stm32mp1_clk rcc@50000000: stm32mp1_clk_enable: id clock 151

[debugging]

Freezes here at rcc setup

Looking for rcc@50000000
Looking for rcc@50000000
- result for rcc@50000000: rcc@50000000 (ret=0)
- result for rcc@50000000: rcc@50000000 (ret=0)
stm32mp1_clk rcc@50000000: stm32mp1_clk_enable: id clock 151 has

log attached.Any suggestion where to look, what to change, what to try  ?

if needed, advise what files needed ? using 2 different ECO system folders with SDK and source files. One using CubeMX generated DT's and then adjusted with additional entries and one using DT's based on the eCO provided 157a-DK1 DT files with some changes.  Exactly the same result. Discrete power, and discrete Crystal OSCs. Board runs ECO 1 fine.

Adding the log of the tree using the CubeMX generated DTS.

https://wiki.st.com/stm32mpu/wiki/Clock_overview

https://github.com/STMicroelectronics/linux/blob/v6.1-stm32mp/include/dt-bindings/clock/stm32mp1-clks.h

shows

#define UART4_K 151

This is the UART debug output  and 151 is the clock it crashes on. So perhaps the boot is continuing but there is no serial output.

Not that I expect reaction anymore from ST on this forum. Don't give me  kudo's for posting a solution. Need guidance how to find the cause. ... Sending out and SOS. message in a bottle...

 

 

 

[michiel.tjampens]

found match at 'pinctrl_stm32': 'st,stm32f429-pinctrl' matches 'st,stm32mp157-z-pinctrl

Probably nothing given that the stm32mp1 seems to share i2c drivers with stm32f, but isn't that odd that those match? (all the other matches in the log are exact). But the crash does happen just before you'd expect a pinctrl line... Just odd that it would crash because of the clock given that uart4 is probably what has been outputting data since the start.

How did you actually get that bootlog? I don't think it's from optee given no I/TC or such in front. Might be handy to know what's supposed to happen after it because that's more likely the cause of the lockup.

[debugging]

Thanks, I saw that match as well., the  UART has something simiar, the include files following, results in STM32MP151.dtsi defining:

uart4: serial@40010000 {

compatible = "st,stm32h7-uart";

reg = <0x40010000 0x400>;

interrupts-extended = <&exti 30 IRQ_TYPE_LEVEL_HIGH>;

clocks = <&rcc UART4_K>;

wakeup-source;

power-domains = <&pd_core>;

dmas = <&dmamux1 63 0x400 0x15>,

<&dmamux1 64 0x400 0x11>;

dma-names = "rx", "tx";

feature-domains = <&etzpc STM32MP1_ETZPC_UART4_ID>;

status = "disabled";

};

uart4: serial@40010000 {

compatible = "st,stm32h7-uart";

The boot log is the output from MP15 UART4 port  (to the host USB serial port). I enabled debug in some U-boot source files such as stm32mp1.c and clk-stm32mp1.c adding #define LOG_DEBUG at the top of the file: ./u-boot-stm32mp-v2022.10-stm32mp-r1/drivers/clk/stm32/clk-stm32mp1.c & ./u-boot-stm32mp-v2022.10-stm32mp-r1/board/st/stm32mp1/stm32mp1.c

The pinmux for the GPIO assignment are correct and u-boot and linux use the same DT.  I didn't change anything for GPIO's as was done by CubeMX.  I suspect that it is not UART4 but perhaps the clock after UART4 since the debug messages always are behind where the actual code is executing. 

/clk-stm32mp1.c ,states the parent is UART24_SEL.

STM32MP1_CLK_SET_CLR(RCC_MP_APB1ENSETR, 16, UART4_K, _UART24_SEL),

 

I noticed the clock enable sequence  and 151 is the first "kernel" clock in the sequence. I have not found where the sequence of clock enabling is defined.

82 HSEM (bus clocks...)
87 GPIOD
84 GPIOA
52 VREF
90 GPIOG
85 GPIOB

151 UART4 (kernel clock)

 

To boot stops in clk-stm32mp1.c in function: static int stm32mp1_clk_enable(struct clk *clk)

       dev_dbg(clk->dev, "%s: id clock %d has been enabled\n", __func__, (u32)clk->id);

This function traces back to U_BOOT_DRIVER.ops.enable(). this reference is only found once in all ECO 5.0 sources

./u-boot-stm32mp-v2022.10-stm32mp-r1-r0/u-boot-stm32mp-v2022.10-stm32mp-r1/drivers/clk/stm32/clk-stm32mp1.c:2342:U_BOOT_DRIVER(stm32mp1_clock) = {

So, can't find out which code is calling it. only the person who wrote the driver probably can help,  but there is no author in the ST source code. It's leading to another dead end.

[michiel.tjampens]

Hm, thought that enabling that debug might give some info (eventhough it's a stm32mp151 instead of stm32mp157).

But I still get wat less output, maybe haven't enabled everything yet. But here atleast it appears that enabling that clock is the last thing before uboot actually starts.

stm32mp1_clk rcc@50000000: stm32mp1_clk_enable: id clock 84 has been enabled
stm32mp1_clk rcc@50000000: stm32mp1_clk_enable: id clock 90 has been enabled
stm32mp1_clk rcc@50000000: stm32mp1_clk_enable: id clock 151 has been enabled
HSI_KER clock is the parent UART24 of clk id 151
id=6 clock = 3d09000 : 64000 kHz
stm32mp1_clk rcc@50000000: computed rate for id clock 151 is 64000000 (parent is HSI_KER)

U-Boot 2022.10-stm32mp-r1-00001-g4686fcffbe-dirty (Oct 03 2023 - 22:43:03 +0200)

 

 

[debugging]

Thanks a lot. I rebuild the whole ECO 5.0.0 tree sources from CubeMX again (3rd attempt) step by step with each change needed. still resulting in the same situation of error 151 (3rd result). I wonder if this has anything to do with U-boot trying to load the from the ext4 partition (as ID151 is defined as a kernel UART device). Just guessing ,since I can't figure out what calls the U-BOOT driver. U_BOOT_DRIVER(stm32mp1_clock).  It could well be that the UART was correctly enabled and that something after that crashes. It must be something simple in a DT or in the ext4 boot partition, but what ... I am using the default stm32mp1_defconfig from ST for u-boot and did not make changes besides enabling DEBUG

[michiel.tjampens]

Don't think so because that "clock 151 has been enabled" is printed again after the line that U-Boot has started.

 

U-Boot 2022.10-stm32mp-r1-00001-g4686fcffbe-dirty (Oct 03 2023 - 22:43:03 +0200)

CPU: STM32MP151AAC Rev.Z
...(removed stuff)...
stm32mp1_clk rcc@50000000: stm32mp1_clk_enable: id clock 84 has been enabled
stm32mp1_clk rcc@50000000: stm32mp1_clk_enable: id clock 90 has been enabled
stm32mp1_clk rcc@50000000: stm32mp1_clk_enable: id clock 151 has been enabled
stm32mp1_clk rcc@50000000: stm32mp1_clk_enable: id clock 85 has been enabled
stm32mp1_clk rcc@50000000: stm32mp1_clk_enable: id clock 86 has been enabled
stm32mp1_clk rcc@50000000: stm32mp1_clk_enable: id clock 87 has been enabled
stm32mp1_clk rcc@50000000: stm32mp1_clk_enable: id clock 118 has been enabled
stm32mp1_clk rcc@50000000: stm32mp1_clk_enable: id clock 88 has been enabled
stm32mp1_clk rcc@50000000: stm32mp1_clk_enable: id clock 119 has been enabled

 

[debugging]

Thanks !. that's a hint... clock 85,86 and 87 are GPIO B,C and D.  Maybe this has something to do with u-boot and RCC and/or SCMI and/or the peripherals using those GPIO's, but I would assume CubeMX had taken care of all the needed settings in the DT.

The clock IDs are defined in the kernel

https://github.com/STMicroelectronics/linux/blob/v6.1-stm32mp/include/dt-bindings/clock/stm32mp1-clks.h

So I am wondering this issues is due to u-boot or kernel configuration issues

Did you add CONFIG_LOG_MAX_LEVEL=7 to stm32mp1_defconfig for debug messages and check in ./u-boot-stm32mp-v2022.10-stm32mp-r1-r0/u-boot-stm32mp-v2022.10-stm32mp-r1/drivers/clk/stm32/clk-stm32mp1.c to add #define LOG_DEBUG at the top.

[michiel.tjampens]

The above was after adding the LOG_DEBUG. Just added CONFIG_LOG_MAX_LEVEL=7, doesn't seem to make a difference.

[debugging]

Hmm. checked and I only added LOG_DEBUG in that file. Did you add LOG_LEVEL=LOG_LEVEL_INFO and DEBUG=1 on the make command line ?

[michiel.tjampens]

Thanks, that seems to have made the difference, total bootlog is now 21kB ... (includes optee debug)

I also get a lot of "gpio_stm32 gpio@50008000: set_state_simple op missing" like you, so it's probably not relevant to your issue.

[debugging]

Good that it works. ! :) I also see those simple state missing messages. Now I need to figure out the clock 151 problem..I am really stuck. (Like many times before) It's a lonely place here with few folks with knowledge of support.