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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
