cancel
Showing results for 
Search instead for 
Did you mean: 

u-boot and kernel dependency

AVazquez
Associate III

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?

5 REPLIES 5
Olivier GALLIEN
ST Employee

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

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

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

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
Associate

Hi Alex & Guillermo,

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

Best regards.

Gabriel

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