On 13/01/26 05:23, 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.
>
>>>>> - 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 ?


Yeah from start... In this case, the FDT for OS is aligned, but the sub DT
from the FIT is not aligned by 8-bytes.

>
>> 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).

Instead of -E, we can use '-b' which always takes DT and make sure that is 
8-byte aligned by default:

Usage: mkimage [-D dtc_options] [-f fit-image.its|-f auto|-f auto-conf|-F] [-b 
<dtb> [-b <dtb>]] [-E] [-B size] [-i <ramdisk.cpio.gz>] fit-image
-b => append the device tree binary to the FIT

Thanks,
Beleswar

Reply via email to