On 2/24/2026 8:00 PM, Bryan Brattlof wrote:
> On February 24, 2026 thus sayeth Vignesh Raghavendra:
>>
>>
>> On 23/02/26 20:15, Udit Kumar wrote:
>>> unlocking control mmr before spl_early_init leads to
>>
>> Nit: capitalize the first letter
>>
>>> unpredicable behaviour.
>>
>> and run through codespell.
>>
>> Commit msg is vague. What unpredictable behavior? How do we know moving
>> the ctrl_mmr_unlock() to after spl_early_init() really resolves this
>> unpredictable behavior?
>
> This is an issue has been reported by many people using any of our SE
> configured reference SoCs which we haven't been able to give an answer
> for.[0]
>
> The current theory is the CTRL_MMR ranges are firewalled by ROM and TIFS
> is unlocking them for us. If that's true then we need to move this until
> after the version message is returned to guarantee the range is unlocked
> by the time we get to this point.
>
> Moving it to after the spl_early_init() adds more time but isn't
> guaranteed with many boots.
>
> [0]
> https://lore.kernel.org/u-boot/[email protected]/
Thanks Bryan,
Make sense to move unlock of mmr after fw versions are printed. So that we are
sure
tifs and boot-rom are finishing with firewalling.
FYI, i just did one experiment, put random delay before calls to
ctrl_mmr_unlock()
and wdt seems to be working ok.
Another option I see, let original code be as is, and add support similar to
above patch
for wdt.
>
> ~Bryan
>
>>
>>> So unlock it after spl_early_init.
>>>
>>
>> Wrap commit msg at 80 char uniformly please.
>>
>>> Fixes: 5e291ee34fd4 ("arch: mach-k3: Introduce basic files to support J722S
>>> SoC family")
>>> Reported-by: Diwakar Dhyani <[email protected]>
>>> Signed-off-by: Udit Kumar <[email protected]>
>>> ---
>>
>>> On HS-SE of J722S in particular, enable_mcu_esm_reset function is not able
>>> to reset bit-17 of ctrl mmr CTRLMMR_MCU_RST_CTRL.
>>> Which leads to wdt is not functional. With this change
>>> bit-17 was getting reset properly on HS-SE and HS-FS devices.
>>>
>>
>> This too needs to go into commit msg if not in $subject as this is what
>> user actually sees as the issue.
>>
>>> HS-FS
>>> https://gist.github.com/uditkumarti/4ba05c9335212630ce9240ac67e11c2d#file-hs-fs
>>>
>>> HS-SE
>>> https://gist.github.com/uditkumarti/4ba05c9335212630ce9240ac67e11c2d#file-hs-se
>>>
>>> arch/arm/mach-k3/j722s/j722s_init.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-k3/j722s/j722s_init.c
>>> b/arch/arm/mach-k3/j722s/j722s_init.c
>>> index 1180c75f551..a0dab5d7032 100644
>>> --- a/arch/arm/mach-k3/j722s/j722s_init.c
>>> +++ b/arch/arm/mach-k3/j722s/j722s_init.c
>>> @@ -84,13 +84,13 @@ static void k3_spl_init(void)
>>> */
>>> 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();
>>> +
>>> /*
>>> * Process pinctrl for the serial0 a.k.a. WKUP_UART0 module and continue
>>> * regardless of the result of pinctrl. Do this without probing the
>>
>> --
>> Regards
>> Vignesh
>> https://ti.com/opensource
>>
