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

[Marek Vasut]

On 1/20/26 3:56 PM, Jamie.Gibbons at microchip.com wrote:
> On Tue, 2026-01-20 at 15:53 +0100, Marek Vasut wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you
>> know the content is safe
>>
>> 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 ?
> Yes, no problem. I will do so.
Thank you !