[RESEND PATCH v3 0/3] rpi: Convert to standard boot

[RESEND PATCH v3 0/3] rpi: Convert to standard boot

[Simon Glass]

This series moves Raspberry Pi boards over to use standard boot.

It also moves rpi over to use a text-based environment. Unfortunately it
is not possible to empty the header file due to several CFG options.

Fix the repeated "and and" while we are here.

Note that this reduces rodata size by about 4.5KB. We could get another

for a total image-size saving of about 15KB. This is mostly because
HUSH_PARSER is not enabled anymore and the environment shrinks down by
about 3.5K. Hush is not actually needed anymore, since standard boot does
not use it. Also CMD_SYSBOOT is dropped since standard boot calls the
pxe_utils code directly in that case.

Changes in v3:
- Rebase to -master

Changes in v2:
- Rebase to -next
- Add new patch to disable DISTRO_DEFAULTS

Simon Glass (3):
  arm: rpi: Switch to standard boot
  rpi: Disable DISTRO_DEFAULTS
  arm: rpi: Switch to a text environment

 board/raspberrypi/rpi/rpi.env  |  77 +++++++++++++++++++
 configs/rpi_0_w_defconfig      |   2 +-
 configs/rpi_2_defconfig        |   2 +-
 configs/rpi_3_32b_defconfig    |   2 +-
 configs/rpi_3_b_plus_defconfig |   2 +-
 configs/rpi_3_defconfig        |   2 +-
 configs/rpi_4_32b_defconfig    |   2 +-
 configs/rpi_4_defconfig        |   2 +-
 configs/rpi_arm64_defconfig    |   2 +-
 configs/rpi_defconfig          |   2 +-
 include/configs/rpi.h          | 134 ---------------------------------
 11 files changed, 86 insertions(+), 143 deletions(-)
 create mode 100644 board/raspberrypi/rpi/rpi.env

-- 
2.41.0.487.g6d72f3e995-goog

[RESEND PATCH v3 1/3] arm: rpi: Switch to standard boot

[Simon Glass]

Drop use of the distro scripts and use standard boot instead.

We don't need to specify the mmc devices individually, since they are
used in order from 0 to 2, and standard boot uses that order anyway.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v3:
- Rebase to -master

Changes in v2:
- Rebase to -next

 configs/rpi_0_w_defconfig      |  1 +
 configs/rpi_2_defconfig        |  1 +
 configs/rpi_3_32b_defconfig    |  1 +
 configs/rpi_3_b_plus_defconfig |  1 +
 configs/rpi_3_defconfig        |  1 +
 configs/rpi_4_32b_defconfig    |  1 +
 configs/rpi_4_defconfig        |  1 +
 configs/rpi_arm64_defconfig    |  1 +
 configs/rpi_defconfig          |  1 +
 include/configs/rpi.h          | 38 ++--------------------------------
 10 files changed, 11 insertions(+), 36 deletions(-)

diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig
index 5da334a8bcf9..7554e671e2ca 100644
--- a/configs/rpi_0_w_defconfig
+++ b/configs/rpi_0_w_defconfig
@@ -12,6 +12,7 @@ CONFIG_DEFAULT_DEVICE_TREE="bcm2835-rpi-zero-w"
 CONFIG_SYS_PROMPT="U-Boot> "
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_SYS_LOAD_ADDR=0x1000000
+CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_USE_PREBOOT=y
diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig
index 990862160712..653f78bec1e8 100644
--- a/configs/rpi_2_defconfig
+++ b/configs/rpi_2_defconfig
@@ -13,6 +13,7 @@ CONFIG_DEFAULT_DEVICE_TREE="bcm2836-rpi-2-b"
 CONFIG_SYS_PROMPT="U-Boot> "
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_SYS_LOAD_ADDR=0x1000000
+CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_USE_PREBOOT=y
diff --git a/configs/rpi_3_32b_defconfig b/configs/rpi_3_32b_defconfig
index 80885aa9488d..305f1dacfd46 100644
--- a/configs/rpi_3_32b_defconfig
+++ b/configs/rpi_3_32b_defconfig
@@ -12,6 +12,7 @@ CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b"
 CONFIG_SYS_PROMPT="U-Boot> "
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_SYS_LOAD_ADDR=0x1000000
+CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_USE_PREBOOT=y
diff --git a/configs/rpi_3_b_plus_defconfig b/configs/rpi_3_b_plus_defconfig
index 0acce8b883f8..f36f1258aa6d 100644
--- a/configs/rpi_3_b_plus_defconfig
+++ b/configs/rpi_3_b_plus_defconfig
@@ -11,6 +11,7 @@ CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b-plus"
 CONFIG_SYS_PROMPT="U-Boot> "
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_SYS_LOAD_ADDR=0x1000000
+CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_USE_PREBOOT=y
diff --git a/configs/rpi_3_defconfig b/configs/rpi_3_defconfig
index bb6fe128061b..a0d8be42537f 100644
--- a/configs/rpi_3_defconfig
+++ b/configs/rpi_3_defconfig
@@ -11,6 +11,7 @@ CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b"
 CONFIG_SYS_PROMPT="U-Boot> "
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_SYS_LOAD_ADDR=0x1000000
+CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_USE_PREBOOT=y
diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig
index f6213340971e..71f61c52e52d 100644
--- a/configs/rpi_4_32b_defconfig
+++ b/configs/rpi_4_32b_defconfig
@@ -10,6 +10,7 @@ CONFIG_SYS_PROMPT="U-Boot> "
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_SYS_LOAD_ADDR=0x1000000
+CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_PCI=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_DISTRO_DEFAULTS=y
diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
index bbc0fd6c649a..fa2c05da21e8 100644
--- a/configs/rpi_4_defconfig
+++ b/configs/rpi_4_defconfig
@@ -10,6 +10,7 @@ CONFIG_SYS_PROMPT="U-Boot> "
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_SYS_LOAD_ADDR=0x1000000
+CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_PCI=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_DISTRO_DEFAULTS=y
diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
index 5d9a273cb920..3e64573b70b1 100644
--- a/configs/rpi_arm64_defconfig
+++ b/configs/rpi_arm64_defconfig
@@ -10,6 +10,7 @@ CONFIG_SYS_PROMPT="U-Boot> "
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_SYS_LOAD_ADDR=0x1000000
+CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_PCI=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_DISTRO_DEFAULTS=y
diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig
index 550b8dcb9587..4b8e402c89d4 100644
--- a/configs/rpi_defconfig
+++ b/configs/rpi_defconfig
@@ -12,6 +12,7 @@ CONFIG_DEFAULT_DEVICE_TREE="bcm2835-rpi-b"
 CONFIG_SYS_PROMPT="U-Boot> "
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_SYS_LOAD_ADDR=0x1000000
+CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_USE_PREBOOT=y
diff --git a/include/configs/rpi.h b/include/configs/rpi.h
index 4da982f73578..4160db2d8e14 100644
--- a/include/configs/rpi.h
+++ b/include/configs/rpi.h
@@ -122,47 +122,13 @@
 	"fdt_addr_r=0x02600000\0" \
 	"ramdisk_addr_r=0x02700000\0"
 
