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

[Marek Vasut]

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 ?