drivers: clk: stm32h7: Endless loop of dead in driver probe function
Johannes (krjdev) Krottmayer
krjdev at gmail.com
Wed Mar 9 08:24:59 CET 2022
Sorry, for my late response. :(
On 08.03.22 10:00, Patrick DELAUNAY wrote:> Yes, the current clock
driver for STM32 MCU is not perfect,> > as the all U-Boot and the
Linux support on STM32 MCU.>
> For information, in the other driver based on a other version of RCC for
> STM32 MPU
> STM32MP1 = clk_stm32mp1.c, it is correctly managed in
> stm32mp1_osc_wait(1, rcc, RCC_OCRDYR, RCC_OCRDYR_HSERDY);
> by using readl_poll_timeout() function.
>> My possible fixes:
>> At a timeout when reading the register and if the timeout is
>> elapsed, print an error message and return with ETIMEDOUT, so
>> the dm manger can call the hang() function.
> I agree, it is a correct management: at least indicate this hardware issue
> even if the rdy bit can't be stay at 0 in normal use case when HSE is
> => replace all while() in the RCC clock driver with readl_poll_timeout
> but to call readl_poll_timeout(), the arch timer need to ready
> (timer_init() already called) when RCC clokc driver probe is executed.
> An issue the I encounters on STM32MP need to be checked in MCU driver:
> the timer can't dependant of RCC probe when polling function is used.
> This issue was solved in STM32MP by using the generic armv7 timer
> (only dependant of Cortex core) and call the initialization in
> int arch_cpu_init(void)
> /* early armv7 timer init: needed for polling */
> return 0;
Is there any reason why not use the ARMv7-M SysTick Timer? There
exists an initialization routine in the U-Boot source tree:
The routines should work for Cortex-M3/M4/M7.
timer_init() and all required functions for mdelay() which are will
be called by the polling functions are implemented.
Don't looked into other TRM's, other than for STM32H745/STM32H747 and
STM32H755/STM32H757 yet, but according the TRM, the SysTick timer for
the core Cortex-M7 should run at 8MHz, after reset:
- HSI should be selected as system clock (sys_ck), running at 64MHz
- Domain 1 prescaler (D1CPRE) with scale 1
- SysTick timer at default configuration (external source) which
has a fixed prescale from 8, according the block schematic in
Correct me please, if I'm wrong.
> The timer management on MCU need to be check before any patch.
Yes, but I can currently only test the correct behavior on a
STM32H747I-DISCO board. Currently creating the device-tree for
> Can you propose something ?
I would use the SysTick Timer on the other devices from the STM32H7
series too, so I would change the current code.
Before I release a patch series here in the official mailing list,
I would suggest, if some other developers or users can verify my
modification on their real hardware.
My GitHub repo:
That I can offer. :)
More information about the U-Boot