-#if IS_ENABLED(CONFIG_CMD_MMC)
-	#define BOOT_TARGET_MMC(func) \
-		func(MMC, mmc, 0) \
-		func(MMC, mmc, 1) \
-		func(MMC, mmc, 2)
-#else
-	#define BOOT_TARGET_MMC(func)
-#endif
-
-#if IS_ENABLED(CONFIG_CMD_USB)
-	#define BOOT_TARGET_USB(func) func(USB, usb, 0)
-#else
-	#define BOOT_TARGET_USB(func)
-#endif
-
-#if CONFIG_IS_ENABLED(CMD_PXE)
-	#define BOOT_TARGET_PXE(func) func(PXE, pxe, na)
-#else
-	#define BOOT_TARGET_PXE(func)
-#endif
-
-#if CONFIG_IS_ENABLED(CMD_DHCP)
-	#define BOOT_TARGET_DHCP(func) func(DHCP, dhcp, na)
-#else
-	#define BOOT_TARGET_DHCP(func)
-#endif
-
-#define BOOT_TARGET_DEVICES(func) \
-	BOOT_TARGET_MMC(func) \
-	BOOT_TARGET_USB(func) \
-	BOOT_TARGET_PXE(func) \
-	BOOT_TARGET_DHCP(func)
-
-#include <config_distro_bootcmd.h>
+#define BOOT_TARGETS	"mmc usb pxe dhcp"
 
 #define CFG_EXTRA_ENV_SETTINGS \
 	"dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \
 	ENV_DEVICE_SETTINGS \
 	ENV_DFU_SETTINGS \
 	ENV_MEM_LAYOUT_SETTINGS \
-	BOOTENV
-
+	"boot_targets=" BOOT_TARGETS "\0"
 
 #endif
-- 
2.41.0.487.g6d72f3e995-goog

[RESEND PATCH v3 2/3] rpi: Disable DISTRO_DEFAULTS

[Simon Glass]

Disable this option to reclaim some space, since bootstd requires less
functionality to operate (e.g. hush parser).

Signed-off-by: Simon Glass <sjg@chromium.org>
---

(no changes since v2)

Changes in v2:
- Add new patch to disable DISTRO_DEFAULTS

 configs/rpi_0_w_defconfig      | 1 -
 configs/rpi_2_defconfig        | 1 -
 configs/rpi_3_32b_defconfig    | 1 -
 configs/rpi_3_b_plus_defconfig | 1 -
 configs/rpi_3_defconfig        | 1 -
 configs/rpi_4_32b_defconfig    | 1 -
 configs/rpi_4_defconfig        | 1 -
 configs/rpi_arm64_defconfig    | 1 -
 configs/rpi_defconfig          | 1 -
 9 files changed, 9 deletions(-)

diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig
index 7554e671e2ca..3167bfbe48f7 100644
--- a/configs/rpi_0_w_defconfig
+++ b/configs/rpi_0_w_defconfig
@@ -14,7 +14,6 @@ CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_SYS_LOAD_ADDR=0x1000000
 CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_DISTRO_DEFAULTS=y
 CONFIG_USE_PREBOOT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig
index 653f78bec1e8..883dab161702 100644
--- a/configs/rpi_2_defconfig
+++ b/configs/rpi_2_defconfig
@@ -15,7 +15,6 @@ CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_SYS_LOAD_ADDR=0x1000000
 CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_DISTRO_DEFAULTS=y
 CONFIG_USE_PREBOOT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
diff --git a/configs/rpi_3_32b_defconfig b/configs/rpi_3_32b_defconfig
index 305f1dacfd46..5ff7d987a431 100644
--- a/configs/rpi_3_32b_defconfig
+++ b/configs/rpi_3_32b_defconfig
@@ -14,7 +14,6 @@ CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_SYS_LOAD_ADDR=0x1000000
 CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_DISTRO_DEFAULTS=y
 CONFIG_USE_PREBOOT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
diff --git a/configs/rpi_3_b_plus_defconfig b/configs/rpi_3_b_plus_defconfig
index f36f1258aa6d..31f2a6eb310c 100644
--- a/configs/rpi_3_b_plus_defconfig
+++ b/configs/rpi_3_b_plus_defconfig
@@ -13,7 +13,6 @@ CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_SYS_LOAD_ADDR=0x1000000
 CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_DISTRO_DEFAULTS=y
 CONFIG_USE_PREBOOT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
diff --git a/configs/rpi_3_defconfig b/configs/rpi_3_defconfig
index a0d8be42537f..fa6e1507d640 100644
--- a/configs/rpi_3_defconfig
+++ b/configs/rpi_3_defconfig
@@ -13,7 +13,6 @@ CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_SYS_LOAD_ADDR=0x1000000
 CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_DISTRO_DEFAULTS=y
 CONFIG_USE_PREBOOT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig
index 71f61c52e52d..55bf6c0770f0 100644
--- a/configs/rpi_4_32b_defconfig
+++ b/configs/rpi_4_32b_defconfig
@@ -13,7 +13,6 @@ CONFIG_SYS_LOAD_ADDR=0x1000000
 CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_PCI=y
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_DISTRO_DEFAULTS=y
 CONFIG_USE_PREBOOT=y
 CONFIG_PREBOOT="pci enum; usb start;"
 # CONFIG_DISPLAY_CPUINFO is not set
diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
index fa2c05da21e8..6679cce9a165 100644
--- a/configs/rpi_4_defconfig
+++ b/configs/rpi_4_defconfig
@@ -13,7 +13,6 @@ CONFIG_SYS_LOAD_ADDR=0x1000000
 CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_PCI=y
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_DISTRO_DEFAULTS=y
 CONFIG_USE_PREBOOT=y
 CONFIG_PREBOOT="pci enum; usb start;"
 # CONFIG_DISPLAY_CPUINFO is not set
diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
index 3e64573b70b1..26e29ffb5a1f 100644
--- a/configs/rpi_arm64_defconfig
+++ b/configs/rpi_arm64_defconfig
@@ -13,7 +13,6 @@ CONFIG_SYS_LOAD_ADDR=0x1000000
 CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_PCI=y
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_DISTRO_DEFAULTS=y
 CONFIG_USE_PREBOOT=y
 CONFIG_PREBOOT="pci enum; usb start;"
 # CONFIG_DISPLAY_CPUINFO is not set
diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig
index 4b8e402c89d4..0ac5efec717b 100644
--- a/configs/rpi_defconfig
+++ b/configs/rpi_defconfig
@@ -14,7 +14,6 @@ CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_SYS_LOAD_ADDR=0x1000000
 CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_DISTRO_DEFAULTS=y
 CONFIG_USE_PREBOOT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
-- 
2.41.0.487.g6d72f3e995-goog

[RESEND PATCH v3 3/3] arm: rpi: Switch to a text environment

[Simon Glass]

Use the new environment format so we can drop most of the config.h file.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

(no changes since v1)

 board/raspberrypi/rpi/rpi.env |  77 ++++++++++++++++++++++++++
 include/configs/rpi.h         | 100 ----------------------------------
 2 files changed, 77 insertions(+), 100 deletions(-)
 create mode 100644 board/raspberrypi/rpi/rpi.env

diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env
new file mode 100644
index 000000000000..30228285edde
--- /dev/null
+++ b/board/raspberrypi/rpi/rpi.env
@@ -0,0 +1,77 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+/* environment for Raspberry Pi boards */
+
+dhcpuboot=usb start; dhcp u-boot.uimg; bootm
+
+/* Environment */
+stdin=serial,usbkbd
+stdout=serial,vidconsole
+stderr=serial,vidconsole
+
+/* DFU over USB/UDC */
+#ifdef CONFIG_CMD_DFU
+dfu_alt_info=u-boot.bin fat 0 1;uboot.env fat 0 1;
+  config.txt fat 0 1;
+#ifdef CONFIG_ARM64
+dfu_alt_info+=Image fat 0 1
+#else
+dfu_alt_info+=zImage fat 0 1
+#endif
+#endif  /* CONFIG_CMD_DFU */
+
+/*
+ * Memory layout for where various images get loaded by boot scripts:
+ *
+ * I suspect address 0 is used as the SMP pen on the RPi2, so avoid this.
+ *
+ * Older versions of the boot firmware place the firmware-loaded DTB at 0x100,
+ * newer versions place it in high memory. So prevent U-Boot from doing its own
+ * DTB + initrd relocation so that we won't accidentally relocate the initrd
+ * over the firmware-loaded DTB and generally try to lay out things starting
+ * from the bottom of RAM.
+ *
+ * kernel_addr_r has different constraints on ARM and Aarch64.  For 32-bit ARM,
+ * it must be within the first 128M of RAM in order for the kernel's
+ * CONFIG_AUTO_ZRELADDR option to work. The kernel itself will be decompressed
+ * to 0x8000 but the decompressor clobbers 0x4000-0x8000 as well. The
+ * decompressor also likes to relocate itself to right past the end of the
+ * decompressed kernel, so in total the sum of the compressed and
+ * decompressed kernel needs to be reserved.
+ *
+ *   For Aarch64, the kernel image is uncompressed and must be loaded at
+ *   text_offset bytes (specified in the header of the Image) into a 2MB
+ *   boundary. The 'booti' command relocates the image if necessary. Linux uses
+ *   a default text_offset of 0x80000.  In summary, loading at 0x80000
+ *   satisfies all these constraints and reserving memory up to 0x02400000
+ *   permits fairly large (roughly 36M) kernels.
+ *
+ * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
+ * conflict with something else. Reserving 1M for each of them at
+ * 0x02400000-0x02500000 and 0x02500000-0x02600000 should be plenty.
+ *
+ * On ARM, both the DTB and any possible initrd must be loaded such that they
+ * fit inside the lowmem mapping in Linux. In practice, this usually means not
+ * more than ~700M away from the start of the kernel image but this number can
+ * be larger OR smaller depending on e.g. the 'vmalloc=xxxM' command line
+ * parameter given to the kernel. So reserving memory from low to high
+ * satisfies this constraint again. Reserving 1M at 0x02600000-0x02700000 for
+ * the DTB leaves rest of the free RAM to the initrd starting at 0x02700000.
+ * Even with the smallest possible CPU-GPU memory split of the CPU getting
+ * only 64M, the remaining 25M starting at 0x02700000 should allow quite
+ * large initrds before they start colliding with U-Boot.
+ */
+#ifdef CONFIG_ARM64
+fdt_high=ffffffffffffffff
+initrd_high=ffffffffffffffff
+#else
+fdt_high=ffffffff
+initrd_high=ffffffff
+#endif
+kernel_addr_r=0x00080000
+scriptaddr=0x02400000
+pxefile_addr_r=0x02500000
+fdt_addr_r=0x02600000
+ramdisk_addr_r=0x02700000
+
+boot_targets=mmc usb pxe dhcp
diff --git a/include/configs/rpi.h b/include/configs/rpi.h
index 4160db2d8e14..8e56bdc84a89 100644
--- a/include/configs/rpi.h
+++ b/include/configs/rpi.h
@@ -13,8 +13,6 @@
 #include <asm/arch/base.h>
 #endif
 
