2020-08-18 08:03 AM
Hi All.
I am currently using STM32MP15-Ecosystem-v1.2.0. for DK2. At the moment I don't plan to completely upgrade to v2.0.0 but I would like to test the new kernel version (5.4.31). I have compiled the new kernel version and a new device tree but once the kernel is loaded into memory, no trace of the kernel log is shown and the system doesn't start.
Is there any dependency between kernel and u-boot (and maybe TF-a) that makes it necessary to upgrade both?
2020-08-24 07:50 AM
Hi @AVazquez
There is API break between kernel 4.19 and kernel 5.4 for kernel start, and so yes you need to take V2.0 compatible tf-a and uboot in order to use new kernel 5.4.
Hope it help
Olivier
2020-08-24 11:41 AM
Hi @Community member
Thanks for the answer. I found it very strange what was happening with the kernel.
I would like to have some more information about it.
Is this documented somewhere? or Is there a kernel log where this was integrated?
Thanks!!
AVazquez
2020-08-26 01:02 AM
Hi @Community member,
Is this "API break" due to the switch to SCMI for clocks/resets? (this commit on GitHub)
Thank you,
Guillermo
2020-09-11 02:49 AM
Hi Alex & Guillermo,
Yes clocks / resets secured use now a SCMI server from TF-A instead proprietary SMCs.
Best regards.
Gabriel
2020-09-14 03:48 AM
Thank you @Gabriel Fernandez . This is very helpful.
I see that a later commit introduced a new stm32mp15-no-scmi.dtsi file "to be backward compatible with old bootchain".
If this .dtsi file is used, I assume the kernel will not use secure services for clock/resets, so this can be used to boot a 5.4 kernel with a Basic bootchain (i.e. U-boot SPL as fsbl and U-boot as ssbl, no TF-A anywhere). Right?
Also I understand that this .dtsi file will NOT work for booting a 5.4 kernel with the trusted boot chain from BSP 1.2.0, since the TF-A from 1.2.0 would prevent direct access to the secured clocks / resets. Is this correct?
Thanks again.
Guillermo