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 ? [...]