-/* Architecture, CPU, etc.*/
-
 /* Use SoC timer for AArch32, but architected timer for AArch64 */
 #ifndef CONFIG_ARM64
 #define CFG_SYS_TIMER_RATE		1000000
@@ -33,102 +31,4 @@
  */
 #define CFG_SYS_SDRAM_SIZE		SZ_128M
 
-/* Devices */
-/* LCD */
-
-/* DFU over USB/UDC */
-#ifdef CONFIG_CMD_DFU
-#ifdef CONFIG_ARM64
-#define KERNEL_FILENAME		"Image"
-#else
-#define KERNEL_FILENAME		"zImage"
-#endif
-
-#define ENV_DFU_SETTINGS \
-	"dfu_alt_info=u-boot.bin fat 0 1;uboot.env fat 0 1;" \
-		      "config.txt fat 0 1;" \
-		      KERNEL_FILENAME " fat 0 1\0"
-#else
-#define ENV_DFU_SETTINGS ""
-#endif
-
-/* Console configuration */
-
-/* Environment */
-
-/* Shell */
-
-/* Environment */
-#define ENV_DEVICE_SETTINGS \
-	"stdin=serial,usbkbd\0" \
-	"stdout=serial,vidconsole\0" \
-	"stderr=serial,vidconsole\0"
-
-#ifdef CONFIG_ARM64
-#define FDT_HIGH "ffffffffffffffff"
-#define INITRD_HIGH "ffffffffffffffff"
-#else
-#define FDT_HIGH "ffffffff"
-#define INITRD_HIGH "ffffffff"
-#endif
-
-/*
- * Memory layout for where various images get loaded by boot scripts:
- *
- * I suspect address 0 is used as the SMP pen on the RPi2, so avoid this.
- *
- * Older versions of the boot firmware place the firmware-loaded DTB at 0x100,
- * newer versions place it in high memory. So prevent U-Boot from doing its own
- * DTB + initrd relocation so that we won't accidentally relocate the initrd
- * over the firmware-loaded DTB and generally try to lay out things starting
- * from the bottom of RAM.
- *
- * kernel_addr_r has different constraints on ARM and Aarch64.  For 32-bit ARM,
- * it must be within the first 128M of RAM in order for the kernel's
- * CONFIG_AUTO_ZRELADDR option to work. The kernel itself will be decompressed
- * to 0x8000 but the decompressor clobbers 0x4000-0x8000 as well. The
- * decompressor also likes to relocate itself to right past the end of the
- * decompressed kernel, so in total the sum of the compressed and and
- * decompressed kernel needs to be reserved.
- *
- *   For Aarch64, the kernel image is uncompressed and must be loaded at
- *   text_offset bytes (specified in the header of the Image) into a 2MB
- *   boundary. The 'booti' command relocates the image if necessary. Linux uses
- *   a default text_offset of 0x80000.  In summary, loading at 0x80000
- *   satisfies all these constraints and reserving memory up to 0x02400000
- *   permits fairly large (roughly 36M) kernels.
- *
- * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
- * conflict with something else. Reserving 1M for each of them at
- * 0x02400000-0x02500000 and 0x02500000-0x02600000 should be plenty.
- *
- * On ARM, both the DTB and any possible initrd must be loaded such that they
- * fit inside the lowmem mapping in Linux. In practice, this usually means not
- * more than ~700M away from the start of the kernel image but this number can
- * be larger OR smaller depending on e.g. the 'vmalloc=xxxM' command line
- * parameter given to the kernel. So reserving memory from low to high
- * satisfies this constraint again. Reserving 1M at 0x02600000-0x02700000 for
- * the DTB leaves rest of the free RAM to the initrd starting at 0x02700000.
- * Even with the smallest possible CPU-GPU memory split of the CPU getting
- * only 64M, the remaining 25M starting at 0x02700000 should allow quite
- * large initrds before they start colliding with U-Boot.
- */
-#define ENV_MEM_LAYOUT_SETTINGS \
-	"fdt_high=" FDT_HIGH "\0" \
-	"initrd_high=" INITRD_HIGH "\0" \
-	"kernel_addr_r=0x00080000\0" \
-	"scriptaddr=0x02400000\0" \
-	"pxefile_addr_r=0x02500000\0" \
-	"fdt_addr_r=0x02600000\0" \
-	"ramdisk_addr_r=0x02700000\0"
-
-#define BOOT_TARGETS	"mmc usb pxe dhcp"
-
-#define CFG_EXTRA_ENV_SETTINGS \
-	"dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \
-	ENV_DEVICE_SETTINGS \
-	ENV_DFU_SETTINGS \
-	ENV_MEM_LAYOUT_SETTINGS \
-	"boot_targets=" BOOT_TARGETS "\0"
-
 #endif
-- 
2.41.0.487.g6d72f3e995-goog

Re: [RESEND PATCH v3 0/3] rpi: Convert to standard boot

[Simon Glass]

Hi Matthias, Peter,

On Thu, 27 Jul 2023 at 15:54, Simon Glass <sjg@chromium.org> wrote:
>
> This series moves Raspberry Pi boards over to use standard boot.
>
> It also moves rpi over to use a text-based environment. Unfortunately it
> is not possible to empty the header file due to several CFG options.
>
> Fix the repeated "and and" while we are here.
>
> Note that this reduces rodata size by about 4.5KB. We could get another
>
> for a total image-size saving of about 15KB. This is mostly because
> HUSH_PARSER is not enabled anymore and the environment shrinks down by
> about 3.5K. Hush is not actually needed anymore, since standard boot does
> not use it. Also CMD_SYSBOOT is dropped since standard boot calls the
> pxe_utils code directly in that case.

It has now been about 6 months since I sent the v1 series of this.
Even this v3 series is now out of date (in the cover letter).

Is rpi still maintained?

Regards,
Simon

