[PATCH v3 0/6] K3: wait for TIFS init before CTRL_MMR unlock

[PATCH v3 0/6] K3: wait for TIFS init before CTRL_MMR unlock

[Markus Schneider-Pargmann]

Hi,

this series uses a TIFS barrier before doing the ctrl_mmr_unlock(). This
specific implementation works for the platforms where TIFS is already
running at this point. Note that other K3 platforms may have the same
problem, but for these this implementation is not straight forward.

This series is only tested on am625 HS-SE. I don't have any other HS-SE
boards.

Best,
Markus

---
Changes in v3:
- Added patche to add SPL_DM_EVENT
- Changed the patches to not wait for TIFS and unlock after
  spl_early_init() but instead at EVT_DM_POST_INIT_F.
- Link to v2: https://patch.msgid.link/20261016-v2026-10-next-topic-am62-hs-se-fix-unlock-race-v2-0-c7ab53f79b34@baylibre.com

Changes in v2:
- Create a common helper k3_sysfw_wait_ready() to make the purpose of
  the get_ti_sci_handle() clear.
- Extend the series to the other SoCs with the same boot process: am62a7,
  am62p5 and j722s.
- Link to v1: https://patch.msgid.link/20260923-v2026-10-next-topic-am62-hs-se-fix-unlock-race-v1-1-300ddb9f5be8@baylibre.com

To: u-boot@lists.u-boot-project.org
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Daniel Schultz <d.schultz@phytec.de>
Cc: Udit Kumar <u-kumar1@ti.com>
Cc: Richard Genoud <richard.genoud@bootlin.com>
Cc: Anshul Dalal <anshuld@ti.com>
Cc: Aristo Chen <aristo.chen@canonical.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Kory Maincent <kory.maincent@bootlin.com>
Cc: Paresh Bhagat <p-bhagat@ti.com>
Cc: Julien Panis <jpanis@baylibre.com>
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>

---
Markus Schneider-Pargmann (6):
      arm: mach-k3: common: add helper to wait for TIFS initialization
      dm: core: Add SPL_DM_EVENT
      arm: mach-k3: am625: Wait for TIFS initialization
      arm: mach-k3: am62a7: Wait for TIFS initialization
      arm: mach-k3: am62p5: Wait for TIFS initialization
      arm: mach-k3: j722s: Wait for TIFS initialization

 arch/arm/mach-k3/Kconfig              |  4 ++++
 arch/arm/mach-k3/am62ax/am62a7_init.c | 17 +++++++++++++++--
 arch/arm/mach-k3/am62px/am62p5_init.c | 17 +++++++++++++++--
 arch/arm/mach-k3/am62x/am625_init.c   | 17 +++++++++++++++--
 arch/arm/mach-k3/common.c             | 10 ++++++++++
 arch/arm/mach-k3/common.h             |  1 +
 arch/arm/mach-k3/j722s/j722s_init.c   | 17 +++++++++++++++--
 drivers/core/Kconfig                  | 10 ++++++++++
 8 files changed, 85 insertions(+), 8 deletions(-)
---
base-commit: 75df64103873fac09642860cedadaffb8cf6b2c7
change-id: 20260923-v2026-10-next-topic-am62-hs-se-fix-unlock-race-15fda445257e

Best regards,
--  
Markus Schneider-Pargmann <msp@baylibre.com>

[PATCH v3 1/6] arm: mach-k3: common: add helper to wait for TIFS initialization

[Markus Schneider-Pargmann]

Add a helper to wait for TIFS initialization to be finished. Effectively
this is just a call to get_ti_sci_handle() but I think a separate
function makes the purpose of this call better visible.

get_ti_sci_handle() internally leads to fetching the TIFS version with a
message and response. TIFS only responds once initialization finished.
If a response is not received get_ti_sci_handle() returns after a
timeout.

Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
---
 arch/arm/mach-k3/common.c | 10 ++++++++++
 arch/arm/mach-k3/common.h |  1 +
 2 files changed, 11 insertions(+)

diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index 6e382efdb3be..480c90cfa65f 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -54,6 +54,16 @@ struct ti_sci_handle *get_ti_sci_handle(void)
 	return (struct ti_sci_handle *)ti_sci_get_handle_from_sysfw(dev);
 }
 
+void k3_sysfw_wait_ready(void)
+{
+	/*
+	 * Wait for TIFS initialization to finish. This helper is used to make
+	 * sure TIFS removed the firewall before U-Boot tries to unlock CTRL_MMR
+	 * registers and continues the boot.
+	 */
+	get_ti_sci_handle();
+}
+
 void k3_sysfw_print_ver(void)
 {
 	struct ti_sci_handle *ti_sci = get_ti_sci_handle();
diff --git a/arch/arm/mach-k3/common.h b/arch/arm/mach-k3/common.h
index 37ff98d89924..146b986febc6 100644
--- a/arch/arm/mach-k3/common.h
+++ b/arch/arm/mach-k3/common.h
@@ -38,6 +38,7 @@ void disable_linefill_optimization(void);
 int remove_fwl_region(struct fwl_data *fwl);
 void remove_fwl_configs(struct fwl_data *fwl_data, size_t fwl_data_size);
 int load_firmware(char *name_fw, char *name_loadaddr, u32 *loadaddr);
+void k3_sysfw_wait_ready(void);
 void k3_sysfw_print_ver(void);
 void k3_dm_print_ver(void);
 void spl_enable_cache(void);

-- 
2.56.0

Re: [PATCH v3 1/6] arm: mach-k3: common: add helper to wait for TIFS initialization

[Richard GENOUD]

Le 30/10/2026 à 13:27, Markus Schneider-Pargmann a écrit :
> Add a helper to wait for TIFS initialization to be finished. Effectively
> this is just a call to get_ti_sci_handle() but I think a separate
> function makes the purpose of this call better visible.
> 
> get_ti_sci_handle() internally leads to fetching the TIFS version with a
> message and response. TIFS only responds once initialization finished.
> If a response is not received get_ti_sci_handle() returns after a
> timeout.
> 
Tested-by: Richard Genoud <richard.genoud@bootlin.com> # on j722s HS-FS
> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> ---
>   arch/arm/mach-k3/common.c | 10 ++++++++++
>   arch/arm/mach-k3/common.h |  1 +
>   2 files changed, 11 insertions(+)
> 
> diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
> index 6e382efdb3be..480c90cfa65f 100644
> --- a/arch/arm/mach-k3/common.c
> +++ b/arch/arm/mach-k3/common.c
> @@ -54,6 +54,16 @@ struct ti_sci_handle *get_ti_sci_handle(void)
>   	return (struct ti_sci_handle *)ti_sci_get_handle_from_sysfw(dev);
>   }
>   
> +void k3_sysfw_wait_ready(void)
> +{
> +	/*
> +	 * Wait for TIFS initialization to finish. This helper is used to make
> +	 * sure TIFS removed the firewall before U-Boot tries to unlock CTRL_MMR
> +	 * registers and continues the boot.
> +	 */
> +	get_ti_sci_handle();
> +}
> +
>   void k3_sysfw_print_ver(void)
>   {
>   	struct ti_sci_handle *ti_sci = get_ti_sci_handle();
> diff --git a/arch/arm/mach-k3/common.h b/arch/arm/mach-k3/common.h
> index 37ff98d89924..146b986febc6 100644
> --- a/arch/arm/mach-k3/common.h
> +++ b/arch/arm/mach-k3/common.h
> @@ -38,6 +38,7 @@ void disable_linefill_optimization(void);
>   int remove_fwl_region(struct fwl_data *fwl);
>   void remove_fwl_configs(struct fwl_data *fwl_data, size_t fwl_data_size);
>   int load_firmware(char *name_fw, char *name_loadaddr, u32 *loadaddr);
> +void k3_sysfw_wait_ready(void);
>   void k3_sysfw_print_ver(void);
>   void k3_dm_print_ver(void);
>   void spl_enable_cache(void);
> 

[PATCH v3 2/6] dm: core: Add SPL_DM_EVENT

[Markus Schneider-Pargmann]

Add an option to allow DM_EVENT in SPL.

Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
---
 drivers/core/Kconfig | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index ae0c34667723..22b72d6b766c 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -117,6 +117,16 @@ config DM_EVENT
 	  register a 'spy' function that is called when the event occurs. Such
 	  subsystems must select this option.
 
+config SPL_DM_EVENT
+	bool
+	depends on SPL_DM
+	select SPL_EVENT
+	help
+	  This enables support for generating events related to driver model
+	  operations in SPL, such as probing or removing a device. Subsystems
+	  can register a 'spy' function that is called when the event occurs.
+	  Such subsystems must select this option.
+
 config SPL_DM_DEVICE_REMOVE
 	bool "Support device removal in SPL"
 	depends on SPL_DM

-- 
2.56.0

Re: [PATCH v3 2/6] dm: core: Add SPL_DM_EVENT

[Simon Glass]

Hi Markus,

On 2026-10-30T12:27:40+11:00, Markus Schneider-Pargmann
<msp@baylibre.com> wrote:
> dm: core: Add SPL_DM_EVENT
>
> Add an option to allow DM_EVENT in SPL.

Please can you say why this is needed, i.e. that the K3 SoCs want a
spy on EVT_DM_POST_INIT_F in SPL, so they can unlock CTRL_MMR after
TIFS is ready but before any device is probed. It is also worth a
sentence that CONFIG_IS_ENABLED(DM_EVENT) is currently always false in
SPL, so with this option dm_init_and_scan() and device_notify() start
sending events there too.

> diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
> @@ -117,6 +117,16 @@ config DM_EVENT
> +config SPL_DM_EVENT
> +	bool
> +	depends on SPL_DM
> +	select SPL_EVENT

SPL_EVENT is inside 'if EVENT' in common/Kconfig, so it depends on
EVENT. That is fine on K3, since ARCH_K3 selects both, but another
board selecting SPL_DM_EVENT without EVENT would get an
unmet-dependency warning. DM_EVENT selects EVENT, so I suggest adding
'select EVENT' here too.

>
> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
>
>  drivers/core/Kconfig | 10 ++++++++++
>  1 file changed, 10 insertions(+)

Regards,
Simon

Re: [PATCH v3 2/6] dm: core: Add SPL_DM_EVENT

[Markus Schneider-Pargmann]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

Hi Simon,

On Sat Oct 31, 2026 at 7:44 PM CET, Simon Glass wrote:
> Hi Markus,
>
> On 2026-10-30T12:27:40+11:00, Markus Schneider-Pargmann
> <msp@baylibre.com> wrote:
>> dm: core: Add SPL_DM_EVENT
>>
>> Add an option to allow DM_EVENT in SPL.
>
> Please can you say why this is needed, i.e. that the K3 SoCs want a
> spy on EVT_DM_POST_INIT_F in SPL, so they can unlock CTRL_MMR after
> TIFS is ready but before any device is probed. It is also worth a
> sentence that CONFIG_IS_ENABLED(DM_EVENT) is currently always false in
> SPL, so with this option dm_init_and_scan() and device_notify() start
> sending events there too.
>
>> diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
>> @@ -117,6 +117,16 @@ config DM_EVENT
>> +config SPL_DM_EVENT
>> +	bool
>> +	depends on SPL_DM
>> +	select SPL_EVENT
>
> SPL_EVENT is inside 'if EVENT' in common/Kconfig, so it depends on
> EVENT. That is fine on K3, since ARCH_K3 selects both, but another
> board selecting SPL_DM_EVENT without EVENT would get an
> unmet-dependency warning. DM_EVENT selects EVENT, so I suggest adding
> 'select EVENT' here too.

Thanks for your review, good points, I will fix both.

Best
Markus

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 289 bytes --]

