From: Stefan Kerkmann <s.kerkmann@pengutronix.de>
To: Sascha Hauer <s.hauer@pengutronix.de>,
Ahmad Fatoum <a.fatoum@pengutronix.de>,
BAREBOX <barebox@lists.infradead.org>
Cc: Stefan Kerkmann <s.kerkmann@pengutronix.de>
Subject: [PATCH v2 2/2] habv4: use hab rom implementation of report_event
Date: Fri, 12 Jan 2024 16:21:08 +0100 [thread overview]
Message-ID: <20240112-fix-habv4-event-report-v2-2-1c91bc857935@pengutronix.de> (raw)
In-Reply-To: <20240112-fix-habv4-event-report-v2-0-1c91bc857935@pengutronix.de>
The existing habv4 rom vector table had some mismatches in the API of
the function pointers which broke calling into the HAB rom - mainly
observed with the `report_event` function. The suspected culprit here is
the `bytes` pointer which was `uint32_t*` vs. the documented `size_t*`.
When compiled using the ILP32 data model e.g. for 32-Bit systems both
referrenced values have the same width, but once compiled for (I)LP64
they differ as `size_t` is 64-Bit wide there. This seems to trigger a
memory corruption once that pointer is passed to the HAB boot rom code
and dereferenced there, the root cause wasn't investigated further
though.
As this implementation has only been tested on imx8mm, imx8nm and imx8mp
boards I'm beeing defensive and only enable it for these targets. Once
all SOCs of the family have been verified to work correctly the OCRAM
readout workaround can be removed.
Signed-off-by: Stefan Kerkmann <s.kerkmann@pengutronix.de>
---
drivers/hab/habv4.c | 48 ++++++++++++++++++++++++++++++++++++++----------
1 file changed, 38 insertions(+), 10 deletions(-)
diff --git a/drivers/hab/habv4.c b/drivers/hab/habv4.c
index 92bee8399d..4e401ca9d3 100644
--- a/drivers/hab/habv4.c
+++ b/drivers/hab/habv4.c
@@ -184,6 +184,33 @@ enum hab_sip_cmd {
FSL_SIP_HAB_AUTH_IMG_NO_DCD = 0x08,
};
+static enum hab_status hab_sip_report_event(enum hab_status status,
+ uint32_t index, uint8_t *event,
+ size_t *bytes)
+{
+ struct arm_smccc_res res;
+
+ v8_flush_dcache_range((unsigned long)bytes,
+ (unsigned long)bytes + sizeof(*bytes));
+
+ if (event)
+ v8_flush_dcache_range((unsigned long)event,
+ (unsigned long)event + *bytes);
+
+ arm_smccc_smc(FSL_SIP_HAB, FSL_SIP_HAB_REPORT_EVENT,
+ (unsigned long)index, (unsigned long)event,
+ (unsigned long)bytes, 0, 0, 0, &res);
+
+ v8_inv_dcache_range((unsigned long)bytes,
+ (unsigned long)bytes + sizeof(*bytes));
+
+ if (event)
+ v8_inv_dcache_range((unsigned long)event,
+ (unsigned long)event + *bytes);
+
+ return (enum hab_status)res.a0;
+}
+
static enum hab_status hab_sip_report_status(enum hab_config *config,
enum habv4_state *state)
{
@@ -220,9 +247,6 @@ static uint32_t hab_sip_get_version(void)
#define HABV4_EVENT_MAX_LEN 0x80
#define IMX8MQ_ROM_OCRAM_ADDRESS 0x9061C0
-#define IMX8MM_ROM_OCRAM_ADDRESS 0x908040
-#define IMX8MN_ROM_OCRAM_ADDRESS 0x908040
-#define IMX8MP_ROM_OCRAM_ADDRESS 0x90D040
static enum hab_status imx8m_read_sram_events(enum hab_status status,
uint32_t index, uint8_t *event,
@@ -239,12 +263,6 @@ static enum hab_status imx8m_read_sram_events(enum hab_status status,
if (cpu_is_mx8mq())
sram = (char *)IMX8MQ_ROM_OCRAM_ADDRESS;
- else if (cpu_is_mx8mm())
- sram = (char *)IMX8MM_ROM_OCRAM_ADDRESS;
- else if (cpu_is_mx8mn())
- sram = (char *)IMX8MN_ROM_OCRAM_ADDRESS;
- else if (cpu_is_mx8mp())
- sram = (char *)IMX8MP_ROM_OCRAM_ADDRESS;
else
return HAB_STATUS_FAILURE;
@@ -296,9 +314,19 @@ static enum hab_status imx8m_read_sram_events(enum hab_status status,
return HAB_STATUS_FAILURE;
}
+static enum hab_status imx8m_report_event(enum hab_status status,
+ uint32_t index, uint8_t *event,
+ size_t *bytes)
+{
+ if (cpu_is_mx8mm() || cpu_is_mx8mn() || cpu_is_imx8mp())
+ return hab_sip_report_event(status, index, event, bytes);
+ else
+ return imx8m_read_sram_events(status, index, event, bytes);
+}
+
struct habv4_rvt hab_smc_ops = {
.header = { .tag = 0xdd },
- .report_event = imx8m_read_sram_events,
+ .report_event = imx8m_report_event,
.report_status = hab_sip_report_status,
};
--
2.39.2
next prev parent reply other threads:[~2024-01-12 15:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-12 15:21 [PATCH v2 0/2] Use HABv4 report_event implementation for imx8mm and imx8mn Stefan Kerkmann
2024-01-12 15:21 ` [PATCH v2 1/2] habv4: correct habv4 rom vector table Stefan Kerkmann
2024-01-12 15:21 ` Stefan Kerkmann [this message]
2024-01-12 16:29 ` [PATCH v2 2/2] habv4: use hab rom implementation of report_event Stefan Kerkmann
2024-01-16 6:53 ` Sascha Hauer
2024-01-16 8:13 ` Ahmad Fatoum
2024-01-17 7:20 ` Sascha Hauer
2024-01-17 7:45 ` Stefan Kerkmann
2024-01-16 6:50 ` [PATCH v2 0/2] Use HABv4 report_event implementation for imx8mm and imx8mn Sascha Hauer
2024-01-16 7:09 ` Sascha Hauer
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=20240112-fix-habv4-event-report-v2-2-1c91bc857935@pengutronix.de \
--to=s.kerkmann@pengutronix.de \
--cc=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.de \
/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