mail archive of the barebox mailing list
 help / color / mirror / Atom feed
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




  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