On 11/16/25 3:09 PM, Tom Rini wrote:
Hello Tom,
diff --git a/boot/image-fdt.c b/boot/image-fdt.c
index 3f0ac54f76f..e88525a3846 100644
--- a/boot/image-fdt.c
+++ b/boot/image-fdt.c
@@ -189,6 +189,10 @@ int boot_relocate_fdt(char **of_flat_tree, ulong *of_size)
/* All ones means use fdt in place */
of_start = fdt_blob;
addr = map_to_sysmem(fdt_blob);
+ if (addr & 7) {
+ printf("WARNING: The 'fdt_high' environment variable
is set to ~0 and DT is at non-8-byte aligned address.\nWARNING: This system will likely
fail to boot. Unset 'fdt_high' environment variable and submit fix upstream.\n");
+ }
+
err = lmb_alloc_mem(LMB_MEM_ALLOC_ADDR, 0, &addr,
of_len, LMB_NONE);
if (err) {
I think we need to yell about it sooner.
I don't think so, for two reasons:
- If the user uses e.g. bootz to boot their kernel, which on arm32 is still
sadly happening, they wouldn't trigger this problem at all and they wouldn't
care about whichever way their fdt_high is set.
Which part of the problem? If the dtb is not 8-byte aligned the kernel
will fail. All the accessors require 8 byte alignment.
On 64bit systems, yes. On 32bit systems it is not so clear cut, they
might boot with 4-byte aligned DTs. I might be wrong about this, but if
I recall it right, bootz is very simplistic and it doesn't handle much
in terms of DT relocation, and ignores fdt_high, so the users on those
32bit systems that use bootz to boot also don't care about fdt_high much.
- If the user sets 'fdt_high' as part of their boot command, they would not
get any warning print if we warn earlier, but they would get one when they
boot and trigger this affected code path.
Maybe we need warnings in two locations ?
Maybe? I was thinking it should be around this in boot/image-fdt.c:
/* If fdt_high is set use it to select the relocation address */
fdt_high = env_get("fdt_high");
if (fdt_high) {
ulong high_addr = hextoul(fdt_high, NULL);
if (high_addr == ~0UL) {
/* All ones means use fdt in place */
This is exactly the code that this patch modifies . Where in the above
do you think this change should be ?
As that's where all of the code paths end up calling, I think. But if
it's multiple paths, yes, multiple warnings if we can't abstract it out
to a common path.
Today (and for quite some
years) if you pass a 4 byte and not 8 byte aligned DT to Linux, it fails
to boot or breaks in loud
Worse, not loud, but silent.
Also true, yes.
and odd ways. This has in turn lead to much
time spent and some of our older threads with the libfdt folks years
ago. So I think we need something earlier in code where we're seeing
that fdt_high is set to ~0 and that's where we say "Stop doing this, it
will be removed soon".
We cannot remove this functionality, someone might actually depend on it for
whatever reason. It is part of the command line ABI now.
The valid use case is boot time optimization. It's also a
micro-optimization (as actually megabyte sized device trees like when
people wanted to pass FPGA bitstreams in 15+ years ago are not allowed)
( not allowed where exactly ? fitImage is a DT too )
I think really. I am loath to break ABI like this but I'm not entirely
sure we have a choice.
We do, we simply warn users and remove the usage and fdt_high=~0
assignments from the tree. The functionality itself does not have to be
removed.
Maybe we detect disabled relocation and
misaligned device tree and fall back to prompt? Or if it's too late,
panic with an explanation? Or maybe we just move it 4 bytes higher. The
device is in a going to fail state anyhow, so trying to recover it might
be OK, and since the device tree needs to be modified by us it has to be
in writable memory.
Keep in mind, on arm32 it may not necessarily fail to boot with 4-byte
aligned DT.
