On Jan 08, 2026 at 09:51:32 -0600, Bryan Brattlof wrote:
> On January 8, 2026 thus sayeth Bryan Brattlof:
> > On January 8, 2026 thus sayeth Akashdeep Kaur:
> > > Hi Andrew,
> > >
> > > On 06/01/26 22:53, Andrew Davis wrote:
> > > > On 1/5/26 10:38 AM, Markus Schneider-Pargmann (TI.com) wrote:
> > > > > Add a small helper that uses memory regions referenced by the R5
> > > > > devicetree node to calculate the LPM meta data address.
> > > > >
> > > > > Signed-off-by: Markus Schneider-Pargmann (TI.com) <[email protected]>
> > > > > ---
> > > > > arch/arm/mach-k3/am62xx-lpm-common.c | 45
> > > > > ++++++++++++++++++++++++++ ++++++++++
> > > > > arch/arm/mach-k3/am62xx-lpm-common.h | 1 +
> > > > > 2 files changed, 46 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm/mach-k3/am62xx-lpm-common.c
> > > > > b/arch/arm/mach-k3/ am62xx-lpm-common.c
> > > > > index
> > > > > fa068c60ce9ccf9cec89aeae1d224b07091a3298..6870395aec838949b5c25a32262a6c30e6c88d2e
> > > > > 100644
> > > > > --- a/arch/arm/mach-k3/am62xx-lpm-common.c
> > > > > +++ b/arch/arm/mach-k3/am62xx-lpm-common.c
> > > > > @@ -9,6 +9,8 @@
> > > > > #include <config.h>
> > > > > #include <asm/arch/hardware.h>
> > > > > #include <asm/io.h>
> > > > > +#include <dm/of_access.h>
> > > > > +#include <dm/ofnode.h>
> > > > > #include <linux/soc/ti/ti_sci_protocol.h>
> > > > > #include <vsprintf.h>
> > > > > #include <wait_bit.h>
> > > > > @@ -48,6 +50,8 @@
> > > > > #define WKUP_CTRL_MMR_CANUART_WAKE_OFF_MODE_STAT 0x18318
> > > > > #define WKUP_CTRL_MMR_CANUART_WAKE_OFF_MODE_STAT_MW 0x555555
> > > > > +#define K3_R5_MEMREGION_LPM_METADATA_OFFSET 0x108000
> > > > > +
> > > >
> > > > Could this offset into the R5's second reserved memory area change based
> > > > on the firmware used? Actually this whole thing feels hacky. Why not
> > > > just add the location to DT explicitly instead of trying to derive it.
> > >
> > > The offset value of LPM Metadata in linker file will always be relative to
> > > the position of DM's reserved memory region in DDR.
> > >
> > > Reference:
> > > https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62ax-sk/r5fss0-0_freertos/ti-arm-clang/linker.cmd#L169
> > >
> >
> > Does this work currently? Linux today doesn't have these properties in
> > the Wakup R5 node and from these linker files[0][2] they look hard coded
> > to addresses we do not have a carveout[1][3] for.
> >
>
> I'm sorry I hit send a little to quickly. This is starting to make sense
> to me now.
>
> DDR and DDR_LPM_DATA is covered by wkup_r5fss0_core0_memory_region{}
>
> and DDR_IPC_VRING_LINUX, DDR_IPC_RESOURCE_TABLE_LINUX,
> DDR_IPC_TRACE_LINUX is covered by wkup_r5fss0_core0_dma_memory_region{}
>
> Can we use those nodes?
Yes, and that's kinda what we're doing :)
*meta_data_addr += K3_R5_MEMREGION_LPM_METADATA_OFFSET;
The meta_data_addr comes from one of the reserved DT nodes.
r5f-dma-memory@9c900000 + The offset 0x108000 gives us what we want.
Is this approach acceptable now that the idea of this offset
is clear, and that it's not some independent address on it's own that
we're #defining here?
>
> > If we haven't started on the Linux side it appears an easier path is
> > to put the carveout directly in the reserved-memory{} nodes or to put
> > the information into the board files and let U-Boot reserve the memory
> > during bootup.
> >
> > Or at least some way to make this more flexible than this. This feels
> > very brittle.
> >
> > [0]
> > 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#L173
> > [1]
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts#n47
> > [2]
> > https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62ax-sk/r5fss0-0_freertos/ti-arm-clang/linker.cmd#L172
> > [3]
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
> >
> > > >
> > > > Actually, don't we pick this address as part of the
> > > > TISCI_MSG_PREPARE_SLEEP?
> > >
> > > This is not done as a part of PREPARE SLEEP message. As DM is the one
> > > reserving static memory for LPM, it is already aware of the address where
> > > context needs to be saved.
> >
> > >
> > > > Or does DM do it now, either way there must be some better way to
> > > > coordinate
> > > > between DM and R5 SPL than hardcoded offsets..
> >
> > +1 with the number of carveouts for DSP, VPAC, MCU firmware we have on
> > these SoCs juggling all the careouts for the different use cases and DDR
> > densities is going to become a problem.
> >
> > ~Bryan
--
Best regards,
Dhruva Gole
Texas Instruments Incorporated
