[PATCH 0/4] arm: mach-k3: Add DM firmware memory fixup

[Markus Schneider-Pargmann]

Hi Paresh,

On Thu Jun 11, 2026 at 8:14 PM CEST, Paresh Bhagat wrote:
> Hi Markus,
>
> Btw Had a quick look at series
>
> https://lore.kernel.org/all/20260609-topic-am62a-ioddr-dt-v6-19-v6-0-16afba97fbe0@baylibre.com/
>
> I did not know this problem was for other devices too.
>
>
> On 10/06/26 13:42, Markus Schneider-Pargmann wrote:
>> Hi Paresh,
>>
>> On Tue Jun 9, 2026 at 8:10 PM CEST, Paresh Bhagat wrote:
>>> This patch series addresses DM firmware reserved memory fixup for AM62a
>>> and AM62d:
>>>
>>> 1. AM62D is missing OF_SYSTEM_SETUP config, required for FDT fixups to
>>>     be applied before passing dtb to kernel.
>>>
>>> 2. DM firmware reserved memory region is insufficient to accommodate the
>>>     binary. Analysis of the DM firmware binary using objdump reveals that
>>>     the resource_table section and .stack section occupies memory from
>>>     0x9c900000 to 0x9e608000. So increase the reserved region size from
>>>     0xf00000 to 0x1f00000 via fdt fixup. Add new configs in Kconfig.
>> I am wondering why you chose 0x1f00000 and not 0x1d08000?
>>
>> Also for am62a the firmware linker file says it is shorter:
>>      /* DDR for DM R5F code/data [ size 27 MiB + 364 KB ] */
>>      DDR                         : ORIGIN = 0x9CAA5000 LENGTH = 0x1B5B000
>>
>>      https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62px-sk/wkup-r5fss0-0_freertos/ti-arm-clang/linker.cmd#L175
>>
>> I am wondering what is correct, the linker file or the objdump you did?
>
>
> Yes apart from the objdump output I noticed a gap between end of 
> wkup_r5fss0_core0_memory_region and start of secure_ddr. So intention to 
> fix the bug and use all of the available space.
>
>
>>
>>> 3. The existing fdt_fixup_reserved_memory() used a delete/recreate
>>>     approach which corrupted phandle references to DM node, causing DM
>>>     initialization failures. Fixed it by updating nodes in-place using
>>>     fdt_setprop() to preserve original phandles.
>> I haven't looked at the code yet, why do you use a fixup instead of
>> fixing the devicetree?
>>
>> Best
>> Markus
>
>
> I had a discussion with bryan regarding the device tree fix approach. He 
> pointed out that firmware and kernel versions can be updated 
> independently which can lead to unused reserved memory. So bootloaders 
> should dynamically update the reserved memory based on firmware 
> requirements before handing off to kernel.

Maybe I am missing something here, but isn't the firmware distributed
together with u-boot? u-boot gets the devicetree merged from upstream
every major version. So isn't a kernel update independent of
u-boot/firmware/devicetree update?

Also do updates to the memory regions of your firmware really happen
that often?

Best
Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 289 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260612/a608dcbc/attachment.sig>