On Tue, Jan 13, 2026 at 12:53:39AM +0100, Marek Vasut wrote: > On 1/12/26 11:03 PM, Tom Rini wrote: > > > > > This we can fix in the Makefile via the dd command as suggested by Tom. > > > > > > My concern is about LEGACY fitImages (means already generated ones), not > > > newly generated ones. > > > > Why is that a concern? If it's a legacy fitImage for the OS, we relocate > > the device tree already normally to be aligned. If it's a legacy > > fitImage of U-Boot, it's an old U-Boot? > > Not necessarily, it could be new U-Boot using old fitImage, for whatever > reason (falcon boot maybe ?). We should not break that.
If it's falcon boot then it's the OS case and we relocate it before passing on, that's not changed. That's why I'm saying I'm not sure there's a legacy case to worry about, since the big change now is that U-Boot also demands correctly aligned device trees. The Linux Kernel essentially always has, and other OSes probably as well. We were just bad and let 4-byte work for so long. > > > > > - Should mkimage -E align blobs to 8 bytes by default ? I think yes, > > > > > and frankly, I thought it does so already, but apparently not. > > > > > > > > > > > > This can be done, but should it be? Not all FITs demand an 8-byte > > > > alignment right? It is only the FDT which requires this. > > > Maybe if image type is flat_dt, it should be implicitly 8-byte aligned > > > then > > > ? > > > > Well, the device tree spec says 8-byte alignment. > > 8 byte alignment of what, start of DT, right ? > > > It's not "FDT for OS" > > that's 8-byte, it's any device tree should start out 8 byte aligned, and > > everything else should then be naturally aligned. If we're looking in a > > device tree for another device tree to use in place and not relocate > > then that second tree must be aligned. > > > > Or am I missing something? > The discussion is about mkimage -E which generates DTs for U-Boot SPL use. > The DTs in those external data should likely be aligned to 8 bytes by > default, i.e. implicitly set -B 8 (they don't seem to be right now). Right. So the only legacy case I can see would be using an old mkimage to generate a current U-Boot image. And I'm not super sure that can happen, outside of some sort of external to us tooling being wrapped around things, and at that point we have little control. -- Tom
signature.asc
Description: PGP signature
