[RESEND PATCH v3 0/3] rpi: Convert to standard boot
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
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
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
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
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
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
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
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
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
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
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
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 [..]
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
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
participants (2)
-
Peter Robinson -
Simon Glass