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...

[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.

[debugging · Accepted solution]

Fixed the 151 error. Known bug in ECO code. :(

[krasl]

I have the same problem on my platform with similar configuration. Can you describe more you solution? thanks

[Rockyaaaaa]

I'm having the exact same problem, can you tell me how to fix it?

[teg500]

I Also have a this problem where u-boot stops at the clock 151. On thing worth to note that for me if I turn off debug printing Linux will boot just fine so u-boot must somehow run but it stops printing around the DDR frequency printing. So we are able to use the system but it's more or less a requirement that we should be able to enter u-boot. 

optee optee: OP-TEE: revision 3.19 (afacf356)                                                                                                                Clocks:                                                                                                                                                 
- MPU : 650 MHz                                                                                                                                          
- MCU : 64 MHz                                                                                                                                      
- AXI : 133 MHz                                                                                                                                             
- PER : 64 MHz                                                                                                                                                              
- DDR ��M&&j!�5                                                                                                              
               [    0.000000] Booting Linux on physical CPU 0x0           
[    0.000000] Linux version 6.1.28 (oe-user@oe-host) (arm-ostl-linux-gnueabi-gcc (GCC) 12.2.0, GNU ld (GNU Binutils) 2.40.20230119) #1 SMP PREEMPT Thu May 11 14:04:52 UTC 2023         
[    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d 
[    0.000000] CPU: div instructions available: patching division code   

.......

[teg500]

Hi, I tried to post here yesterday but my post is not visible so I will try again, could be because i copied part of my boot log my have contained bad characters. So I try again.  

I have the exact same problem as well, it stops u-boot uart at - DDR  (some times bad characters comes her so it seems the UART is abruptly stopped) and if I enable debugging it stops at enabling clock 151. One thing worth noting is that it seems to be the u-boot console that is not working, Linux boots just fine as long as i disable the debug log. I would like to acces the uboot console so I would be very interested in what this known bug in the ECO is, is there a place where these known bugs are written down???

[debugging]

This was a bug known by ST but ST somehow does not publish a (well) know issue list.

Trying to setup a known issues list  :https://discord.gg/XgEtT4ah

[teg500]

Thank you so much. It is finally working now. It seems like ST does not have much interest in having customers when they don't post these kinds of bugs publicly and that they don't make a new minor release as soon as such a bug is discovered.

[AlbertSong]

Hi, I just encountered the same issue, "stops u-boot uart at - DDR (some times bad characters comes her so it seems the UART is abruptly stopped) ", and sadly blocked here for several days after trying many different methods..can you share how you fix the problem? Many thanks for that. And one more question, using the default working stream, do you know where to insert the macro like CONFIG_LOG_MAX_LEVEL=7? Now I have to use the git and create patch file to replace the one appeared in the layer of meta-st, really cost huge amount of time. Thanks

[teg500]

Hi

I wonder if anyone using the standard ECO rev 5 have working U-Boot? Anyways @debugging  did post a link to his discord server where the issue is described. 

I have added the patch that I use here in case you are not using Discord. 

I have to note that this bug by ST is costing their customers a lot of time and money and when they know about the bug why do they not fix it or at least publish it. 

Could anyone from ST comment on this issue ? @PatrickF ??