Re: [PATCH v3 2/6] dm: core: Add SPL_DM_EVENT

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]

On Mon, Nov 02, 2026 at 10:26:44AM +0100, Markus Schneider-Pargmann wrote:
> Hi Simon,
> 
> On Sat Oct 31, 2026 at 7:44 PM CET, Simon Glass wrote:
> > Hi Markus,
> >
> > On 2026-10-30T12:27:40+11:00, Markus Schneider-Pargmann
> > <msp@baylibre.com> wrote:
> >> dm: core: Add SPL_DM_EVENT
> >>
> >> Add an option to allow DM_EVENT in SPL.
> >
> > Please can you say why this is needed, i.e. that the K3 SoCs want a
> > spy on EVT_DM_POST_INIT_F in SPL, so they can unlock CTRL_MMR after
> > TIFS is ready but before any device is probed. It is also worth a
> > sentence that CONFIG_IS_ENABLED(DM_EVENT) is currently always false in
> > SPL, so with this option dm_init_and_scan() and device_notify() start
> > sending events there too.
> >
> >> diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
> >> @@ -117,6 +117,16 @@ config DM_EVENT
> >> +config SPL_DM_EVENT
> >> +	bool
> >> +	depends on SPL_DM
> >> +	select SPL_EVENT
> >
> > SPL_EVENT is inside 'if EVENT' in common/Kconfig, so it depends on
> > EVENT. That is fine on K3, since ARCH_K3 selects both, but another
> > board selecting SPL_DM_EVENT without EVENT would get an
> > unmet-dependency warning. DM_EVENT selects EVENT, so I suggest adding
> > 'select EVENT' here too.
> 
> Thanks for your review, good points, I will fix both.

