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

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

[Johannes (krjdev) Krottmayer]

Hi,

Some IMHO fatal issues in the the clock driver for the
STM32H7 series driver.

Affected driver:
drivers/clk/clk_stm32h7.c

Affected configs (boards):
configs/stm32h750-art-pi_defconfig
configs/stm32h743-disco_defconfig
configs/stm32h743-eval_defconfig

Description:
The driver currently requires a external working clock source
(HSE). No issues in the circuit are accepted by the current
implementation. Also a fixed (defined) frequency of the external
clock source.

In the probe function stm32_clk_probe() from the driver there
will be configure_clocks() called. Here are the issues.

As code snippet from configure_clocks():

/* Switch on HSE */
setbits_le32(&regs->cr, RCC_CR_HSEON);
while (!(readl(&regs->cr) & RCC_CR_HSERDY))
	;

RCC_CR_HSERDY will here never set, when there is no external
clock source or an issue in the circuit. -> Endless loop of dead.

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.

Johannes K.

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

[Patrick DELAUNAY]

Hi,

On 3/2/22 18:00, Johannes (krjdev) Krottmayer wrote:
> Hi,
>
> Some IMHO fatal issues in the the clock driver for the
> STM32H7 series driver.
>
> Affected driver:
> drivers/clk/clk_stm32h7.c
>
> Affected configs (boards):
> configs/stm32h750-art-pi_defconfig
> configs/stm32h743-disco_defconfig
> configs/stm32h743-eval_defconfig
>
> Description:
> The driver currently requires a external working clock source
> (HSE). No issues in the circuit are accepted by the current
> implementation. Also a fixed (defined) frequency of the external
> clock source.
>
> In the probe function stm32_clk_probe() from the driver there
> will be configure_clocks() called. Here are the issues.
>
> As code snippet from configure_clocks():
>
> /* Switch on HSE */
> setbits_le32(&regs->cr, RCC_CR_HSEON);
> while (!(readl(&regs->cr) & RCC_CR_HSERDY))
> 	;
>
> RCC_CR_HSERDY will here never set, when there is no external
> clock source or an issue in the circuit. -> Endless loop of dead.


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


The timer management on MCU need to be check before any patch.


Can you propose something ?


>
> Johannes K.


Patrick

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

[Johannes (krjdev) Krottmayer]

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:

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

Kind regards,

Johannes

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

[Patrice CHOTARD]

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.

Thanks
Patrice

> 
> Kind regards,
> 
> Johannes

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

[Johannes (krjdev) Krottmayer]

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

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

Kind regards

Johannes

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

[Patrice CHOTARD]

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

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

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