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.
Andrew
~Bryan