I didn't chime in, in time I guess. Being able to have SPL_X and not X
enabled is generally speaking allowed and a feature. So it's probable
that some symbol needs to be moved and/or some Makefiles updated, but
SPL_EVENT / SPL_DM_EVENT select'ing EVENT is wrong.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v3 2/6] dm: core: Add SPL_DM_EVENT

[Markus Schneider-Pargmann]

[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]

On Mon Nov 2, 2026 at 6:15 PM CET, Tom Rini wrote:
> On Mon, Nov 02, 2026 at 10:26:44AM +0100, Markus Schneider-Pargmann wrote:
>> Hi Simon,
>> 
>> On Sat Oct 31, 2026 at 7:44 PM CET, Simon Glass wrote:
>> > Hi Markus,
>> >
>> > On 2026-10-30T12:27:40+11:00, Markus Schneider-Pargmann
>> > <msp@baylibre.com> wrote:
>> >> dm: core: Add SPL_DM_EVENT
>> >>
>> >> Add an option to allow DM_EVENT in SPL.
>> >
>> > Please can you say why this is needed, i.e. that the K3 SoCs want a
>> > spy on EVT_DM_POST_INIT_F in SPL, so they can unlock CTRL_MMR after
>> > TIFS is ready but before any device is probed. It is also worth a
>> > sentence that CONFIG_IS_ENABLED(DM_EVENT) is currently always false in
>> > SPL, so with this option dm_init_and_scan() and device_notify() start
>> > sending events there too.
>> >
>> >> diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
>> >> @@ -117,6 +117,16 @@ config DM_EVENT
>> >> +config SPL_DM_EVENT
>> >> +	bool
>> >> +	depends on SPL_DM
>> >> +	select SPL_EVENT
>> >
>> > SPL_EVENT is inside 'if EVENT' in common/Kconfig, so it depends on
>> > EVENT. That is fine on K3, since ARCH_K3 selects both, but another
>> > board selecting SPL_DM_EVENT without EVENT would get an
>> > unmet-dependency warning. DM_EVENT selects EVENT, so I suggest adding
>> > 'select EVENT' here too.
>> 
>> Thanks for your review, good points, I will fix both.
>
> I didn't chime in, in time I guess. Being able to have SPL_X and not X
> enabled is generally speaking allowed and a feature. So it's probable
> that some symbol needs to be moved and/or some Makefiles updated, but
> SPL_EVENT / SPL_DM_EVENT select'ing EVENT is wrong.

Thank you, I think we can split these up, I will create a patch for the
next version.

Best
Markus

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 289 bytes --]

[PATCH v3 3/6] arm: mach-k3: am625: Wait for TIFS initialization

[Markus Schneider-Pargmann]

