On January 9, 2026 thus sayeth Andrew Davis: > On 1/9/26 7:18 AM, Bryan Brattlof wrote: > > 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? > > > > > Who is "we" here? The MCU+ team making the current example DM firmware > are part of TI too, let's not act like they are some outside force we > just have to live with their decision to hard-code this.. > > Nothing is stopping us from telling the DM firmware (at runtime even) > where to put the LPM saved data, or we can have some mechanism to find > it from the DM firmware itself. > > > > > 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 :/ > > Zephyr :) > > It isn't ready yet, but Zephyr based DM firmware isn't an impossibility. > And many of these limitations will no longer apply. All I want to do is > make sure we do not bake-in the brittleness and random hard-coded offsets > into U-Boot, especially when it may not even apply to future firmware. > > So to solve the problem today I'd suggest, instead of assuming > r5f-dma-memory@9c900000 + offset 0x108000, make a new DT node specifically > for storing the LPM. The address of the node can be the same as firmware > hard-codes it today, here you just read the node address directly. Then > should that node disappear someday, U-Boot can go down a different path. > This gives us a way to identify that future situation, while also just > being less hacky IMHO than using hard-coded offsets. >
This is a good approach. We already inject space for other boot critical firmware and the IPC space they use for Linux during bootup. And we can reclaim the space if someone chooses to disable this feature. ~Bryan
