From: Daniel Schultz <d.schultz@phytec.de>
To: "bb@ti.com" <bb@ti.com>,
"Sverdlin, Alexander" <alexander.sverdlin@siemens.com>
Cc: "upstream@lists.phytec.de" <upstream@lists.phytec.de>,
"trini@konsulko.com" <trini@konsulko.com>,
"s-vadapalli@ti.com" <s-vadapalli@ti.com>,
"u-boot@lists.denx.de" <u-boot@lists.denx.de>,
"c-vankar@ti.com" <c-vankar@ti.com>,
"kishon@ti.com" <kishon@ti.com>
Subject: Re: [PATCH] arm: mach-k3: am625: Unlock MMR registers again
Date: Wed, 10 Sep 2025 16:06:24 +0200 [thread overview]
Message-ID: <50c51eea-af1f-48ad-bb15-eeeeedbf9bf1@phytec.de> (raw)
In-Reply-To: <20250910132609.bfqpdflcgfbtouq4@bryanbrattlof.com>
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
next prev parent reply other threads:[~2025-09-10 14:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-15 16:02 [PATCH] arm: mach-k3: am625: Unlock MMR registers again Daniel Schultz
2025-08-21 16:21 ` Sverdlin, Alexander
2025-09-10 11:50 ` Daniel Schultz
2025-09-10 12:08 ` bb
2025-09-10 12:27 ` Sverdlin, Alexander
2025-09-10 12:53 ` bb
2025-09-10 13:01 ` Sverdlin, Alexander
2025-09-10 13:26 ` bb
2025-09-10 14:06 ` Daniel Schultz [this message]
2026-01-12 3:04 ` [Upstream] " Wadim Egorov
2026-01-13 3:02 ` bb
2026-01-12 7:31 ` Sverdlin, Alexander
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50c51eea-af1f-48ad-bb15-eeeeedbf9bf1@phytec.de \
--to=d.schultz@phytec.de \
--cc=alexander.sverdlin@siemens.com \
--cc=bb@ti.com \
--cc=c-vankar@ti.com \
--cc=kishon@ti.com \
--cc=s-vadapalli@ti.com \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=upstream@lists.phytec.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.