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?
> 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
