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

[Bryan Brattlof]

On June 12, 2026 thus sayeth 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?

This originally spawned because the reserved memory size in Linux's DT 
was wrong. Fortunately it was a simple math error and yeah we should fit 
it there as well. But the fix exposed another issue. 

If DM _was_ to change its memory layout we don't have a way to fix it 
unless we keep the U-Boot build and Linux in sync. Unfortunately most of 
the distributions do not pin them together as tightly as we need for 
that to work.

For SoCs like the 62 you are correct. There hasn't been much of a need 
to change the memory layout at all however for devices like the AM67A, 
AM62A and AM62D we've found people are starting to use different 
firmware to help with whatever they are tasking the DSP to do.

The fdt fixup approach also has the added benefit of allowing people to 
try out different RTOS builds without having the headache of needing to 
modify DT to get the board to boot.

~Bryan