> Date: Wed, 21 Dec 2022 16:56:37 -0500 > From: Tom Rini <tr...@konsulko.com> > > On Sat, Dec 17, 2022 at 11:14:41PM +0100, Mark Kettenis wrote: > > > From: Eugen Hristev <eugen.hris...@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.hris...@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). Cheers, Mark