[PATCH RESEND 0/2] spacemit: k1: SPL robustness for boards without a PMIC or SPI NOR

[PATCH RESEND 0/2] spacemit: k1: SPL robustness for boards without a PMIC or SPI NOR

[Dave Klotz]

Resent: the first posting's cover letter went out with the same
Message-ID as the cover letter of "pci: spacemit: fixes for the K1 PCIe
host driver", so this series threaded under that one. No changes.

Two small SPL changes for K1 boards that do not look like the BPI-F3
and MusePi Pro:

1. pmic_init() and nor_early_init() panic when the device tree gives
   the SPL no PMIC or no SPI controller. A board that boots from eMMC or
   microSD with its rails already up (the OrangePi R2S and RV2) stops
   there. Log it and carry on.
2. Provide board_boot_order(): the device the BootROM booted from, as
   detected now, then the other MMC controller and SPI NOR, so an
   unexpected BootROM path still finds U-Boot.

Tested on an OrangePi RV2 booting from microSD (no SPI controller in
the SPL): "No SPI controller", then the SPL loads U-Boot from the card
through the detected MMC2. The fallback order was not exercised, since
the detection was right.

Dave Klotz (2):
  spacemit: k1: do not require a PMIC or an SPI controller in SPL
  spacemit: k1: fall back to the other boot devices in SPL

 board/spacemit/k1/spl.c | 48 +++++++++++++++++++++++++++++++++++++----
 1 file changed, 44 insertions(+), 4 deletions(-)


base-commit: a000f2af240eaa996cec92f8d44bad96fdf3f898
-- 
2.55.0

[PATCH RESEND 1/2] spacemit: k1: do not require a PMIC or an SPI controller in SPL

[Dave Klotz]

pmic_init() and nor_early_init() panic when the board device tree
describes no PMIC or no SPI controller to the SPL. The OrangePi R2S
boots from eMMC with its rails already up, and boards that boot from
eMMC or microSD need no SPI NOR, so the SPL stops before it can load
U-Boot.

Log the missing device and carry on instead. If the SPL then has to
boot from SPI without a controller, spl_spi_load_image() reports it.

Signed-off-by: Dave Klotz <DaveWK225@protonmail.com>
---
 board/spacemit/k1/spl.c | 22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/board/spacemit/k1/spl.c b/board/spacemit/k1/spl.c
index ef23db62d6..96ee4449c4 100644
--- a/board/spacemit/k1/spl.c
+++ b/board/spacemit/k1/spl.c
@@ -301,8 +301,16 @@ void pmic_init(void)
 	int ret;
 
 	ret = uclass_get_device(UCLASS_PMIC, 0, &pmic_dev);
-	if (ret)
-		panic("Fail to detect PMIC (%d)\n", ret);
+	if (ret) {
+		/*
+		 * Not every K1 board describes its PMIC to the SPL, and on some
+		 * the rails are already up when the SPL runs. Only boards whose
+		 * DDR bring-up depends on programming the bucks need one, so a
+		 * missing PMIC is not fatal here.
+		 */
+		log_info("No PMIC (%d), leaving rails as found\n", ret);
+		return;
+	}
 	set_vdd_core();
 	set_vdd_1v8();
 	set_vdd_mmc();
@@ -412,9 +420,15 @@ void nor_early_init(void)
 	struct udevice *dev;
 	int ret;
 
+	/*
+	 * A board that boots from eMMC or microSD may describe no SPI
+	 * controller at all; that is not fatal unless the SPL boots from SPI.
+	 */
 	ret = uclass_get_device(UCLASS_SPI, 0, &dev);
-	if (ret)
-		panic("Fail to detect spi controller.\n");
+	if (ret) {
+		log_info("No SPI controller (%d)\n", ret);
+		return;
+	}
 	udelay(10);
 	ret = uclass_get_device(UCLASS_SPI_FLASH, 0, &dev);
 	if (ret)
-- 
2.55.0

[PATCH RESEND 2/2] spacemit: k1: fall back to the other boot devices in SPL

[Dave Klotz]

spl_boot_device() derives the boot device from BootROM state: the SD
API pointer the BootROM leaves in SRAM, the boot flag register, and the
boot strap. Not every BootROM path is covered by that. On the OrangePi
R2S, for example, the BootROM probes a card first ("try sd...") and only
then loads the FSBL from eMMC, and on the OrangePi RV2 it falls back
from the card to SPI NOR. If the detection names a device that holds no
image, the SPL stops with "failed to boot from all boot devices".

Provide board_boot_order(): the detected device first, then the other
MMC controller and SPI NOR when this SPL can read them.

Signed-off-by: Dave Klotz <DaveWK225@protonmail.com>
---
 board/spacemit/k1/spl.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/board/spacemit/k1/spl.c b/board/spacemit/k1/spl.c
index 96ee4449c4..cc0e26bb02 100644
--- a/board/spacemit/k1/spl.c
+++ b/board/spacemit/k1/spl.c
@@ -498,6 +498,32 @@ u32 spl_boot_device(void)
 	return ret;
 }
 
+/*
+ * Try the device the BootROM booted from first, then the other storage
+ * this SPL can read. The boot-mode detection relies on BootROM state; if
+ * it names a device that holds no image (the BootROM probed a card before
+ * falling back to eMMC, say), the SPL still finds U-Boot instead of
+ * stopping at "failed to boot from all boot devices".
+ */
+void board_boot_order(u32 *spl_boot_list)
+{
+	u32 fallbacks[3];
+	int i, n = 0, m = 0;
+
+	if (CONFIG_IS_ENABLED(MMC)) {
+		fallbacks[m++] = BOOT_DEVICE_MMC1;
+		fallbacks[m++] = BOOT_DEVICE_MMC2;
+	}
+	if (CONFIG_IS_ENABLED(SPI_LOAD))
+		fallbacks[m++] = BOOT_DEVICE_SPI;
+
+	spl_boot_list[n++] = spl_boot_device();
+	for (i = 0; i < m; i++)
+		if (fallbacks[i] != spl_boot_list[0])
+			spl_boot_list[n++] = fallbacks[i];
+	spl_boot_list[n] = BOOT_DEVICE_NONE;
+}
+
 void spl_board_init(void)
 {
 }
-- 
2.55.0

Re: [PATCH RESEND 0/2] spacemit: k1: SPL robustness for boards without a PMIC or SPI NOR

[Dave Klotz]

Also tested on an OrangePi R2S (K1, 2 GiB, boots from eMMC), with the
same tree as the RV2 runs (upstream next plus these series and board
support that is not posted yet):

- the SPL logs "No PMIC (-19)" and "No SPI controller (-96)" and goes
  on to load U-Boot from the eMMC, which the boot-mode detection named
  correctly (BOOT_DEVICE_MMC1), so the fallback order was not needed;
- FreeBSD's reboot resets the board through OpenSBI and the board comes
  back up unattended.