On January 8, 2026 thus sayeth Dhruva Gole: > 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? >
Yeah I don't think I have a better idea. It looks like quite a lot of stuff in the MCU+ toolchain is hard coded and incredibly brittle. This being so brittle and hacky is an unfortunate side effect. I wish there was a better way :/ ~Bryan
