[PATCH] arm: mach-k3: am625: Unlock MMR registers again

[bb at ti.com]

On September 10, 2025 thus sayeth Daniel Schultz:
> Hi Alexander,
> 
> On 8/21/25 18:21, Sverdlin, Alexander wrote:
> > Dear Daniel, TI team,
> > 
> > On Fri, 2025-08-15 at 09:02 -0700, Daniel Schultz 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.

~Bryan