public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Wadim Egorov <w.egorov@phytec.de>
To: Daniel Schultz <d.schultz@phytec.de>, "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: [Upstream] Re: [PATCH] arm: mach-k3: am625: Unlock MMR registers again
Date: Mon, 12 Jan 2026 10:04:18 +0700	[thread overview]
Message-ID: <5e333477-1745-4db8-a56a-abfdad8ef825@phytec.de> (raw)
In-Reply-To: <50c51eea-af1f-48ad-bb15-eeeeedbf9bf1@phytec.de>



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


  reply	other threads:[~2026-01-12  3:05 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
2026-01-12  3:04                 ` Wadim Egorov [this message]
2026-01-13  3:02                   ` [Upstream] " 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=5e333477-1745-4db8-a56a-abfdad8ef825@phytec.de \
    --to=w.egorov@phytec.de \
    --cc=alexander.sverdlin@siemens.com \
    --cc=bb@ti.com \
    --cc=c-vankar@ti.com \
    --cc=d.schultz@phytec.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox