Hi Udit
On 2/24/2026 10:12 PM, Kumar, Udit wrote:
>
>
> 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.
Unless we somehow know when TIFS is done with unlocking (is the version print
suggested by Bryan a solid yes it's done? if so that's the right solution) I
think unlocking the MCU_ESM for WDT is a better fix. Else we're randomly trying
to estimate when unlocking is over, perhaps there are further CTRL_MMRs in queue
to be unlocked at that point and we'd be doing this again (although this is
unlikely since spl_early_init probably takes a good amount of time)
>
>>
>> ~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
>>>
>
--
Thanking You
Neha Malcom Francis