On HS-SE platforms TIFS takes longer to initialize. TIFS only removes
the firewall on the registers at the end of initialization. On HS-SE the
U-Boot ctrl_mmr_unlock() can happen before TIFS removed the firewall
leading to a race condition. This leads to a broken watchdog since the
signal configuration doesn't succeed because the write doesn't take
effect.

Wait for TIFS to be initialized using k3_sysfw_wait_ready() before doing
ctrl_mmr_unlock(). As spl_early_init() may already probe some drivers, I
am attaching to the EVT_DM_POST_INIT_F event to wait for TIFS and call
ctrl_mmr_unlock() before anything got probed.

Link: https://lore.kernel.org/u-boot/20250815160240.3575140-1-d.schultz@phytec.de/
Link: https://lore.kernel.org/u-boot/20260225051559.416445-1-u-kumar1@ti.com/
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
---
 arch/arm/mach-k3/Kconfig            |  1 +
 arch/arm/mach-k3/am62x/am625_init.c | 17 +++++++++++++++--
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index a32ed3a9683f..b1f290c1d765 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -6,6 +6,7 @@ choice
 
 config SOC_K3_AM625
 	bool "TI's K3 based AM625 SoC Family Support"
+	select SPL_DM_EVENT if SPL
 
 config SOC_K3_AM62A7
 	bool "TI's K3 based AM62A7 SoC Family Support"
diff --git a/arch/arm/mach-k3/am62x/am625_init.c b/arch/arm/mach-k3/am62x/am625_init.c
index decb50bf853d..c7e976fe5ca9 100644
--- a/arch/arm/mach-k3/am62x/am625_init.c
+++ b/arch/arm/mach-k3/am62x/am625_init.c
@@ -12,6 +12,7 @@
 #include <dm.h>
 #include <dm/uclass-internal.h>
 #include <dm/pinctrl.h>
+#include <event.h>
 
 #include "../sysfw-loader.h"
 #include "../common.h"
@@ -100,6 +101,20 @@ static void ctrl_mmr_unlock(void)
 	mmr_unlock(PADCFG_MMR1_BASE, 1);
 }
 
+/*
+ * Called by spl_early_init() after all devices are bound, but before any of
+ * them are probed. TIFS has to finish its initialization before CTRL_MMR can
+ * be unlocked, and any device probe may already need the unlocked CTRL_MMR.
+ */
+static int k3_spl_dm_post_init_f(void)
+{
+	k3_sysfw_wait_ready();
+	ctrl_mmr_unlock();
+
+	return 0;
+}
+EVENT_SPY_SIMPLE(EVT_DM_POST_INIT_F, k3_spl_dm_post_init_f);
+
 static __maybe_unused void enable_mcu_esm_reset(void)
 {
 	/* Set CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RST_EN_Z  to '0' (low active) */
@@ -158,8 +173,6 @@ void board_init_f(ulong dummy)
 	 */
 	store_boot_info_from_rom();
 
-	ctrl_mmr_unlock();
-
 	/* Init DM early */
 	spl_early_init();
 

-- 
2.56.0

[PATCH v3 4/6] arm: mach-k3: am62a7: Wait for TIFS initialization

[Markus Schneider-Pargmann]

On HS-SE platforms TIFS takes longer to initialize. TIFS only removes
the firewall on the registers at the end of initialization. On HS-SE the
U-Boot ctrl_mmr_unlock() can happen before TIFS removed the firewall
leading to a race condition. This leads to a broken watchdog since the
signal configuration doesn't succeed because the write doesn't take
effect.

Wait for TIFS to be initialized using k3_sysfw_wait_ready() before doing
ctrl_mmr_unlock(). As spl_early_init() may already probe some drivers, I
am attaching to the EVT_DM_POST_INIT_F event to wait for TIFS and call
ctrl_mmr_unlock() before anything got probed.

Link: https://lore.kernel.org/u-boot/20250815160240.3575140-1-d.schultz@phytec.de/
Link: https://lore.kernel.org/u-boot/20260225051559.416445-1-u-kumar1@ti.com/
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
---
 arch/arm/mach-k3/Kconfig              |  1 +
 arch/arm/mach-k3/am62ax/am62a7_init.c | 17 +++++++++++++++--
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index b1f290c1d765..405c5d4fad94 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -10,6 +10,7 @@ config SOC_K3_AM625
 
 config SOC_K3_AM62A7
 	bool "TI's K3 based AM62A7 SoC Family Support"
+	select SPL_DM_EVENT if SPL
 
 config SOC_K3_AM62P5
 	bool "TI's K3 based AM62P5 SoC Family Support"
diff --git a/arch/arm/mach-k3/am62ax/am62a7_init.c b/arch/arm/mach-k3/am62ax/am62a7_init.c
index 0d86d52ef267..ddfe84217ab4 100644
--- a/arch/arm/mach-k3/am62ax/am62a7_init.c
+++ b/arch/arm/mach-k3/am62ax/am62a7_init.c
@@ -11,6 +11,7 @@
 #include <dm.h>
 #include <dm/uclass-internal.h>
 #include <dm/pinctrl.h>
+#include <event.h>
 
 #include "../sysfw-loader.h"
 #include "../common.h"
@@ -110,6 +111,20 @@ static void ctrl_mmr_unlock(void)
 	mmr_unlock(PADCFG_MMR1_BASE, 1);
 }
 