Re: [RESEND PATCH v3 0/3] rpi: Convert to standard boot

[Peter Robinson]

On Wed, Aug 16, 2023 at 4:08 PM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Matthias, Peter,
>
> On Thu, 27 Jul 2023 at 15:54, Simon Glass <sjg@chromium.org> wrote:
> >
> > This series moves Raspberry Pi boards over to use standard boot.
> >
> > It also moves rpi over to use a text-based environment. Unfortunately it
> > is not possible to empty the header file due to several CFG options.
> >
> > Fix the repeated "and and" while we are here.
> >
> > Note that this reduces rodata size by about 4.5KB. We could get another
> >
> > for a total image-size saving of about 15KB. This is mostly because
> > HUSH_PARSER is not enabled anymore and the environment shrinks down by
> > about 3.5K. Hush is not actually needed anymore, since standard boot does
> > not use it. Also CMD_SYSBOOT is dropped since standard boot calls the
> > pxe_utils code directly in that case.
>
> It has now been about 6 months since I sent the v1 series of this.
> Even this v3 series is now out of date (in the cover letter).
>
> Is rpi still maintained?

Yes, but we've had conversations about this in the past and snide
comments and regressions don't enamor me to your patches...

That said without seeing this email I actually started tested them yesterday.

U-Boot isn't part of my $dayjob and I've had limited time of late,
that's slowly getting better.

Peter

Re: [RESEND PATCH v3 0/3] rpi: Convert to standard boot

[Simon Glass]

Hi Peter,

On Sat, 19 Aug 2023 at 07:53, Peter Robinson <pbrobinson@gmail.com> wrote:
>
> On Wed, Aug 16, 2023 at 4:08 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Matthias, Peter,
> >
> > On Thu, 27 Jul 2023 at 15:54, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > This series moves Raspberry Pi boards over to use standard boot.
> > >
> > > It also moves rpi over to use a text-based environment. Unfortunately it
> > > is not possible to empty the header file due to several CFG options.
> > >
> > > Fix the repeated "and and" while we are here.
> > >
> > > Note that this reduces rodata size by about 4.5KB. We could get another
> > >
> > > for a total image-size saving of about 15KB. This is mostly because
> > > HUSH_PARSER is not enabled anymore and the environment shrinks down by
> > > about 3.5K. Hush is not actually needed anymore, since standard boot does
> > > not use it. Also CMD_SYSBOOT is dropped since standard boot calls the
> > > pxe_utils code directly in that case.
> >
> > It has now been about 6 months since I sent the v1 series of this.
> > Even this v3 series is now out of date (in the cover letter).
> >
> > Is rpi still maintained?
>
> Yes, but we've had conversations about this in the past and snide
> comments and regressions don't enamor me to your patches...

I'm sorry for the snide comments.

>
> That said without seeing this email I actually started tested them yesterday.
>
> U-Boot isn't part of my $dayjob and I've had limited time of late,
> that's slowly getting better.

OK, good. We have seen quite a few regressions and bugs. I expect that
to continue for at least a few more releases, as more boards pick this
up.

Regards,
Simon

Re: [RESEND PATCH v3 0/3] rpi: Convert to standard boot

[Peter Robinson]

On Mon, Aug 21, 2023 at 8:13 PM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Peter,
>
> On Sat, 19 Aug 2023 at 07:53, Peter Robinson <pbrobinson@gmail.com> wrote:
> >
> > On Wed, Aug 16, 2023 at 4:08 PM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Matthias, Peter,
> > >
> > > On Thu, 27 Jul 2023 at 15:54, Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > This series moves Raspberry Pi boards over to use standard boot.
> > > >
> > > > It also moves rpi over to use a text-based environment. Unfortunately it
> > > > is not possible to empty the header file due to several CFG options.
> > > >
> > > > Fix the repeated "and and" while we are here.
> > > >
> > > > Note that this reduces rodata size by about 4.5KB. We could get another
> > > >
> > > > for a total image-size saving of about 15KB. This is mostly because
> > > > HUSH_PARSER is not enabled anymore and the environment shrinks down by
> > > > about 3.5K. Hush is not actually needed anymore, since standard boot does
> > > > not use it. Also CMD_SYSBOOT is dropped since standard boot calls the
> > > > pxe_utils code directly in that case.
> > >
> > > It has now been about 6 months since I sent the v1 series of this.
> > > Even this v3 series is now out of date (in the cover letter).
> > >
> > > Is rpi still maintained?
> >
> > Yes, but we've had conversations about this in the past and snide
> > comments and regressions don't enamor me to your patches...
>
> I'm sorry for the snide comments.
>
> >
> > That said without seeing this email I actually started tested them yesterday.
> >
> > U-Boot isn't part of my $dayjob and I've had limited time of late,
> > that's slowly getting better.
>
> OK, good. We have seen quite a few regressions and bugs. I expect that
> to continue for at least a few more releases, as more boards pick this
> up.

Yes, tracking regressions, like the numerous ones on rockchip over the
last few releases, and making things continue to work for users have
been taking up the lions share of my free time and are definitely one
of the reasons I've been reticent to take these patches.

I have been following reports of supposed regressions upstream on the
Raspberry Pi boards and most of them are not regressions but rather
users looking to do things that aren't widely tested (NVME) or aren't
enabled by default (USB on CM4) and related pieces. We're certainly
not seeing them on Fedora.

I've pushed these patches to a Fedora build for wider testing and I'm
testing my devices more this week and should have a pull later in the
week.

Peter

Re: [RESEND PATCH v3 0/3] rpi: Convert to standard boot

[Peter Robinson]

Hi Simon,

So with more testing of 2023.10 in Fedora we found a regression where
the display dies when the vc4 module loads in the kernel. With further
debug it was found that it was due to the new U-Boot and with
bisecting it myself I have found this series is the cause of the
regression.

The testing I have done is with recent RPi firmware, U-Boot 2023.10
and kernel 6.5.x, but also seen with 6.4.x, with a minimal text only
image. I can also reproduce it by using the F-38 GA image, no updates
and purely just changing the U-Boot component. I've done my testing on
the RPi4.

