Kernel-5.15 bootloader dependency

[AVazquez]

Hi All!!

I am currently using openstlinux-5.10-dunfell-mp1-21-11-17 for EV1.

My idea is upgrade kernel version to 5.15 and keep u-boot-2020.10 and tf-a-2.4.

My problem is that only upgrading the kernel and dtb, the kernel crashes and doesn't show any log traces (added boot.log).

Is there any dependency (or API break) between kernel and bootloaders(U-boot/Tf-a)?

I would like to know if it have fix

[Olivier GALLIEN]

Hi @AVazquez​ ,

There's strong dependencies between kernel and BSP inside a release, and major release usually contain API breaks.

It's recommended to always use a complete and consistent release.

see STM32 MPU OpenSTLinux release note - v4.0.0 - stm32mpu

Olivier

[Grodriguez]

We want to be able to upgrade the kernel once the product is in the field and we would rather NOT update u-boot or tf-a. This is rather standard procedure and should be possible IMHO. You don't have any plans to support this?

[Grodriguez]

Hi @Community member​ ,

Can you clarify what is your backwards compatibility policy on this matter? Customers are not supposed to upgrade the kernel after delivery, unless the whole system is upgraded at once? (not very practical)

As far as I know the upstream kernel does not have such issues, so I assume that whatever APIs are being broken are ST specific. Can you provide details on this?

I think this is an important topic for any real world product based on ST MPUs.

Thank you,

Guillermo

[Olivier GALLIEN]

Hi @Grodriguez​ , @AVazquez​ ,

Do you have already product on the field, or do you prepare it to be compliant to such update ?

Dependences between U-boot/Secure Monitor and kernel between 2 major/LTS release are usually bring by power and secure services.

From DV4.0 we introduce Secure Firmware update feature which provide a secure A/B mechanism to update FIP and Kernel.

BL2 will now remains compatible with all coming release.

We really advise you to update to DV4 prior to send product in the field.

Note that that for futur proof we also advise to swith to Optee instead of SP_MIN which is deprecated.

Olivier

[Grodriguez]

Product is not yet in the field but about to be released and with a tight deadline. We are on BSP release 3.1.

According to this article: https://community.st.com/s/article/FAQ-STM32MP1-Which-OpenSTLinux-Release-should-be-used, releases with x.1 minor version are always better tested than x.0, so this is why we initially thought that we'd stay on 3.1 instead of migrating to 4.0.

BUT, we want to be able to upgrade the kernel in the future. Also, in general we do NOT want to update TF-A / u-boot. Will this be possible? Or will you continue to enforce the rule that a future kernel (for example from BSP 5.0) cannot be upgraded unless the whole system (including TF-A + u-boot) is upgraded at once?

This is the first time I see a situation like this; the upstream kernel is as far as I know backwards compatible and can be upgraded without requiring this kind of all-or-nothing approach.

Also, regarding OPTEE: do you have any documentation related to the differences and implications of switching from SP_MIN to OPTEE ? e.g. is there an impact on boot time, RAM usage, performance ?

Thank you,

Guillermo

[PPiwk.1]

Hi,

We have very similar user case, and faced the same issue. After updating the new kernel only (from 5.10 to 5.15), the boot process hangs after that message.

Starting kernel ...

Have you found any solution how to keep the current TF-A and U-boot and update only the linux component?

Thanks in advance,

Piotr Piwko