[PATCH 1/1] image: fit: Apply overlays on a writable FDT copy

[Marek Vasut]

On 2/9/26 8:57 AM, James Hilliard wrote:
> On Sun, Feb 8, 2026 at 4:19 PM Marek Vasut <marek.vasut at mailbox.org> wrote:
>>
>> On 2/8/26 11:37 PM, James Hilliard wrote:
>>> boot_get_fdt_fit() relocates the base FDT with boot_relocate_fdt()
>>> before applying overlays. That uses the bootm memory map and can
>>> overlap with the FIT buffer when the FIT is loaded into RAM, corrupting
>>> data needed to load the kernel and ramdisk.
>>>
>>> Allocate a writable copy of the base FDT with memalign() and
>>> fdt_open_into(), grow it as needed for each overlay, and apply the
>>> overlays to this buffer. Also check fdt_pack() errors and free the
>>> temporary overlay copy after each application.
>>>
>>> Fixes: 881f0b77dc8c ("image: apply FDTOs on FDT node")
>>> Signed-off-by: James Hilliard <james.hilliard1 at gmail.com>
>> This code is starting to be super-convoluted. Can you please have a look
>> at [1] and see if that can be somehow extended to cover this ? I think
>> it should trim the complexity, but it likely needs a bit more work.
> 
> Hmm, that kinda looks like it's solving a different issue? At least I'm
> not really seeing an obvious way an alignment refactor like that
> would help with this issue with a bad relocation corrupting the FIT
> buffer.
> 
> I agree the code here is a bit convoluted, so maybe I'm missing the
> relation between the fdt alignment and the relocation location issues.

Well, if the FDT embedded in a fitImage is at 4-Byte aligned address, it 
has to be copied into a temporary buffer before the DTO is applied. In 
your case, if the FDT is embedded in the fitImage period, it has to be 
copied into a temporary buffer. It seems to be almost the same thing, is 
it not ? Note that the temporary buffer would be mallocated, and 
therefore out of harms way ?