Let me know if you need more information, I believe you have a RPi you
can test with.

Regards,
Peter

On Thu, Jul 27, 2023 at 10:54 PM Simon Glass <sjg@chromium.org> wrote:
>
> This series moves Raspberry Pi boards over to use standard boot.
>
> It also moves rpi over to use a text-based environment. Unfortunately it
> is not possible to empty the header file due to several CFG options.
>
> Fix the repeated "and and" while we are here.
>
> Note that this reduces rodata size by about 4.5KB. We could get another
>
> for a total image-size saving of about 15KB. This is mostly because
> HUSH_PARSER is not enabled anymore and the environment shrinks down by
> about 3.5K. Hush is not actually needed anymore, since standard boot does
> not use it. Also CMD_SYSBOOT is dropped since standard boot calls the
> pxe_utils code directly in that case.
>
> Changes in v3:
> - Rebase to -master
>
> Changes in v2:
> - Rebase to -next
> - Add new patch to disable DISTRO_DEFAULTS
>
> Simon Glass (3):
>   arm: rpi: Switch to standard boot
>   rpi: Disable DISTRO_DEFAULTS
>   arm: rpi: Switch to a text environment
>
>  board/raspberrypi/rpi/rpi.env  |  77 +++++++++++++++++++
>  configs/rpi_0_w_defconfig      |   2 +-
>  configs/rpi_2_defconfig        |   2 +-
>  configs/rpi_3_32b_defconfig    |   2 +-
>  configs/rpi_3_b_plus_defconfig |   2 +-
>  configs/rpi_3_defconfig        |   2 +-
>  configs/rpi_4_32b_defconfig    |   2 +-
>  configs/rpi_4_defconfig        |   2 +-
>  configs/rpi_arm64_defconfig    |   2 +-
>  configs/rpi_defconfig          |   2 +-
>  include/configs/rpi.h          | 134 ---------------------------------
>  11 files changed, 86 insertions(+), 143 deletions(-)
>  create mode 100644 board/raspberrypi/rpi/rpi.env
>
> --
> 2.41.0.487.g6d72f3e995-goog
>

Re: [RESEND PATCH v3 0/3] rpi: Convert to standard boot

[Simon Glass]

Hi Peter,

On Fri, 6 Oct 2023 at 03:22, Peter Robinson <pbrobinson@gmail.com> wrote:
>
> Hi Simon,
>
> So with more testing of 2023.10 in Fedora we found a regression where
> the display dies when the vc4 module loads in the kernel. With further
> debug it was found that it was due to the new U-Boot and with
> bisecting it myself I have found this series is the cause of the
> regression.
>
> The testing I have done is with recent RPi firmware, U-Boot 2023.10
> and kernel 6.5.x, but also seen with 6.4.x, with a minimal text only
> image. I can also reproduce it by using the F-38 GA image, no updates
> and purely just changing the U-Boot component. I've done my testing on
> the RPi4.
>
> Let me know if you need more information, I believe you have a RPi you
> can test with.

Thanks for the report. Which rpi should I test with? I take it that
vc4 is a kernel module? Do you have the error message?

Regards,
Simon


>
> Regards,
> Peter
>
> On Thu, Jul 27, 2023 at 10:54 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > This series moves Raspberry Pi boards over to use standard boot.
> >
> > It also moves rpi over to use a text-based environment. Unfortunately it
> > is not possible to empty the header file due to several CFG options.
> >
> > Fix the repeated "and and" while we are here.
> >
> > Note that this reduces rodata size by about 4.5KB. We could get another
> >
> > for a total image-size saving of about 15KB. This is mostly because
> > HUSH_PARSER is not enabled anymore and the environment shrinks down by
> > about 3.5K. Hush is not actually needed anymore, since standard boot does
> > not use it. Also CMD_SYSBOOT is dropped since standard boot calls the
> > pxe_utils code directly in that case.
> >
> > Changes in v3:
> > - Rebase to -master
> >
> > Changes in v2:
> > - Rebase to -next
> > - Add new patch to disable DISTRO_DEFAULTS
> >
> > Simon Glass (3):
> >   arm: rpi: Switch to standard boot
> >   rpi: Disable DISTRO_DEFAULTS
> >   arm: rpi: Switch to a text environment
> >
> >  board/raspberrypi/rpi/rpi.env  |  77 +++++++++++++++++++
> >  configs/rpi_0_w_defconfig      |   2 +-
> >  configs/rpi_2_defconfig        |   2 +-
> >  configs/rpi_3_32b_defconfig    |   2 +-
> >  configs/rpi_3_b_plus_defconfig |   2 +-
> >  configs/rpi_3_defconfig        |   2 +-
> >  configs/rpi_4_32b_defconfig    |   2 +-
> >  configs/rpi_4_defconfig        |   2 +-
> >  configs/rpi_arm64_defconfig    |   2 +-
> >  configs/rpi_defconfig          |   2 +-
> >  include/configs/rpi.h          | 134 ---------------------------------
> >  11 files changed, 86 insertions(+), 143 deletions(-)
> >  create mode 100644 board/raspberrypi/rpi/rpi.env
> >
> > --
> > 2.41.0.487.g6d72f3e995-goog
> >

Re: [RESEND PATCH v3 0/3] rpi: Convert to standard boot

[Peter Robinson]

Hi Simon,

> > So with more testing of 2023.10 in Fedora we found a regression where
> > the display dies when the vc4 module loads in the kernel. With further
> > debug it was found that it was due to the new U-Boot and with
> > bisecting it myself I have found this series is the cause of the
> > regression.
> >
> > The testing I have done is with recent RPi firmware, U-Boot 2023.10
> > and kernel 6.5.x, but also seen with 6.4.x, with a minimal text only
> > image. I can also reproduce it by using the F-38 GA image, no updates
> > and purely just changing the U-Boot component. I've done my testing on
> > the RPi4.
> >
> > Let me know if you need more information, I believe you have a RPi you
> > can test with.
>
> Thanks for the report. Which rpi should I test with? I take it that
> vc4 is a kernel module? Do you have the error message?

