Date: Wed, 21 Dec 2022 18:09:10 -0500 From: Tom Rini trini@konsulko.com
On Wed, Dec 21, 2022 at 11:42:56PM +0100, Mark Kettenis wrote:
Date: Wed, 21 Dec 2022 16:56:37 -0500 From: Tom Rini trini@konsulko.com
On Sat, Dec 17, 2022 at 11:14:41PM +0100, Mark Kettenis wrote:
From: Eugen Hristev eugen.hristev@microchip.com Date: Thu, 15 Dec 2022 13:58:25 +0200
Newer DTC require that the DTB start address is aligned at 8 bytes. In the u-boot.bin case, the u-boot-nodtb.bin is concatenated with the DTB, but there is no alignment/padding to the next 8byte aligned address. This causes the board to fail booting, because the FDT will claim that the DTB inside u-boot.bin is not a valid DTB, it will fail with -FDT_ERR_ALIGNMENT. To solve this, have the u-boot binary `_end` aligned with 8 bytes. The objcopy in the Makefile will create the u-boot-nodtb.bin and it has to be truncated to 8 bytes to correspond to the u-boot.map file which will have the `_end` aligned to 8 bytes. The lds files which use devicetrees have been changed to align the `_end` tag with 8 bytes.
This patch is also a prerequisite to have the possibility to update the dtc inside u-boot to newer versions (1.6.1+)
Signed-off-by: Eugen Hristev eugen.hristev@microchip.com
Hi,
I could not test all affected boards, it's an impossible task. I tried this on at91 boards which I have, and ran the CI on denx. I cannot guarantee that no other boards are affected, so this patch is a bit of an RFC. If the u-boot-nodtb.bin does not have the size equal with the corresponding one in u-boot.map, the binary_size_check will fail at build time with something like this:
u-boot.map shows a binary size of 502684 but u-boot-nodtb.bin shows 502688
Thanks, Eugen
Makefile | 2 ++ arch/arm/cpu/armv8/u-boot.lds | 4 ++-- arch/arm/cpu/u-boot-spl.lds | 1 + arch/arm/cpu/u-boot.lds | 1 + arch/arm/lib/elf_arm_efi.lds | 5 +++++ arch/arm/mach-at91/arm926ejs/u-boot-spl.lds | 2 +- arch/arm/mach-at91/armv7/u-boot-spl.lds | 2 +- arch/arm/mach-zynq/u-boot-spl.lds | 2 +- arch/mips/cpu/u-boot.lds | 2 +- arch/sandbox/cpu/u-boot.lds | 6 ++++++ arch/sh/cpu/u-boot.lds | 2 ++ board/ti/am335x/u-boot.lds | 1 + tools/binman/test/u_boot_binman_embed.lds | 2 +- 13 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile index 9d84f96481..b4d387bcce 100644 --- a/Makefile +++ b/Makefile @@ -1317,6 +1317,8 @@ endif
u-boot-nodtb.bin: u-boot FORCE $(call if_changed,objcopy_uboot) +# Make sure the size is 8 byte-aligned.
- @truncate -s %8 $@
$ truncate ksh: truncate: not found
In other words: truncate(1) isn't a standard UNIX utility and not present on OpenBSD for example. It isn't part of POSIX and therefore its usage is unportable.
Please find a different solution.
Ah yes. Can this perhaps be done with dd? A bit of looking around suggests that this might be a portable way to truncate a file to say 512 bytes: dd if=/dev/urandom of=testfile bs=1 count=500 dd if=/dev/null of=testfile bs=1 count=512
And then hexdump or whatever to see that the last 12 bytes are zero. Can you please test this on OpenBSD? We'll need some shell work to get current byte size and make it 8-byte aligned, but that should be portable at least. Thanks!
Hi Tom,
That results on a file with zero bytes on OpenBSD... but also on Linux. Did you intend to write something different? I can't immediately come up with a way to do this with dd(1).
Ah, I typod that, sorry! I meant (and just re-checked): dd if=/dev/urandom of=testfile bs=1 count=500 dd if=/dev/null of=testfile bs=1 seek=512
Which here does: $ dd if=/dev/urandom of=testfile bs=1 count=500 500+0 records in 500+0 records out 500 bytes copied, 0.00641125 s, 78.0 kB/s $ dd if=/dev/null of=testfile bs=1 seek=512 0+0 records in 0+0 records out 0 bytes copied, 0.000358246 s, 0.0 kB/s $ ls -l testfile -rw-rw-r-- 1 trini trini 512 Dec 21 18:07 testfile $ hexdump testfile | tail -n2 00001f0 8cdd 300e 0000 0000 0000 0000 0000 0000 0000200
That works here as well.