AM625: Software watchdog not working on HS-SE devices

Hello Matthias,

Let me ask around with some of my team mates. Please ping the thread if we have not replied by Monday.

Regards,

Nick

Hello Nick,

it is Monday ;-)

Matthias

Hello Matthias,

Thank you for the ping.

The patch looks like a fine workaround, but I suspect that it does not address the actual source of the behavior.

As far as I can tell from looking at am625_init.c, function board_init_f() unlocks all the control MMRs with ctrl_mmr_unlock(). I do not see any code in the _init file that explicitly locks the control MMRs, so it looks like the intent is that the control MMRs should still be unlocked when function board_init_f() calls enable_mcu_esm_reset(). If your observations are correct, then HS-SE processors execute different code between ctrl_mmr_unlock() and enable_mcu_esm_reset() than HS-FS, and that different code re-locks the control MMRs. I am not sure if that behavior for HS-SE is intentional or not.

At some point in the board_init_f function, print statements become possible (Not sure where exactly but we see printf statements start to pop up). So you could use that to narrow down at what point the MMRs get re-locked.

I am not sure if we are tracking this behavior yet. I can file a bug based on your input (not filed yet). I cannot guarantee that we will have updated code by the December SDK release, but you could also submit a patch to upstream or the ti-u-boot repo (I think?).

Regards,

Nick

Hi Nick,

I came to the same conclusion - or more specifically, the person that wrote the patch came to the same conclusion.

I would welcome if you can track this.

While I haven't verified it, my assumption is that this relocking is done as part of the starting of the external FW at https://github.com/TexasInstruments/ti-u-boot/blob/ti-u-boot-2025.01/arch/arm/mach-k3/am62x/am625_init.c#L247

So I guess this is were the ARM Trusted Firmware is either started or triggered to execute something.

We haven't touched the ARM Trusted Firmware yet, and I would welcome if it stayed that way.

Hi Nick,

I have just realized that my previous comment is incorrect:

As CONFIG_K3_LOAD_SYSFW is not set in the configuration files, this part cannot be responsible for locking the registers...

I need to do some further analysis.

I have some U-Boot configurations that will later allow the Linux kernel to make the watchdog reset the system, but it was no longer necessary to unlock those registers again.

Is there a definitive way to figure out if these registers are still locked?

I would assume that if a write access works, that these registers are not locked, but early access to it let the system crash.

Access later simply works ... now.

When I read back the value from the kick registers that are written to to unlock access, I always read back the proper unlock data...

Writing to these registers worked the last time, so the "problem" with my current configuration might simply be that all of a sudden my registers are no longer locked and I don't know why...

Hello Mattias,

Interesting.

Based on the TRM, it looks like we should be able to read the UNLOCKED bit of the LOCKi_KICK0 register in order to see if a section is locked or not:

The LOCKi_KICK0 and LOCKi_KICK1 registers are used for this purpose. A write is required first to the LOCKi_KICK0[31-1] KEY field and then to the LOCKi_KICK1[31-0] KEY field with exact data values to unlock the protection mechanism. Once released then all registers within Partition "i" having write permissions can be written to. The read only registers are still read only. An indication for unlocked Partition "i" is when the LOCKi_KICK0[0] UNLOCKED bit is set to 1h. When the protection mechanism is locked (indicated by LOCKi_KICK0[0] UNLOCKED = 0h) none of the registers within Partition "i" can be written to.

Regards,

Nick

Hi Nick,

I got back to the state where I can see that I cannot modify the registers.

I assume I simpy got lost between "This code is executed on the R5 processor" and "This code is executed on the A53 processor".

This is also true for the following thing I wrote:

"As CONFIG_K3_LOAD_SYSFW is not set in the configuration files, this part cannot be responsible for locking the registers..."

K3_LOAD_SYSFW is not set in the A53 config, but it is set in the R5 config.

I still have the following problem. I cannot reliably detect when the register access is locked again.

I have written the following test function:

bool mmr_is_locked(uintptr_t base, u32 partition) {
    u32 kick0;

    /* Translate the base address */
    uintptr_t part_base = base + partition * CTRL_MMR0_PARTITION_SIZE;

    kick0 = readl(part_base + CTRLMMR_LOCK_KICK0);

    return !(kick0 & 0x1);    // only first bit determines if locked
}

It works fine when I call it late during the boot process, but then the register is already locked again.

When I call it early, most specifically immediately after I unlock register access with a call to ctrl_mmr_unlock(), the system will simply lock up. This feels particularly weird as both _unlock and _is_locked access the identical registers, but is_locked reads it and _unlock will simply write to it.

What I have done now is that I test for the locking status:

static __maybe_unused void enable_mcu_esm_reset(void)
{
       bool locked;
       u32 stat;

       /* Register access is locked again on HS-SE devices */
       locked = mmr_is_locked(MCU_CTRL_MMR0_BASE, 6);
       if (locked)
               mmr_unlock(MCU_CTRL_MMR0_BASE, 6);

        /* Set CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RST_EN_Z  to '0' (low active) */

       stat = readl(CTRLMMR_MCU_RST_CTRL);
 
        stat &= RST_CTRL_ESM_ERROR_RST_EN_Z_MASK;
        writel(stat, CTRLMMR_MCU_RST_CTRL);

       /* Restore old setting */
       if (locked)
               mmr_lock(MCU_CTRL_MMR0_BASE, 6);
}

I can also attach the complete patch file here.

Nick, you have wrote about suggesting that for the ti-u-boot repo? Is there a mailing list / contact possibility specific for that?

Apart from the potential race condition I assume that a similar issue will also exist on AM62px AM62Lx, AM62ax and I don't have access to all of these SOMs, so a fix that would be provided at some point by TI would be highly welcome.

Hi Nick Saulnier 

What do you think about the suggested patch from my previous answer?

Could this be something that could / should be integrated in the U-Boot delivery from TI? You wrote about ti-uboot-repo, but I wouldn't know how to contact them...

Hello Matthias,

Apologies for the delayed responses here. Running out of time for today, let me check on preferred method to submit patches.

Regards,

Nick

Matthias Proske said:

Can you comment on this patch?

Yes , Please comment and post your feedback in u-boot mailing list u-boot@lists.denx.de for  https://lists.denx.de/pipermail/u-boot/2025-August/596717.html 

Matthias Proske said:

Best-case scenario: Can you provide a fix in the next release?

The next release will be 12.x baseline which comes with LTS migration and u-boot version migration atleast to 2026.01 version .

Once fix is mainlined will backport it accordingly to ti-u-boot-2026.0x version towards 12.0 release.

Okay, so there is "just" the normal U-Boot mailing list...

(I hope that doesn't sound too negative, that is not my intention)...

A similar patch has already been posted here: 

https://lists.denx.de/pipermail/u-boot/2025-August/596717.html

The response has been more curiosity:

- Where does the unlocking actually happen?

- Should it remain unlocked for future operations as well?

The original author didn't seem to have the answers and the thread ran dry.

I also don't know where the locking happens. I would assume that this comes from the TIFS firmware.

That would also mean that my patch could introduce a race condition.

This was also why I wrote about *a fix* and not *my fix*, because I assume that something better should go upstream, but for that I would either need a lot more time (for which I don't have the resources), or additional information on what is going on here..

Given that I would consider this a bug in the SW delivery from TI and that more AM62xxx variantes might be affected, I was hoping for more initiative from TI.