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

[Markus Schneider-Pargmann]

Hi Bryan,

On Fri Jun 12, 2026 at 3:55 PM CEST, Bryan Brattlof wrote:
> 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.

Thanks for explaining. If you prefer the fixups, can you please change
the code to be able to work with both layouts as documented in the
binding documentation?

  oneOf:
    - description: Basic layout
      items:
        - description: region used for dynamic DMA allocations like vrings and
                       vring buffers
        - description: region reserved for firmware image sections
    - description: Detailed layout
      items:
        - description: region used for dynamic DMA allocations like vrings and
                       vring buffers
        - description: region reserved for IPC resources
        - description: LPM FS stub binary
        - description: LPM metadata
        - description: LPM FS context data and reserved sections
        - description: DM RM/PM trace and firmware code/data

You can use the memory-region-names to know what is what.

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/20260619/75a532f0/attachment.sig>