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

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

[Daniel Schultz]

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.

Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
---
 arch/arm/mach-k3/am62x/am625_init.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-k3/am62x/am625_init.c b/arch/arm/mach-k3/am62x/am625_init.c
index a422919fab1..498bbe45b38 100644
--- a/arch/arm/mach-k3/am62x/am625_init.c
+++ b/arch/arm/mach-k3/am62x/am625_init.c
@@ -84,6 +84,9 @@ static void ctrl_mmr_unlock(void)
 
 static __maybe_unused void enable_mcu_esm_reset(void)
 {
+	/* CTRLMMR_MCU_RST registers are locked again on HS-SE devices */
+	mmr_unlock(MCU_CTRL_MMR0_BASE, 6);
+
 	/* Set CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RST_EN_Z  to '0' (low active) */
 	u32 stat = readl(CTRLMMR_MCU_RST_CTRL);
 
-- 
2.25.1

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

[Sverdlin, Alexander]

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?

> Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
> ---
>  arch/arm/mach-k3/am62x/am625_init.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/mach-k3/am62x/am625_init.c b/arch/arm/mach-k3/am62x/am625_init.c
> index a422919fab1..498bbe45b38 100644
> --- a/arch/arm/mach-k3/am62x/am625_init.c
> +++ b/arch/arm/mach-k3/am62x/am625_init.c
> @@ -84,6 +84,9 @@ static void ctrl_mmr_unlock(void)
>  
>  static __maybe_unused void enable_mcu_esm_reset(void)
>  {
> +	/* CTRLMMR_MCU_RST registers are locked again on HS-SE devices */
> +	mmr_unlock(MCU_CTRL_MMR0_BASE, 6);
> +
>  	/* Set CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RST_EN_Z  to '0' (low active) */
>  	u32 stat = readl(CTRLMMR_MCU_RST_CTRL);
>  

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

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

[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.

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.

- Daniel

>
>> Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
>> ---
>>   arch/arm/mach-k3/am62x/am625_init.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm/mach-k3/am62x/am625_init.c b/arch/arm/mach-k3/am62x/am625_init.c
>> index a422919fab1..498bbe45b38 100644
>> --- a/arch/arm/mach-k3/am62x/am625_init.c
>> +++ b/arch/arm/mach-k3/am62x/am625_init.c
>> @@ -84,6 +84,9 @@ static void ctrl_mmr_unlock(void)
>>   
>>   static __maybe_unused void enable_mcu_esm_reset(void)
>>   {
>> +	/* CTRLMMR_MCU_RST registers are locked again on HS-SE devices */
>> +	mmr_unlock(MCU_CTRL_MMR0_BASE, 6);
>> +
>>   	/* Set CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RST_EN_Z  to '0' (low active) */
>>   	u32 stat = readl(CTRLMMR_MCU_RST_CTRL);
>>   

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

[bb]

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

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

[Sverdlin, Alexander]

Hi Bryan!

On Wed, 2025-09-10 at 07:08 -0500, bb@ti.com wrote:
> 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.

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?

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

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

[bb]

On September 10, 2025 thus sayeth Sverdlin, Alexander:
> Hi Bryan!
> 
> On Wed, 2025-09-10 at 07:08 -0500, bb@ti.com wrote:
> > 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.
> 
> 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.

~Bryan

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

[Sverdlin, Alexander]

Hi Bryan!

On Wed, 2025-09-10 at 07:53 -0500, bb@ti.com 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?

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

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

[bb]

On September 10, 2025 thus sayeth Sverdlin, Alexander:
> Hi Bryan!
> 
> On Wed, 2025-09-10 at 07:53 -0500, bb@ti.com 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

~Bryan

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

[Daniel Schultz]

On 9/10/25 15:26, bb@ti.com wrote:
> On September 10, 2025 thus sayeth Sverdlin, Alexander:
>> Hi Bryan!
>>
>> On Wed, 2025-09-10 at 07:53 -0500, bb@ti.com 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

- Daniel

>
> ~Bryan

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

[Wadim Egorov]

On 9/10/25 9:06 PM, Daniel Schultz wrote:
> 
> On 9/10/25 15:26, bb@ti.com wrote:
>> On September 10, 2025 thus sayeth Sverdlin, Alexander:
>>> Hi Bryan!
>>>
>>> On Wed, 2025-09-10 at 07:53 -0500, bb@ti.com 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 -- upstream@lists.phytec.de
> To unsubscribe send an email to upstream-leave@lists.phytec.de

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

[Sverdlin, Alexander]

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.
> 
> Signed-off-by: Daniel Schultz <d.schultz@phytec.de>

Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>

> ---
>  arch/arm/mach-k3/am62x/am625_init.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/mach-k3/am62x/am625_init.c b/arch/arm/mach-k3/am62x/am625_init.c
> index a422919fab1..498bbe45b38 100644
> --- a/arch/arm/mach-k3/am62x/am625_init.c
> +++ b/arch/arm/mach-k3/am62x/am625_init.c
> @@ -84,6 +84,9 @@ static void ctrl_mmr_unlock(void)
>  
>  static __maybe_unused void enable_mcu_esm_reset(void)
>  {
> +	/* CTRLMMR_MCU_RST registers are locked again on HS-SE devices */
> +	mmr_unlock(MCU_CTRL_MMR0_BASE, 6);
> +
>  	/* Set CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RST_EN_Z  to '0' (low active) */
>  	u32 stat = readl(CTRLMMR_MCU_RST_CTRL);

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

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

[bb]

On January 12, 2026 thus sayeth Wadim Egorov:
> 
> 
> On 9/10/25 9:06 PM, Daniel Schultz wrote:
> > 
> > On 9/10/25 15:26, bb@ti.com wrote:
> > > On September 10, 2025 thus sayeth Sverdlin, Alexander:
> > > > Hi Bryan!
> > > > 
> > > > On Wed, 2025-09-10 at 07:53 -0500, bb@ti.com 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