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

[Johannes (krjdev) Krottmayer]

Hi Patrice!

I have bricked my board. LOL. Hope I can recover it, when
soldering BOOT0 to VDD. Solder Bridge 192 (SB192).

Don't verified the power settings first in the clock driver.

The current power configuration clears SCUEN. But on STM32H747,
this disables the SMPS converter. Same bit position (SDEN) in
PWR_CR3...

On 09.03.22 09:08, Patrice CHOTARD wrote:
> 
> 
> 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