+/*
+ * Called by spl_early_init() after all devices are bound, but before any of
+ * them are probed. TIFS has to finish its initialization before CTRL_MMR can
+ * be unlocked, and any device probe may already need the unlocked CTRL_MMR.
+ */
+static int k3_spl_dm_post_init_f(void)
+{
+	k3_sysfw_wait_ready();
+	ctrl_mmr_unlock();
+
+	return 0;
+}
+EVENT_SPY_SIMPLE(EVT_DM_POST_INIT_F, k3_spl_dm_post_init_f);
+
 static __maybe_unused void enable_mcu_esm_reset(void)
 {
 	/* Set CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RST_EN_Z  to '0' (low active) */
@@ -134,8 +149,6 @@ void board_init_f(ulong dummy)
 	 */
 	store_boot_info_from_rom();
 
-	ctrl_mmr_unlock();
-
 	/* Init DM early */
 	spl_early_init();
 

-- 
2.56.0

[PATCH v3 5/6] arm: mach-k3: am62p5: Wait for TIFS initialization

[Markus Schneider-Pargmann]

On HS-SE platforms TIFS takes longer to initialize. TIFS only removes
the firewall on the registers at the end of initialization. On HS-SE the
U-Boot ctrl_mmr_unlock() can happen before TIFS removed the firewall
leading to a race condition. This leads to a broken watchdog since the
signal configuration doesn't succeed because the write doesn't take
effect.

Wait for TIFS to be initialized using k3_sysfw_wait_ready() before doing
ctrl_mmr_unlock(). As spl_early_init() may already probe some drivers, I
am attaching to the EVT_DM_POST_INIT_F event to wait for TIFS and call
ctrl_mmr_unlock() before anything got probed.

Link: https://lore.kernel.org/u-boot/20250815160240.3575140-1-d.schultz@phytec.de/
Link: https://lore.kernel.org/u-boot/20260225051559.416445-1-u-kumar1@ti.com/
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
---
 arch/arm/mach-k3/Kconfig              |  1 +
 arch/arm/mach-k3/am62px/am62p5_init.c | 17 +++++++++++++++--
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 405c5d4fad94..3c567f50b223 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -14,6 +14,7 @@ config SOC_K3_AM62A7
 
 config SOC_K3_AM62P5
 	bool "TI's K3 based AM62P5 SoC Family Support"
+	select SPL_DM_EVENT if SPL
 
 config SOC_K3_AM642
 	bool "TI's K3 based AM642 SoC Family Support"
diff --git a/arch/arm/mach-k3/am62px/am62p5_init.c b/arch/arm/mach-k3/am62px/am62p5_init.c
index 599ea7cf2dd8..014f494c8e6c 100644
--- a/arch/arm/mach-k3/am62px/am62p5_init.c
+++ b/arch/arm/mach-k3/am62px/am62p5_init.c
@@ -11,6 +11,7 @@
 #include <dm.h>
 #include <dm/uclass-internal.h>
 #include <dm/pinctrl.h>
+#include <event.h>
 
 #include "../sysfw-loader.h"
 #include "../common.h"
@@ -93,6 +94,20 @@ static void ctrl_mmr_unlock(void)
 	mmr_unlock(PADCFG_MMR1_BASE, 1);
 }
 
