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

[Patrice CHOTARD]

Hi Johannes

On 3/9/22 12:38, Johannes (krjdev) Krottmayer wrote:
> 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...

Right, i double check in datasheets, PWR_CR3 register differs between 
STM32H743 (single core M7 only) and STM32H747 (dual core M7+M4).

This driver must be updated to fit with dual core STM32H747.

Patrice


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