From: Tanmay Shah <tanmay.shah@amd.com>
To: <michal.simek@amd.com>
Cc: <linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, Tanmay Shah <tanmay.shah@amd.com>
Subject: [PATCH] firmware: xilinx: support RPU boot from DDR
Date: Mon, 3 Aug 2026 13:05:02 -0700 [thread overview]
Message-ID: <20260803200502.209361-1-tanmay.shah@amd.com> (raw)
Cortex-R52 cores can boot from DDR. In such case, elf's boot address
will be in the ddr, and it should be passed to the PLM via EEMI call.
Add ddr boot config EEMI call before starting RPU to configure the boot
address. Also make sure TCM-Boot is support for old platforms as well.
Remove HIVEC & LOVEC enum, as now PLM supports boot address directly.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
---
drivers/firmware/xilinx/zynqmp.c | 44 ++++++++++++++++++++++++----
include/linux/firmware/xlnx-zynqmp.h | 5 ----
2 files changed, 38 insertions(+), 11 deletions(-)
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index f9a3a95b0638..bc3e407dbac3 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -1523,7 +1523,6 @@ EXPORT_SYMBOL_GPL(zynqmp_pm_request_wake);
*/
int zynqmp_pm_start_rpu(const u32 node, const u64 bootaddr)
{
- enum rpu_boot_mem bootmem;
int ret;
/*
@@ -1532,22 +1531,55 @@ int zynqmp_pm_start_rpu(const u32 node, const u64 bootaddr)
* starts at the base-address and subsequent vectors are on 4-byte
* boundaries.
*
+ * The Cortex-R5 cores can boot from TCM and OCM memories.
* Exception vectors can start either from 0x0000_0000 (LOVEC) or
* from 0xFFFF_0000 (HIVEC) which is mapped in the OCM (On-Chip Memory)
*
* Usually firmware will put Exception vectors at LOVEC.
*
+ * The Cortex-R52 cores can boot from DDR and TCM.
+ * That means vector table can be at address 0x0 or at any DDR address
+ * that is in the 32-bit address range. Note that booting from DDR
+ * address 0x0 is not supported and the user must always assume that if
+ * 0x0 address is passed, then it will be TCM boot.
+ *
* It is not recommend that you change the exception vector.
* Changing the EVP to HIVEC will result in increased interrupt latency
* and jitter. Also, if the OCM is secured and the Cortex-R5F processor
* is non-secured, then the Cortex-R5F processor cannot access the
* HIVEC exception vectors in the OCM.
*/
- bootmem = (bootaddr >= 0xFFFC0000) ?
- PM_RPU_BOOTMEM_HIVEC : PM_RPU_BOOTMEM_LOVEC;
+ if (upper_32_bits(bootaddr)) {
+ pr_err("invalid bootaddr = 0x%llx\n", bootaddr);
+ return -EINVAL;
+ }
- pr_debug("RPU boot addr 0x%llx from %s.", bootaddr,
- bootmem == PM_RPU_BOOTMEM_HIVEC ? "OCM" : "TCM");
+ /*
+ * New platforms can boot from DDR and require the DDR address
+ * to be configured explicitly. If the correct version of the
+ * IOCTL_RPU_BOOT_ADDR_CONFIG ioctl is not supported, do not
+ * treat it as a failure. If a DDR address is passed on other
+ * platforms, the PM request wake EEMI call will still fail and
+ * the RPU won't boot.
+ */
+ ret = zynqmp_pm_is_function_supported(PM_IOCTL,
+ IOCTL_RPU_BOOT_ADDR_CONFIG);
+ if (!ret) {
+ /* config ddr boot address */
+ ret = zynqmp_pm_invoke_fn(PM_IOCTL, NULL, 3,
+ node,
+ IOCTL_RPU_BOOT_ADDR_CONFIG,
+ bootaddr);
+ if (ret < 0) {
+ pr_err("failed to set RPU Boot address 0x%llx\n",
+ bootaddr);
+ return ret;
+ }
+ } else if (ret != -EOPNOTSUPP && ret != -ENODATA) {
+ pr_err("ioctl rpu boot addr config ver check failed %d\n",
+ ret);
+ return ret;
+ }
/* Request node before starting RPU core if new version of API is supported */
if (zynqmp_pm_feature(PM_REQUEST_NODE) > PM_API_VERSION_1) {
@@ -1561,7 +1593,7 @@ int zynqmp_pm_start_rpu(const u32 node, const u64 bootaddr)
}
ret = zynqmp_pm_request_wake(node, true,
- bootmem, ZYNQMP_PM_REQUEST_ACK_NO);
+ bootaddr, ZYNQMP_PM_REQUEST_ACK_NO);
if (ret)
pr_err("failed to start RPU = 0x%x\n", node);
return ret;
diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
index 347df66ee176..577a762e624b 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -269,11 +269,6 @@ enum rpu_oper_mode {
PM_RPU_MODE_SPLIT = 1,
};
-enum rpu_boot_mem {
- PM_RPU_BOOTMEM_LOVEC = 0,
- PM_RPU_BOOTMEM_HIVEC = 1,
-};
-
enum rpu_tcm_comb {
PM_RPU_TCM_SPLIT = 0,
PM_RPU_TCM_COMB = 1,
base-commit: 9a4cdc958dd79fc6c3b20b51a10debec6ca09fec
--
2.34.1
next reply other threads:[~2026-08-03 20:05 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 20:05 Tanmay Shah [this message]
2026-09-25 13:42 ` Michal Simek
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=20260803200502.209361-1-tanmay.shah@amd.com \
--to=tanmay.shah@amd.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.simek@amd.com \
/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
all inboxes | Powered by JetHome®