From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: barebox@lists.infradead.org
Cc: Ahmad Fatoum <a.fatoum@pengutronix.de>
Subject: [PATCH 5/9] mci: pbl: add autodetection of BootROM-initialized standard capacity cards
Date: Tue, 22 Apr 2025 07:26:31 +0200 [thread overview]
Message-ID: <20250422052635.3423961-6-a.fatoum@pengutronix.de> (raw)
In-Reply-To: <20250422052635.3423961-1-a.fatoum@pengutronix.de>
We more or less manage without driver model in PBL, because we reuse
hardware setup done by the BootROM.
In case of SD/eMMC cards, this presents one annoying problem: A card in
transfer state can't be asked whether it's standard or high capacity,
but we require this information to know whether we need to use a byte or
a block offset for the READ_MULTIPLE_BLOCK command.
We had a number of workaround for that:
- On i.MX, the bootloader is located raw near the start of the SD/MMC,
so we just read from offset 0 onwards and then jump to the correct
location
- On AT91SAM9, the BootROM supports only standard capacity SD-Cards,
so we hardcode that
- On older platforms, we have a separate configuration for the
first stage that can use the normal mci-core and reinitialized
the card with the downside of needing two builds.
- On everything else, we assume that we have a high capacity card.
Fortunately, at the modest cost of 4 commands, we can get out
of transmission mode, ask the card for its capacity and back,
so let's do that.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
drivers/mci/mci-pbl.c | 108 ++++++++++++++++++++++++++++++++++++++++--
1 file changed, 105 insertions(+), 3 deletions(-)
diff --git a/drivers/mci/mci-pbl.c b/drivers/mci/mci-pbl.c
index b58cd8dafe84..610002b3d022 100644
--- a/drivers/mci/mci-pbl.c
+++ b/drivers/mci/mci-pbl.c
@@ -1,4 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
+// SPDX-FileCopyrightText: 2025 Ahmad Fatoum
/*
* This code assumes that the SD/eMMC is already in transfer mode,
* because it card initialization has been done by the BootROM.
@@ -16,7 +17,6 @@
#include <pbl/mci.h>
#include <pbl/bio.h>
#include <linux/minmax.h>
-#include <linux/bug.h>
#define MCI_PBL_BLOCK_LEN 512
@@ -76,6 +76,22 @@ static int pbl_bio_mci_read(struct pbl_bio *bio, off_t start,
return count;
}
+static enum pbl_mci_capacity capacity_decode(unsigned csd_struct_ver)
+{
+ switch (csd_struct_ver) {
+ case 0:
+ return PBL_MCI_STANDARD_CAPACITY;
+ case 1:
+ return PBL_MCI_HIGH_CAPACITY;
+ case 2:
+ return PBL_MCI_ULTRA_CAPACITY;
+ case 3:
+ return PBL_MCI_RESERVED_CAPACITY;
+ }
+
+ return PBL_MCI_UNKNOWN_CAPACITY;
+}
+
static const char *capacity_tostr(enum pbl_mci_capacity capacity)
{
switch (capacity) {
@@ -94,11 +110,97 @@ static const char *capacity_tostr(enum pbl_mci_capacity capacity)
return "unknown";
}
+/**
+ * pbl_mci_check_high_capacity() - Determine what type of card we have
+ * @mci: already initialized MCI card
+ *
+ * Standard capacity cards use a byte offset for the READ_MULTIPLE_BLOCK
+ * command argument, which high capacity uses a block offset.
+ *
+ * As we haven't set up the card ourselves here, we do not have
+ * this information directly available.
+ *
+ * A workaround is reading from address 0 onwards, which works for raw
+ * second stage barebox located near start of the card, but is not so
+ * good when we need to load barebox from a file system.
+ *
+ * This function implements the necessary state transitions, so we
+ * can reread the CSD and determine, which the card is high capacity
+ * or not.
+ *
+ * Refer to Part1_Physical_Layer_Simplified_Specification_Ver9.00.pdf
+ * "Figure 4-13 : SD Memory Card State Diagram (data transfer mode)"
+ * for a visualization of how this works.
+ *
+ * Return: 0 when capacity type could be determined and
+ * mci->high_capacity was updated or a negative return code upon error.
+ */
+static int pbl_mci_check_high_capacity(struct pbl_mci *mci)
+{
+ struct mci_cmd cmd = {};
+ unsigned rca_arg = 0; /* RCA shifted up by 16 bis */
+ int ret, ret2;
+
+ /* CMD7: Deselect all cards and move into standby mode */
+ mci_setup_cmd(&cmd, MMC_CMD_SELECT_CARD, 0, MMC_RSP_NONE);
+ ret = pbl_mci_send_cmd(mci, &cmd, NULL);
+ if (ret) {
+ pr_debug("deselecting cards failed: %d\n", ret);
+ return ret;
+ }
+
+ /*
+ * CMD3: Need to get RCA for SDs, so we can use it to communicate
+ * with the correct SD (argument to CMD9)
+ *
+ * TODO: What to do about eMMCs? These would get a
+ * MMC_CMD_SET_RELATIVE_ADDR here
+ *
+ * Figure 27 — e•MMC state diagram (data transfer mode) n
+ * JESD84-B51.pdf doesn't list CMD3 as allowed command while
+ * in stand-by mode
+ */
+ mci_setup_cmd(&cmd, SD_CMD_SEND_RELATIVE_ADDR, 0, MMC_RSP_R6);
+ ret = pbl_mci_send_cmd(mci, &cmd, NULL);
+ if (ret) {
+ pr_debug("sending relative address failed: %d\n", ret);
+ goto out;
+ }
+
+ rca_arg = cmd.response[0] & GENMASK(31, 16);
+
+ /* CMD9: Get the Card-Specific Data */
+ mci_setup_cmd(&cmd, MMC_CMD_SEND_CSD, rca_arg, MMC_RSP_R2);
+ ret = pbl_mci_send_cmd(mci, &cmd, NULL);
+ if (ret) {
+ pr_err("sending CSD failed: %d\n", ret);
+ goto out;
+ }
+
+ /* Check CSD version */
+ mci->capacity = capacity_decode(cmd.response[0] >> 30);
+ pr_debug("detect %s capacity\n", capacity_tostr(mci->capacity));
+
+out:
+ /* CMD7: now let's got get back to transfer mode */
+ mci_setup_cmd(&cmd, MMC_CMD_SELECT_CARD, rca_arg, MMC_RSP_R1b);
+ ret2 = pbl_mci_send_cmd(mci, &cmd, NULL);
+ if (ret2) {
+ pr_err("reselecting card with %x failed: %d\n", rca_arg, ret2);
+ return ret2;
+ }
+
+ return ret;
+}
+
int pbl_mci_bio_init(struct pbl_mci *mci, struct pbl_bio *bio)
{
-
+ /*
+ * There's no useful recovery possible here, so we try to continue
+ * after having printed an error
+ */
if (mci->capacity == PBL_MCI_UNKNOWN_CAPACITY)
- BUG();
+ (void)pbl_mci_check_high_capacity(mci);
else
pr_debug("assuming %s capacity card\n",
capacity_tostr(mci->capacity));
--
2.39.5
next prev parent reply other threads:[~2025-04-22 5:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-22 5:26 [PATCH 0/9] ARM: OMAP: beaglebone: add PBL SD xload support Ahmad Fatoum
2025-04-22 5:26 ` [PATCH 1/9] clocksource: make available in PBL Ahmad Fatoum
2025-04-22 5:26 ` [PATCH 2/9] clocksource: ti-dm: " Ahmad Fatoum
2025-04-22 5:26 ` [PATCH 3/9] mci: move mci_setup_cmd definition into header Ahmad Fatoum
2025-04-22 5:26 ` [PATCH 4/9] mci: add common PBL helper for chainloading after BootROM initialization Ahmad Fatoum
2025-04-22 5:26 ` Ahmad Fatoum [this message]
2025-04-22 5:26 ` [PATCH 6/9] mci: omap_hsmmc: split out common code Ahmad Fatoum
2025-04-22 5:26 ` [PATCH 7/9] ARM: OMAP: add am33xx_hsmmc_start_image for PBL Ahmad Fatoum
2025-04-22 5:26 ` [PATCH 8/9] mci: omap_hsmmc: add xload implementation " Ahmad Fatoum
2025-04-22 5:26 ` [PATCH 9/9] ARM: OMAP: beaglebone: add PBL SD xload support Ahmad Fatoum
2025-04-22 10:55 ` [PATCH 0/9] " 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=20250422052635.3423961-6-a.fatoum@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
/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