Well I've been testing on the RPi4 (as I mentioned above), there's no
direct error message that's directly linked but the screen goes blank
and turns off, even on a text only install, and yes, on the rpi4 the
vc4 kernel module deals with driving the HDMI and other output
interfaces (whereas the v3d is the driver for the render unit), and on
rpi3 and older vc4 also runs the 3D render module too.

> Regards,
> Simon
>
>
> >
> > Regards,
> > Peter
> >
> > On Thu, Jul 27, 2023 at 10:54 PM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > This series moves Raspberry Pi boards over to use standard boot.
> > >
> > > It also moves rpi over to use a text-based environment. Unfortunately it
> > > is not possible to empty the header file due to several CFG options.
> > >
> > > Fix the repeated "and and" while we are here.
> > >
> > > Note that this reduces rodata size by about 4.5KB. We could get another
> > >
> > > for a total image-size saving of about 15KB. This is mostly because
> > > HUSH_PARSER is not enabled anymore and the environment shrinks down by
> > > about 3.5K. Hush is not actually needed anymore, since standard boot does
> > > not use it. Also CMD_SYSBOOT is dropped since standard boot calls the
> > > pxe_utils code directly in that case.
> > >
> > > Changes in v3:
> > > - Rebase to -master
> > >
> > > Changes in v2:
> > > - Rebase to -next
> > > - Add new patch to disable DISTRO_DEFAULTS
> > >
> > > Simon Glass (3):
> > >   arm: rpi: Switch to standard boot
> > >   rpi: Disable DISTRO_DEFAULTS
> > >   arm: rpi: Switch to a text environment
> > >
> > >  board/raspberrypi/rpi/rpi.env  |  77 +++++++++++++++++++
> > >  configs/rpi_0_w_defconfig      |   2 +-
> > >  configs/rpi_2_defconfig        |   2 +-
> > >  configs/rpi_3_32b_defconfig    |   2 +-
> > >  configs/rpi_3_b_plus_defconfig |   2 +-
> > >  configs/rpi_3_defconfig        |   2 +-
> > >  configs/rpi_4_32b_defconfig    |   2 +-
> > >  configs/rpi_4_defconfig        |   2 +-
> > >  configs/rpi_arm64_defconfig    |   2 +-
> > >  configs/rpi_defconfig          |   2 +-
> > >  include/configs/rpi.h          | 134 ---------------------------------
> > >  11 files changed, 86 insertions(+), 143 deletions(-)
> > >  create mode 100644 board/raspberrypi/rpi/rpi.env
> > >
> > > --
> > > 2.41.0.487.g6d72f3e995-goog
> > >

Re: [RESEND PATCH v3 0/3] rpi: Convert to standard boot

[Simon Glass]

Hi Peter,

On Sun, 8 Oct 2023 at 12:02, Peter Robinson <pbrobinson@gmail.com> wrote:
>
> Hi Simon,
>
> > > So with more testing of 2023.10 in Fedora we found a regression where
> > > the display dies when the vc4 module loads in the kernel. With further
> > > debug it was found that it was due to the new U-Boot and with
> > > bisecting it myself I have found this series is the cause of the
> > > regression.
> > >
> > > The testing I have done is with recent RPi firmware, U-Boot 2023.10
> > > and kernel 6.5.x, but also seen with 6.4.x, with a minimal text only
> > > image. I can also reproduce it by using the F-38 GA image, no updates
> > > and purely just changing the U-Boot component. I've done my testing on
> > > the RPi4.
> > >
> > > Let me know if you need more information, I believe you have a RPi you
> > > can test with.
> >
> > Thanks for the report. Which rpi should I test with? I take it that
> > vc4 is a kernel module? Do you have the error message?
>
> Well I've been testing on the RPi4 (as I mentioned above), there's no
> direct error message that's directly linked but the screen goes blank
> and turns off, even on a text only install, and yes, on the rpi4 the
> vc4 kernel module deals with driving the HDMI and other output
> interfaces (whereas the v3d is the driver for the render unit), and on
> rpi3 and older vc4 also runs the 3D render module too.

OK I have an rpi4, but I don't get that far:

>>>
U-Boot 2023.10-00111-g7d1e5aacdb4 (Oct 08 2023 - 14:14:10 -0600)

DRAM:  948 MiB (effective 3.9 GiB)
RPI 4 Model B (0xc03111)
Core:  205 devices, 16 uclasses, devicetree: board
MMC:   mmcnr@7e300000: 1, mmc@7e340000: 0
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
In:    serial,usbkbd
Out:   serial,vidconsole
Err:   serial,vidconsole
Net:   eth0: ethernet@7d580000
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... 3 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0
U-Boot> bootfl scan
Card did not respond to voltage select! : -110
** Booting bootflow 'usb_mass_storage.lun0.bootdev.part_2' with efi
Card did not respond to voltage select! : -110
Failed to load EFI variables
ERROR: invalid device tree
Boot failed (err=-22)
<<<

Do you know what that might be? I ask because it seems that you are
actually able to boot.

I'll keep looking.

Regards,
Simon
[..]

Re: [RESEND PATCH v3 0/3] rpi: Convert to standard boot

[Simon Glass]

Hi Peter,

