]> git.ipfire.org Git - thirdparty/u-boot.git/commitdiff
board: ti: j722s: add processor ACL entry for wkup_r5
authorAbhash Kumar Jha <a-kumar2@ti.com>
Fri, 15 May 2026 08:17:45 +0000 (13:47 +0530)
committerTom Rini <trini@konsulko.com>
Fri, 29 May 2026 20:17:14 +0000 (14:17 -0600)
On the j722s platform, the DM firmware resets the wkup_r5 core at boot to
enable both of its TCM memories.

This reset sequence involves three steps:
- Acquiring processor ownership of wkup_r5
- Configuring the core and requesting a reset via TIFS
- Releasing ownership.

When the Linux remoteproc driver comes up, it acquires ownership of wkup_r5
to query its state, making A53_2 the new owner.
During system suspend, TIFS saves the processor ACL[1] table to DDR as
part of its context.

On resume, TIFS restores the ACL table, leaving A53_2 as the owner of
wkup_r5. At this point, DM (WKUP_0_R5_0 host[2]) no longer has ownership
and is therefore unable to perform the reset sequence it needs,
causing it to crash.

To fix this, configure the wkup_r5[3] processor with dual ownership:
- WKUP_0_R5_0 (Secure) as primary owner.
- A53_2 (Non-Secure) as secondary owner.

[1] https://software-dl.ti.com/tisci/esd/latest/3_boardcfg/BOARDCFG_SEC.html#pub-boardcfg-proc-acl
[2] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j722s/hosts.html
[3] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j722s/processors.html

Signed-off-by: Abhash Kumar Jha <a-kumar2@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
board/ti/j722s/sec-cfg.yaml

index e9a9d526cfb7a9318d0ef7708fa2787cd59234b6..b68b305b6bb64026fa6e662d2e0a4e7aeb64af96 100644 (file)
@@ -16,9 +16,9 @@ sec-cfg:
             size: 164
         proc_acl_entries:
             -
-                processor_id: 0
-                proc_access_master: 0
-                proc_access_secondary: [0, 0, 0]
+                processor_id: 0x1
+                proc_access_master: 0x23
+                proc_access_secondary: [0xC, 0, 0]
             -
                 processor_id: 0
                 proc_access_master: 0