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