u-boot and kernel dependency

[AVazquez]

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?

[Olivier GALLIEN]

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

[AVazquez]

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

[Grodriguez]

Hi @Community member​,

Is this "API break" due to the switch to SCMI for clocks/resets? (this commit on GitHub)

Thank you,

Guillermo

[Gabriel Fernandez]

Hi Alex & Guillermo,

Yes clocks / resets secured use now a SCMI server from TF-A instead proprietary SMCs.

Best regards.

Gabriel

[Grodriguez]

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