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
