On January 12, 2026 thus sayeth Wadim Egorov:
>
>
> On 9/10/25 9:06 PM, Daniel Schultz wrote:
> >
> > On 9/10/25 15:26, [email protected] wrote:
> > > On September 10, 2025 thus sayeth Sverdlin, Alexander:
> > > > Hi Bryan!
> > > >
> > > > On Wed, 2025-09-10 at 07:53 -0500, [email protected] wrote:
> > > > > > > > > > The watchdog requires to have the MCU ESM error source
> > > > > > > > > > enabled to
> > > > > > > > > > trigger a system reboot. When booting HS-SE (security
> > > > > > > > > > enforced)
> > > > > > > > > > devices, the MMR registers are locked again and all write
> > > > > > > > > > commands
> > > > > > > > > > are simply ignored.
> > > > > > > > > >
> > > > > > > > > > Unlock the MMR registers again to successfully enable the
> > > > > > > > > > MCU ESM
> > > > > > > > > > source.
> > > > > > > > > I'm just curious, could you please elaborate
> > > > > > > > > a bit, where the registers
> > > > > > > > > are being locked again if they are being
> > > > > > > > > unlocked by ctrl_mmr_unlock()
> > > > > > > > > in board_init_f() before enable_mcu_esm_reset()?
> > > > > > > > >
> > > > > > > > > Is it TIFS firmware?
> > > > > > > > > What else could be affected?
> > > > > > > > > Do we expect to leave General Purpose Control Registers
> > > > > > > > > unlocked
> > > > > > > > > when we return from board_init_f()?
> > > > > > > > > Does it mean that the whole ctrl_mmr_unlock() has to be
> > > > > > > > > re-done
> > > > > > > > > after k3_sysfw_loader() call?
> > > > > > > > I really can't tell why those registers are
> > > > > > > > locked again. I figured out
> > > > > > > > they're only locked again after loading the TIFS
> > > > > > > > firmware on HS- SE devices.
> > > > > > > > So, I also assume the firmware itself locks
> > > > > > > > those registers again as part of
> > > > > > > > a secure/security feature.
> > > > > > > Hmm yeah this is likely a bug or a config issue. Ideally we
> > > > > > > (U-Boot/Linux) should be in complete control of when
> > > > > > > these are locked or
> > > > > > > unlocked. TIFS or DM shouldn't be anywhere near these MMRs.
> > > > > > >
> > > > > > > > The A53 SPL will unlock those registers again,
> > > > > > > > which will be permanent. Only
> > > > > > > > the watchdog is problematic because
> > > > > > > > enable_mcu_esm_reset is currently only
> > > > > > > > called in the R5 SPL (config only enabled in the R5 SPL
> > > > > > > > defconfig).
> > > > > > > >
> > > > > > > > BTW: We have seen the same behavior with the AM68A/J721S2.
> > > > > > > Hmm this is strange.
> > > > > > Thanks for your assessment!
> > > > > > Do you know who can be contacted at TI regarding this
> > > > > > possible problem in
> > > > > > TIFS firmware? Maybe this has to be fixed in TIFS firmware indeed?
> > > > > I've started creating some noise internally to see if we can debug
> > > > > this
> > > > > faster. Most of these teams are fairly insulated from the outside
> > > > > world
> > > > > and can only be reached via e2e tickets.
> > > > Thanks for looking into this!
> > > > I read it as if we would not need to create an e2e ticket for now?
> > > That's correct. I short circuited the e2e process by creating a bug and
> > > messaging a few people internally to jump start the process:
> > >
> > > https://sir.ext.ti.com/jira/browse/EXT_EP-12916
> >
> > Just for reference, I already opened an e2e post some weeks ago:
> > https://e2e.ti.com/support/processors-group/processors/f/processors-
> > forum/1511852/am625-am62x-hs-se-spl-cannot-write-to-
> > mcu_mmr0_rst_ctrl/5813164#5813164
>
> I would like to know if we can proceed with Daniels patch.
> The reply in the E2E post suggests more or less the same change.
Hey! Sorry for the delay, I don't think the ticket went anywhere :(
I played around with an HS-SE configured 62P-SK board for a few hours
today to see if I could reproduce what we're seeing here.
I know the TRM doesn't really describe this but the first bit (bit 0) in
the LOCK*_KICK* registers indicate if the MMR regions is locked or
unlocked. So initially I added some prints so I could at-least see if
the 62P SoCs are doing the same thing.
diff --git a/arch/arm/mach-k3/am62px/am62p5_init.c
b/arch/arm/mach-k3/am62px/am62p5_init.c
index 599ea7cf2dd8..b474802ed694 100644
--- a/arch/arm/mach-k3/am62px/am62p5_init.c
+++ b/arch/arm/mach-k3/am62px/am62p5_init.c
@@ -104,6 +104,7 @@ static __maybe_unused void enable_mcu_esm_reset(void)
void board_init_f(ulong dummy)
{
+ uintptr_t a = MCU_CTRL_MMR0_BASE + (4 * CTRL_MMR0_PARTITION_SIZE) +
CTRLMMR_LOCK_KICK0;
struct udevice *dev;
int ret;
@@ -122,6 +123,7 @@ void board_init_f(ulong dummy)
ret = spl_early_init();
if (ret)
panic("spl_early_init() failed: %d\n", ret);
+ u32 u = readl(a) & 0x1;
/*
* Process pinctrl for the serial0 and serial3, aka WKUP_UART0 and
@@ -183,6 +185,7 @@ void board_init_f(ulong dummy)
}
preloader_console_init();
+ printf("MCU_CTRL_MMR_CFG0_LOCK4_KICK0 is: %s\n", u ? "open" :
"locked");
/* Output System Firmware version info */
k3_sysfw_print_ver();
What I didn't expect was it looks like the R5 SPL is not unlocking the
MMR partitions at all[0] and relying on the A53 SPL to unlock them later
on during bootup. Even moving the readl(a) further up could actually
break boot.
What is odd is moving the ctrl_mmr_unlock() to after the
spl_early_init() gets the R5 SPL to unlock the MMRs for me[1]
diff --git a/arch/arm/mach-k3/am62px/am62p5_init.c
b/arch/arm/mach-k3/am62px/am62p5_init.c
index b474802ed694..e6400b9d09d4 100644
--- a/arch/arm/mach-k3/am62px/am62p5_init.c
+++ b/arch/arm/mach-k3/am62px/am62p5_init.c
@@ -117,12 +117,14 @@ void board_init_f(ulong dummy)
*/
store_boot_info_from_rom();
- ctrl_mmr_unlock();
/* Init DM early */
ret = spl_early_init();
if (ret)
panic("spl_early_init() failed: %d\n", ret);
+
+ ctrl_mmr_unlock();
+
u32 u = readl(a) & 0x1;
The only thing running this early during boot is the TIFS vendor
firmware and this R5 U-Boot SPL which makes me think this is most likely
some type of race between TIFS firmware unlocking a firewall or
something along those lines.
Moving the readl(a) above the ctrl_mmr_unlock()[2] seems to indicate
nothing is actually locking the regions again so it's probably a timing
related thing.
diff --git a/arch/arm/mach-k3/am62px/am62p5_init.c
b/arch/arm/mach-k3/am62px/am62p5_init.c
index e6400b9d09d4..81b2c279bedd 100644
--- a/arch/arm/mach-k3/am62px/am62p5_init.c
+++ b/arch/arm/mach-k3/am62px/am62p5_init.c
@@ -123,10 +123,10 @@ void board_init_f(ulong dummy)
if (ret)
panic("spl_early_init() failed: %d\n", ret);
- ctrl_mmr_unlock();
-
u32 u = readl(addr) & 0x1;
+ ctrl_mmr_unlock();
+
/*
* Process pinctrl for the serial0 and serial3, aka WKUP_UART0 and
* MAIN_UART1 modules and continue regardless of the result of
pinctrl.
What I haven't determined yet is what is actually blocking us from
writing to the KICK register and if TIFS firmware is doing anything to
help us. If they are then we may need to move the ctrl_mmr_unlock()
until after we know TIFS is ready.
Sorry for not pushing this harder internally
~Bryan
[0] https://paste.sr.ht/~bryanb/546373815c73894943685d1560937b586e4f5eee
[1] https://paste.sr.ht/~bryanb/6cde0b6595ec903b5791fe6a9305050f28e15ba7
[2] https://paste.sr.ht/~bryanb/89f3ae8232bd9644fa6ff107b48d34c3e0c11e9e
