[PATCH v2] scripts/dtc: Update to upstream version v1.7.2-35-g52f07dcca47c

[Marek Vasut]

On 1/20/26 3:50 PM, Jamie.Gibbons at microchip.com wrote:
> On Tue, 2026-01-20 at 15:32 +0100, Marek Vasut wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you
>> know the content is safe
>>
>> On 1/20/26 2:53 PM, Jamie.Gibbons at microchip.com wrote:
>>> Hi Marek,
>>>
>>> On Tue, 2026-01-20 at 11:58 +0100, Marek Vasut wrote:
>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you
>>>> know the content is safe
>>>>
>>>> On 1/20/26 11:45 AM, Jamie.Gibbons at microchip.com wrote:
>>>>
>>>> Hello Jamie,
>>>>
>>>>>> 2489                 debug("%s loaded at 0x%08lx
>>>>>> len=0x%08lx\n",
>>>>>> 2490                                 uname, ovload, ovlen);
>>>>>> 2491                 ov = map_sysmem(ovload, ovlen);
>>>>>> 2492
>>>>>> 2493                 ovcopylen = ALIGN(fdt_totalsize(ov),
>>>>>> SZ_4K);
>>>>>> 2494                 ovcopy = memalign(8, ovcopylen);
>>>>>> 2495                 if (!ovcopy) {
>>>>>> 2496                         printf("failed to duplicate DTO
>>>>>> before
>>>>>> application\n");
>>>>>> 2497                         fdt_noffset = -ENOMEM;
>>>>>> 2498                         goto out;
>>>>>> 2499                 }
>>>>>> 2500
>>>>>> 2501                 err = fdt_open_into(ov, ovcopy,
>>>>>> ovcopylen);
>>>>>> 2502                 if (err < 0) {
>>>>>> 2503                         printf("failed on fdt_open_into
>>>>>> for
>>>>>> DTO\n");
>>>>>>
>>>>>> This is where it fails. Is $ov or $ovcopy 4-byte aligned ?
>>>>>> Enable
>>>>>> the
>>>>>> debug() print at the beginning (or #define DEBUG at the
>>>>>> beginning
>>>>>> of
>>>>>> this file) to find out.
>>>>>>
>>>>>> If $ov is 4-byte aligned, try to generate your fitImage with
>>>>>> "mkimage
>>>>>> ... -E -B 8 ..." , does that make any difference ?
>>>>>
>>>>> Thank you for your suggestions.
>>>>>
>>>>> I followed your advice and investigated the alignment of the
>>>>> overlay
>>>>> buffer. The error code returned by fdt_open_into was
>>>>> FDT_ERR_ALIGNMENT
>>>>> (-19), confirming that the overlay was not sufficiently aligned
>>>>> for
>>>>> the
>>>>> updated libfdt.
>>>>>
>>>>> I modified our Buildroot post-image.sh script to generate the
>>>>> FIT
>>>>> image
>>>>> using the suggested arguments. With the -B 8 option, all blobs
>>>>> in
>>>>> the
>>>>> FIT image are now 8-byte aligned. This resolved the alignment
>>>>> error,
>>>>> and device tree overlays are now applied successfully in U-
>>>>> Boot.
>>>>
>>>> But this is not the fix. Which parameter of fdt_open_into() is
>>>> unaligned, the ov or ovcopy ?
>>>
>>> ov is unaligned
>> Does this help even without the mkimage -B 8 ?
>>
>> diff --git a/boot/image-fit.c b/boot/image-fit.c
>> index 2d040e38d97..49fdc1f0535 100644
>> --- a/boot/image-fit.c
>> +++ b/boot/image-fit.c
>> @@ -2481,7 +2481,7 @@ int boot_get_fdt_fit(struct bootm_headers
>> *images,
>> ulong addr,
>>                           addr, &uname, &uconfig,
>>                           arch, IH_TYPE_FLATDT,
>>                           BOOTSTAGE_ID_FIT_FDT_START,
>> -                       FIT_LOAD_IGNORED, &ovload, &ovlen);
>> +                       FIT_LOAD_OPTIONAL_NON_ZERO, &ovload, &ovlen);
>>                   if (ov_noffset < 0) {
>>                           printf("load of %s failed\n", uname);
>>                           continue;
> This solution removed this misalignment in ov and allowed the system to
> boot - without any change/additional arguments to mkimage.
Would you be willing to submit this as a bugfix ?