STM32F429 has a peculiar arrangement for flash sector size. Starting at 0x08000000, the sectors are (total flash size is 2M): (4 x 16K) + (1 x 64K) + (7 x 128K) + (4 x 16K) + (1 x 64K) + (7 x 128K)
Current U-Boot code for STM32F429 uses the following flash layout: - 0x08000000 : U-Boot (256K) - 0x08040000 : U-Boot env (8K) - 0x08042000 : DTB (8K) - 0x08044000 : Linux kernel
With this layout, environment, DTB and first part of kernel are in the same sector of 128K. U-Boot command "saveenv" erases the whole sector, deleting both DTB and kernel!
Splitting environment, DTB and kernel in independent flash sectors is the correct way to go, but we should avoid wasting big sectors of 128K for the tiny environment and DTB.
Since the reset entry point is fixed at 0x08000000, a good solution is to use a simple SPL to jump ahead, so the initial small sectors become available for env and DTB. But the new flash layout will then look a little upside-down: - 0x08000000 : SPL (16K) - almost only a "goto 0x0800c000" - 0x08004000 : U-Boot env (16K) - 0x08008000 : DTB (16K) - 0x0800c000 : U-Boot (16K + 64K + 128K) - 0x08040000 : Linux kernel
I have already run some experiment recompiling U-Boot for the new target address 0x0800c000. The SPL can be as simple as extracting the first 8 bytes from the binary of U-Boot compiled for 0x0800c000. A more complete SPL could print a welcome msg on console, check that the content at 0x0800c000 is reasonable for a U-Boot binary then either print an error msg or jump to U-Boot.
Before sending patches, I would like to get confirmation that the proposed flash layout can be accepted. Any other target in U-Boot that has similar flash layout constraint?
Also, does it make sense to build a full SPL when a simple dd bs=8 count=1 if=u-boot.bin of=spl/u-boot-spl.bin can already provide a working solution?
Regards, Antonio