[Buildroot] [RFC PATCH] stm32mp1: modify gpt partitions to fix BSP update
Peter Korsgaard
peter at korsgaard.com
Sat Feb 6 17:49:38 UTC 2021
>>>>> "Sergey" == Sergey Matyukevich <geomatsi at gmail.com> writes:
> Hi all,
> BSP update for stm32mp1 boards does not work right out of the box. The
> first boot is ok, but the second boot fails:
> NOTICE: CPU: STM32MP157CAC Rev.B
> NOTICE: Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
> NOTICE: Board: MB1272 Var2.0 Rev.C-01
> NOTICE: BL2: v2.4(release):2020.11-1087-g8fac193e6d-dirty
> NOTICE: BL2: Built : 20:58:09, Jan 27 2021
> ERROR: Checksum: 0x5023a37 (awaited: 0x5046ea4)
> ERROR: Header check failed
> ERROR: BL2: Failed to load image id 5 (-12)
> The root cause is in changes for stm32mp1 trusted defconfig in updated
> U-Boot: see U-Boot commit 76db1681da52 ("stm32mp1: use a specific SD/eMMC
> partition for U-Boot enviromnent"). Starting from that commit, U-Boot
> environment is stored at the end of the U-Boot partition. As a result,
> saving environment changes GPT partition checksum verified by ATF.
> IIUC at least the following two approaches can be implemented to make
> updated BSP work smoothly.
> The first approach is to modify U-Boot config fragment for stm32mp1 boards
> and to re-enable saving U-Boot environment on ext4. However this choice
> implies certain restriction on rootfs ext4 features since it should be
> writable by U-Boot. See the mentioned U-Boot commit message for details.
> Another approach is implemented by the attached patch: keep U-Boot
> environment on a dedicated GPT partition.
> Thoughts ? Comments ?
If upstream wants to use a separate partition for the environment, then
that is fine by me - But I would prefer to not patch u-boot and just
name the environment partition ssbl.
--
Bye, Peter Korsgaard
More information about the buildroot
mailing list