On Sun, 8 Oct 2023 at 14:20, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Peter,
>
> On Sun, 8 Oct 2023 at 12:02, Peter Robinson <pbrobinson@gmail.com> wrote:
> >
> > Hi Simon,
> >
> > > > So with more testing of 2023.10 in Fedora we found a regression
where
> > > > the display dies when the vc4 module loads in the kernel. With
further
> > > > debug it was found that it was due to the new U-Boot and with
> > > > bisecting it myself I have found this series is the cause of the
> > > > regression.
> > > >
> > > > The testing I have done is with recent RPi firmware, U-Boot 2023.10
> > > > and kernel 6.5.x, but also seen with 6.4.x, with a minimal text only
> > > > image. I can also reproduce it by using the F-38 GA image, no
updates
> > > > and purely just changing the U-Boot component. I've done my testing
on
> > > > the RPi4.
> > > >
> > > > Let me know if you need more information, I believe you have a RPi
you
> > > > can test with.
> > >
> > > Thanks for the report. Which rpi should I test with? I take it that
> > > vc4 is a kernel module? Do you have the error message?
> >
> > Well I've been testing on the RPi4 (as I mentioned above), there's no
> > direct error message that's directly linked but the screen goes blank
> > and turns off, even on a text only install, and yes, on the rpi4 the
> > vc4 kernel module deals with driving the HDMI and other output
> > interfaces (whereas the v3d is the driver for the render unit), and on
> > rpi3 and older vc4 also runs the 3D render module too.
>
> OK I have an rpi4, but I don't get that far:
>
> >>>
> U-Boot 2023.10-00111-g7d1e5aacdb4 (Oct 08 2023 - 14:14:10 -0600)
>
> DRAM:  948 MiB (effective 3.9 GiB)
> RPI 4 Model B (0xc03111)
> Core:  205 devices, 16 uclasses, devicetree: board
> MMC:   mmcnr@7e300000: 1, mmc@7e340000: 0
> Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
> In:    serial,usbkbd
> Out:   serial,vidconsole
> Err:   serial,vidconsole
> Net:   eth0: ethernet@7d580000
> PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
> starting USB...
> Bus xhci_pci: Register 5000420 NbrPorts 5
> Starting the controller
> USB XHCI 1.00
> scanning bus xhci_pci for devices... 3 USB Device(s) found
>        scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0
> U-Boot> bootfl scan
> Card did not respond to voltage select! : -110
> ** Booting bootflow 'usb_mass_storage.lun0.bootdev.part_2' with efi
> Card did not respond to voltage select! : -110
> Failed to load EFI variables
> ERROR: invalid device tree
> Boot failed (err=-22)
> <<<
>
> Do you know what that might be? I ask because it seems that you are
> actually able to boot.
>
> I'll keep looking.

This was apparently a corrupted uSD card as I tried again and it booted.

Regards,
Simon

Re: [RESEND PATCH v3 0/3] rpi: Convert to standard boot

[Simon Glass]

Hi Peter,

On Tue, 10 Oct 2023 at 08:58, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Peter,
>
> On Sun, 8 Oct 2023 at 14:20, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Peter,
> >
> > On Sun, 8 Oct 2023 at 12:02, Peter Robinson <pbrobinson@gmail.com> wrote:
> > >
> > > Hi Simon,
> > >
> > > > > So with more testing of 2023.10 in Fedora we found a regression where
> > > > > the display dies when the vc4 module loads in the kernel. With further
> > > > > debug it was found that it was due to the new U-Boot and with
> > > > > bisecting it myself I have found this series is the cause of the
> > > > > regression.
> > > > >
> > > > > The testing I have done is with recent RPi firmware, U-Boot 2023.10
> > > > > and kernel 6.5.x, but also seen with 6.4.x, with a minimal text only
> > > > > image. I can also reproduce it by using the F-38 GA image, no updates
> > > > > and purely just changing the U-Boot component. I've done my testing on
> > > > > the RPi4.
> > > > >
> > > > > Let me know if you need more information, I believe you have a RPi you
> > > > > can test with.
> > > >
> > > > Thanks for the report. Which rpi should I test with? I take it that
> > > > vc4 is a kernel module? Do you have the error message?
> > >
> > > Well I've been testing on the RPi4 (as I mentioned above), there's no
> > > direct error message that's directly linked but the screen goes blank
> > > and turns off, even on a text only install, and yes, on the rpi4 the
> > > vc4 kernel module deals with driving the HDMI and other output
> > > interfaces (whereas the v3d is the driver for the render unit), and on
> > > rpi3 and older vc4 also runs the 3D render module too.
> >
> > OK I have an rpi4, but I don't get that far:
> >
> > >>>
> > U-Boot 2023.10-00111-g7d1e5aacdb4 (Oct 08 2023 - 14:14:10 -0600)
> >
> > DRAM:  948 MiB (effective 3.9 GiB)
> > RPI 4 Model B (0xc03111)
> > Core:  205 devices, 16 uclasses, devicetree: board
> > MMC:   mmcnr@7e300000: 1, mmc@7e340000: 0
> > Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
> > In:    serial,usbkbd
> > Out:   serial,vidconsole
> > Err:   serial,vidconsole
> > Net:   eth0: ethernet@7d580000
> > PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
> > starting USB...
> > Bus xhci_pci: Register 5000420 NbrPorts 5
> > Starting the controller
> > USB XHCI 1.00
> > scanning bus xhci_pci for devices... 3 USB Device(s) found
> >        scanning usb for storage devices... 1 Storage Device(s) found
> > Hit any key to stop autoboot:  0
> > U-Boot> bootfl scan
> > Card did not respond to voltage select! : -110
> > ** Booting bootflow 'usb_mass_storage.lun0.bootdev.part_2' with efi
> > Card did not respond to voltage select! : -110
> > Failed to load EFI variables
> > ERROR: invalid device tree
> > Boot failed (err=-22)
> > <<<
> >
> > Do you know what that might be? I ask because it seems that you are
> > actually able to boot.
> >
> > I'll keep looking.
>
> This was apparently a corrupted uSD card as I tried again and it booted.

It boots up and I see a strange greenish cloud picture. But the image
disappears every 10 seconds or so. Is that the problem you are seeing?

Then I tried again with bootstd disabled and it booted with the fedora
thing in the top left. No flicker.

Then I tried again with bootstd enabled and it booted with the fedora
thing in the middle No flicker.

So I am not sure what is going on here.

I noticed this in the output when booting from Fedora (without updating U-Boot):

Found EFI removable media binary efi/boot/bootaa64.efi
Found DTB mmc 0:2 /dtb/broadcom/bcm2711-rpi-4-b.dtb

The first line looks OK, but I cannot see the second line anywhere in
the distro scripts. Also I know of no mechanism to use a DT from a
different partition than the EFI app. Could Fedora be doing something
strange here?

One last thing is that Fedora has the DT files in the root dir of
partition 1. They should be in the dtb/broadcom directory, I believe.

Regards,
Simon