On 2/6/20 9:59 AM, Patrick DELAUNAY wrote:
Hi Marek,
Hello Patrick
[...]
My problem is with the bootloader-Linux clock tree dependency. That dependency should not exist or be minimized, otherwise you end up with a very poor long-term experience, see above. And if you want for this platform to be successful in the industrial/automotive deployments, then you want to make sure the long-term experience is a good one.
With STM32MP15x SOC and RCC, very few clocks need to be fixed by bootloaders (in fact more or less the root clocks of the system = frequency of PLL1 to PLL4, common for many device or protected by security feature), I think it is the case for any platform.
All the other clocks have a initial value / source provided by bootloaders but they can also be modified at runtime (by device tree assigned-clock-parents for not secure clocks and with SMC call to TF-A secure monitor for "secure" clock).
For ST boards, we are trying to don't modify the initial clock tree-source only to prove that this clock tree is functional / correct for most of case.
But for client and after first deployment, clock tree modification must be done in Linux kernel without any Bootloader update (and avoid all known issue for OTA).
I shared your concerns with my team and we are completely agree with you.
So, shall we expect a proper fix for the Linux kernel too ?
[...]