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.
- Daniel
~Bryan
_______________________________________________
upstream mailing list -- [email protected]
To unsubscribe send an email to [email protected]