+/*
+ * Called by spl_early_init() after all devices are bound, but before any of
+ * them are probed. TIFS has to finish its initialization before CTRL_MMR can
+ * be unlocked, and any device probe may already need the unlocked CTRL_MMR.
+ */
+static int k3_spl_dm_post_init_f(void)
+{
+	k3_sysfw_wait_ready();
+	ctrl_mmr_unlock();
+
+	return 0;
+}
+EVENT_SPY_SIMPLE(EVT_DM_POST_INIT_F, k3_spl_dm_post_init_f);
+
 static __maybe_unused void enable_mcu_esm_reset(void)
 {
 	/* Set CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RST_EN_Z  to '0' (low active) */
@@ -116,8 +131,6 @@ void board_init_f(ulong dummy)
 	 */
 	store_boot_info_from_rom();
 
-	ctrl_mmr_unlock();
-
 	/* Init DM early */
 	ret = spl_early_init();
 	if (ret)

-- 
2.56.0

[PATCH v3 6/6] arm: mach-k3: j722s: Wait for TIFS initialization

[Markus Schneider-Pargmann]

On HS-SE platforms TIFS takes longer to initialize. TIFS only removes
the firewall on the registers at the end of initialization. On HS-SE the
U-Boot ctrl_mmr_unlock() can happen before TIFS removed the firewall
leading to a race condition. This leads to a broken watchdog since the
signal configuration doesn't succeed because the write doesn't take
effect.

Wait for TIFS to be initialized using k3_sysfw_wait_ready() before doing
ctrl_mmr_unlock(). As spl_early_init() may already probe some drivers, I
am attaching to the EVT_DM_POST_INIT_F event to wait for TIFS and call
ctrl_mmr_unlock() before anything got probed.

Link: https://lore.kernel.org/u-boot/20250815160240.3575140-1-d.schultz@phytec.de/
Link: https://lore.kernel.org/u-boot/20260225051559.416445-1-u-kumar1@ti.com/
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
---
 arch/arm/mach-k3/Kconfig            |  1 +
 arch/arm/mach-k3/j722s/j722s_init.c | 17 +++++++++++++++--
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 3c567f50b223..a952638fc282 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -33,6 +33,7 @@ config SOC_K3_J721S2
 
 config SOC_K3_J722S
 	bool "TI's K3 based J722S SoC Family Support"
+	select SPL_DM_EVENT if SPL
 
 config SOC_K3_J784S4
 	bool "TI's K3 based J784S4 SoC Family Support"
diff --git a/arch/arm/mach-k3/j722s/j722s_init.c b/arch/arm/mach-k3/j722s/j722s_init.c
index 1180c75f551d..7b09691998c9 100644
--- a/arch/arm/mach-k3/j722s/j722s_init.c
+++ b/arch/arm/mach-k3/j722s/j722s_init.c
@@ -11,6 +11,7 @@
 #include <dm.h>
 #include <dm/uclass-internal.h>
 #include <dm/pinctrl.h>
+#include <event.h>
 
 #include "../sysfw-loader.h"
 #include "../common.h"
@@ -70,6 +71,20 @@ static void ctrl_mmr_unlock(void)
 	mmr_unlock(PADCFG_MMR1_BASE, 1);
 }
 
