Problems booting with U-boot in Ecosystem 2.0 using the trusted bootchain

[Fee]

Hi,

we were facing trouble booting the Ecosystem 2.0 with the new U-Boot (v2020.01-stm32mp-r1).

We are using buildroot as the tool to build our distribution. With the Ecosystem 1.2 we could build everything perfectly and the booting was fine too. We used your Github to get the sources for the trusted boot chain (TF-A, OP-TEE, U-Boot, Kernel).

Recently we migrated to the new Ecosystem 2.0. When using the sources from your github directly we encountered two problems:

1. The Kernel wasn't able to load. The problem was a wrong .config file. We used your release from the wiki (the archive file with the patches) to reconstruct the .config file from that. With this new .config file it worked, the kernel got loaded. Just want to point out, that using the 'default' .config file from your github didn't work for us in case it is meant to work straight away.
2. The other problem we were facing is that the U-Boot did write the environment variables to the MMC (we have a DK2 board so in that case to the SD card). After rebooting the image check of the U-Boot was failing (see attatched log; TF-A checks the U-Boot image). Some time back I read in this forum that you plan to move the U-Boot environment variables to the end of ssbl (https://community.st.com/s/question/0D53W000004HoKgSAK/uboot-environment-configuration). Obviously that is the case now. The only way to avoid failing the second boot was to put the variables in the rootfs again (using U-Boot menuconfig). Using your .config from the archive release didn't do the trick as it did with the kernel.

We are not signing the images for now, so the checksum embedded in the header is the source for the failure of the image check (see log). The STM32 header of course isn't rewritten by U-Boot when it writes the environment variables (and it shouldn't do it of course).

My question is now, if that is some error on our side (maybe some configuration missed)? Is there some fix to get the environments in the ssbl and using the trusted boot chain?

Cheers

[Bernard PUEL]

Hello,

First you can find any reference concerning buildroot with openstlinux : https://bootlin.com/blog/building-a-linux-system-for-the-stm32mp1-basic-system/

For the kernel question:

It is normal not to have the same config in Github kernel compared to developer package.

Github kernel has only fragment 1 and 2 applied whereas on developper package your have additionnal fragment 3 to 6 related to the user land.

This way Github delivery is "userland agnostic" but this is not explaining why buildroot cannot build the kernel.

[Fee]

Hi,

thanks for your answer, I was not aware that not all config patches are applied to the Github.

To clarify, buildroot is able to build the kernel, it was just not starting when booting the DK2 Board (hanging after U-Boot 'Starting kernel' message). It was able to start when all the contig patches were applied to the kernel. Then the system boots up fine (the point 1 of my question is solved with it).

The point 2 (U-Boot problems) still remained. Obviously the image of U-Boot gets updated which then triggers the checksum error (the new checksum of the image is not matching the checksum of the .stm32 header).

[Bernard PUEL · Accepted solution]

For point 2, we can see in the trace the first boot is ok and default u-boot mmc env is stored as default. Then at the next boot the u-boot partition is corrupted (TF-A checksum failed before loading u-boot).

mmc env is stored in the same partition of u-boot so probably the pb comes from a too small partition size for u-boot (enough for u-boot but not enough for u-boot + env variables).

This is what is to check.

[Bernard PUEL]

What I also see in your trace: TFA and Optee versions are old ones (but probably due to debug trial).

[Fee]

Hi @Bernard PUEL​ ,

thanks for the support! The expansion of the ssbl partition solved the problem!