drivers: clk: stm32h7: Endless loop of dead in driver probe function

Patrice CHOTARD patrice.chotard at foss.st.com
Wed Mar 9 09:08:48 CET 2022



On 3/9/22 09:02, Johannes (krjdev) Krottmayer wrote:
> Hi Patrice!
> 
> On 09.03.22 08:43, Patrice CHOTARD wrote:
>> Hi johannes
>>
>> On 3/9/22 08:24, Johannes (krjdev) Krottmayer wrote:
>>> Hi Patrick!
>>>
>>> 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
>>>>
>>>> present.>
>>>> => 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
>>>>
>>>> arch/arm/mach-stm32mp/cpu.c:
>>>>
>>>> int arch_cpu_init(void)
>>>> {
>>>> ....
>>>>
>>>>      /* early armv7 timer init: needed for polling */
>>>>      timer_init();
>>>>
>>>>      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:
>>
>> Simply because when i introduced stm32h7 board, i didn't need it ;-)
>>
>>>
>>> arch/arm/cpu/armv4m/systick-timer.c
>>>
>>> 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
>>>   TRM.
>>>
>>> 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
>>> the SoC.
>>>
>>>> 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:
>>> https://github.com/krjdev/stm32_u-boot
>>> (branch stm32h747_disco)
>>>
>>> That I can offer. :)
>>
>> I have a stm21h7xxi-disco (MB1248) i can give it a try this week.
>> I will keep you in touch.
> 
> Please can you give me some additional time for this? The device-tree
> needs some fixes. Missing clocks and resets for the required driver.
> 
> I will create a git tag, when I'm ready and I have tested to run
> U-Boot on my board. :)
> 
> Working since sunday on the device-trees...Maybe tommorrow. :)

No problem, i will wait your green light :-D

Patrice

> 
>> Thanks
>> Patrice
>>
>>>
>>> Kind regards,
>>>
>>> Johannes
> 
> Kind regards
> 
> Johannes


More information about the U-Boot mailing list