+/*
+ * Called by spl_early_init() after all devices are bound, but before any of
+ * them are probed. TIFS has to finish its initialization before CTRL_MMR can
+ * be unlocked, and any device probe may already need the unlocked CTRL_MMR.
+ */
+static int k3_spl_dm_post_init_f(void)
+{
+	k3_sysfw_wait_ready();
+	ctrl_mmr_unlock();
+
+	return 0;
+}
+EVENT_SPY_SIMPLE(EVT_DM_POST_INIT_F, k3_spl_dm_post_init_f);
+
 static void k3_spl_init(void)
 {
 	struct udevice *dev;
@@ -84,8 +99,6 @@ static void k3_spl_init(void)
 	 */
 	store_boot_info_from_rom();
 
-	ctrl_mmr_unlock();
-
 	/* Init DM early */
 	ret = spl_early_init();
 	if (ret)

-- 
2.56.0

Re: [PATCH v3 6/6] arm: mach-k3: j722s: Wait for TIFS initialization

[Richard GENOUD]

Le 30/10/2026 à 13:27, Markus Schneider-Pargmann a écrit :
> On HS-SE platforms TIFS takes longer to initialize. TIFS only removes
> the firewall on the registers at the end of initialization. On HS-SE the
> U-Boot ctrl_mmr_unlock() can happen before TIFS removed the firewall
> leading to a race condition. This leads to a broken watchdog since the
> signal configuration doesn't succeed because the write doesn't take
> effect.
> 
> Wait for TIFS to be initialized using k3_sysfw_wait_ready() before doing
> ctrl_mmr_unlock(). As spl_early_init() may already probe some drivers, I
> am attaching to the EVT_DM_POST_INIT_F event to wait for TIFS and call
> ctrl_mmr_unlock() before anything got probed.
> 
> Link: https://lore.kernel.org/u-boot/20250815160240.3575140-1-d.schultz@phytec.de/
> Link: https://lore.kernel.org/u-boot/20260225051559.416445-1-u-kumar1@ti.com/
Tested-by: Richard Genoud <richard.genoud@bootlin.com> # on j722s HS-FS

Thanks!> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> ---
>   arch/arm/mach-k3/Kconfig            |  1 +
>   arch/arm/mach-k3/j722s/j722s_init.c | 17 +++++++++++++++--
>   2 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
> index 3c567f50b223..a952638fc282 100644
> --- a/arch/arm/mach-k3/Kconfig
> +++ b/arch/arm/mach-k3/Kconfig
> @@ -33,6 +33,7 @@ config SOC_K3_J721S2
>   
>   config SOC_K3_J722S
>   	bool "TI's K3 based J722S SoC Family Support"
> +	select SPL_DM_EVENT if SPL
>   
>   config SOC_K3_J784S4
>   	bool "TI's K3 based J784S4 SoC Family Support"
> diff --git a/arch/arm/mach-k3/j722s/j722s_init.c b/arch/arm/mach-k3/j722s/j722s_init.c
> index 1180c75f551d..7b09691998c9 100644
> --- a/arch/arm/mach-k3/j722s/j722s_init.c
> +++ b/arch/arm/mach-k3/j722s/j722s_init.c
> @@ -11,6 +11,7 @@
>   #include <dm.h>
>   #include <dm/uclass-internal.h>
>   #include <dm/pinctrl.h>
> +#include <event.h>
>   
>   #include "../sysfw-loader.h"
>   #include "../common.h"
> @@ -70,6 +71,20 @@ static void ctrl_mmr_unlock(void)
>   	mmr_unlock(PADCFG_MMR1_BASE, 1);
>   }
>   
> +/*
> + * Called by spl_early_init() after all devices are bound, but before any of
> + * them are probed. TIFS has to finish its initialization before CTRL_MMR can
> + * be unlocked, and any device probe may already need the unlocked CTRL_MMR.
> + */
> +static int k3_spl_dm_post_init_f(void)
> +{
> +	k3_sysfw_wait_ready();
> +	ctrl_mmr_unlock();
> +
> +	return 0;
> +}
> +EVENT_SPY_SIMPLE(EVT_DM_POST_INIT_F, k3_spl_dm_post_init_f);
> +
>   static void k3_spl_init(void)
>   {
>   	struct udevice *dev;
> @@ -84,8 +99,6 @@ static void k3_spl_init(void)
>   	 */
>   	store_boot_info_from_rom();
>   
> -	ctrl_mmr_unlock();
> -
>   	/* Init DM early */
>   	ret = spl_early_init();
>   	if (ret)
> 


-- 
Richard Genoud, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com