[PATCH v4] tools: fit_image: Fallback to 8-byte alignment for flat_dt images

[Marek Vasut]

On 1/28/26 4:26 PM, Padhi, Beleswar wrote:
> 
> On 1/28/2026 8:26 PM, Marek Vasut wrote:
>> On 1/28/26 3:18 PM, Beleswar Padhi wrote:
>>> From: Marek Vasut <marek.vasut+renesas at mailbox.org>
>>
>> Please drop this , it isnt needed.
>>
>>> When CONFIG_SPL_MULTI_DTB_FIT is enabled, multiple device trees are
>>> packed inside the multidtb.fit FIT image. While the individual DTBs
>>> and the FIT image start address are 8-byte aligned, the DTBs embedded
>>> within the FIT image are not guaranteed to maintain 8-byte alignment.
>>>
>>> This misalignment causes -FDT_ERR_ALIGNMENT failure in
>>> setup_multi_dtb_fit() when locating the next available DTB within the
>>> FIT blob and setting gd->fdt_blob, because of the recent libfdt
>>> hardening since commit 0535e46d55d7 ("scripts/dtc: Update to upstream
>>> version v1.7.2-35-g52f07dcca47c")
>>>
>>> To fix this, check the image type when extracting
>>
>> "extracting" ? This code changes mkimage, so not "extracting" but 
>> "packing" (into fitImage), right ?
> 
> 
> Well the function name is fit_extract_data(). It is documented as 
> extracting
> all the data properties of a node to the end of the fit. So just keeping 
> the
> same terminology. Its obviously not in the same context as extracting data
> out of a FIT image to consume information...

... check the image type when moving image data at the end of the tree 
... or something like that ?

>>> FIT image data and
>>> set the alignment size to 8 bytes (if not already) only for flat_dt
>>> images. This ensures correct alignment for device tree blobs as per the
>>> DT spec, while also allowing different alignment sizes for other image
>>> types within the FIT.
>>
>> [...]
>>
>>> diff --git a/tools/fit_image.c b/tools/fit_image.c
>>> index e865f65a400..f842c845771 100644
>>> --- a/tools/fit_image.c
>>> +++ b/tools/fit_image.c
>>> @@ -682,9 +682,17 @@ static int fit_extract_data(struct 
>>> image_tool_params *params, const char *fname)
>>>       for (node = fdt_first_subnode(fdt, images);
>>>            node >= 0;
>>>            node = fdt_next_subnode(fdt, node)) {
>>> -        const char *data;
>>> +        const char *data, *type;
>>>           int len;
>>>   +        /* Fallback to 8-byte alignment for DTBs if unaligned */
>>> +        type = fdt_getprop(fdt, node, FIT_TYPE_PROP, &len);
>>> +        if (type &&
>>> +            len == sizeof("flat_dt") &&
>>> +            !memcmp(type, "flat_dt", len) &&
>>> +            align_size & 0x7)
>>
>> What will be the resulting alignment if align_size = 0x1f ? 8 right ? 
>> I think it should be 0x20 .
> 
> 
> I thought we agreed on resetting align_size to 8 if its not already aligned
> (regardless if < or > 8) in v3 version of this patch[0]. Do we really 
> have to
> align the align_size var itself? It seems like a overkill to me...
Maybe simply call round_up(8) on the align_size , to align to the next 
8-byte aligned offset , but somewhat respect user wishes ?

But looking at this code one more time , look at the calloc() in this 
function, I think you might also have to allocate a bit more memory to 
really hold all the newly aligned DTs, right ?

Also, don't you need to align the buf_ptr as well ? Consider a scenario 
where the fitImage contains two images, one ends at 4-byte aligned 
address, followed by a DT. The users passes -B 4 to mkimage, and I think 
buf_ptr would then be 4-byte aligned, so will the DT, no ?