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