[PATCH 0/7] efi: Various tidy-ups and drop the default
It has come to light that EFI_LOADER adds an extraordinary amount of code to U-Boot. For example, with nokia_rx51 the size delta is about 90KB. About 170 boards explicitly disable the option, but is is clear that many more could, thus saving image size and boot time.
The current situation is affecting U-Boot's image as a svelt bootloader.
EFI_LOADER is required by EBBR, a new boot standard which aims to bring in UEFI protocols to U-Boot. But EBRR is not required for booting. U-Boot already provides support for FIT, the 'bootm' command and a suitable hand-off to Linux. EBRR has made the decision to create a parallel infrastructure, e.g. does not use FIT, nor U-Boot's signing infrastructure.
EBBR should be truly optional, enabled only by boards that use it. Most don't use it but it is enabled anyway. The default boot path should be one that makes use of the existing U-Boot support.
To try to retify this situation, this series adds a new Kconfig option for EBBR so that the naming is more explicit. Then EFI_LOADER is updated to depend on it.
For now, only sandbox enables EBBR. Other boards can be added as needed, presumably by distributions that require it. Another approach would be to add 'CONFIG_EBBR=y' to the .config before building, in the build system. That might be more friendly to U-Boot users.
This series also fixes a minor issue noticed during testing.
Simon Glass (7): configs: Resync with savedefconfig Makefile: Drop include/asm directory as well as symlink disk: Tidy up #ifdefs in part_efi Use LIB_UUID with ACPIGEN and FS_BTRFS Allow efi_loader header to be included always lib: Create a new Kconfig option for charset conversion efi: Make EBBR optional
Makefile | 2 +- common/Kconfig.boot | 15 ++ configs/am335x_igep003x_defconfig | 1 - configs/am335x_pdu001_defconfig | 1 - configs/am64x_evm_a53_defconfig | 31 ++- configs/am64x_evm_r5_defconfig | 6 +- configs/apalis-imx8_defconfig | 1 - configs/apalis-imx8x_defconfig | 1 - configs/aristainetos2c_defconfig | 1 - configs/aristainetos2ccslb_defconfig | 1 - ...edev_cc_v1_0_ultrazedev_som_v1_0_defconfig | 1 - configs/bcm7260_defconfig | 1 - configs/bcm7445_defconfig | 1 - configs/bcm963158_ram_defconfig | 1 - configs/bcm968580xref_ram_defconfig | 1 - configs/bitmain_antminer_s9_defconfig | 1 - configs/bk4r1_defconfig | 1 - configs/brppt1_mmc_defconfig | 1 - configs/brppt1_nand_defconfig | 1 - configs/brppt1_spi_defconfig | 1 - configs/brppt2_defconfig | 1 - configs/brsmarc1_defconfig | 1 - configs/brxre1_defconfig | 1 - configs/chromebook_coral_defconfig | 1 - configs/chromebook_link_defconfig | 1 - configs/colibri-imx8x_defconfig | 1 - configs/colibri_vf_defconfig | 1 - configs/controlcenterdc_defconfig | 1 - configs/crs305-1g-4s-bit_defconfig | 1 - configs/crs305-1g-4s_defconfig | 1 - configs/crs326-24g-2s-bit_defconfig | 1 - configs/crs326-24g-2s_defconfig | 1 - configs/crs328-4c-20s-4s-bit_defconfig | 1 - configs/crs328-4c-20s-4s_defconfig | 1 - configs/deneb_defconfig | 1 - configs/draco_defconfig | 2 +- configs/dragonboard820c_defconfig | 1 - configs/efi-x86_app_defconfig | 1 - configs/etamin_defconfig | 2 +- configs/evb-ast2600_defconfig | 1 - configs/evb-px30_defconfig | 1 - configs/evb-rk3308_defconfig | 1 - configs/firefly-px30_defconfig | 1 - configs/ge_bx50v3_defconfig | 1 - configs/giedi_defconfig | 1 - configs/grpeach_defconfig | 1 - configs/imx8mm-cl-iot-gate_defconfig | 8 - configs/imx8qm_mek_defconfig | 1 - configs/imx8qm_rom7720_a1_4G_defconfig | 1 - configs/imx8qxp_mek_defconfig | 1 - configs/j7200_evm_r5_defconfig | 15 +- configs/j721e_evm_r5_defconfig | 13 +- configs/kontron_sl28_defconfig | 2 - configs/kp_imx53_defconfig | 1 - configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1028aqds_tfa_defconfig | 1 - configs/ls1028aqds_tfa_lpuart_defconfig | 1 - configs/ls1028ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1028ardb_tfa_defconfig | 1 - configs/ls1043aqds_defconfig | 1 - configs/ls1043aqds_lpuart_defconfig | 1 - configs/ls1043aqds_nand_defconfig | 1 - configs/ls1043aqds_nor_ddr3_defconfig | 1 - configs/ls1043aqds_qspi_defconfig | 1 - configs/ls1043aqds_sdcard_ifc_defconfig | 1 - configs/ls1043aqds_sdcard_qspi_defconfig | 1 - configs/ls1043aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1043aqds_tfa_defconfig | 1 - configs/ls1043ardb_SECURE_BOOT_defconfig | 1 - configs/ls1043ardb_defconfig | 1 - configs/ls1043ardb_nand_SECURE_BOOT_defconfig | 1 - configs/ls1043ardb_nand_defconfig | 1 - .../ls1043ardb_sdcard_SECURE_BOOT_defconfig | 1 - configs/ls1043ardb_sdcard_defconfig | 1 - configs/ls1043ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1043ardb_tfa_defconfig | 1 - configs/ls1046aqds_SECURE_BOOT_defconfig | 1 - configs/ls1046aqds_defconfig | 1 - configs/ls1046aqds_lpuart_defconfig | 1 - configs/ls1046aqds_nand_defconfig | 1 - configs/ls1046aqds_qspi_defconfig | 1 - configs/ls1046aqds_sdcard_ifc_defconfig | 1 - configs/ls1046aqds_sdcard_qspi_defconfig | 1 - configs/ls1046aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1046aqds_tfa_defconfig | 1 - configs/ls1046ardb_emmc_defconfig | 1 - configs/ls1046ardb_qspi_SECURE_BOOT_defconfig | 1 - configs/ls1046ardb_qspi_defconfig | 1 - configs/ls1046ardb_qspi_spl_defconfig | 1 - .../ls1046ardb_sdcard_SECURE_BOOT_defconfig | 1 - configs/ls1046ardb_sdcard_defconfig | 1 - configs/ls1046ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1046ardb_tfa_defconfig | 1 - configs/ls1088aqds_qspi_SECURE_BOOT_defconfig | 1 - configs/ls1088aqds_qspi_defconfig | 1 - configs/ls1088aqds_tfa_defconfig | 1 - configs/ls1088ardb_qspi_SECURE_BOOT_defconfig | 1 - configs/ls1088ardb_qspi_defconfig | 1 - configs/ls1088ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1088ardb_tfa_defconfig | 1 - configs/ls2080aqds_SECURE_BOOT_defconfig | 1 - configs/ls2080aqds_defconfig | 1 - configs/ls2080aqds_nand_defconfig | 1 - configs/ls2080aqds_qspi_defconfig | 1 - configs/ls2080aqds_sdcard_defconfig | 1 - configs/ls2080ardb_SECURE_BOOT_defconfig | 1 - configs/ls2080ardb_defconfig | 1 - configs/ls2080ardb_nand_defconfig | 1 - configs/ls2081ardb_defconfig | 1 - configs/ls2088aqds_tfa_defconfig | 1 - configs/ls2088ardb_qspi_SECURE_BOOT_defconfig | 1 - configs/ls2088ardb_qspi_defconfig | 1 - configs/ls2088ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls2088ardb_tfa_defconfig | 1 - configs/lx2160aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/lx2160aqds_tfa_defconfig | 1 - configs/lx2160ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/lx2160ardb_tfa_defconfig | 1 - configs/lx2160ardb_tfa_stmm_defconfig | 4 - configs/lx2162aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/lx2162aqds_tfa_defconfig | 1 - .../lx2162aqds_tfa_verified_boot_defconfig | 1 - configs/mt7623n_bpir2_defconfig | 1 - configs/mt7629_rfb_defconfig | 1 - configs/mt8183_pumpkin_defconfig | 1 - configs/mt8516_pumpkin_defconfig | 1 - configs/mvebu_puzzle-m801-88f8040_defconfig | 1 - configs/mx6memcal_defconfig | 1 - configs/octeontx2_95xx_defconfig | 1 - configs/octeontx2_96xx_defconfig | 1 - configs/octeontx_81xx_defconfig | 1 - configs/octeontx_83xx_defconfig | 1 - configs/omap4_sdp4430_defconfig | 1 - configs/opos6uldev_defconfig | 1 - configs/pcm052_defconfig | 1 - configs/phycore-am335x-r2-regor_defconfig | 1 - configs/phycore-am335x-r2-wega_defconfig | 1 - configs/pxm2_defconfig | 2 +- configs/qemu-riscv32_defconfig | 2 - configs/qemu-riscv32_smode_defconfig | 2 - configs/qemu-riscv64_defconfig | 2 - configs/qemu-riscv64_smode_defconfig | 2 - configs/qemu-x86_64_defconfig | 2 - configs/qemu-x86_defconfig | 2 - configs/qemu_arm64_defconfig | 2 - configs/qemu_arm_defconfig | 2 - configs/rastaban_defconfig | 2 +- configs/roc-cc-rk3308_defconfig | 1 - configs/rock-pi-n10-rk3399pro_defconfig | 1 - configs/rock-pi-n8-rk3288_defconfig | 1 - configs/rpi_0_w_defconfig | 1 - configs/rpi_defconfig | 1 - configs/rut_defconfig | 2 +- configs/sama5d27_wlsom1_ek_mmc_defconfig | 1 - .../sama5d27_wlsom1_ek_qspiflash_defconfig | 1 - configs/sama5d2_icp_mmc_defconfig | 1 - configs/sama7g5ek_mmc1_defconfig | 1 - configs/sama7g5ek_mmc_defconfig | 1 - configs/sipeed_maix_bitm_defconfig | 1 - configs/sipeed_maix_smode_defconfig | 1 - configs/socfpga_de1_soc_defconfig | 1 - configs/somlabs_visionsom_6ull_defconfig | 1 - configs/stemmy_defconfig | 1 - configs/stm32mp15_basic_defconfig | 3 - configs/stm32mp15_trusted_defconfig | 3 - configs/tbs2910_defconfig | 1 - configs/thuban_defconfig | 2 +- configs/vf610twr_defconfig | 1 - configs/vf610twr_nand_defconfig | 1 - configs/xenguest_arm64_defconfig | 1 - configs/xilinx_versal_mini_defconfig | 1 - configs/xilinx_versal_mini_emmc0_defconfig | 1 - configs/xilinx_versal_mini_emmc1_defconfig | 1 - configs/xilinx_versal_virt_defconfig | 2 - configs/xilinx_zynqmp_mini_defconfig | 1 - configs/xilinx_zynqmp_mini_emmc0_defconfig | 1 - configs/xilinx_zynqmp_mini_emmc1_defconfig | 1 - configs/xilinx_zynqmp_mini_nand_defconfig | 1 - .../xilinx_zynqmp_mini_nand_single_defconfig | 1 - configs/xilinx_zynqmp_mini_qspi_defconfig | 1 - configs/xilinx_zynqmp_r5_defconfig | 1 - configs/xilinx_zynqmp_virt_defconfig | 9 - configs/zynq_cse_nand_defconfig | 1 - configs/zynq_cse_nor_defconfig | 1 - configs/zynq_cse_qspi_defconfig | 1 - disk/part_efi.c | 11 +- drivers/core/Kconfig | 1 + fs/btrfs/Kconfig | 1 + include/efi_loader.h | 186 +++++++++--------- lib/Kconfig | 8 + lib/Makefile | 2 +- lib/efi_loader/Kconfig | 5 +- 192 files changed, 160 insertions(+), 353 deletions(-)
Resync all defconfig files using moveconfig.py
Signed-off-by: Simon Glass sjg@chromium.org ---
configs/am64x_evm_a53_defconfig | 31 +++++++++++-------------------- configs/am64x_evm_r5_defconfig | 6 ++---- configs/draco_defconfig | 2 +- configs/etamin_defconfig | 2 +- configs/j7200_evm_r5_defconfig | 15 +++++---------- configs/j721e_evm_r5_defconfig | 13 +++++-------- configs/pxm2_defconfig | 2 +- configs/rastaban_defconfig | 2 +- configs/rut_defconfig | 2 +- configs/thuban_defconfig | 2 +- 10 files changed, 29 insertions(+), 48 deletions(-)
diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig index fbce9e96748..c459afdb680 100644 --- a/configs/am64x_evm_a53_defconfig +++ b/configs/am64x_evm_a53_defconfig @@ -30,8 +30,8 @@ CONFIG_SPL_SYS_MALLOC_SIMPLE=y CONFIG_SPL_STACK_R=y CONFIG_SPL_SEPARATE_BSS=y CONFIG_SPL_DMA=y -CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_ENV_SUPPORT=y +CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_DM_MAILBOX=y CONFIG_SPL_DM_SPI_FLASH=y CONFIG_SPL_POWER_DOMAIN=y @@ -44,8 +44,11 @@ CONFIG_SPL_USB_GADGET=y CONFIG_SPL_DFU=y CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_CMD_ASKENV=y +CONFIG_CMD_DFU=y +CONFIG_CMD_DM=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y CONFIG_CMD_TIME=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y @@ -66,6 +69,11 @@ CONFIG_SPL_OF_TRANSLATE=y CONFIG_CLK=y CONFIG_SPL_CLK=y CONFIG_CLK_TI_SCI=y +CONFIG_DFU_MMC=y +CONFIG_DFU_RAM=y +CONFIG_DFU_SF=y +CONFIG_SYS_DFU_DATA_BUF_SIZE=0x40000 +CONFIG_SYS_DFU_MAX_FILE_SIZE=0x800000 CONFIG_DMA_CHANNELS=y CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y @@ -107,37 +115,20 @@ CONFIG_SYSRESET_TI_SCI=y CONFIG_TIMER=y CONFIG_SPL_TIMER=y CONFIG_OMAP_TIMER=y -CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 -CONFIG_CMD_DFU=y -CONFIG_CMD_DM=y -CONFIG_CMD_USB=y -CONFIG_DFU=y -CONFIG_DFU_OVER_USB=y -# CONFIG_DFU_TFTP is not set -CONFIG_DFU_MMC=y -CONFIG_DFU_RAM=y -CONFIG_DFU_SF=y -# CONFIG_DFU_VIRT is not set -CONFIG_SYS_DFU_DATA_BUF_SIZE=0x40000 -CONFIG_SYS_DFU_MAX_FILE_SIZE=0x800000 CONFIG_USB=y CONFIG_DM_USB=y CONFIG_DM_USB_GADGET=y CONFIG_SPL_DM_USB_GADGET=y -CONFIG_USB_HOST=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_CDNS3=y CONFIG_USB_CDNS3_GADGET=y -CONFIG_SPL_USB_CDNS3_GADGET=y CONFIG_USB_CDNS3_HOST=y +CONFIG_SPL_USB_CDNS3_GADGET=y CONFIG_SPL_USB_CDNS3_HOST=y -CONFIG_USB_CDNS3_TI=y -CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" CONFIG_USB_GADGET_VENDOR_NUM=0x0451 CONFIG_USB_GADGET_PRODUCT_NUM=0x6165 -CONFIG_USB_GADGET_VBUS_DRAW=2 -CONFIG_USB_GADGET_DUALSPEED=y CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_USB_FUNCTION_MASS_STORAGE=y +CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 diff --git a/configs/am64x_evm_r5_defconfig b/configs/am64x_evm_r5_defconfig index 3e9b5650c60..c2dd597e0fb 100644 --- a/configs/am64x_evm_r5_defconfig +++ b/configs/am64x_evm_r5_defconfig @@ -28,11 +28,11 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x80080000 CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y +CONFIG_SPL_BOARD_INIT=y CONFIG_SPL_SYS_MALLOC_SIMPLE=y CONFIG_SPL_STACK_R=y CONFIG_SPL_SEPARATE_BSS=y CONFIG_SPL_EARLY_BSS=y -CONFIG_SPL_BOARD_INIT=y CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_DM_MAILBOX=y @@ -117,16 +117,14 @@ CONFIG_SPL_TIMER=y CONFIG_OMAP_TIMER=y CONFIG_USB=y CONFIG_DM_USB=y -CONFIG_SPL_DM_USB=y CONFIG_DM_USB_GADGET=y CONFIG_SPL_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_CDNS3=y CONFIG_USB_CDNS3_GADGET=y -CONFIG_SPL_USB_CDNS3_GADGET=y CONFIG_USB_CDNS3_HOST=y +CONFIG_SPL_USB_CDNS3_GADGET=y CONFIG_SPL_USB_CDNS3_HOST=y -CONFIG_USB_CDNS3_TI=y CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" diff --git a/configs/draco_defconfig b/configs/draco_defconfig index e3ccdea5f5e..c7412235033 100644 --- a/configs/draco_defconfig +++ b/configs/draco_defconfig @@ -75,8 +75,8 @@ CONFIG_SPL_DM=y CONFIG_BOOTCOUNT_LIMIT=y CONFIG_BOOTCOUNT_ENV=y CONFIG_DFU_NAND=y -# CONFIG_SPL_DM_MMC is not set CONFIG_SYS_DFU_DATA_BUF_SIZE=0x100000 +# CONFIG_SPL_DM_MMC is not set CONFIG_MMC_OMAP_HS=y CONFIG_MTD=y CONFIG_MTD_RAW_NAND=y diff --git a/configs/etamin_defconfig b/configs/etamin_defconfig index 10534d36b11..326a8fec509 100644 --- a/configs/etamin_defconfig +++ b/configs/etamin_defconfig @@ -76,8 +76,8 @@ CONFIG_SPL_DM=y CONFIG_BOOTCOUNT_LIMIT=y CONFIG_BOOTCOUNT_ENV=y CONFIG_DFU_NAND=y -# CONFIG_SPL_DM_MMC is not set CONFIG_SYS_DFU_DATA_BUF_SIZE=0x100000 +# CONFIG_SPL_DM_MMC is not set CONFIG_MMC_OMAP_HS=y CONFIG_MTD=y CONFIG_MTD_RAW_NAND=y diff --git a/configs/j7200_evm_r5_defconfig b/configs/j7200_evm_r5_defconfig index 5c51bd5ae71..abe330be538 100644 --- a/configs/j7200_evm_r5_defconfig +++ b/configs/j7200_evm_r5_defconfig @@ -24,6 +24,7 @@ CONFIG_DEFAULT_DEVICE_TREE="k3-j7200-r5-common-proc-board" # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_SPL_LOAD_FIT=y CONFIG_SPL_LOAD_FIT_ADDRESS=0x80080000 +CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y # CONFIG_USE_SPL_FIT_GENERATOR is not set CONFIG_USE_BOOTCOMMAND=y # CONFIG_DISPLAY_CPUINFO is not set @@ -75,7 +76,9 @@ CONFIG_SPL_SYSCON=y CONFIG_SPL_OF_TRANSLATE=y CONFIG_CLK=y CONFIG_SPL_CLK=y -# CONFIG_CLK_TI_SCI is not set +CONFIG_SPL_CLK_CCF=y +CONFIG_SPL_CLK_K3_PLL=y +CONFIG_SPL_CLK_K3=y CONFIG_DMA_CHANNELS=y CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y @@ -110,7 +113,7 @@ CONFIG_SPL_PINCTRL=y # CONFIG_SPL_PINCTRL_GENERIC is not set CONFIG_PINCTRL_SINGLE=y CONFIG_POWER_DOMAIN=y -# CONFIG_TI_SCI_POWER_DOMAIN is not set +CONFIG_TI_POWER_DOMAIN=y CONFIG_K3_SYSTEM_CONTROLLER=y CONFIG_REMOTEPROC_TI_K3_ARM64=y CONFIG_DM_RESET=y @@ -142,13 +145,5 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0x6164 CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_FS_EXT4=y CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 -CONFIG_SOC_DEVICE=y -CONFIG_SOC_DEVICE_TI_K3=y -CONFIG_TI_POWER_DOMAIN=y -CONFIG_SPL_CLK_CCF=y CONFIG_LIB_RATIONAL=y CONFIG_SPL_LIB_RATIONAL=y -CONFIG_SPL_CLK_K3_PLL=y -CONFIG_SPL_CLK_K3=y -CONFIG_K3_DM_FW=y -CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig index 8a9b20141bc..ff6798283df 100644 --- a/configs/j721e_evm_r5_defconfig +++ b/configs/j721e_evm_r5_defconfig @@ -24,6 +24,7 @@ CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-r5-common-proc-board" # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_SPL_LOAD_FIT=y CONFIG_SPL_LOAD_FIT_ADDRESS=0x80080000 +CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y # CONFIG_USE_SPL_FIT_GENERATOR is not set CONFIG_USE_BOOTCOMMAND=y # CONFIG_DISPLAY_CPUINFO is not set @@ -72,7 +73,9 @@ CONFIG_SPL_REGMAP=y CONFIG_SPL_OF_TRANSLATE=y CONFIG_CLK=y CONFIG_SPL_CLK=y -# CONFIG_CLK_TI_SCI is not set +CONFIG_SPL_CLK_CCF=y +CONFIG_SPL_CLK_K3_PLL=y +CONFIG_SPL_CLK_K3=y CONFIG_DMA_CHANNELS=y CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y @@ -102,7 +105,7 @@ CONFIG_SPL_PINCTRL=y # CONFIG_SPL_PINCTRL_GENERIC is not set CONFIG_PINCTRL_SINGLE=y CONFIG_POWER_DOMAIN=y -# CONFIG_TI_SCI_POWER_DOMAIN is not set +CONFIG_TI_POWER_DOMAIN=y CONFIG_DM_PMIC=y CONFIG_PMIC_TPS65941=y CONFIG_DM_REGULATOR=y @@ -140,11 +143,5 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0x6163 CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_FS_EXT4=y CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 -CONFIG_TI_POWER_DOMAIN=y -CONFIG_SPL_CLK_CCF=y CONFIG_LIB_RATIONAL=y CONFIG_SPL_LIB_RATIONAL=y -CONFIG_SPL_CLK_K3_PLL=y -CONFIG_SPL_CLK_K3=y -CONFIG_K3_DM_FW=y -CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y diff --git a/configs/pxm2_defconfig b/configs/pxm2_defconfig index 8c21890ed72..1d719c31ca4 100644 --- a/configs/pxm2_defconfig +++ b/configs/pxm2_defconfig @@ -74,8 +74,8 @@ CONFIG_SPL_DM=y CONFIG_BOOTCOUNT_LIMIT=y CONFIG_BOOTCOUNT_ENV=y CONFIG_DFU_NAND=y -# CONFIG_SPL_DM_MMC is not set CONFIG_SYS_DFU_DATA_BUF_SIZE=0x100000 +# CONFIG_SPL_DM_MMC is not set CONFIG_MMC_OMAP_HS=y CONFIG_MTD=y CONFIG_MTD_RAW_NAND=y diff --git a/configs/rastaban_defconfig b/configs/rastaban_defconfig index 29ade173f4a..4216fdde9d2 100644 --- a/configs/rastaban_defconfig +++ b/configs/rastaban_defconfig @@ -75,8 +75,8 @@ CONFIG_SPL_DM=y CONFIG_BOOTCOUNT_LIMIT=y CONFIG_BOOTCOUNT_ENV=y CONFIG_DFU_NAND=y -# CONFIG_SPL_DM_MMC is not set CONFIG_SYS_DFU_DATA_BUF_SIZE=0x100000 +# CONFIG_SPL_DM_MMC is not set CONFIG_MMC_OMAP_HS=y CONFIG_MTD=y CONFIG_MTD_RAW_NAND=y diff --git a/configs/rut_defconfig b/configs/rut_defconfig index 0913388339d..0a880d3f6ea 100644 --- a/configs/rut_defconfig +++ b/configs/rut_defconfig @@ -74,8 +74,8 @@ CONFIG_SPL_DM=y CONFIG_BOOTCOUNT_LIMIT=y CONFIG_BOOTCOUNT_ENV=y CONFIG_DFU_NAND=y -# CONFIG_SPL_DM_MMC is not set CONFIG_SYS_DFU_DATA_BUF_SIZE=0x100000 +# CONFIG_SPL_DM_MMC is not set CONFIG_MMC_OMAP_HS=y CONFIG_MTD=y CONFIG_MTD_RAW_NAND=y diff --git a/configs/thuban_defconfig b/configs/thuban_defconfig index 247538a5d9f..880bf413b0c 100644 --- a/configs/thuban_defconfig +++ b/configs/thuban_defconfig @@ -75,8 +75,8 @@ CONFIG_SPL_DM=y CONFIG_BOOTCOUNT_LIMIT=y CONFIG_BOOTCOUNT_ENV=y CONFIG_DFU_NAND=y -# CONFIG_SPL_DM_MMC is not set CONFIG_SYS_DFU_DATA_BUF_SIZE=0x100000 +# CONFIG_SPL_DM_MMC is not set CONFIG_MMC_OMAP_HS=y CONFIG_MTD=y CONFIG_MTD_RAW_NAND=y
At present when using 'make mrproper' on an out-of-tree build, a warning is shown about include/asm being a directory. With old versions of U-Boot it is a file, but more recently it has become a directory.
Remove this directory first, since that covers both cases.
Signed-off-by: Simon Glass sjg@chromium.org ---
Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile index a73481d18c1..0848387029b 100644 --- a/Makefile +++ b/Makefile @@ -2078,7 +2078,7 @@ CLEAN_FILES += include/bmp_logo.h include/bmp_logo_data.h tools/version.h \
# Directories & files removed with 'make mrproper' MRPROPER_DIRS += include/config include/generated spl tpl \ - .tmp_objdiff doc/output + .tmp_objdiff doc/output include/asm
# Remove include/asm symlink created by U-Boot before v2014.01 MRPROPER_FILES += .config .config.old include/autoconf.mk* include/config.h \
This file does not correctly handle the various cases, sometimes producing warnings about partition_basic_data_guid being defined but not used. Fix it.
Signed-off-by: Simon Glass sjg@chromium.org ---
disk/part_efi.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c index 0fb7ff0b6bb..fdca91a6974 100644 --- a/disk/part_efi.c +++ b/disk/part_efi.c @@ -29,12 +29,13 @@
DECLARE_GLOBAL_DATA_PTR;
-/* - * GUID for basic data partions. - */ +#ifdef CONFIG_HAVE_BLOCK_DEVICE + +/* GUID for basic data partitons */ +#if CONFIG_IS_ENABLED(EFI_PARTITION) static const efi_guid_t partition_basic_data_guid = PARTITION_BASIC_DATA_GUID; +#endif
-#ifdef CONFIG_HAVE_BLOCK_DEVICE /** * efi_crc32() - EFI version of crc32 function * @buf: buffer to calculate crc32 of @@ -1126,4 +1127,4 @@ U_BOOT_PART_TYPE(a_efi) = { .print = part_print_ptr(part_print_efi), .test = part_test_efi, }; -#endif +#endif /* CONFIG_HAVE_BLOCK_DEVICE */
On 6/28/21 3:48 AM, Simon Glass wrote:
This file does not correctly handle the various cases, sometimes producing warnings about partition_basic_data_guid being defined but not used. Fix it.
Signed-off-by: Simon Glass sjg@chromium.org
disk/part_efi.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c index 0fb7ff0b6bb..fdca91a6974 100644 --- a/disk/part_efi.c +++ b/disk/part_efi.c @@ -29,12 +29,13 @@
DECLARE_GLOBAL_DATA_PTR;
-/*
- GUID for basic data partions.
- */
+#ifdef CONFIG_HAVE_BLOCK_DEVICE
This #ifdef should be removed. Make CONFIG_HAVE_BLOCK_DEVICE a prerequisite for CONFIG_PARTITIONS instead.
+/* GUID for basic data partitons */ +#if CONFIG_IS_ENABLED(EFI_PARTITION)
part_efi.c is not compiled without CONFIG_$(SPL_)EFI_PARTITION=y. Why put an #if on EFI_PARTITION here?
Best regards
Heinrich
static const efi_guid_t partition_basic_data_guid = PARTITION_BASIC_DATA_GUID; +#endif
-#ifdef CONFIG_HAVE_BLOCK_DEVICE /**
- efi_crc32() - EFI version of crc32 function
- @buf: buffer to calculate crc32 of
@@ -1126,4 +1127,4 @@ U_BOOT_PART_TYPE(a_efi) = { .print = part_print_ptr(part_print_efi), .test = part_test_efi, }; -#endif +#endif /* CONFIG_HAVE_BLOCK_DEVICE */
On Mon, Jun 28, 2021 at 01:20:05PM +0200, Heinrich Schuchardt wrote:
On 6/28/21 3:48 AM, Simon Glass wrote:
This file does not correctly handle the various cases, sometimes producing warnings about partition_basic_data_guid being defined but not used. Fix it.
Signed-off-by: Simon Glass sjg@chromium.org
disk/part_efi.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c index 0fb7ff0b6bb..fdca91a6974 100644 --- a/disk/part_efi.c +++ b/disk/part_efi.c @@ -29,12 +29,13 @@
DECLARE_GLOBAL_DATA_PTR;
-/*
- GUID for basic data partions.
- */
+#ifdef CONFIG_HAVE_BLOCK_DEVICE
This #ifdef should be removed. Make CONFIG_HAVE_BLOCK_DEVICE a prerequisite for CONFIG_PARTITIONS instead.
Ah, this is where things get funny. No, you can't do that as you can use partitions without block devices. I think it was some xilinx setup that has this?
On 28.06.21 15:50, Tom Rini wrote:
On Mon, Jun 28, 2021 at 01:20:05PM +0200, Heinrich Schuchardt wrote:
On 6/28/21 3:48 AM, Simon Glass wrote:
This file does not correctly handle the various cases, sometimes producing warnings about partition_basic_data_guid being defined but not used. Fix it.
Signed-off-by: Simon Glass sjg@chromium.org
disk/part_efi.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c index 0fb7ff0b6bb..fdca91a6974 100644 --- a/disk/part_efi.c +++ b/disk/part_efi.c @@ -29,12 +29,13 @@
DECLARE_GLOBAL_DATA_PTR;
-/*
- GUID for basic data partions.
- */
+#ifdef CONFIG_HAVE_BLOCK_DEVICE
This #ifdef should be removed. Make CONFIG_HAVE_BLOCK_DEVICE a prerequisite for CONFIG_PARTITIONS instead.
Ah, this is where things get funny. No, you can't do that as you can use partitions without block devices. I think it was some xilinx setup that has this?
How can you have a partition without a block device? There must be some backing storage for the partition.
Anyway this #ifdef should be in Kconfig or in Makefile and not here.
Best regards
Heinrich
Since the ACPI-generation code makes use of UUIDs we typically need to enabled UUID support for it to build. Add a new Kconfig condition.
Use it for BTRFS also.
Signed-off-by: Simon Glass sjg@chromium.org ---
drivers/core/Kconfig | 1 + fs/btrfs/Kconfig | 1 + 2 files changed, 2 insertions(+)
diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig index d618e1637b9..9ae188c1dfc 100644 --- a/drivers/core/Kconfig +++ b/drivers/core/Kconfig @@ -325,6 +325,7 @@ config DM_DEV_READ_INLINE config ACPIGEN bool "Support ACPI table generation in driver model" default y if SANDBOX || (GENERATE_ACPI_TABLE && !QEMU) + select LIB_UUID help This option enables generation of ACPI tables using driver-model devices. It adds a new operation struct to each driver, to support diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig index 2a32f42ad13..a0b48c23b31 100644 --- a/fs/btrfs/Kconfig +++ b/fs/btrfs/Kconfig @@ -1,6 +1,7 @@ config FS_BTRFS bool "Enable BTRFS filesystem support" select CRC32C + select LIB_UUID select LZO select ZSTD select RBTREE
It is bad practice to put function declarations behind an #ifdef since it makes it impossible to use IS_ENABLED() in the C code.
This header provides two different versions of various functions. Collect them together in one place for clarity. Allow all the rest of the header to be included, regardless of the setting of EFI_LOADER.
Signed-off-by: Simon Glass sjg@chromium.org ---
include/efi_loader.h | 186 ++++++++++++++++++++++--------------------- 1 file changed, 95 insertions(+), 91 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h index 0a9c82a257e..2d532c5ccbb 100644 --- a/include/efi_loader.h +++ b/include/efi_loader.h @@ -28,12 +28,104 @@ static inline void *guidcpy(void *dst, const void *src) return memcpy(dst, src, sizeof(efi_guid_t)); }
-/* No need for efi loader support in SPL */ -#if CONFIG_IS_ENABLED(EFI_LOADER) - #include <linux/list.h> #include <linux/oid_registry.h>
+#if CONFIG_IS_ENABLED(EFI_LOADER) + +/** + * __efi_runtime_data - declares a non-const variable for EFI runtime section + * + * This macro indicates that a variable is non-const and should go into the + * EFI runtime section, and thus still be available when the OS is running. + * + * Only use on variables not declared const. + * + * Example: + * + * :: + * + * static __efi_runtime_data my_computed_table[256]; + */ +#define __efi_runtime_data __section(".data.efi_runtime") + +/** + * __efi_runtime_rodata - declares a read-only variable for EFI runtime section + * + * This macro indicates that a variable is read-only (const) and should go into + * the EFI runtime section, and thus still be available when the OS is running. + * + * Only use on variables also declared const. + * + * Example: + * + * :: + * + * static const __efi_runtime_rodata my_const_table[] = { 1, 2, 3 }; + */ +#define __efi_runtime_rodata __section(".rodata.efi_runtime") + +/** + * __efi_runtime - declares a function for EFI runtime section + * + * This macro indicates that a function should go into the EFI runtime section, + * and thus still be available when the OS is running. + * + * Example: + * + * :: + * + * static __efi_runtime compute_my_table(void); + */ +#define __efi_runtime __section(".text.efi_runtime") + +/* + * Call this with mmio_ptr as the _pointer_ to a pointer to an MMIO region + * to make it available at runtime + */ +efi_status_t efi_add_runtime_mmio(void *mmio_ptr, u64 len); + +/* + * Special case handler for error/abort that just tries to dtrt to get + * back to u-boot world + */ +void efi_restore_gd(void); +/* Call this to set the current device name */ +void efi_set_bootdev(const char *dev, const char *devnr, const char *path, + void *buffer, size_t buffer_size); +/* Called by networking code to memorize the dhcp ack package */ +void efi_net_set_dhcp_ack(void *pkt, int len); +/* Print information about all loaded images */ +void efi_print_image_infos(void *pc); + +/* Hook at initialization */ +efi_status_t efi_launch_capsules(void); + +#else /* CONFIG_IS_ENABLED(EFI_LOADER) */ + +/* Without CONFIG_EFI_LOADER we don't have a runtime section, stub it out */ +#define __efi_runtime_data +#define __efi_runtime_rodata +#define __efi_runtime +static inline efi_status_t efi_add_runtime_mmio(void *mmio_ptr, u64 len) +{ + return EFI_SUCCESS; +} + +/* No loader configured, stub out EFI_ENTRY */ +static inline void efi_restore_gd(void) { } +static inline void efi_set_bootdev(const char *dev, const char *devnr, + const char *path, void *buffer, + size_t buffer_size) { } +static inline void efi_net_set_dhcp_ack(void *pkt, int len) { } +static inline void efi_print_image_infos(void *pc) { } +static inline efi_status_t efi_launch_capsules(void) +{ + return EFI_SUCCESS; +} + +#endif /* CONFIG_IS_ENABLED(EFI_LOADER) */ + /* Maximum number of configuration tables */ #define EFI_MAX_CONFIGURATION_TABLES 16
@@ -465,8 +557,6 @@ efi_status_t efi_smbios_register(void); struct efi_simple_file_system_protocol * efi_fs_from_path(struct efi_device_path *fp);
-/* Called by networking code to memorize the dhcp ack package */ -void efi_net_set_dhcp_ack(void *pkt, int len); /* Called by efi_set_watchdog_timer to reset the timer */ efi_status_t efi_set_watchdog(unsigned long timeout);
@@ -480,14 +570,8 @@ efi_status_t efi_load_pe(struct efi_loaded_image_obj *handle, struct efi_loaded_image *loaded_image_info); /* Called once to store the pristine gd pointer */ void efi_save_gd(void); -/* Special case handler for error/abort that just tries to dtrt to get - * back to u-boot world */ -void efi_restore_gd(void); /* Call this to relocate the runtime section to an address space */ void efi_runtime_relocate(ulong offset, struct efi_mem_desc *map); -/* Call this to set the current device name */ -void efi_set_bootdev(const char *dev, const char *devnr, const char *path, - void *buffer, size_t buffer_size); /* Add a new object to the object list. */ void efi_add_handle(efi_handle_t obj); /* Create handle */ @@ -619,8 +703,6 @@ efi_status_t efi_setup_loaded_image(struct efi_device_path *device_path, struct efi_device_path *file_path, struct efi_loaded_image_obj **handle_ptr, struct efi_loaded_image **info_ptr); -/* Print information about all loaded images */ -void efi_print_image_infos(void *pc);
#ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER extern void *efi_bounce_buffer; @@ -682,62 +764,12 @@ ssize_t efi_dp_check_length(const struct efi_device_path *dp, (((_dp)->type == DEVICE_PATH_TYPE_##_type) && \ ((_dp)->sub_type == DEVICE_PATH_SUB_TYPE_##_subtype))
-/** - * __efi_runtime_data - declares a non-const variable for EFI runtime section - * - * This macro indicates that a variable is non-const and should go into the - * EFI runtime section, and thus still be available when the OS is running. - * - * Only use on variables not declared const. - * - * Example: - * - * :: - * - * static __efi_runtime_data my_computed_table[256]; - */ -#define __efi_runtime_data __section(".data.efi_runtime") - -/** - * __efi_runtime_rodata - declares a read-only variable for EFI runtime section - * - * This macro indicates that a variable is read-only (const) and should go into - * the EFI runtime section, and thus still be available when the OS is running. - * - * Only use on variables also declared const. - * - * Example: - * - * :: - * - * static const __efi_runtime_rodata my_const_table[] = { 1, 2, 3 }; - */ -#define __efi_runtime_rodata __section(".rodata.efi_runtime") - -/** - * __efi_runtime - declares a function for EFI runtime section - * - * This macro indicates that a function should go into the EFI runtime section, - * and thus still be available when the OS is running. - * - * Example: - * - * :: - * - * static __efi_runtime compute_my_table(void); - */ -#define __efi_runtime __section(".text.efi_runtime") - /* Indicate supported runtime services */ efi_status_t efi_init_runtime_supported(void);
/* Update CRC32 in table header */ void __efi_runtime efi_update_table_header_crc32(struct efi_table_hdr *table);
-/* Call this with mmio_ptr as the _pointer_ to a pointer to an MMIO region - * to make it available at runtime */ -efi_status_t efi_add_runtime_mmio(void *mmio_ptr, u64 len); - /* Boards may provide the functions below to implement RTS functionality */
void __efi_runtime EFIAPI efi_reset_system( @@ -926,34 +958,6 @@ efi_status_t efi_capsule_authenticate(const void *capsule,
#define EFI_CAPSULE_DIR L"\EFI\UpdateCapsule\"
-/* Hook at initialization */ -efi_status_t efi_launch_capsules(void); - -#else /* CONFIG_IS_ENABLED(EFI_LOADER) */ - -/* Without CONFIG_EFI_LOADER we don't have a runtime section, stub it out */ -#define __efi_runtime_data -#define __efi_runtime_rodata -#define __efi_runtime -static inline efi_status_t efi_add_runtime_mmio(void *mmio_ptr, u64 len) -{ - return EFI_SUCCESS; -} - -/* No loader configured, stub out EFI_ENTRY */ -static inline void efi_restore_gd(void) { } -static inline void efi_set_bootdev(const char *dev, const char *devnr, - const char *path, void *buffer, - size_t buffer_size) { } -static inline void efi_net_set_dhcp_ack(void *pkt, int len) { } -static inline void efi_print_image_infos(void *pc) { } -static inline efi_status_t efi_launch_capsules(void) -{ - return EFI_SUCCESS; -} - -#endif /* CONFIG_IS_ENABLED(EFI_LOADER) */ - /** * Install the ESRT system table. *
On 6/28/21 3:48 AM, Simon Glass wrote:
It is bad practice to put function declarations behind an #ifdef since it makes it impossible to use IS_ENABLED() in the C code.
This header provides two different versions of various functions. Collect them together in one place for clarity. Allow all the rest of the header to be included, regardless of the setting of EFI_LOADER.
Signed-off-by: Simon Glass sjg@chromium.org
include/efi_loader.h | 186 ++++++++++++++++++++++--------------------- 1 file changed, 95 insertions(+), 91 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h index 0a9c82a257e..2d532c5ccbb 100644 --- a/include/efi_loader.h +++ b/include/efi_loader.h @@ -28,12 +28,104 @@ static inline void *guidcpy(void *dst, const void *src) return memcpy(dst src, sizeof(efi_guid_t)); }
-/* No need for efi loader support in SPL */ -#if CONFIG_IS_ENABLED(EFI_LOADER)
- #include <linux/list.h> #include <linux/oid_registry.h>
Why are these includes not listed with the other includes? Please, move them up.
Why should we have both "#include <blk.h>" and "struct blk_desc;"? I assume "struct blk_desc;" can be eliminated. Cf. e6f6f9e64882 ("common: Drop part.h from common header")
Hiding "efi_status_t efi_add_runtime_mmio()" through "efi_status_t efi_launch_capsules()" behind "#if CONFIG_IS_ENABLED(EFI_LOADER)" contradicts the commit message.
+CC Alex, reviewer EFI PAYLOAD
Best regards
Heinrich
+#if CONFIG_IS_ENABLED(EFI_LOADER)
+/**
- __efi_runtime_data - declares a non-const variable for EFI runtime section
- This macro indicates that a variable is non-const and should go into the
- EFI runtime section, and thus still be available when the OS is running.
- Only use on variables not declared const.
- Example:
- ::
- static __efi_runtime_data my_computed_table[256];
- */
+#define __efi_runtime_data __section(".data.efi_runtime")
+/**
- __efi_runtime_rodata - declares a read-only variable for EFI runtime section
- This macro indicates that a variable is read-only (const) and should go into
- the EFI runtime section, and thus still be available when the OS is running.
- Only use on variables also declared const.
- Example:
- ::
- static const __efi_runtime_rodata my_const_table[] = { 1, 2, 3 };
- */
+#define __efi_runtime_rodata __section(".rodata.efi_runtime")
+/**
- __efi_runtime - declares a function for EFI runtime section
- This macro indicates that a function should go into the EFI runtime section,
- and thus still be available when the OS is running.
- Example:
- ::
- static __efi_runtime compute_my_table(void);
- */
+#define __efi_runtime __section(".text.efi_runtime")
+/*
- Call this with mmio_ptr as the _pointer_ to a pointer to an MMIO region
- to make it available at runtime
- */
+efi_status_t efi_add_runtime_mmio(void *mmio_ptr, u64 len);
+/*
- Special case handler for error/abort that just tries to dtrt to get
- back to u-boot world
- */
+void efi_restore_gd(void); +/* Call this to set the current device name */ +void efi_set_bootdev(const char *dev, const char *devnr, const char *path,
void *buffer, size_t buffer_size);+/* Called by networking code to memorize the dhcp ack package */ +void efi_net_set_dhcp_ack(void *pkt, int len); +/* Print information about all loaded images */ +void efi_print_image_infos(void *pc);
+/* Hook at initialization */ +efi_status_t efi_launch_capsules(void);
+#else /* CONFIG_IS_ENABLED(EFI_LOADER) */
+/* Without CONFIG_EFI_LOADER we don't have a runtime section, stub it out */ +#define __efi_runtime_data +#define __efi_runtime_rodata +#define __efi_runtime +static inline efi_status_t efi_add_runtime_mmio(void *mmio_ptr, u64 len) +{
- return EFI_SUCCESS;
+}
+/* No loader configured, stub out EFI_ENTRY */ +static inline void efi_restore_gd(void) { } +static inline void efi_set_bootdev(const char *dev, const char *devnr,
const char *path, void *buffer,size_t buffer_size) { }+static inline void efi_net_set_dhcp_ack(void *pkt, int len) { } +static inline void efi_print_image_infos(void *pc) { } +static inline efi_status_t efi_launch_capsules(void) +{
- return EFI_SUCCESS;
+}
+#endif /* CONFIG_IS_ENABLED(EFI_LOADER) */
- /* Maximum number of configuration tables */ #define EFI_MAX_CONFIGURATION_TABLES 16
@@ -465,8 +557,6 @@ efi_status_t efi_smbios_register(void); struct efi_simple_file_system_protocol * efi_fs_from_path(struct efi_device_path *fp);
-/* Called by networking code to memorize the dhcp ack package */ -void efi_net_set_dhcp_ack(void *pkt, int len); /* Called by efi_set_watchdog_timer to reset the timer */ efi_status_t efi_set_watchdog(unsigned long timeout);
@@ -480,14 +570,8 @@ efi_status_t efi_load_pe(struct efi_loaded_image_obj *handle, struct efi_loaded_image *loaded_image_info); /* Called once to store the pristine gd pointer */ void efi_save_gd(void); -/* Special case handler for error/abort that just tries to dtrt to get
- back to u-boot world */
-void efi_restore_gd(void); /* Call this to relocate the runtime section to an address space */ void efi_runtime_relocate(ulong offset, struct efi_mem_desc *map); -/* Call this to set the current device name */ -void efi_set_bootdev(const char *dev, const char *devnr, const char *path,
void *buffer, size_t buffer_size);@@ -619,8 +703,6 @@ efi_status_t efi_setup_loaded_image(struct efi_device_path *device_path, struct efi_device_path *file_path, struct efi_loaded_image_obj **handle_ptr, struct efi_loaded_image **info_ptr); -/* Print information about all loaded images */ -void efi_print_image_infos(void *pc);
#ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER extern void *efi_bounce_buffer; @@ -682,62 +764,12 @@ ssize_t efi_dp_check_length(const struct efi_device_path *dp, (((_dp)->type == DEVICE_PATH_TYPE_##_type) && \ ((_dp)->sub_type == DEVICE_PATH_SUB_TYPE_##_subtype))
-/**
- __efi_runtime_data - declares a non-const variable for EFI runtime section
- This macro indicates that a variable is non-const and should go into the
- EFI runtime section, and thus still be available when the OS is running.
- Only use on variables not declared const.
- Example:
- ::
- static __efi_runtime_data my_computed_table[256];
- */
-#define __efi_runtime_data __section(".data.efi_runtime")
-/**
- __efi_runtime_rodata - declares a read-only variable for EFI runtime section
- This macro indicates that a variable is read-only (const) and should go into
- the EFI runtime section, and thus still be available when the OS is running.
- Only use on variables also declared const.
- Example:
- ::
- static const __efi_runtime_rodata my_const_table[] = { 1, 2, 3 };
- */
-#define __efi_runtime_rodata __section(".rodata.efi_runtime")
-/**
- __efi_runtime - declares a function for EFI runtime section
- This macro indicates that a function should go into the EFI runtime section,
- and thus still be available when the OS is running.
- Example:
- ::
- static __efi_runtime compute_my_table(void);
- */
-#define __efi_runtime __section(".text.efi_runtime")
/* Indicate supported runtime services */ efi_status_t efi_init_runtime_supported(void);
/* Update CRC32 in table header */ void __efi_runtime efi_update_table_header_crc32(struct efi_table_hdr *table);
-/* Call this with mmio_ptr as the _pointer_ to a pointer to an MMIO region
- to make it available at runtime */
-efi_status_t efi_add_runtime_mmio(void *mmio_ptr, u64 len);
/* Boards may provide the functions below to implement RTS functionality */
void __efi_runtime EFIAPI efi_reset_system(
@@ -926,34 +958,6 @@ efi_status_t efi_capsule_authenticate(const void *capsule,
#define EFI_CAPSULE_DIR L"\EFI\UpdateCapsule\"
-/* Hook at initialization */ -efi_status_t efi_launch_capsules(void);
-#else /* CONFIG_IS_ENABLED(EFI_LOADER) */
-/* Without CONFIG_EFI_LOADER we don't have a runtime section, stub it out */ -#define __efi_runtime_data -#define __efi_runtime_rodata -#define __efi_runtime -static inline efi_status_t efi_add_runtime_mmio(void *mmio_ptr, u64 len) -{
- return EFI_SUCCESS;
-}
-/* No loader configured, stub out EFI_ENTRY */ -static inline void efi_restore_gd(void) { } -static inline void efi_set_bootdev(const char *dev, const char *devnr,
const char *path, void *buffer,size_t buffer_size) { }-static inline void efi_net_set_dhcp_ack(void *pkt, int len) { } -static inline void efi_print_image_infos(void *pc) { } -static inline efi_status_t efi_launch_capsules(void) -{
- return EFI_SUCCESS;
-}
-#endif /* CONFIG_IS_ENABLED(EFI_LOADER) */
- /**
- Install the ESRT system table.
Rather than looking at two KConfig options in the Makefile, create a new Kconfig option for compiling lib/charset.c
Enable it for UFS also, which needs this support.
Signed-off-by: Simon Glass sjg@chromium.org ---
lib/Kconfig | 8 ++++++++ lib/Makefile | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/lib/Kconfig b/lib/Kconfig index ad0cd52edd8..e1415799965 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -40,6 +40,14 @@ config CC_OPTIMIZE_LIBS_FOR_SPEED
If unsure, say N.
+config CHARSET + bool + default y if UT_UNICODE || EFI_LOADER || UFS + help + Enables support for various conversions between different + character sets, such as between unicode representations and + different 'code pages'. + config DYNAMIC_CRC_TABLE bool "Enable Dynamic tables for CRC" help diff --git a/lib/Makefile b/lib/Makefile index 881034f4ae3..2d2b273ccef 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -25,7 +25,7 @@ obj-$(CONFIG_AES) += aes/ obj-$(CONFIG_$(SPL_TPL_)BINMAN_FDT) += binman.o
ifndef API_BUILD -ifneq ($(CONFIG_UT_UNICODE)$(CONFIG_EFI_LOADER),) +ifneq ($(CONFIG_CHARSET),) obj-y += charset.o endif endif
On 6/28/21 3:48 AM, Simon Glass wrote:
Rather than looking at two KConfig options in the Makefile, create a new Kconfig option for compiling lib/charset.c
Enable it for UFS also, which needs this support.
+CC Faiz, maintainer UFS
Function utf16_to_utf8() is used in ufshcd_read_string_desc(). It assumes that UTF-16 is using CPU endianness. What does UFS require on big-endian systems?
Signed-off-by: Simon Glass sjg@chromium.org
Reviewed-by: Heinrich Schuchardt xypron.glpk@gmx.de
lib/Kconfig | 8 ++++++++ lib/Makefile | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/lib/Kconfig b/lib/Kconfig index ad0cd52edd8..e1415799965 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -40,6 +40,14 @@ config CC_OPTIMIZE_LIBS_FOR_SPEED
If unsure, say N.+config CHARSET
- bool
- default y if UT_UNICODE || EFI_LOADER || UFS
- help
Enables support for various conversions between differentcharacter sets, such as between unicode representations anddifferent 'code pages'.- config DYNAMIC_CRC_TABLE bool "Enable Dynamic tables for CRC" help
diff --git a/lib/Makefile b/lib/Makefile index 881034f4ae3..2d2b273ccef 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -25,7 +25,7 @@ obj-$(CONFIG_AES) += aes/ obj-$(CONFIG_$(SPL_TPL_)BINMAN_FDT) += binman.o
ifndef API_BUILD -ifneq ($(CONFIG_UT_UNICODE)$(CONFIG_EFI_LOADER),) +ifneq ($(CONFIG_CHARSET),) obj-y += charset.o endif endif
Add a new Kconfig option for EBBR so that the naming is more explicit. Make EFI_LOADER depend on it.
Avoid enabling the options (EBBR / EFI_LOADER) by default, to save space.
Also add dependencies on driver model and OF_CONTROL, since boards which have not migrated to these should not be using new features like EBBR. The unwillingness to use driver model has resulted in the duplication of driver model code in EFI, which is part of the reason for this bloat.
Resync the CONFIG options also.
Signed-off-by: Simon Glass sjg@chromium.org ---
common/Kconfig.boot | 15 +++++++++++++++ configs/am335x_igep003x_defconfig | 1 - configs/am335x_pdu001_defconfig | 1 - configs/apalis-imx8_defconfig | 1 - configs/apalis-imx8x_defconfig | 1 - configs/aristainetos2c_defconfig | 1 - configs/aristainetos2ccslb_defconfig | 1 - ...trazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig | 1 - configs/bcm7260_defconfig | 1 - configs/bcm7445_defconfig | 1 - configs/bcm963158_ram_defconfig | 1 - configs/bcm968580xref_ram_defconfig | 1 - configs/bitmain_antminer_s9_defconfig | 1 - configs/bk4r1_defconfig | 1 - configs/brppt1_mmc_defconfig | 1 - configs/brppt1_nand_defconfig | 1 - configs/brppt1_spi_defconfig | 1 - configs/brppt2_defconfig | 1 - configs/brsmarc1_defconfig | 1 - configs/brxre1_defconfig | 1 - configs/chromebook_coral_defconfig | 1 - configs/chromebook_link_defconfig | 1 - configs/colibri-imx8x_defconfig | 1 - configs/colibri_vf_defconfig | 1 - configs/controlcenterdc_defconfig | 1 - configs/crs305-1g-4s-bit_defconfig | 1 - configs/crs305-1g-4s_defconfig | 1 - configs/crs326-24g-2s-bit_defconfig | 1 - configs/crs326-24g-2s_defconfig | 1 - configs/crs328-4c-20s-4s-bit_defconfig | 1 - configs/crs328-4c-20s-4s_defconfig | 1 - configs/deneb_defconfig | 1 - configs/dragonboard820c_defconfig | 1 - configs/efi-x86_app_defconfig | 1 - configs/evb-ast2600_defconfig | 1 - configs/evb-px30_defconfig | 1 - configs/evb-rk3308_defconfig | 1 - configs/firefly-px30_defconfig | 1 - configs/ge_bx50v3_defconfig | 1 - configs/giedi_defconfig | 1 - configs/grpeach_defconfig | 1 - configs/imx8mm-cl-iot-gate_defconfig | 8 -------- configs/imx8qm_mek_defconfig | 1 - configs/imx8qm_rom7720_a1_4G_defconfig | 1 - configs/imx8qxp_mek_defconfig | 1 - configs/kontron_sl28_defconfig | 2 -- configs/kp_imx53_defconfig | 1 - configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1028aqds_tfa_defconfig | 1 - configs/ls1028aqds_tfa_lpuart_defconfig | 1 - configs/ls1028ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1028ardb_tfa_defconfig | 1 - configs/ls1043aqds_defconfig | 1 - configs/ls1043aqds_lpuart_defconfig | 1 - configs/ls1043aqds_nand_defconfig | 1 - configs/ls1043aqds_nor_ddr3_defconfig | 1 - configs/ls1043aqds_qspi_defconfig | 1 - configs/ls1043aqds_sdcard_ifc_defconfig | 1 - configs/ls1043aqds_sdcard_qspi_defconfig | 1 - configs/ls1043aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1043aqds_tfa_defconfig | 1 - configs/ls1043ardb_SECURE_BOOT_defconfig | 1 - configs/ls1043ardb_defconfig | 1 - configs/ls1043ardb_nand_SECURE_BOOT_defconfig | 1 - configs/ls1043ardb_nand_defconfig | 1 - configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig | 1 - configs/ls1043ardb_sdcard_defconfig | 1 - configs/ls1043ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1043ardb_tfa_defconfig | 1 - configs/ls1046aqds_SECURE_BOOT_defconfig | 1 - configs/ls1046aqds_defconfig | 1 - configs/ls1046aqds_lpuart_defconfig | 1 - configs/ls1046aqds_nand_defconfig | 1 - configs/ls1046aqds_qspi_defconfig | 1 - configs/ls1046aqds_sdcard_ifc_defconfig | 1 - configs/ls1046aqds_sdcard_qspi_defconfig | 1 - configs/ls1046aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1046aqds_tfa_defconfig | 1 - configs/ls1046ardb_emmc_defconfig | 1 - configs/ls1046ardb_qspi_SECURE_BOOT_defconfig | 1 - configs/ls1046ardb_qspi_defconfig | 1 - configs/ls1046ardb_qspi_spl_defconfig | 1 - configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig | 1 - configs/ls1046ardb_sdcard_defconfig | 1 - configs/ls1046ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1046ardb_tfa_defconfig | 1 - configs/ls1088aqds_qspi_SECURE_BOOT_defconfig | 1 - configs/ls1088aqds_qspi_defconfig | 1 - configs/ls1088aqds_tfa_defconfig | 1 - configs/ls1088ardb_qspi_SECURE_BOOT_defconfig | 1 - configs/ls1088ardb_qspi_defconfig | 1 - configs/ls1088ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1088ardb_tfa_defconfig | 1 - configs/ls2080aqds_SECURE_BOOT_defconfig | 1 - configs/ls2080aqds_defconfig | 1 - configs/ls2080aqds_nand_defconfig | 1 - configs/ls2080aqds_qspi_defconfig | 1 - configs/ls2080aqds_sdcard_defconfig | 1 - configs/ls2080ardb_SECURE_BOOT_defconfig | 1 - configs/ls2080ardb_defconfig | 1 - configs/ls2080ardb_nand_defconfig | 1 - configs/ls2081ardb_defconfig | 1 - configs/ls2088aqds_tfa_defconfig | 1 - configs/ls2088ardb_qspi_SECURE_BOOT_defconfig | 1 - configs/ls2088ardb_qspi_defconfig | 1 - configs/ls2088ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls2088ardb_tfa_defconfig | 1 - configs/lx2160aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/lx2160aqds_tfa_defconfig | 1 - configs/lx2160ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/lx2160ardb_tfa_defconfig | 1 - configs/lx2160ardb_tfa_stmm_defconfig | 4 ---- configs/lx2162aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/lx2162aqds_tfa_defconfig | 1 - configs/lx2162aqds_tfa_verified_boot_defconfig | 1 - configs/mt7623n_bpir2_defconfig | 1 - configs/mt7629_rfb_defconfig | 1 - configs/mt8183_pumpkin_defconfig | 1 - configs/mt8516_pumpkin_defconfig | 1 - configs/mvebu_puzzle-m801-88f8040_defconfig | 1 - configs/mx6memcal_defconfig | 1 - configs/octeontx2_95xx_defconfig | 1 - configs/octeontx2_96xx_defconfig | 1 - configs/octeontx_81xx_defconfig | 1 - configs/octeontx_83xx_defconfig | 1 - configs/omap4_sdp4430_defconfig | 1 - configs/opos6uldev_defconfig | 1 - configs/pcm052_defconfig | 1 - configs/phycore-am335x-r2-regor_defconfig | 1 - configs/phycore-am335x-r2-wega_defconfig | 1 - configs/qemu-riscv32_defconfig | 2 -- configs/qemu-riscv32_smode_defconfig | 2 -- configs/qemu-riscv64_defconfig | 2 -- configs/qemu-riscv64_smode_defconfig | 2 -- configs/qemu-x86_64_defconfig | 2 -- configs/qemu-x86_defconfig | 2 -- configs/qemu_arm64_defconfig | 2 -- configs/qemu_arm_defconfig | 2 -- configs/roc-cc-rk3308_defconfig | 1 - configs/rock-pi-n10-rk3399pro_defconfig | 1 - configs/rock-pi-n8-rk3288_defconfig | 1 - configs/rpi_0_w_defconfig | 1 - configs/rpi_defconfig | 1 - configs/sama5d27_wlsom1_ek_mmc_defconfig | 1 - configs/sama5d27_wlsom1_ek_qspiflash_defconfig | 1 - configs/sama5d2_icp_mmc_defconfig | 1 - configs/sama7g5ek_mmc1_defconfig | 1 - configs/sama7g5ek_mmc_defconfig | 1 - configs/sipeed_maix_bitm_defconfig | 1 - configs/sipeed_maix_smode_defconfig | 1 - configs/socfpga_de1_soc_defconfig | 1 - configs/somlabs_visionsom_6ull_defconfig | 1 - configs/stemmy_defconfig | 1 - configs/stm32mp15_basic_defconfig | 3 --- configs/stm32mp15_trusted_defconfig | 3 --- configs/tbs2910_defconfig | 1 - configs/vf610twr_defconfig | 1 - configs/vf610twr_nand_defconfig | 1 - configs/xenguest_arm64_defconfig | 1 - configs/xilinx_versal_mini_defconfig | 1 - configs/xilinx_versal_mini_emmc0_defconfig | 1 - configs/xilinx_versal_mini_emmc1_defconfig | 1 - configs/xilinx_versal_virt_defconfig | 2 -- configs/xilinx_zynqmp_mini_defconfig | 1 - configs/xilinx_zynqmp_mini_emmc0_defconfig | 1 - configs/xilinx_zynqmp_mini_emmc1_defconfig | 1 - configs/xilinx_zynqmp_mini_nand_defconfig | 1 - configs/xilinx_zynqmp_mini_nand_single_defconfig | 1 - configs/xilinx_zynqmp_mini_qspi_defconfig | 1 - configs/xilinx_zynqmp_r5_defconfig | 1 - configs/xilinx_zynqmp_virt_defconfig | 9 --------- configs/zynq_cse_nand_defconfig | 1 - configs/zynq_cse_nor_defconfig | 1 - configs/zynq_cse_qspi_defconfig | 1 - lib/efi_loader/Kconfig | 5 +++-- 175 files changed, 18 insertions(+), 207 deletions(-)
diff --git a/common/Kconfig.boot b/common/Kconfig.boot index 89a3161f1fa..8212c1a3d85 100644 --- a/common/Kconfig.boot +++ b/common/Kconfig.boot @@ -300,6 +300,21 @@ config LEGACY_IMAGE_FORMAT loaded. If a board needs the legacy image format support in this case, enable it here.
+config EBBR + bool "Enable support for Embeeded Boot Base Requirements (EBBR)" + select EFI_LOADER + help + Enable this to support ARM's EBBR boot method. This bases everything + on UEFI protocols. + + This Embedded Base Boot Requirements (EBBR) specification defines an + interface between platform firmware and an operating system that is + suitable for embedded platforms. EBBR-compliant platforms present a + consistent interface that will boot an EBBR-compliant operating + system without any custom tailoring required. For example, an Arm + A-class embedded platform will benefit from a standard interface that + supports features such as secure boot and firmware update. + config SUPPORT_RAW_INITRD bool "Enable raw initrd images" help diff --git a/configs/am335x_igep003x_defconfig b/configs/am335x_igep003x_defconfig index 6ebf8f859dd..8c96bee8787 100644 --- a/configs/am335x_igep003x_defconfig +++ b/configs/am335x_igep003x_defconfig @@ -79,4 +79,3 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_OMAP3_SPI=y CONFIG_FDT_FIXUP_PARTITIONS=y -# CONFIG_GENERATE_SMBIOS_TABLE is not set diff --git a/configs/am335x_pdu001_defconfig b/configs/am335x_pdu001_defconfig index 81f211b5d5e..2c15ccc1783 100644 --- a/configs/am335x_pdu001_defconfig +++ b/configs/am335x_pdu001_defconfig @@ -53,4 +53,3 @@ CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_TPS65910=y CONFIG_CONS_INDEX=4 # CONFIG_SPL_USE_TINY_PRINTF is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/apalis-imx8_defconfig b/configs/apalis-imx8_defconfig index b03a0e2e2dc..0af26f905cb 100644 --- a/configs/apalis-imx8_defconfig +++ b/configs/apalis-imx8_defconfig @@ -65,4 +65,3 @@ CONFIG_DM_SERIAL=y CONFIG_FSL_LPUART=y CONFIG_DM_THERMAL=y CONFIG_IMX_SCU_THERMAL=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/apalis-imx8x_defconfig b/configs/apalis-imx8x_defconfig index 0d225db4365..d621fb86350 100644 --- a/configs/apalis-imx8x_defconfig +++ b/configs/apalis-imx8x_defconfig @@ -74,4 +74,3 @@ CONFIG_DM_SERIAL=y CONFIG_FSL_LPUART=y CONFIG_DM_THERMAL=y CONFIG_IMX_SCU_THERMAL=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/aristainetos2c_defconfig b/configs/aristainetos2c_defconfig index 4d9cb5b4f11..eb26c336fa2 100644 --- a/configs/aristainetos2c_defconfig +++ b/configs/aristainetos2c_defconfig @@ -122,4 +122,3 @@ CONFIG_SPLASH_SCREEN_ALIGN=y CONFIG_VIDEO_BMP_RLE8=y CONFIG_BMP_16BPP=y CONFIG_IMX_WATCHDOG=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/aristainetos2ccslb_defconfig b/configs/aristainetos2ccslb_defconfig index dd63e8f29d1..01bba9c17cb 100644 --- a/configs/aristainetos2ccslb_defconfig +++ b/configs/aristainetos2ccslb_defconfig @@ -122,4 +122,3 @@ CONFIG_SPLASH_SCREEN_ALIGN=y CONFIG_VIDEO_BMP_RLE8=y CONFIG_BMP_16BPP=y CONFIG_IMX_WATCHDOG=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig b/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig index 6c0d22c2ab7..40214df6f27 100644 --- a/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig +++ b/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig @@ -63,4 +63,3 @@ CONFIG_SPI=y CONFIG_ZYNQMP_GQSPI=y CONFIG_PANIC_HANG=y CONFIG_OF_LIBFDT_OVERLAY=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/bcm7260_defconfig b/configs/bcm7260_defconfig index a42a6acb06d..75373dacb8d 100644 --- a/configs/bcm7260_defconfig +++ b/configs/bcm7260_defconfig @@ -31,4 +31,3 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_BCMSTB=y CONFIG_MTD=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/bcm7445_defconfig b/configs/bcm7445_defconfig index 96e8da0748a..6477b93f6f7 100644 --- a/configs/bcm7445_defconfig +++ b/configs/bcm7445_defconfig @@ -36,4 +36,3 @@ CONFIG_DM_SPI_FLASH=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_BCMSTB_SPI=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/bcm963158_ram_defconfig b/configs/bcm963158_ram_defconfig index 0be1e0981ab..95395a1768f 100644 --- a/configs/bcm963158_ram_defconfig +++ b/configs/bcm963158_ram_defconfig @@ -54,4 +54,3 @@ CONFIG_BCM63XX_HSSPI=y CONFIG_SYSRESET=y CONFIG_SYSRESET_WATCHDOG=y CONFIG_WDT_BCM6345=y -# CONFIG_GENERATE_SMBIOS_TABLE is not set diff --git a/configs/bcm968580xref_ram_defconfig b/configs/bcm968580xref_ram_defconfig index 8f74a4516f8..5aef078822c 100644 --- a/configs/bcm968580xref_ram_defconfig +++ b/configs/bcm968580xref_ram_defconfig @@ -51,4 +51,3 @@ CONFIG_BCM63XX_HSSPI=y CONFIG_SYSRESET=y CONFIG_SYSRESET_WATCHDOG=y CONFIG_WDT_BCM6345=y -# CONFIG_GENERATE_SMBIOS_TABLE is not set diff --git a/configs/bitmain_antminer_s9_defconfig b/configs/bitmain_antminer_s9_defconfig index 76cccfa586c..166f3319a5e 100644 --- a/configs/bitmain_antminer_s9_defconfig +++ b/configs/bitmain_antminer_s9_defconfig @@ -74,4 +74,3 @@ CONFIG_ZYNQ_SERIAL=y # CONFIG_WATCHDOG is not set CONFIG_WDT=y CONFIG_WDT_CDNS=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/bk4r1_defconfig b/configs/bk4r1_defconfig index e6583bcfc0a..56f5dbedaec 100644 --- a/configs/bk4r1_defconfig +++ b/configs/bk4r1_defconfig @@ -86,4 +86,3 @@ CONFIG_FSL_LPUART=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_FSL_QSPI=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/brppt1_mmc_defconfig b/configs/brppt1_mmc_defconfig index 2c73ece62a0..9df1f7a59ac 100644 --- a/configs/brppt1_mmc_defconfig +++ b/configs/brppt1_mmc_defconfig @@ -98,4 +98,3 @@ CONFIG_USB_GADGET=y CONFIG_FAT_WRITE=y CONFIG_LZO=y # CONFIG_OF_LIBFDT_OVERLAY is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/brppt1_nand_defconfig b/configs/brppt1_nand_defconfig index f4827e427f6..82f1ffff31d 100644 --- a/configs/brppt1_nand_defconfig +++ b/configs/brppt1_nand_defconfig @@ -104,4 +104,3 @@ CONFIG_USB_GADGET=y CONFIG_FAT_WRITE=y CONFIG_LZO=y # CONFIG_OF_LIBFDT_OVERLAY is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/brppt1_spi_defconfig b/configs/brppt1_spi_defconfig index 37e7e3d8797..97be4e0cadd 100644 --- a/configs/brppt1_spi_defconfig +++ b/configs/brppt1_spi_defconfig @@ -114,4 +114,3 @@ CONFIG_USB_GADGET=y CONFIG_FAT_WRITE=y CONFIG_LZO=y # CONFIG_OF_LIBFDT_OVERLAY is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/brppt2_defconfig b/configs/brppt2_defconfig index 38f5cce4682..c5b78495086 100644 --- a/configs/brppt2_defconfig +++ b/configs/brppt2_defconfig @@ -97,4 +97,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_STORAGE=y CONFIG_SPL_TINY_MEMSET=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/brsmarc1_defconfig b/configs/brsmarc1_defconfig index c27dd9243e2..0c80dd493c5 100644 --- a/configs/brsmarc1_defconfig +++ b/configs/brsmarc1_defconfig @@ -114,4 +114,3 @@ CONFIG_USB_GADGET=y CONFIG_SPL_TINY_MEMSET=y CONFIG_SHA1=y CONFIG_SHA256=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/brxre1_defconfig b/configs/brxre1_defconfig index c1014db629a..2b86caebdca 100644 --- a/configs/brxre1_defconfig +++ b/configs/brxre1_defconfig @@ -94,4 +94,3 @@ CONFIG_USB_GADGET=y CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_SPL_TINY_MEMSET=y # CONFIG_OF_LIBFDT_OVERLAY is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/chromebook_coral_defconfig b/configs/chromebook_coral_defconfig index d785c9ba1a5..10f7fcf020c 100644 --- a/configs/chromebook_coral_defconfig +++ b/configs/chromebook_coral_defconfig @@ -115,4 +115,3 @@ CONFIG_CMD_DHRYSTONE=y CONFIG_TPM=y # CONFIG_GZIP is not set CONFIG_BLOBLIST_TABLES=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/chromebook_link_defconfig b/configs/chromebook_link_defconfig index 6a69938677f..1e7901e3bff 100644 --- a/configs/chromebook_link_defconfig +++ b/configs/chromebook_link_defconfig @@ -71,4 +71,3 @@ CONFIG_VIDEO_IVYBRIDGE_IGD=y CONFIG_CMD_DHRYSTONE=y CONFIG_TPM=y # CONFIG_GZIP is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/colibri-imx8x_defconfig b/configs/colibri-imx8x_defconfig index eba334bbd0a..81d922ee5fb 100644 --- a/configs/colibri-imx8x_defconfig +++ b/configs/colibri-imx8x_defconfig @@ -62,4 +62,3 @@ CONFIG_DM_SERIAL=y CONFIG_FSL_LPUART=y CONFIG_DM_THERMAL=y CONFIG_IMX_SCU_THERMAL=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/colibri_vf_defconfig b/configs/colibri_vf_defconfig index 13399ca839a..49eeaf2fa9a 100644 --- a/configs/colibri_vf_defconfig +++ b/configs/colibri_vf_defconfig @@ -101,4 +101,3 @@ CONFIG_VIDEO_FSL_DCU_FB=y CONFIG_SPLASH_SCREEN_ALIGN=y CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_FDT_FIXUP_PARTITIONS=y -# CONFIG_EFI_UNICODE_CAPITALIZATION is not set diff --git a/configs/controlcenterdc_defconfig b/configs/controlcenterdc_defconfig index ba0a87d532c..4cd12e0a778 100644 --- a/configs/controlcenterdc_defconfig +++ b/configs/controlcenterdc_defconfig @@ -83,4 +83,3 @@ CONFIG_DM_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_STORAGE=y CONFIG_TPM=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/crs305-1g-4s-bit_defconfig b/configs/crs305-1g-4s-bit_defconfig index a6f48843954..2a2e355f31a 100644 --- a/configs/crs305-1g-4s-bit_defconfig +++ b/configs/crs305-1g-4s-bit_defconfig @@ -44,4 +44,3 @@ CONFIG_PCI=y CONFIG_PCI_MVEBU=y CONFIG_SYS_NS16550=y CONFIG_KIRKWOOD_SPI=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/crs305-1g-4s_defconfig b/configs/crs305-1g-4s_defconfig index ea48ba2ebed..89aaee47139 100644 --- a/configs/crs305-1g-4s_defconfig +++ b/configs/crs305-1g-4s_defconfig @@ -45,4 +45,3 @@ CONFIG_PCI=y CONFIG_PCI_MVEBU=y CONFIG_SYS_NS16550=y CONFIG_KIRKWOOD_SPI=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/crs326-24g-2s-bit_defconfig b/configs/crs326-24g-2s-bit_defconfig index 8aeb591b05d..358db9fc8db 100644 --- a/configs/crs326-24g-2s-bit_defconfig +++ b/configs/crs326-24g-2s-bit_defconfig @@ -44,4 +44,3 @@ CONFIG_PCI=y CONFIG_PCI_MVEBU=y CONFIG_SYS_NS16550=y CONFIG_KIRKWOOD_SPI=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/crs326-24g-2s_defconfig b/configs/crs326-24g-2s_defconfig index d0b2bc5ff6b..fbb52764ad7 100644 --- a/configs/crs326-24g-2s_defconfig +++ b/configs/crs326-24g-2s_defconfig @@ -44,4 +44,3 @@ CONFIG_PCI=y CONFIG_PCI_MVEBU=y CONFIG_SYS_NS16550=y CONFIG_KIRKWOOD_SPI=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/crs328-4c-20s-4s-bit_defconfig b/configs/crs328-4c-20s-4s-bit_defconfig index 507f3ca9030..12c09a3b13b 100644 --- a/configs/crs328-4c-20s-4s-bit_defconfig +++ b/configs/crs328-4c-20s-4s-bit_defconfig @@ -44,4 +44,3 @@ CONFIG_PCI=y CONFIG_PCI_MVEBU=y CONFIG_SYS_NS16550=y CONFIG_KIRKWOOD_SPI=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/crs328-4c-20s-4s_defconfig b/configs/crs328-4c-20s-4s_defconfig index b958bd5a5e7..c8393c8fdee 100644 --- a/configs/crs328-4c-20s-4s_defconfig +++ b/configs/crs328-4c-20s-4s_defconfig @@ -44,4 +44,3 @@ CONFIG_PCI=y CONFIG_PCI_MVEBU=y CONFIG_SYS_NS16550=y CONFIG_KIRKWOOD_SPI=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/deneb_defconfig b/configs/deneb_defconfig index 3889ce08eae..9a7b2bd6224 100644 --- a/configs/deneb_defconfig +++ b/configs/deneb_defconfig @@ -106,4 +106,3 @@ CONFIG_DM_THERMAL=y CONFIG_IMX_SCU_THERMAL=y # CONFIG_SPL_WDT is not set CONFIG_SPL_TINY_MEMSET=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/dragonboard820c_defconfig b/configs/dragonboard820c_defconfig index d43fdf16b6d..a9fbfe2c8b2 100644 --- a/configs/dragonboard820c_defconfig +++ b/configs/dragonboard820c_defconfig @@ -14,7 +14,6 @@ CONFIG_BOOTARGS="console=ttyMSM0,115200n8" # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_MISC_INIT_R=y CONFIG_SYS_PROMPT="dragonboard820c => " -CONFIG_CMD_BOOTEFI_HELLO=y CONFIG_CMD_MD5SUM=y CONFIG_CMD_MEMINFO=y CONFIG_CMD_GPIO=y diff --git a/configs/efi-x86_app_defconfig b/configs/efi-x86_app_defconfig index 4644e51ccb3..ebb98022f38 100644 --- a/configs/efi-x86_app_defconfig +++ b/configs/efi-x86_app_defconfig @@ -36,4 +36,3 @@ CONFIG_SYSCON=y # CONFIG_REGEX is not set # CONFIG_GZIP is not set CONFIG_EFI=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig index 91518dbe358..9b424b25474 100644 --- a/configs/evb-ast2600_defconfig +++ b/configs/evb-ast2600_defconfig @@ -65,4 +65,3 @@ CONFIG_SPL_SYSRESET=y CONFIG_WDT=y CONFIG_HEXDUMP=y # CONFIG_SPL_HEXDUMP is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/evb-px30_defconfig b/configs/evb-px30_defconfig index d2fdfef2938..7b9c767c0b6 100644 --- a/configs/evb-px30_defconfig +++ b/configs/evb-px30_defconfig @@ -105,4 +105,3 @@ CONFIG_SPL_TINY_MEMSET=y CONFIG_TPL_TINY_MEMSET=y CONFIG_LZO=y CONFIG_ERRNO_STR=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/evb-rk3308_defconfig b/configs/evb-rk3308_defconfig index 9230983c880..501143cd0ef 100644 --- a/configs/evb-rk3308_defconfig +++ b/configs/evb-rk3308_defconfig @@ -73,4 +73,3 @@ CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_SPL_TINY_MEMSET=y CONFIG_LZO=y CONFIG_ERRNO_STR=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/firefly-px30_defconfig b/configs/firefly-px30_defconfig index 6487615fe08..b8d65224659 100644 --- a/configs/firefly-px30_defconfig +++ b/configs/firefly-px30_defconfig @@ -104,4 +104,3 @@ CONFIG_SPL_TINY_MEMSET=y CONFIG_TPL_TINY_MEMSET=y CONFIG_LZO=y CONFIG_ERRNO_STR=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/ge_bx50v3_defconfig b/configs/ge_bx50v3_defconfig index a266ffd849f..23542d9d777 100644 --- a/configs/ge_bx50v3_defconfig +++ b/configs/ge_bx50v3_defconfig @@ -98,4 +98,3 @@ CONFIG_VIDEO_IPUV3=y CONFIG_WATCHDOG_TIMEOUT_MSECS=8000 CONFIG_IMX_WATCHDOG=y CONFIG_BCH=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/giedi_defconfig b/configs/giedi_defconfig index 1c51943d3ea..566c1449704 100644 --- a/configs/giedi_defconfig +++ b/configs/giedi_defconfig @@ -106,4 +106,3 @@ CONFIG_DM_THERMAL=y CONFIG_IMX_SCU_THERMAL=y # CONFIG_SPL_WDT is not set CONFIG_SPL_TINY_MEMSET=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/grpeach_defconfig b/configs/grpeach_defconfig index b05d657f5c9..417fd5a8ce5 100644 --- a/configs/grpeach_defconfig +++ b/configs/grpeach_defconfig @@ -65,4 +65,3 @@ CONFIG_DM_USB=y CONFIG_USB_R8A66597_HCD=y CONFIG_USB_STORAGE=y CONFIG_OF_LIBFDT_OVERLAY=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/imx8mm-cl-iot-gate_defconfig b/configs/imx8mm-cl-iot-gate_defconfig index be98fa833bd..f5407025b30 100644 --- a/configs/imx8mm-cl-iot-gate_defconfig +++ b/configs/imx8mm-cl-iot-gate_defconfig @@ -35,8 +35,6 @@ CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_POWER_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_SYS_PROMPT="u-boot=> " -CONFIG_CMD_BOOTEFI_SELFTEST=y -CONFIG_CMD_NVEDIT_EFI=y CONFIG_CMD_EEPROM=y CONFIG_CMD_SHA1SUM=y CONFIG_CMD_BIND=y @@ -51,7 +49,6 @@ CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_SNTP=y CONFIG_CMD_CACHE=y -CONFIG_CMD_EFIDEBUG=y CONFIG_CMD_RTC=y CONFIG_CMD_TIME=y CONFIG_CMD_GETTIME=y @@ -141,8 +138,3 @@ CONFIG_TPM=y CONFIG_LZO=y CONFIG_BZIP2=y CONFIG_OF_LIBFDT_OVERLAY=y -CONFIG_EFI_SET_TIME=y -CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y -CONFIG_EFI_CAPSULE_ON_DISK=y -CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y -CONFIG_EFI_SECURE_BOOT=y diff --git a/configs/imx8qm_mek_defconfig b/configs/imx8qm_mek_defconfig index 8765c91ab99..a89ea3c68d3 100644 --- a/configs/imx8qm_mek_defconfig +++ b/configs/imx8qm_mek_defconfig @@ -84,4 +84,3 @@ CONFIG_SPL_DM_REGULATOR_GPIO=y CONFIG_DM_SERIAL=y CONFIG_FSL_LPUART=y CONFIG_SPL_TINY_MEMSET=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/imx8qm_rom7720_a1_4G_defconfig b/configs/imx8qm_rom7720_a1_4G_defconfig index d363b1adef1..19416d4c5b9 100644 --- a/configs/imx8qm_rom7720_a1_4G_defconfig +++ b/configs/imx8qm_rom7720_a1_4G_defconfig @@ -81,4 +81,3 @@ CONFIG_SPL_DM_REGULATOR_GPIO=y CONFIG_DM_SERIAL=y CONFIG_FSL_LPUART=y CONFIG_SPL_TINY_MEMSET=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/imx8qxp_mek_defconfig b/configs/imx8qxp_mek_defconfig index 5c78319d56d..8f7ff6226ab 100644 --- a/configs/imx8qxp_mek_defconfig +++ b/configs/imx8qxp_mek_defconfig @@ -88,4 +88,3 @@ CONFIG_FSL_LPUART=y CONFIG_DM_THERMAL=y CONFIG_IMX_SCU_THERMAL=y CONFIG_SPL_TINY_MEMSET=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/kontron_sl28_defconfig b/configs/kontron_sl28_defconfig index 98718db5c2e..43cbce061d9 100644 --- a/configs/kontron_sl28_defconfig +++ b/configs/kontron_sl28_defconfig @@ -36,7 +36,6 @@ CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y CONFIG_SPL_SPI_LOAD=y CONFIG_CMD_ASKENV=y CONFIG_CMD_GREPENV=y -CONFIG_CMD_NVEDIT_EFI=y CONFIG_CMD_DM=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y @@ -44,7 +43,6 @@ CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y CONFIG_CMD_CACHE=y -CONFIG_CMD_EFIDEBUG=y CONFIG_CMD_RNG=y CONFIG_MP=y CONFIG_OF_CONTROL=y diff --git a/configs/kp_imx53_defconfig b/configs/kp_imx53_defconfig index 71754380561..a9f6a7416e7 100644 --- a/configs/kp_imx53_defconfig +++ b/configs/kp_imx53_defconfig @@ -57,4 +57,3 @@ CONFIG_USB=y CONFIG_USB_EHCI_MX5=y CONFIG_USB_STORAGE=y CONFIG_HEXDUMP=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig index b576806b9dd..a42962931b4 100644 --- a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig @@ -87,4 +87,3 @@ CONFIG_WDT=y CONFIG_WDT_SP805=y CONFIG_RSA=y CONFIG_OF_LIBFDT_OVERLAY=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1028aqds_tfa_defconfig b/configs/ls1028aqds_tfa_defconfig index bcdb96d0bbe..f3a91ac204d 100644 --- a/configs/ls1028aqds_tfa_defconfig +++ b/configs/ls1028aqds_tfa_defconfig @@ -92,4 +92,3 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_WDT=y CONFIG_WDT_SP805=y CONFIG_OF_LIBFDT_OVERLAY=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1028aqds_tfa_lpuart_defconfig b/configs/ls1028aqds_tfa_lpuart_defconfig index e310cfee1d8..ef86cbaf3eb 100644 --- a/configs/ls1028aqds_tfa_lpuart_defconfig +++ b/configs/ls1028aqds_tfa_lpuart_defconfig @@ -92,4 +92,3 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_WDT=y CONFIG_WDT_SP805=y CONFIG_OF_LIBFDT_OVERLAY=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig index 34cd6fbaab2..12d66fc0316 100644 --- a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig @@ -82,4 +82,3 @@ CONFIG_WDT=y CONFIG_WDT_SP805=y CONFIG_RSA=y CONFIG_OF_LIBFDT_OVERLAY=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig index 6ffc3bd3993..cd24b1c5a14 100644 --- a/configs/ls1028ardb_tfa_defconfig +++ b/configs/ls1028ardb_tfa_defconfig @@ -91,4 +91,3 @@ CONFIG_USB_ETHER_RTL8152=y CONFIG_WDT=y CONFIG_WDT_SP805=y CONFIG_OF_LIBFDT_OVERLAY=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1043aqds_defconfig b/configs/ls1043aqds_defconfig index 42fd350075d..d4439b81155 100644 --- a/configs/ls1043aqds_defconfig +++ b/configs/ls1043aqds_defconfig @@ -68,4 +68,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1043aqds_lpuart_defconfig b/configs/ls1043aqds_lpuart_defconfig index 1bafc2bb03a..acdb899827c 100644 --- a/configs/ls1043aqds_lpuart_defconfig +++ b/configs/ls1043aqds_lpuart_defconfig @@ -70,4 +70,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1043aqds_nand_defconfig b/configs/ls1043aqds_nand_defconfig index 8fb23acd884..b23bd435c47 100644 --- a/configs/ls1043aqds_nand_defconfig +++ b/configs/ls1043aqds_nand_defconfig @@ -84,4 +84,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1043aqds_nor_ddr3_defconfig b/configs/ls1043aqds_nor_ddr3_defconfig index f87c9a7cbfe..52b87eaf1fb 100644 --- a/configs/ls1043aqds_nor_ddr3_defconfig +++ b/configs/ls1043aqds_nor_ddr3_defconfig @@ -69,4 +69,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1043aqds_qspi_defconfig b/configs/ls1043aqds_qspi_defconfig index 5de4e07457c..4dfa8607f40 100644 --- a/configs/ls1043aqds_qspi_defconfig +++ b/configs/ls1043aqds_qspi_defconfig @@ -65,4 +65,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1043aqds_sdcard_ifc_defconfig b/configs/ls1043aqds_sdcard_ifc_defconfig index 6e3318b1ed3..2177836befc 100644 --- a/configs/ls1043aqds_sdcard_ifc_defconfig +++ b/configs/ls1043aqds_sdcard_ifc_defconfig @@ -85,4 +85,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1043aqds_sdcard_qspi_defconfig b/configs/ls1043aqds_sdcard_qspi_defconfig index cd20980c989..9683ef80f6e 100644 --- a/configs/ls1043aqds_sdcard_qspi_defconfig +++ b/configs/ls1043aqds_sdcard_qspi_defconfig @@ -79,4 +79,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig index 4caabcadb81..334e52ac947 100644 --- a/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig @@ -71,4 +71,3 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_RSA_SOFTWARE_EXP=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1043aqds_tfa_defconfig b/configs/ls1043aqds_tfa_defconfig index fb280726382..8cf4c65322a 100644 --- a/configs/ls1043aqds_tfa_defconfig +++ b/configs/ls1043aqds_tfa_defconfig @@ -78,4 +78,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1043ardb_SECURE_BOOT_defconfig b/configs/ls1043ardb_SECURE_BOOT_defconfig index 5e1cfc6f31e..776fada6fe9 100644 --- a/configs/ls1043ardb_SECURE_BOOT_defconfig +++ b/configs/ls1043ardb_SECURE_BOOT_defconfig @@ -61,4 +61,3 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_RSA_SOFTWARE_EXP=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1043ardb_defconfig b/configs/ls1043ardb_defconfig index bd7b2db13a7..5ad28f907bf 100644 --- a/configs/ls1043ardb_defconfig +++ b/configs/ls1043ardb_defconfig @@ -61,4 +61,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1043ardb_nand_SECURE_BOOT_defconfig b/configs/ls1043ardb_nand_SECURE_BOOT_defconfig index 04633bc7b7e..93e2495ba8d 100644 --- a/configs/ls1043ardb_nand_SECURE_BOOT_defconfig +++ b/configs/ls1043ardb_nand_SECURE_BOOT_defconfig @@ -81,4 +81,3 @@ CONFIG_USB_XHCI_DWC3=y # CONFIG_SPL_USE_TINY_PRINTF is not set CONFIG_RSA=y CONFIG_SPL_RSA=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1043ardb_nand_defconfig b/configs/ls1043ardb_nand_defconfig index 5c993f3a017..64c8a03252c 100644 --- a/configs/ls1043ardb_nand_defconfig +++ b/configs/ls1043ardb_nand_defconfig @@ -80,4 +80,3 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y # CONFIG_SPL_USE_TINY_PRINTF is not set -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig b/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig index 1f6087ccd61..b2f2dfacdf9 100644 --- a/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig +++ b/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig @@ -83,4 +83,3 @@ CONFIG_USB_XHCI_DWC3=y # CONFIG_SPL_USE_TINY_PRINTF is not set CONFIG_RSA=y CONFIG_SPL_RSA=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1043ardb_sdcard_defconfig b/configs/ls1043ardb_sdcard_defconfig index c66ec3ba539..aa2d37f634d 100644 --- a/configs/ls1043ardb_sdcard_defconfig +++ b/configs/ls1043ardb_sdcard_defconfig @@ -80,4 +80,3 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y # CONFIG_SPL_USE_TINY_PRINTF is not set -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1043ardb_tfa_SECURE_BOOT_defconfig b/configs/ls1043ardb_tfa_SECURE_BOOT_defconfig index 44cbd76abf4..c6cbf174cfc 100644 --- a/configs/ls1043ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1043ardb_tfa_SECURE_BOOT_defconfig @@ -62,4 +62,3 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_RSA_SOFTWARE_EXP=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1043ardb_tfa_defconfig b/configs/ls1043ardb_tfa_defconfig index 7e53bc4b653..8046a15d6a9 100644 --- a/configs/ls1043ardb_tfa_defconfig +++ b/configs/ls1043ardb_tfa_defconfig @@ -65,4 +65,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1046aqds_SECURE_BOOT_defconfig b/configs/ls1046aqds_SECURE_BOOT_defconfig index 7e7ae34226c..555181a4a46 100644 --- a/configs/ls1046aqds_SECURE_BOOT_defconfig +++ b/configs/ls1046aqds_SECURE_BOOT_defconfig @@ -69,4 +69,3 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1046aqds_defconfig b/configs/ls1046aqds_defconfig index 8905d450da3..aa1e47404c9 100644 --- a/configs/ls1046aqds_defconfig +++ b/configs/ls1046aqds_defconfig @@ -71,4 +71,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1046aqds_lpuart_defconfig b/configs/ls1046aqds_lpuart_defconfig index 6627ac2bb0f..aec467bf299 100644 --- a/configs/ls1046aqds_lpuart_defconfig +++ b/configs/ls1046aqds_lpuart_defconfig @@ -73,4 +73,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1046aqds_nand_defconfig b/configs/ls1046aqds_nand_defconfig index 9da564a788c..93a9381ada3 100644 --- a/configs/ls1046aqds_nand_defconfig +++ b/configs/ls1046aqds_nand_defconfig @@ -79,4 +79,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1046aqds_qspi_defconfig b/configs/ls1046aqds_qspi_defconfig index 6cf46ff2c93..542ee0efc47 100644 --- a/configs/ls1046aqds_qspi_defconfig +++ b/configs/ls1046aqds_qspi_defconfig @@ -69,4 +69,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1046aqds_sdcard_ifc_defconfig b/configs/ls1046aqds_sdcard_ifc_defconfig index 165c272c41f..65503ff52bb 100644 --- a/configs/ls1046aqds_sdcard_ifc_defconfig +++ b/configs/ls1046aqds_sdcard_ifc_defconfig @@ -89,4 +89,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1046aqds_sdcard_qspi_defconfig b/configs/ls1046aqds_sdcard_qspi_defconfig index 8e60a358586..35918e11050 100644 --- a/configs/ls1046aqds_sdcard_qspi_defconfig +++ b/configs/ls1046aqds_sdcard_qspi_defconfig @@ -84,4 +84,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1046aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1046aqds_tfa_SECURE_BOOT_defconfig index 7e57b53a1f1..3ce71fea5a0 100644 --- a/configs/ls1046aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1046aqds_tfa_SECURE_BOOT_defconfig @@ -71,4 +71,3 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1046aqds_tfa_defconfig b/configs/ls1046aqds_tfa_defconfig index 9366bc1d328..15a92f4ef37 100644 --- a/configs/ls1046aqds_tfa_defconfig +++ b/configs/ls1046aqds_tfa_defconfig @@ -81,4 +81,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1046ardb_emmc_defconfig b/configs/ls1046ardb_emmc_defconfig index 68efb1be923..e1e7b066f6d 100644 --- a/configs/ls1046ardb_emmc_defconfig +++ b/configs/ls1046ardb_emmc_defconfig @@ -81,4 +81,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig b/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig index 3b43fd0ae6d..bb0bde51429 100644 --- a/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig @@ -64,4 +64,3 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1046ardb_qspi_defconfig b/configs/ls1046ardb_qspi_defconfig index a9036dd11ff..211852489b7 100644 --- a/configs/ls1046ardb_qspi_defconfig +++ b/configs/ls1046ardb_qspi_defconfig @@ -67,4 +67,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1046ardb_qspi_spl_defconfig b/configs/ls1046ardb_qspi_spl_defconfig index a6e464b5c14..262196e2570 100644 --- a/configs/ls1046ardb_qspi_spl_defconfig +++ b/configs/ls1046ardb_qspi_spl_defconfig @@ -86,4 +86,3 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_SPL_GZIP=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig b/configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig index 3514f29bfe3..ae40bb7ee6c 100644 --- a/configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig +++ b/configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig @@ -81,4 +81,3 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_SPL_RSA=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1046ardb_sdcard_defconfig b/configs/ls1046ardb_sdcard_defconfig index e5a8ad15a87..5306a675acb 100644 --- a/configs/ls1046ardb_sdcard_defconfig +++ b/configs/ls1046ardb_sdcard_defconfig @@ -80,4 +80,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig b/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig index faa08b2fed4..8f4aaa6fea3 100644 --- a/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig @@ -63,4 +63,3 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1046ardb_tfa_defconfig b/configs/ls1046ardb_tfa_defconfig index 53f13147fa9..d59e5dea6e4 100644 --- a/configs/ls1046ardb_tfa_defconfig +++ b/configs/ls1046ardb_tfa_defconfig @@ -68,4 +68,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig b/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig index 57c91c1ad8e..0e3ff700377 100644 --- a/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig @@ -74,4 +74,3 @@ CONFIG_USB_DWC3=y CONFIG_USB_GADGET=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1088aqds_qspi_defconfig b/configs/ls1088aqds_qspi_defconfig index 9abaead1c88..59af8086436 100644 --- a/configs/ls1088aqds_qspi_defconfig +++ b/configs/ls1088aqds_qspi_defconfig @@ -75,4 +75,3 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_GADGET=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1088aqds_tfa_defconfig b/configs/ls1088aqds_tfa_defconfig index 5229a351e1a..e71de47397f 100644 --- a/configs/ls1088aqds_tfa_defconfig +++ b/configs/ls1088aqds_tfa_defconfig @@ -99,4 +99,3 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_GADGET=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig b/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig index de3759951e1..cec945c52da 100644 --- a/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig @@ -76,4 +76,3 @@ CONFIG_USB_DWC3=y CONFIG_USB_GADGET=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1088ardb_qspi_defconfig b/configs/ls1088ardb_qspi_defconfig index 0e32aeb6349..0651156eb09 100644 --- a/configs/ls1088ardb_qspi_defconfig +++ b/configs/ls1088ardb_qspi_defconfig @@ -77,4 +77,3 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_GADGET=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig b/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig index 84fbab0f428..0d17e3f7f0f 100644 --- a/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig @@ -85,4 +85,3 @@ CONFIG_USB_GADGET=y CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_RSA_SOFTWARE_EXP=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig index 007a80c2c66..25540ba1575 100644 --- a/configs/ls1088ardb_tfa_defconfig +++ b/configs/ls1088ardb_tfa_defconfig @@ -91,4 +91,3 @@ CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y CONFIG_USB_ETHER_RTL8152=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls2080aqds_SECURE_BOOT_defconfig b/configs/ls2080aqds_SECURE_BOOT_defconfig index bfa697c9ef7..68dafbd9a77 100644 --- a/configs/ls2080aqds_SECURE_BOOT_defconfig +++ b/configs/ls2080aqds_SECURE_BOOT_defconfig @@ -67,4 +67,3 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls2080aqds_defconfig b/configs/ls2080aqds_defconfig index 6f9cce5b255..5c8789b2f42 100644 --- a/configs/ls2080aqds_defconfig +++ b/configs/ls2080aqds_defconfig @@ -68,4 +68,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls2080aqds_nand_defconfig b/configs/ls2080aqds_nand_defconfig index cc0f2b16aaa..de553604058 100644 --- a/configs/ls2080aqds_nand_defconfig +++ b/configs/ls2080aqds_nand_defconfig @@ -75,4 +75,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls2080aqds_qspi_defconfig b/configs/ls2080aqds_qspi_defconfig index cbdf7334562..e4f1d1b4af5 100644 --- a/configs/ls2080aqds_qspi_defconfig +++ b/configs/ls2080aqds_qspi_defconfig @@ -67,4 +67,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls2080aqds_sdcard_defconfig b/configs/ls2080aqds_sdcard_defconfig index 71174de458c..775c00f9be7 100644 --- a/configs/ls2080aqds_sdcard_defconfig +++ b/configs/ls2080aqds_sdcard_defconfig @@ -74,4 +74,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls2080ardb_SECURE_BOOT_defconfig b/configs/ls2080ardb_SECURE_BOOT_defconfig index 1175aafadbf..15528f2e7de 100644 --- a/configs/ls2080ardb_SECURE_BOOT_defconfig +++ b/configs/ls2080ardb_SECURE_BOOT_defconfig @@ -65,4 +65,3 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls2080ardb_defconfig b/configs/ls2080ardb_defconfig index 53abd06ec61..17f7f2d9bae 100644 --- a/configs/ls2080ardb_defconfig +++ b/configs/ls2080ardb_defconfig @@ -66,4 +66,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls2080ardb_nand_defconfig b/configs/ls2080ardb_nand_defconfig index 93032edc0c5..dd4216fd1a5 100644 --- a/configs/ls2080ardb_nand_defconfig +++ b/configs/ls2080ardb_nand_defconfig @@ -71,4 +71,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls2081ardb_defconfig b/configs/ls2081ardb_defconfig index ab1a9e22e03..4bea4aba349 100644 --- a/configs/ls2081ardb_defconfig +++ b/configs/ls2081ardb_defconfig @@ -64,4 +64,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls2088aqds_tfa_defconfig b/configs/ls2088aqds_tfa_defconfig index 5620e8a786b..eb836f7bb47 100644 --- a/configs/ls2088aqds_tfa_defconfig +++ b/configs/ls2088aqds_tfa_defconfig @@ -89,4 +89,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls2088ardb_qspi_SECURE_BOOT_defconfig b/configs/ls2088ardb_qspi_SECURE_BOOT_defconfig index 10c139c98ea..ac06023aa8e 100644 --- a/configs/ls2088ardb_qspi_SECURE_BOOT_defconfig +++ b/configs/ls2088ardb_qspi_SECURE_BOOT_defconfig @@ -66,4 +66,3 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls2088ardb_qspi_defconfig b/configs/ls2088ardb_qspi_defconfig index 58fc6b23844..eea9ec58545 100644 --- a/configs/ls2088ardb_qspi_defconfig +++ b/configs/ls2088ardb_qspi_defconfig @@ -71,4 +71,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls2088ardb_tfa_SECURE_BOOT_defconfig b/configs/ls2088ardb_tfa_SECURE_BOOT_defconfig index eed26fa8983..b3c14527059 100644 --- a/configs/ls2088ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls2088ardb_tfa_SECURE_BOOT_defconfig @@ -82,4 +82,3 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_RSA_SOFTWARE_EXP=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/ls2088ardb_tfa_defconfig b/configs/ls2088ardb_tfa_defconfig index 56cd02418cd..d5d5092b9a1 100644 --- a/configs/ls2088ardb_tfa_defconfig +++ b/configs/ls2088ardb_tfa_defconfig @@ -87,4 +87,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig b/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig index 54d88c88d59..3b4993d9043 100644 --- a/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig @@ -85,4 +85,3 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_RSA_SOFTWARE_EXP=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/lx2160aqds_tfa_defconfig b/configs/lx2160aqds_tfa_defconfig index d25d3e8b98c..6f02c0bca63 100644 --- a/configs/lx2160aqds_tfa_defconfig +++ b/configs/lx2160aqds_tfa_defconfig @@ -91,4 +91,3 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_WDT=y CONFIG_WDT_SBSA=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig b/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig index 1d61807c11e..d0fafb917aa 100644 --- a/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig @@ -76,4 +76,3 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_RSA_SOFTWARE_EXP=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/lx2160ardb_tfa_defconfig b/configs/lx2160ardb_tfa_defconfig index a160cfe21e3..d7514ac7dea 100644 --- a/configs/lx2160ardb_tfa_defconfig +++ b/configs/lx2160ardb_tfa_defconfig @@ -86,4 +86,3 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_WDT=y CONFIG_WDT_SBSA=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/lx2160ardb_tfa_stmm_defconfig b/configs/lx2160ardb_tfa_stmm_defconfig index 8b69a36dd9d..63d93b7af83 100644 --- a/configs/lx2160ardb_tfa_stmm_defconfig +++ b/configs/lx2160ardb_tfa_stmm_defconfig @@ -25,7 +25,6 @@ CONFIG_BOOTARGS="console=ttyAMA0,115200 root=/dev/ram0 earlycon=pl011,mmio32,0x2 # CONFIG_USE_BOOTCOMMAND is not set CONFIG_MISC_INIT_R=y CONFIG_CMD_GREPENV=y -CONFIG_CMD_NVEDIT_EFI=y CONFIG_CMD_EEPROM=y CONFIG_CMD_DM=y CONFIG_CMD_GPIO=y @@ -35,7 +34,6 @@ CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y CONFIG_CMD_CACHE=y -CONFIG_CMD_EFIDEBUG=y CONFIG_MP=y CONFIG_OF_CONTROL=y CONFIG_ENV_OVERWRITE=y @@ -84,5 +82,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_EFI_MM_COMM_TEE=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig b/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig index fcc78c6fe5c..12d8216bc3b 100644 --- a/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig @@ -88,4 +88,3 @@ CONFIG_WDT_SBSA=y CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_RSA_SOFTWARE_EXP=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/lx2162aqds_tfa_defconfig b/configs/lx2162aqds_tfa_defconfig index 42a3a3af446..73f7d8928ca 100644 --- a/configs/lx2162aqds_tfa_defconfig +++ b/configs/lx2162aqds_tfa_defconfig @@ -95,4 +95,3 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_WDT=y CONFIG_WDT_SBSA=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/lx2162aqds_tfa_verified_boot_defconfig b/configs/lx2162aqds_tfa_verified_boot_defconfig index bf0ac38ff23..1ce83076b41 100644 --- a/configs/lx2162aqds_tfa_verified_boot_defconfig +++ b/configs/lx2162aqds_tfa_verified_boot_defconfig @@ -96,4 +96,3 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_WDT=y CONFIG_WDT_SBSA=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/mt7623n_bpir2_defconfig b/configs/mt7623n_bpir2_defconfig index 0a91752e2a9..eda7013f923 100644 --- a/configs/mt7623n_bpir2_defconfig +++ b/configs/mt7623n_bpir2_defconfig @@ -52,4 +52,3 @@ CONFIG_TIMER=y CONFIG_MTK_TIMER=y CONFIG_WDT_MTK=y CONFIG_LZMA=y -# CONFIG_EFI_GRUB_ARM32_WORKAROUND is not set diff --git a/configs/mt7629_rfb_defconfig b/configs/mt7629_rfb_defconfig index cd9f7aaa06e..9eb36da6d3d 100644 --- a/configs/mt7629_rfb_defconfig +++ b/configs/mt7629_rfb_defconfig @@ -93,4 +93,3 @@ CONFIG_USB_KEYBOARD=y CONFIG_WDT_MTK=y CONFIG_LZMA=y CONFIG_SPL_LZMA=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/mt8183_pumpkin_defconfig b/configs/mt8183_pumpkin_defconfig index c74b812bd89..1b503cbc5d2 100644 --- a/configs/mt8183_pumpkin_defconfig +++ b/configs/mt8183_pumpkin_defconfig @@ -76,4 +76,3 @@ CONFIG_WDT=y CONFIG_WDT_MTK=y # CONFIG_REGEX is not set CONFIG_OF_LIBFDT_OVERLAY=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/mt8516_pumpkin_defconfig b/configs/mt8516_pumpkin_defconfig index 780660058da..c8ea22c2482 100644 --- a/configs/mt8516_pumpkin_defconfig +++ b/configs/mt8516_pumpkin_defconfig @@ -74,4 +74,3 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0e8d CONFIG_USB_GADGET_PRODUCT_NUM=0x201c CONFIG_WDT=y CONFIG_WDT_MTK=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/mvebu_puzzle-m801-88f8040_defconfig b/configs/mvebu_puzzle-m801-88f8040_defconfig index 652ea645459..ca01ceaadb2 100644 --- a/configs/mvebu_puzzle-m801-88f8040_defconfig +++ b/configs/mvebu_puzzle-m801-88f8040_defconfig @@ -77,4 +77,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_EHCI_HCD=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/mx6memcal_defconfig b/configs/mx6memcal_defconfig index 41ff942cf1c..914612ae183 100644 --- a/configs/mx6memcal_defconfig +++ b/configs/mx6memcal_defconfig @@ -52,4 +52,3 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y CONFIG_OF_LIBFDT=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/octeontx2_95xx_defconfig b/configs/octeontx2_95xx_defconfig index 25791910c69..acb00210fbd 100644 --- a/configs/octeontx2_95xx_defconfig +++ b/configs/octeontx2_95xx_defconfig @@ -24,7 +24,6 @@ CONFIG_BOOTARGS="console=ttyAMA0,115200n8 earlycon=pl011,0x87e028000000 maxcpus= CONFIG_BOARD_EARLY_INIT_R=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="Marvell> " -# CONFIG_CMD_BOOTEFI_HELLO_COMPILE is not set CONFIG_CMD_MD5SUM=y CONFIG_MD5SUM_VERIFY=y CONFIG_CMD_MX_CYCLIC=y diff --git a/configs/octeontx2_96xx_defconfig b/configs/octeontx2_96xx_defconfig index a1d4ecde85c..fc1d2f83f6c 100644 --- a/configs/octeontx2_96xx_defconfig +++ b/configs/octeontx2_96xx_defconfig @@ -24,7 +24,6 @@ CONFIG_BOOTARGS="console=ttyAMA0,115200n8 earlycon=pl011,0x87e028000000 maxcpus= CONFIG_BOARD_EARLY_INIT_R=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="Marvell> " -# CONFIG_CMD_BOOTEFI_HELLO_COMPILE is not set CONFIG_CMD_MD5SUM=y CONFIG_MD5SUM_VERIFY=y CONFIG_CMD_MX_CYCLIC=y diff --git a/configs/octeontx_81xx_defconfig b/configs/octeontx_81xx_defconfig index 72394a7bb40..cc1cb299e17 100644 --- a/configs/octeontx_81xx_defconfig +++ b/configs/octeontx_81xx_defconfig @@ -26,7 +26,6 @@ CONFIG_BOOTARGS="console=ttyAMA0,115200n8 earlycon=pl011,0x87e028000000 maxcpus= CONFIG_BOARD_EARLY_INIT_R=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="Marvell> " -# CONFIG_CMD_BOOTEFI_HELLO_COMPILE is not set CONFIG_CMD_MD5SUM=y CONFIG_MD5SUM_VERIFY=y CONFIG_CMD_MX_CYCLIC=y diff --git a/configs/octeontx_83xx_defconfig b/configs/octeontx_83xx_defconfig index a82c405b3af..748b4f7010f 100644 --- a/configs/octeontx_83xx_defconfig +++ b/configs/octeontx_83xx_defconfig @@ -24,7 +24,6 @@ CONFIG_BOOTARGS="console=ttyAMA0,115200n8 earlycon=pl011,0x87e028000000 maxcpus= CONFIG_BOARD_EARLY_INIT_R=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="Marvell> " -# CONFIG_CMD_BOOTEFI_HELLO_COMPILE is not set CONFIG_CMD_MD5SUM=y CONFIG_MD5SUM_VERIFY=y CONFIG_CMD_MX_CYCLIC=y diff --git a/configs/omap4_sdp4430_defconfig b/configs/omap4_sdp4430_defconfig index 3592cfd9fae..ef23e8a7533 100644 --- a/configs/omap4_sdp4430_defconfig +++ b/configs/omap4_sdp4430_defconfig @@ -44,4 +44,3 @@ CONFIG_USB_OMAP3=y CONFIG_USB_GADGET=y CONFIG_FAT_WRITE=y # CONFIG_REGEX is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/opos6uldev_defconfig b/configs/opos6uldev_defconfig index 2b83fa206f8..bf7d6d70587 100644 --- a/configs/opos6uldev_defconfig +++ b/configs/opos6uldev_defconfig @@ -114,4 +114,3 @@ CONFIG_BMP_16BPP=y CONFIG_BMP_24BPP=y CONFIG_BMP_32BPP=y CONFIG_OF_LIBFDT_OVERLAY=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/pcm052_defconfig b/configs/pcm052_defconfig index 32f08a17419..8f52d30dc64 100644 --- a/configs/pcm052_defconfig +++ b/configs/pcm052_defconfig @@ -70,4 +70,3 @@ CONFIG_FSL_LPUART=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_FSL_QSPI=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/phycore-am335x-r2-regor_defconfig b/configs/phycore-am335x-r2-regor_defconfig index 8b3ad9db152..44527a2e6a6 100644 --- a/configs/phycore-am335x-r2-regor_defconfig +++ b/configs/phycore-am335x-r2-regor_defconfig @@ -84,4 +84,3 @@ CONFIG_USB_MUSB_TI=y CONFIG_USB_GADGET=y CONFIG_USB_ETHER=y CONFIG_FDT_FIXUP_PARTITIONS=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/phycore-am335x-r2-wega_defconfig b/configs/phycore-am335x-r2-wega_defconfig index cbf3b9fdc15..c8948713f4c 100644 --- a/configs/phycore-am335x-r2-wega_defconfig +++ b/configs/phycore-am335x-r2-wega_defconfig @@ -85,4 +85,3 @@ CONFIG_USB_MUSB_TI=y CONFIG_USB_GADGET=y CONFIG_USB_ETHER=y CONFIG_FDT_FIXUP_PARTITIONS=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu-riscv32_defconfig index 8ac16cf4186..8c961f6b653 100644 --- a/configs/qemu-riscv32_defconfig +++ b/configs/qemu-riscv32_defconfig @@ -6,8 +6,6 @@ CONFIG_DISTRO_DEFAULTS=y CONFIG_FIT=y CONFIG_DISPLAY_CPUINFO=y CONFIG_DISPLAY_BOARDINFO=y -CONFIG_CMD_BOOTEFI_SELFTEST=y -CONFIG_CMD_NVEDIT_EFI=y # CONFIG_CMD_MII is not set CONFIG_OF_PRIOR_STAGE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y diff --git a/configs/qemu-riscv32_smode_defconfig b/configs/qemu-riscv32_smode_defconfig index 05eda439618..a32f498e68d 100644 --- a/configs/qemu-riscv32_smode_defconfig +++ b/configs/qemu-riscv32_smode_defconfig @@ -7,8 +7,6 @@ CONFIG_DISTRO_DEFAULTS=y CONFIG_FIT=y CONFIG_DISPLAY_CPUINFO=y CONFIG_DISPLAY_BOARDINFO=y -CONFIG_CMD_BOOTEFI_SELFTEST=y -CONFIG_CMD_NVEDIT_EFI=y # CONFIG_CMD_MII is not set CONFIG_OF_PRIOR_STAGE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-riscv64_defconfig index daf5d655d01..f80d75ad76b 100644 --- a/configs/qemu-riscv64_defconfig +++ b/configs/qemu-riscv64_defconfig @@ -7,8 +7,6 @@ CONFIG_DISTRO_DEFAULTS=y CONFIG_FIT=y CONFIG_DISPLAY_CPUINFO=y CONFIG_DISPLAY_BOARDINFO=y -CONFIG_CMD_BOOTEFI_SELFTEST=y -CONFIG_CMD_NVEDIT_EFI=y # CONFIG_CMD_MII is not set CONFIG_OF_PRIOR_STAGE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y diff --git a/configs/qemu-riscv64_smode_defconfig b/configs/qemu-riscv64_smode_defconfig index 0000564e41e..1b73e866f59 100644 --- a/configs/qemu-riscv64_smode_defconfig +++ b/configs/qemu-riscv64_smode_defconfig @@ -8,8 +8,6 @@ CONFIG_DISTRO_DEFAULTS=y CONFIG_FIT=y CONFIG_DISPLAY_CPUINFO=y CONFIG_DISPLAY_BOARDINFO=y -CONFIG_CMD_BOOTEFI_SELFTEST=y -CONFIG_CMD_NVEDIT_EFI=y # CONFIG_CMD_MII is not set CONFIG_OF_PRIOR_STAGE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig index 6e42fb7e33e..4ca2b36c867 100644 --- a/configs/qemu-x86_64_defconfig +++ b/configs/qemu-x86_64_defconfig @@ -39,8 +39,6 @@ CONFIG_SPL_PCI=y CONFIG_SPL_PCH_SUPPORT=y CONFIG_SPL_RTC_SUPPORT=y CONFIG_CMD_CPU=y -CONFIG_CMD_BOOTEFI_SELFTEST=y -CONFIG_CMD_NVEDIT_EFI=y CONFIG_CMD_IDE=y CONFIG_CMD_SPI=y CONFIG_CMD_USB=y diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig index 6be7ce0c6e6..48c6cf6b4f6 100644 --- a/configs/qemu-x86_defconfig +++ b/configs/qemu-x86_defconfig @@ -21,8 +21,6 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_LAST_STAGE_INIT=y CONFIG_PCI_INIT_R=y CONFIG_CMD_CPU=y -CONFIG_CMD_BOOTEFI_SELFTEST=y -CONFIG_CMD_NVEDIT_EFI=y CONFIG_CMD_IDE=y CONFIG_CMD_SPI=y CONFIG_CMD_USB=y diff --git a/configs/qemu_arm64_defconfig b/configs/qemu_arm64_defconfig index f6e586627a8..2f7f64e5cab 100644 --- a/configs/qemu_arm64_defconfig +++ b/configs/qemu_arm64_defconfig @@ -15,8 +15,6 @@ CONFIG_USE_PREBOOT=y # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_PCI_INIT_R=y -CONFIG_CMD_BOOTEFI_SELFTEST=y -CONFIG_CMD_NVEDIT_EFI=y CONFIG_CMD_DFU=y CONFIG_CMD_MTD=y CONFIG_CMD_PCI=y diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig index 278d8f41f48..350d545f015 100644 --- a/configs/qemu_arm_defconfig +++ b/configs/qemu_arm_defconfig @@ -17,8 +17,6 @@ CONFIG_USE_PREBOOT=y # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_PCI_INIT_R=y -CONFIG_CMD_BOOTEFI_SELFTEST=y -CONFIG_CMD_NVEDIT_EFI=y CONFIG_CMD_DFU=y CONFIG_CMD_MTD=y CONFIG_CMD_PCI=y diff --git a/configs/roc-cc-rk3308_defconfig b/configs/roc-cc-rk3308_defconfig index 2d02e294e68..bfc9f363ad3 100644 --- a/configs/roc-cc-rk3308_defconfig +++ b/configs/roc-cc-rk3308_defconfig @@ -73,4 +73,3 @@ CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_SPL_TINY_MEMSET=y CONFIG_LZO=y CONFIG_ERRNO_STR=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/rock-pi-n10-rk3399pro_defconfig b/configs/rock-pi-n10-rk3399pro_defconfig index 3255e015120..54a49598b35 100644 --- a/configs/rock-pi-n10-rk3399pro_defconfig +++ b/configs/rock-pi-n10-rk3399pro_defconfig @@ -62,7 +62,6 @@ CONFIG_USB_DWC3=y CONFIG_USB_DWC3_GENERIC=y CONFIG_ROCKCHIP_USB2_PHY=y CONFIG_USB_KEYBOARD=y -# CONFIG_USB_KEYBOARD_FN_KEYS is not set CONFIG_USB_GADGET=y CONFIG_DM_VIDEO=y CONFIG_DISPLAY=y diff --git a/configs/rock-pi-n8-rk3288_defconfig b/configs/rock-pi-n8-rk3288_defconfig index d1d1613f581..f8674ec695b 100644 --- a/configs/rock-pi-n8-rk3288_defconfig +++ b/configs/rock-pi-n8-rk3288_defconfig @@ -71,7 +71,6 @@ CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_DWC2=y CONFIG_ROCKCHIP_USB2_PHY=y CONFIG_USB_KEYBOARD=y -# CONFIG_USB_KEYBOARD_FN_KEYS is not set CONFIG_USB_GADGET=y CONFIG_USB_GADGET_DWC2_OTG=y CONFIG_DM_VIDEO=y diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig index ca92645c033..bfdf6fb0144 100644 --- a/configs/rpi_0_w_defconfig +++ b/configs/rpi_0_w_defconfig @@ -41,4 +41,3 @@ CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_OF_LIBFDT_OVERLAY=y -CONFIG_EFI_LOADER=y diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig index 1880f22c5d2..f4ac27f4b6e 100644 --- a/configs/rpi_defconfig +++ b/configs/rpi_defconfig @@ -41,4 +41,3 @@ CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_OF_LIBFDT_OVERLAY=y -CONFIG_EFI_LOADER=y diff --git a/configs/sama5d27_wlsom1_ek_mmc_defconfig b/configs/sama5d27_wlsom1_ek_mmc_defconfig index 83901980ffc..e99f87f26fb 100644 --- a/configs/sama5d27_wlsom1_ek_mmc_defconfig +++ b/configs/sama5d27_wlsom1_ek_mmc_defconfig @@ -106,4 +106,3 @@ CONFIG_W1_GPIO=y CONFIG_W1_EEPROM=y CONFIG_W1_EEPROM_DS24XXX=y CONFIG_OF_LIBFDT_OVERLAY=y -# CONFIG_EFI_LOADER_HII is not set diff --git a/configs/sama5d27_wlsom1_ek_qspiflash_defconfig b/configs/sama5d27_wlsom1_ek_qspiflash_defconfig index 3cb1ff62aa9..bc65dcecbaa 100644 --- a/configs/sama5d27_wlsom1_ek_qspiflash_defconfig +++ b/configs/sama5d27_wlsom1_ek_qspiflash_defconfig @@ -118,4 +118,3 @@ CONFIG_W1_GPIO=y CONFIG_W1_EEPROM=y CONFIG_W1_EEPROM_DS24XXX=y CONFIG_OF_LIBFDT_OVERLAY=y -# CONFIG_EFI_LOADER_HII is not set diff --git a/configs/sama5d2_icp_mmc_defconfig b/configs/sama5d2_icp_mmc_defconfig index c9e82d03b8a..f21f95490ba 100644 --- a/configs/sama5d2_icp_mmc_defconfig +++ b/configs/sama5d2_icp_mmc_defconfig @@ -77,4 +77,3 @@ CONFIG_TIMER=y CONFIG_SPL_TIMER=y CONFIG_ATMEL_PIT_TIMER=y CONFIG_OF_LIBFDT_OVERLAY=y -# CONFIG_EFI_LOADER_HII is not set diff --git a/configs/sama7g5ek_mmc1_defconfig b/configs/sama7g5ek_mmc1_defconfig index 337b58bc912..9dd28d7745e 100644 --- a/configs/sama7g5ek_mmc1_defconfig +++ b/configs/sama7g5ek_mmc1_defconfig @@ -68,4 +68,3 @@ CONFIG_ATMEL_USART=y CONFIG_TIMER=y CONFIG_MCHP_PIT64B_TIMER=y CONFIG_OF_LIBFDT_OVERLAY=y -# CONFIG_EFI_LOADER_HII is not set diff --git a/configs/sama7g5ek_mmc_defconfig b/configs/sama7g5ek_mmc_defconfig index 1dbf5276dce..6429ff8486e 100644 --- a/configs/sama7g5ek_mmc_defconfig +++ b/configs/sama7g5ek_mmc_defconfig @@ -68,4 +68,3 @@ CONFIG_ATMEL_USART=y CONFIG_TIMER=y CONFIG_MCHP_PIT64B_TIMER=y CONFIG_OF_LIBFDT_OVERLAY=y -# CONFIG_EFI_LOADER_HII is not set diff --git a/configs/sipeed_maix_bitm_defconfig b/configs/sipeed_maix_bitm_defconfig index 33c67c0b540..6bcf7f3d892 100644 --- a/configs/sipeed_maix_bitm_defconfig +++ b/configs/sipeed_maix_bitm_defconfig @@ -18,4 +18,3 @@ CONFIG_SF_DEFAULT_BUS=3 # CONFIG_DM_ETH is not set CONFIG_FS_EXT4=y CONFIG_FS_FAT=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/sipeed_maix_smode_defconfig b/configs/sipeed_maix_smode_defconfig index c20c389cace..af7581cfa11 100644 --- a/configs/sipeed_maix_smode_defconfig +++ b/configs/sipeed_maix_smode_defconfig @@ -18,4 +18,3 @@ CONFIG_SF_DEFAULT_BUS=3 # CONFIG_DM_ETH is not set CONFIG_FS_EXT4=y CONFIG_FS_FAT=y -# CONFIG_EFI_UNICODE_CAPITALIZATION is not set diff --git a/configs/socfpga_de1_soc_defconfig b/configs/socfpga_de1_soc_defconfig index c95d97e9cad..eab82ed84b4 100644 --- a/configs/socfpga_de1_soc_defconfig +++ b/configs/socfpga_de1_soc_defconfig @@ -50,4 +50,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_DWC2=y # CONFIG_SPL_WDT is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/somlabs_visionsom_6ull_defconfig b/configs/somlabs_visionsom_6ull_defconfig index 52e34e3b3f7..7c510b4857d 100644 --- a/configs/somlabs_visionsom_6ull_defconfig +++ b/configs/somlabs_visionsom_6ull_defconfig @@ -54,4 +54,3 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_STORAGE=y CONFIG_LZO=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/stemmy_defconfig b/configs/stemmy_defconfig index 79c05acc6ac..cf0ed40b481 100644 --- a/configs/stemmy_defconfig +++ b/configs/stemmy_defconfig @@ -15,4 +15,3 @@ CONFIG_CMD_GETTIME=y CONFIG_EFI_PARTITION=y # CONFIG_NET is not set # CONFIG_MMC_HW_PARTITIONING is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/stm32mp15_basic_defconfig b/configs/stm32mp15_basic_defconfig index 3ff46f70489..aa973da597b 100644 --- a/configs/stm32mp15_basic_defconfig +++ b/configs/stm32mp15_basic_defconfig @@ -35,7 +35,6 @@ CONFIG_SPL_SPI_FLASH_MTD=y CONFIG_SYS_PROMPT="STM32MP> " CONFIG_CMD_ADTIMG=y CONFIG_CMD_ERASEENV=y -CONFIG_CMD_NVEDIT_EFI=y CONFIG_CMD_MEMINFO=y CONFIG_CMD_MEMTEST=y CONFIG_CMD_UNZIP=y @@ -52,7 +51,6 @@ CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_BMP=y CONFIG_CMD_CACHE=y -CONFIG_CMD_EFIDEBUG=y CONFIG_CMD_TIME=y CONFIG_CMD_TIMER=y CONFIG_CMD_PMIC=y @@ -168,7 +166,6 @@ CONFIG_BMP_32BPP=y CONFIG_WDT=y CONFIG_WDT_STM32MP=y CONFIG_ERRNO_STR=y -# CONFIG_HEXDUMP is not set CONFIG_FDT_FIXUP_PARTITIONS=y # CONFIG_LMB_USE_MAX_REGIONS is not set CONFIG_LMB_MEMORY_REGIONS=2 diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig index afbf721299b..9c7aefc44ff 100644 --- a/configs/stm32mp15_trusted_defconfig +++ b/configs/stm32mp15_trusted_defconfig @@ -18,7 +18,6 @@ CONFIG_BOOTCOMMAND="run bootcmd_stm32mp" CONFIG_SYS_PROMPT="STM32MP> " CONFIG_CMD_ADTIMG=y CONFIG_CMD_ERASEENV=y -CONFIG_CMD_NVEDIT_EFI=y CONFIG_CMD_MEMINFO=y CONFIG_CMD_MEMTEST=y CONFIG_CMD_UNZIP=y @@ -35,7 +34,6 @@ CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_BMP=y CONFIG_CMD_CACHE=y -CONFIG_CMD_EFIDEBUG=y CONFIG_CMD_TIME=y CONFIG_CMD_TIMER=y CONFIG_CMD_PMIC=y @@ -150,7 +148,6 @@ CONFIG_BMP_32BPP=y CONFIG_WDT=y CONFIG_WDT_STM32MP=y CONFIG_ERRNO_STR=y -# CONFIG_HEXDUMP is not set CONFIG_FDT_FIXUP_PARTITIONS=y # CONFIG_LMB_USE_MAX_REGIONS is not set CONFIG_LMB_MEMORY_REGIONS=2 diff --git a/configs/tbs2910_defconfig b/configs/tbs2910_defconfig index e2e4db5c897..0f1e6d3b6b2 100644 --- a/configs/tbs2910_defconfig +++ b/configs/tbs2910_defconfig @@ -108,4 +108,3 @@ CONFIG_VIDEO_IPUV3=y CONFIG_VIDEO_BMP_RLE8=y # CONFIG_GZIP is not set CONFIG_OF_LIBFDT_ASSUME_MASK=0xff -# CONFIG_EFI_LOADER is not set diff --git a/configs/vf610twr_defconfig b/configs/vf610twr_defconfig index 24a7bdedf0a..1af5088430a 100644 --- a/configs/vf610twr_defconfig +++ b/configs/vf610twr_defconfig @@ -47,4 +47,3 @@ CONFIG_PHY_MICREL_KSZ8XXX=y CONFIG_MII=y CONFIG_DM_SERIAL=y CONFIG_FSL_LPUART=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/vf610twr_nand_defconfig b/configs/vf610twr_nand_defconfig index 7cf8ae66042..a41384fa360 100644 --- a/configs/vf610twr_nand_defconfig +++ b/configs/vf610twr_nand_defconfig @@ -47,4 +47,3 @@ CONFIG_PHY_MICREL_KSZ8XXX=y CONFIG_MII=y CONFIG_DM_SERIAL=y CONFIG_FSL_LPUART=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/xenguest_arm64_defconfig b/configs/xenguest_arm64_defconfig index e1707614979..929c249fa69 100644 --- a/configs/xenguest_arm64_defconfig +++ b/configs/xenguest_arm64_defconfig @@ -36,4 +36,3 @@ CONFIG_DM=y # CONFIG_MMC is not set # CONFIG_REQUIRE_SERIAL_CONSOLE is not set CONFIG_DM_SERIAL=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/xilinx_versal_mini_defconfig b/configs/xilinx_versal_mini_defconfig index 85d783c07cb..15c8264e8c1 100644 --- a/configs/xilinx_versal_mini_defconfig +++ b/configs/xilinx_versal_mini_defconfig @@ -56,4 +56,3 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y # CONFIG_MMC is not set CONFIG_ARM_DCC=y # CONFIG_GZIP is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/xilinx_versal_mini_emmc0_defconfig b/configs/xilinx_versal_mini_emmc0_defconfig index 8837987e35e..46577e65c4f 100644 --- a/configs/xilinx_versal_mini_emmc0_defconfig +++ b/configs/xilinx_versal_mini_emmc0_defconfig @@ -55,4 +55,3 @@ CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_ARM_DCC=y CONFIG_FAT_WRITE=y # CONFIG_GZIP is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/xilinx_versal_mini_emmc1_defconfig b/configs/xilinx_versal_mini_emmc1_defconfig index b07dc040607..1b751924cea 100644 --- a/configs/xilinx_versal_mini_emmc1_defconfig +++ b/configs/xilinx_versal_mini_emmc1_defconfig @@ -55,4 +55,3 @@ CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_ARM_DCC=y CONFIG_FAT_WRITE=y # CONFIG_GZIP is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/xilinx_versal_virt_defconfig b/configs/xilinx_versal_virt_defconfig index 121c3ae7205..cbd7adc0d63 100644 --- a/configs/xilinx_versal_virt_defconfig +++ b/configs/xilinx_versal_virt_defconfig @@ -19,7 +19,6 @@ CONFIG_USE_PREBOOT=y CONFIG_BOARD_EARLY_INIT_R=y CONFIG_SYS_PROMPT="Versal> " CONFIG_CMD_BOOTMENU=y -CONFIG_CMD_NVEDIT_EFI=y CONFIG_CMD_MEMTEST=y CONFIG_SYS_ALT_MEMTEST=y CONFIG_CMD_CLK=y @@ -34,7 +33,6 @@ CONFIG_CMD_SF_TEST=y CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y -CONFIG_CMD_EFIDEBUG=y CONFIG_CMD_TIME=y CONFIG_CMD_TIMER=y CONFIG_CMD_EXT4_WRITE=y diff --git a/configs/xilinx_zynqmp_mini_defconfig b/configs/xilinx_zynqmp_mini_defconfig index 64989db2917..ef04102b63a 100644 --- a/configs/xilinx_zynqmp_mini_defconfig +++ b/configs/xilinx_zynqmp_mini_defconfig @@ -56,4 +56,3 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ARM_DCC=y CONFIG_PANIC_HANG=y # CONFIG_GZIP is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/xilinx_zynqmp_mini_emmc0_defconfig b/configs/xilinx_zynqmp_mini_emmc0_defconfig index 4594f8096d3..9ffe45ca7be 100644 --- a/configs/xilinx_zynqmp_mini_emmc0_defconfig +++ b/configs/xilinx_zynqmp_mini_emmc0_defconfig @@ -60,4 +60,3 @@ CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_ARM_DCC=y CONFIG_PANIC_HANG=y # CONFIG_GZIP is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/xilinx_zynqmp_mini_emmc1_defconfig b/configs/xilinx_zynqmp_mini_emmc1_defconfig index d7c64b9da53..65148c37ccc 100644 --- a/configs/xilinx_zynqmp_mini_emmc1_defconfig +++ b/configs/xilinx_zynqmp_mini_emmc1_defconfig @@ -60,4 +60,3 @@ CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_ARM_DCC=y CONFIG_PANIC_HANG=y # CONFIG_GZIP is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/xilinx_zynqmp_mini_nand_defconfig b/configs/xilinx_zynqmp_mini_nand_defconfig index a61507ea7ae..024e567e7ff 100644 --- a/configs/xilinx_zynqmp_mini_nand_defconfig +++ b/configs/xilinx_zynqmp_mini_nand_defconfig @@ -56,4 +56,3 @@ CONFIG_SYS_NAND_MAX_CHIPS=2 CONFIG_ARM_DCC=y CONFIG_PANIC_HANG=y # CONFIG_GZIP is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/xilinx_zynqmp_mini_nand_single_defconfig b/configs/xilinx_zynqmp_mini_nand_single_defconfig index cd5f6de635f..56e6744bf29 100644 --- a/configs/xilinx_zynqmp_mini_nand_single_defconfig +++ b/configs/xilinx_zynqmp_mini_nand_single_defconfig @@ -55,4 +55,3 @@ CONFIG_NAND_ARASAN=y CONFIG_ARM_DCC=y CONFIG_PANIC_HANG=y # CONFIG_GZIP is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/xilinx_zynqmp_mini_qspi_defconfig b/configs/xilinx_zynqmp_mini_qspi_defconfig index 15cba60d535..3d525264019 100644 --- a/configs/xilinx_zynqmp_mini_qspi_defconfig +++ b/configs/xilinx_zynqmp_mini_qspi_defconfig @@ -65,4 +65,3 @@ CONFIG_SPI=y CONFIG_ZYNQMP_GQSPI=y CONFIG_PANIC_HANG=y # CONFIG_GZIP is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/xilinx_zynqmp_r5_defconfig b/configs/xilinx_zynqmp_r5_defconfig index f7433e994d3..051ea43e606 100644 --- a/configs/xilinx_zynqmp_r5_defconfig +++ b/configs/xilinx_zynqmp_r5_defconfig @@ -19,4 +19,3 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ZYNQ_SERIAL=y CONFIG_TIMER=y CONFIG_CADENCE_TTC_TIMER=y -# CONFIG_EFI_LOADER is not set diff --git a/configs/xilinx_zynqmp_virt_defconfig b/configs/xilinx_zynqmp_virt_defconfig index b0cc9d9ba88..3e1a30ad305 100644 --- a/configs/xilinx_zynqmp_virt_defconfig +++ b/configs/xilinx_zynqmp_virt_defconfig @@ -33,7 +33,6 @@ CONFIG_SPL_ATF=y CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y CONFIG_CMD_BOOTMENU=y CONFIG_CMD_THOR_DOWNLOAD=y -CONFIG_CMD_NVEDIT_EFI=y CONFIG_CMD_MEMTEST=y CONFIG_SYS_ALT_MEMTEST=y CONFIG_CMD_BIND=y @@ -57,7 +56,6 @@ CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_BMP=y CONFIG_CMD_CACHE=y -CONFIG_CMD_EFIDEBUG=y CONFIG_CMD_TIME=y CONFIG_CMD_GETTIME=y CONFIG_CMD_TIMER=y @@ -183,11 +181,4 @@ CONFIG_WDT_CDNS=y CONFIG_PANIC_HANG=y CONFIG_TPM=y CONFIG_SPL_GZIP=y -# CONFIG_SPL_HEXDUMP is not set CONFIG_OF_LIBFDT_OVERLAY=y -CONFIG_EFI_SET_TIME=y -CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y -CONFIG_EFI_CAPSULE_ON_DISK=y -CONFIG_EFI_CAPSULE_ON_DISK_EARLY=y -CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y -CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y diff --git a/configs/zynq_cse_nand_defconfig b/configs/zynq_cse_nand_defconfig index b36fd4a43c6..1ebc2451aa2 100644 --- a/configs/zynq_cse_nand_defconfig +++ b/configs/zynq_cse_nand_defconfig @@ -59,4 +59,3 @@ CONFIG_MTD_RAW_NAND=y CONFIG_NAND_ZYNQ=y CONFIG_ARM_DCC=y # CONFIG_GZIP is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/zynq_cse_nor_defconfig b/configs/zynq_cse_nor_defconfig index 3e614dfc86f..a1649306cce 100644 --- a/configs/zynq_cse_nor_defconfig +++ b/configs/zynq_cse_nor_defconfig @@ -62,4 +62,3 @@ CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y CONFIG_SYS_FLASH_CFI=y CONFIG_ARM_DCC=y # CONFIG_GZIP is not set -# CONFIG_EFI_LOADER is not set diff --git a/configs/zynq_cse_qspi_defconfig b/configs/zynq_cse_qspi_defconfig index 7cb1d6122d4..eb5175c147f 100644 --- a/configs/zynq_cse_qspi_defconfig +++ b/configs/zynq_cse_qspi_defconfig @@ -72,4 +72,3 @@ CONFIG_SPI_FLASH_WINBOND=y CONFIG_ARM_DCC=y CONFIG_ZYNQ_QSPI=y # CONFIG_GZIP is not set -# CONFIG_EFI_LOADER is not set diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 6242caceb7f..01e381e0e57 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,6 +1,6 @@ config EFI_LOADER bool "Support running UEFI applications" - depends on OF_LIBFDT && ( \ + depends on OF_LIBFDT && DM && OF_CONTROL && ( \ ARM && (SYS_CPU = arm1136 || \ SYS_CPU = arm1176 || \ SYS_CPU = armv7 || \ @@ -10,7 +10,8 @@ config EFI_LOADER depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT - default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8 + depends on !ARM || SYS_CPU = armv7 || SYS_CPU = armv8 + default y if SANDBOX select LIB_UUID select HAVE_BLOCK_DEVICE select REGEX
On 6/28/21 3:48 AM, Simon Glass wrote:
Add a new Kconfig option for EBBR so that the naming is more explicit. Make EFI_LOADER depend on it.
Avoid enabling the options (EBBR / EFI_LOADER) by default, to save space.
NAK
Operating systems like Fedora, OpenBSD, FreeBSD require UEFI support.
See discussion in https://lists.denx.de/pipermail/u-boot/2021-June/452947.html
Also add dependencies on driver model and OF_CONTROL, since boards which have not migrated to these should not be using new features like EBBR.
Only supporting devices using the driver model in the UEFI sub-system is fine with me. CONFIG_BLK=y is another possible requirement.
We still have 101 defconfigs not using CONFIG_DM=y. Shouldn't they be eliminated?
We have a low number of boards using CONFIG_DM=y and CONFIG_OF_CONTROL=n. Shouldn't they be moved to CONFIG_OF_CONTROL=y and that symbol be eliminated?
armadillo-800eva_defconfig cm_t335_defconfig colibri_pxa270_defconfig devkit3250_defconfig devkit8000_defconfig ids8313_defconfig integratorap_cm720t_defconfig integratorap_cm920t_defconfig integratorap_cm926ejs_defconfig integratorap_cm946es_defconfig integratorcp_cm1136_defconfig integratorcp_cm920t_defconfig integratorcp_cm926ejs_defconfig integratorcp_cm946es_defconfig kmcoge4_defconfig kzm9g_defconfig mx6memcal_defconfig nokia_rx51_defconfig snapper9260_defconfig snapper9g20_defconfig sniper_defconfig vexpress_aemv8a_semi_defconfig work_92105_defconfig xtfpga_defconfig
We have 274 defconfigs with CONFIG_PARTITIONS=y and CONFIG_BLK=n. Shouldn't they be converted or eliminated?
The unwillingness to use driver model has resulted in the duplication of driver model code in EFI, which is part of the reason for this bloat.
Could you, please, point out where you see possibilities for code reduction.
We started with a situation where many boards were not using the driver model. It is only this year that Tom started to eliminate boards that don't adher to the driver model in some areas.
The semantics used in UEFI and in the rest of U-Boot differ in many aspects. Here are some examples:
* partitions are handled in UEFI like sub-devices but the driver model does not cover partitions yet * to expose partitions UEFI requires fully probed block devices but U-Boot tries to probe upon first usage * UEFI uses file handles but U-Boot does not know this concept
Best regards
Heinrich
On Mon, Jun 28, 2021 at 11:48:00AM +0200, Heinrich Schuchardt wrote:
On 6/28/21 3:48 AM, Simon Glass wrote:
Add a new Kconfig option for EBBR so that the naming is more explicit. Make EFI_LOADER depend on it.
Avoid enabling the options (EBBR / EFI_LOADER) by default, to save space.
NAK
Operating systems like Fedora, OpenBSD, FreeBSD require UEFI support.
See discussion in https://lists.denx.de/pipermail/u-boot/2021-June/452947.html
I also think this is taking things in the wrong direction. It was an intentional "make EFI_LOADER default when supported" when we introduced it, and I still think that's the right overall choice. There's a whole lot of non-customization going on when reference designs are converted to products or other reference designs.
Also add dependencies on driver model and OF_CONTROL, since boards which have not migrated to these should not be using new features like EBBR.
Only supporting devices using the driver model in the UEFI sub-system is fine with me. CONFIG_BLK=y is another possible requirement.
Adding these would be good. And may allow for the code to be simplified?
We still have 101 defconfigs not using CONFIG_DM=y. Shouldn't they be eliminated?
They will be eliminated after v2022.01, following the same 2 years of "the deadline has passed" that's being used by the board removals I've been posting so far this year.
We have a low number of boards using CONFIG_DM=y and CONFIG_OF_CONTROL=n. Shouldn't they be moved to CONFIG_OF_CONTROL=y and that symbol be eliminated?
No, we don't require OF_CONTROL intentionally so that other smaller mechanisms can be used.
[snip]
We have 274 defconfigs with CONFIG_PARTITIONS=y and CONFIG_BLK=n. Shouldn't they be converted or eliminated?
Some number of them will be, I think there's one or two actual funny cases on how that code is used however.
From: Simon Glass sjg@chromium.org Date: Sun, 27 Jun 2021 19:48:34 -0600
It has come to light that EFI_LOADER adds an extraordinary amount of code to U-Boot. For example, with nokia_rx51 the size delta is about 90KB. About 170 boards explicitly disable the option, but is is clear that many more could, thus saving image size and boot time.
EFI_LOADER used to be a lot smaller. It is great to see that over the years UEFI support has become more complete, but a lot of that new code implements features that are not at all essential for just booting an OS from storage. If that growth leads to the suggestion to disable EFI_LOADER completely by default, we're putting the cart before the horse.
The current situation is affecting U-Boot's image as a svelt bootloader.
Really? I know UEFI has a bad reputation in the Open Source world, and some of its Microsoft-isms are really annoying (yay UCS-2). But it works, it provides a standardized approach across several platforms (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally I'd wish the industry had standardized on Open Firmware instead, but that ship sailed a long time ago...
I find it hard to imagine that 90k is a serious amount of storage for something that is going to include a multi-MB Linux kernel. This isn't code that lives in SPL or TPL where severe size restrictions apply.
EFI_LOADER is required by EBBR, a new boot standard which aims to bring in UEFI protocols to U-Boot. But EBRR is not required for booting. U-Boot already provides support for FIT, the 'bootm' command and a suitable hand-off to Linux. EBRR has made the decision to create a parallel infrastructure, e.g. does not use FIT, nor U-Boot's signing infrastructure.
EFI_LOADER is required to boot FreeBSD and OpenBSD on several platforms as well as generic Linux distros. For example OpenBSD/armv7, OpenBSD/arm64 and OpenBSD/riscv64 all rely on EFI_LOADER to boot and have done so for the last 4 years. The fact that ARM has embraced UEFI as an embedded boot standard and branded it EBBR really isn't all that relevant.
FIT simply isn't fit for purpose (pun intended). It only really works for booting Linux, and forces people to combine u-boot, kernel, initial ramdisk and other firmware components into a single image. That is really undesirable as:
- This makes it sigificantly harder to update individual components of such an image. Making it hard to update a kernel is obviously a serious security risk.
- This makes it impossible to build an OS install image that works om multiple boards/SoCs.
EBBR should be truly optional, enabled only by boards that use it. Most don't use it but it is enabled anyway. The default boot path should be one that makes use of the existing U-Boot support.
I don't particularly care about EBBR myself, but EFI_LOADER should be the default for as many armv7/arm64/riscv U-Boot targets as possible to give users an easy way to choose the OS they want to run on their machines. That is the best way to guarantee that vendors ship their firmware with it enabled.
To try to retify this situation, this series adds a new Kconfig option for EBBR so that the naming is more explicit. Then EFI_LOADER is updated to depend on it.
Isn't using the the term EBBR for non-ARM platforms misleading? EFI_LOADER is used much more widely. Anyway, I disagree with this direction.
If size really matters here, we should look at reducing the EFI_LOADER feature set to reduce the amount of code i adds, and maybe introduce an EBBR option that can be enabled by those boards that desire full EBBR compliance?
For now, only sandbox enables EBBR. Other boards can be added as needed, presumably by distributions that require it. Another approach would be to add 'CONFIG_EBBR=y' to the .config before building, in the build system. That might be more friendly to U-Boot users.
This series also fixes a minor issue noticed during testing.
Simon Glass (7): configs: Resync with savedefconfig Makefile: Drop include/asm directory as well as symlink disk: Tidy up #ifdefs in part_efi Use LIB_UUID with ACPIGEN and FS_BTRFS Allow efi_loader header to be included always lib: Create a new Kconfig option for charset conversion efi: Make EBBR optional
Makefile | 2 +- common/Kconfig.boot | 15 ++ configs/am335x_igep003x_defconfig | 1 - configs/am335x_pdu001_defconfig | 1 - configs/am64x_evm_a53_defconfig | 31 ++- configs/am64x_evm_r5_defconfig | 6 +- configs/apalis-imx8_defconfig | 1 - configs/apalis-imx8x_defconfig | 1 - configs/aristainetos2c_defconfig | 1 - configs/aristainetos2ccslb_defconfig | 1 - ...edev_cc_v1_0_ultrazedev_som_v1_0_defconfig | 1 - configs/bcm7260_defconfig | 1 - configs/bcm7445_defconfig | 1 - configs/bcm963158_ram_defconfig | 1 - configs/bcm968580xref_ram_defconfig | 1 - configs/bitmain_antminer_s9_defconfig | 1 - configs/bk4r1_defconfig | 1 - configs/brppt1_mmc_defconfig | 1 - configs/brppt1_nand_defconfig | 1 - configs/brppt1_spi_defconfig | 1 - configs/brppt2_defconfig | 1 - configs/brsmarc1_defconfig | 1 - configs/brxre1_defconfig | 1 - configs/chromebook_coral_defconfig | 1 - configs/chromebook_link_defconfig | 1 - configs/colibri-imx8x_defconfig | 1 - configs/colibri_vf_defconfig | 1 - configs/controlcenterdc_defconfig | 1 - configs/crs305-1g-4s-bit_defconfig | 1 - configs/crs305-1g-4s_defconfig | 1 - configs/crs326-24g-2s-bit_defconfig | 1 - configs/crs326-24g-2s_defconfig | 1 - configs/crs328-4c-20s-4s-bit_defconfig | 1 - configs/crs328-4c-20s-4s_defconfig | 1 - configs/deneb_defconfig | 1 - configs/draco_defconfig | 2 +- configs/dragonboard820c_defconfig | 1 - configs/efi-x86_app_defconfig | 1 - configs/etamin_defconfig | 2 +- configs/evb-ast2600_defconfig | 1 - configs/evb-px30_defconfig | 1 - configs/evb-rk3308_defconfig | 1 - configs/firefly-px30_defconfig | 1 - configs/ge_bx50v3_defconfig | 1 - configs/giedi_defconfig | 1 - configs/grpeach_defconfig | 1 - configs/imx8mm-cl-iot-gate_defconfig | 8 - configs/imx8qm_mek_defconfig | 1 - configs/imx8qm_rom7720_a1_4G_defconfig | 1 - configs/imx8qxp_mek_defconfig | 1 - configs/j7200_evm_r5_defconfig | 15 +- configs/j721e_evm_r5_defconfig | 13 +- configs/kontron_sl28_defconfig | 2 - configs/kp_imx53_defconfig | 1 - configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1028aqds_tfa_defconfig | 1 - configs/ls1028aqds_tfa_lpuart_defconfig | 1 - configs/ls1028ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1028ardb_tfa_defconfig | 1 - configs/ls1043aqds_defconfig | 1 - configs/ls1043aqds_lpuart_defconfig | 1 - configs/ls1043aqds_nand_defconfig | 1 - configs/ls1043aqds_nor_ddr3_defconfig | 1 - configs/ls1043aqds_qspi_defconfig | 1 - configs/ls1043aqds_sdcard_ifc_defconfig | 1 - configs/ls1043aqds_sdcard_qspi_defconfig | 1 - configs/ls1043aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1043aqds_tfa_defconfig | 1 - configs/ls1043ardb_SECURE_BOOT_defconfig | 1 - configs/ls1043ardb_defconfig | 1 - configs/ls1043ardb_nand_SECURE_BOOT_defconfig | 1 - configs/ls1043ardb_nand_defconfig | 1 - .../ls1043ardb_sdcard_SECURE_BOOT_defconfig | 1 - configs/ls1043ardb_sdcard_defconfig | 1 - configs/ls1043ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1043ardb_tfa_defconfig | 1 - configs/ls1046aqds_SECURE_BOOT_defconfig | 1 - configs/ls1046aqds_defconfig | 1 - configs/ls1046aqds_lpuart_defconfig | 1 - configs/ls1046aqds_nand_defconfig | 1 - configs/ls1046aqds_qspi_defconfig | 1 - configs/ls1046aqds_sdcard_ifc_defconfig | 1 - configs/ls1046aqds_sdcard_qspi_defconfig | 1 - configs/ls1046aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1046aqds_tfa_defconfig | 1 - configs/ls1046ardb_emmc_defconfig | 1 - configs/ls1046ardb_qspi_SECURE_BOOT_defconfig | 1 - configs/ls1046ardb_qspi_defconfig | 1 - configs/ls1046ardb_qspi_spl_defconfig | 1 - .../ls1046ardb_sdcard_SECURE_BOOT_defconfig | 1 - configs/ls1046ardb_sdcard_defconfig | 1 - configs/ls1046ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1046ardb_tfa_defconfig | 1 - configs/ls1088aqds_qspi_SECURE_BOOT_defconfig | 1 - configs/ls1088aqds_qspi_defconfig | 1 - configs/ls1088aqds_tfa_defconfig | 1 - configs/ls1088ardb_qspi_SECURE_BOOT_defconfig | 1 - configs/ls1088ardb_qspi_defconfig | 1 - configs/ls1088ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1088ardb_tfa_defconfig | 1 - configs/ls2080aqds_SECURE_BOOT_defconfig | 1 - configs/ls2080aqds_defconfig | 1 - configs/ls2080aqds_nand_defconfig | 1 - configs/ls2080aqds_qspi_defconfig | 1 - configs/ls2080aqds_sdcard_defconfig | 1 - configs/ls2080ardb_SECURE_BOOT_defconfig | 1 - configs/ls2080ardb_defconfig | 1 - configs/ls2080ardb_nand_defconfig | 1 - configs/ls2081ardb_defconfig | 1 - configs/ls2088aqds_tfa_defconfig | 1 - configs/ls2088ardb_qspi_SECURE_BOOT_defconfig | 1 - configs/ls2088ardb_qspi_defconfig | 1 - configs/ls2088ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls2088ardb_tfa_defconfig | 1 - configs/lx2160aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/lx2160aqds_tfa_defconfig | 1 - configs/lx2160ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/lx2160ardb_tfa_defconfig | 1 - configs/lx2160ardb_tfa_stmm_defconfig | 4 - configs/lx2162aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/lx2162aqds_tfa_defconfig | 1 - .../lx2162aqds_tfa_verified_boot_defconfig | 1 - configs/mt7623n_bpir2_defconfig | 1 - configs/mt7629_rfb_defconfig | 1 - configs/mt8183_pumpkin_defconfig | 1 - configs/mt8516_pumpkin_defconfig | 1 - configs/mvebu_puzzle-m801-88f8040_defconfig | 1 - configs/mx6memcal_defconfig | 1 - configs/octeontx2_95xx_defconfig | 1 - configs/octeontx2_96xx_defconfig | 1 - configs/octeontx_81xx_defconfig | 1 - configs/octeontx_83xx_defconfig | 1 - configs/omap4_sdp4430_defconfig | 1 - configs/opos6uldev_defconfig | 1 - configs/pcm052_defconfig | 1 - configs/phycore-am335x-r2-regor_defconfig | 1 - configs/phycore-am335x-r2-wega_defconfig | 1 - configs/pxm2_defconfig | 2 +- configs/qemu-riscv32_defconfig | 2 - configs/qemu-riscv32_smode_defconfig | 2 - configs/qemu-riscv64_defconfig | 2 - configs/qemu-riscv64_smode_defconfig | 2 - configs/qemu-x86_64_defconfig | 2 - configs/qemu-x86_defconfig | 2 - configs/qemu_arm64_defconfig | 2 - configs/qemu_arm_defconfig | 2 - configs/rastaban_defconfig | 2 +- configs/roc-cc-rk3308_defconfig | 1 - configs/rock-pi-n10-rk3399pro_defconfig | 1 - configs/rock-pi-n8-rk3288_defconfig | 1 - configs/rpi_0_w_defconfig | 1 - configs/rpi_defconfig | 1 - configs/rut_defconfig | 2 +- configs/sama5d27_wlsom1_ek_mmc_defconfig | 1 - .../sama5d27_wlsom1_ek_qspiflash_defconfig | 1 - configs/sama5d2_icp_mmc_defconfig | 1 - configs/sama7g5ek_mmc1_defconfig | 1 - configs/sama7g5ek_mmc_defconfig | 1 - configs/sipeed_maix_bitm_defconfig | 1 - configs/sipeed_maix_smode_defconfig | 1 - configs/socfpga_de1_soc_defconfig | 1 - configs/somlabs_visionsom_6ull_defconfig | 1 - configs/stemmy_defconfig | 1 - configs/stm32mp15_basic_defconfig | 3 - configs/stm32mp15_trusted_defconfig | 3 - configs/tbs2910_defconfig | 1 - configs/thuban_defconfig | 2 +- configs/vf610twr_defconfig | 1 - configs/vf610twr_nand_defconfig | 1 - configs/xenguest_arm64_defconfig | 1 - configs/xilinx_versal_mini_defconfig | 1 - configs/xilinx_versal_mini_emmc0_defconfig | 1 - configs/xilinx_versal_mini_emmc1_defconfig | 1 - configs/xilinx_versal_virt_defconfig | 2 - configs/xilinx_zynqmp_mini_defconfig | 1 - configs/xilinx_zynqmp_mini_emmc0_defconfig | 1 - configs/xilinx_zynqmp_mini_emmc1_defconfig | 1 - configs/xilinx_zynqmp_mini_nand_defconfig | 1 - .../xilinx_zynqmp_mini_nand_single_defconfig | 1 - configs/xilinx_zynqmp_mini_qspi_defconfig | 1 - configs/xilinx_zynqmp_r5_defconfig | 1 - configs/xilinx_zynqmp_virt_defconfig | 9 - configs/zynq_cse_nand_defconfig | 1 - configs/zynq_cse_nor_defconfig | 1 - configs/zynq_cse_qspi_defconfig | 1 - disk/part_efi.c | 11 +- drivers/core/Kconfig | 1 + fs/btrfs/Kconfig | 1 + include/efi_loader.h | 186 +++++++++--------- lib/Kconfig | 8 + lib/Makefile | 2 +- lib/efi_loader/Kconfig | 5 +- 192 files changed, 160 insertions(+), 353 deletions(-)
-- 2.32.0.93.g670b81a890-goog
I generally agree with Mark here.
On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Sun, 27 Jun 2021 19:48:34 -0600
It has come to light that EFI_LOADER adds an extraordinary amount of code to U-Boot. For example, with nokia_rx51 the size delta is about 90KB. About 170 boards explicitly disable the option, but is is clear that many more could, thus saving image size and boot time.
EFI_LOADER used to be a lot smaller. It is great to see that over the years UEFI support has become more complete, but a lot of that new code implements features that are not at all essential for just booting an OS from storage. If that growth leads to the suggestion to disable EFI_LOADER completely by default, we're putting the cart before the horse.
The current situation is affecting U-Boot's image as a svelt bootloader.
Really? I know UEFI has a bad reputation in the Open Source world, and some of its Microsoft-isms are really annoying (yay UCS-2). But it works, it provides a standardized approach across several platforms (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally I'd wish the industry had standardized on Open Firmware instead, but that ship sailed a long time ago...
I think the basics of EFI (mostly those that EBBR requires) are sane and nice to boot multiple architectures as well.
I find it hard to imagine that 90k is a serious amount of storage for something that is going to include a multi-MB Linux kernel. This isn't code that lives in SPL or TPL where severe size restrictions apply.
EFI_LOADER is required by EBBR, a new boot standard which aims to bring in UEFI protocols to U-Boot. But EBRR is not required for booting. U-Boot already provides support for FIT, the 'bootm' command and a suitable hand-off to Linux. EBRR has made the decision to create a parallel infrastructure, e.g. does not use FIT, nor U-Boot's signing infrastructure.
EFI_LOADER is required to boot FreeBSD and OpenBSD on several platforms as well as generic Linux distros. For example OpenBSD/armv7, OpenBSD/arm64 and OpenBSD/riscv64 all rely on EFI_LOADER to boot and have done so for the last 4 years. The fact that ARM has embraced UEFI as an embedded boot standard and branded it EBBR really isn't all that relevant.
FIT simply isn't fit for purpose (pun intended). It only really works for booting Linux, and forces people to combine u-boot, kernel, initial ramdisk and other firmware components into a single image. That is really undesirable as:
This makes it sigificantly harder to update individual components of such an image. Making it hard to update a kernel is obviously a serious security risk.
This makes it impossible to build an OS install image that works om multiple boards/SoCs.
EBBR should be truly optional, enabled only by boards that use it. Most don't use it but it is enabled anyway. The default boot path should be one that makes use of the existing U-Boot support.
I don't particularly care about EBBR myself, but EFI_LOADER should be the default for as many armv7/arm64/riscv U-Boot targets as possible to give users an easy way to choose the OS they want to run on their machines. That is the best way to guarantee that vendors ship their firmware with it enabled.
To try to retify this situation, this series adds a new Kconfig option for EBBR so that the naming is more explicit. Then EFI_LOADER is updated to depend on it.
Isn't using the the term EBBR for non-ARM platforms misleading?
Not really, we are discussing with RISC-V atm and having platfomrs being EBBR compliant. In essence we don't desire EBBR to be an Arm only thing.
EFI_LOADER is used much more widely. Anyway, I disagree with this direction.
Same here
If size really matters here, we should look at reducing the EFI_LOADER feature set to reduce the amount of code i adds, and maybe introduce an EBBR option that can be enabled by those boards that desire full EBBR compliance?
+1
[...]
On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Sun, 27 Jun 2021 19:48:34 -0600
It has come to light that EFI_LOADER adds an extraordinary amount of code to U-Boot. For example, with nokia_rx51 the size delta is about 90KB. About 170 boards explicitly disable the option, but is is clear that many more could, thus saving image size and boot time.
EFI_LOADER used to be a lot smaller. It is great to see that over the years UEFI support has become more complete, but a lot of that new code implements features that are not at all essential for just booting an OS from storage. If that growth leads to the suggestion to disable EFI_LOADER completely by default, we're putting the cart before the horse.
Well, I see I forgot to prefix my patch with RFC, but I hadn't found EFI_LOADER being used in the wild on armv7, but wasn't sure about the BSD families. I did see that Debian doesn't use it, and that Armbian doesn't even use it on aarch64.
The current situation is affecting U-Boot's image as a svelt bootloader.
Really? I know UEFI has a bad reputation in the Open Source world, and some of its Microsoft-isms are really annoying (yay UCS-2). But it works, it provides a standardized approach across several platforms (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally I'd wish the industry had standardized on Open Firmware instead, but that ship sailed a long time ago...
I find it hard to imagine that 90k is a serious amount of storage for something that is going to include a multi-MB Linux kernel. This isn't code that lives in SPL or TPL where severe size restrictions apply.
In one of those cases where I need to pop back in to the other (Nokia N900 specific) thread and see if the big size reduction really was just disabling EFI_LOADER, it's perhaps just one of those "fun" things about Kconfig and anything other than "make oldconfig" for spotting new config options that default to enabled.
EFI_LOADER is required by EBBR, a new boot standard which aims to bring in UEFI protocols to U-Boot. But EBRR is not required for booting. U-Boot already provides support for FIT, the 'bootm' command and a suitable hand-off to Linux. EBRR has made the decision to create a parallel infrastructure, e.g. does not use FIT, nor U-Boot's signing infrastructure.
EFI_LOADER is required to boot FreeBSD and OpenBSD on several platforms as well as generic Linux distros. For example OpenBSD/armv7, OpenBSD/arm64 and OpenBSD/riscv64 all rely on EFI_LOADER to boot and have done so for the last 4 years. The fact that ARM has embraced UEFI as an embedded boot standard and branded it EBBR really isn't all that relevant.
To be clear here, I like EFI_LOADER. I too do wish some other technologies had become dominant for technical rather than inertia reasons, but here we are. Having played around with it on aarch64, there are some pretty nice comes-along-with parts to it.
What I hadn't seen, and am only a little skeptical of still, is how far backwards in generations it's going to be used on. The general wish is that users nor off the shelf OS groups need to rebuild U-Boot for a given board, and instead it just works. The number of new designs for 32bit parts is no where near the number of new designs for 64bit parts. So what we're seeing in U-Boot now is people updating support on their older designs, and not necessarily caring about using EFI_LOADER.
Hi Tom, Mark,
On Mon, 28 Jun 2021 at 07:37, Tom Rini trini@konsulko.com wrote:
On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Sun, 27 Jun 2021 19:48:34 -0600
It has come to light that EFI_LOADER adds an extraordinary amount of code to U-Boot. For example, with nokia_rx51 the size delta is about 90KB. About 170 boards explicitly disable the option, but is is clear that many more could, thus saving image size and boot time.
EFI_LOADER used to be a lot smaller. It is great to see that over the years UEFI support has become more complete, but a lot of that new code implements features that are not at all essential for just booting an OS from storage. If that growth leads to the suggestion to disable EFI_LOADER completely by default, we're putting the cart before the horse.
Well, I see I forgot to prefix my patch with RFC, but I hadn't found EFI_LOADER being used in the wild on armv7, but wasn't sure about the BSD families. I did see that Debian doesn't use it, and that Armbian doesn't even use it on aarch64.
The current situation is affecting U-Boot's image as a svelt bootloader.
Really? I know UEFI has a bad reputation in the Open Source world, and some of its Microsoft-isms are really annoying (yay UCS-2). But it works, it provides a standardized approach across several platforms (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally I'd wish the industry had standardized on Open Firmware instead, but that ship sailed a long time ago...
I find it hard to imagine that 90k is a serious amount of storage for something that is going to include a multi-MB Linux kernel. This isn't code that lives in SPL or TPL where severe size restrictions apply.
In one of those cases where I need to pop back in to the other (Nokia N900 specific) thread and see if the big size reduction really was just disabling EFI_LOADER, it's perhaps just one of those "fun" things about Kconfig and anything other than "make oldconfig" for spotting new config options that default to enabled.
Yes it will be interesting to see what you find there. My results on nokia_rx51 were something like this:
default arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0 rodata +10989.0 text +109846.0
without ebbr arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 rodata +5333.0 text +29712.0
with various other things: CONFIG_OF_LIBFDT_ASSUME_MASK=7 # CONFIG_OF_TRANSLATE is not set # CONFIG_SIMPLE_BUS is not set # CONFIG_TI_SYSC is not set # CONFIG_CMD_FDT is not set
arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rodata +3274.0 text +15552.0
(Mark, in the same email:)
FIT simply isn't fit for purpose (pun intended). It only really works for booting Linux, and forces people to combine u-boot, kernel, initial ramdisk and other firmware components into a single image. That is really undesirable as:
- This makes it sigificantly harder to update individual components of such an image. Making it hard to update a kernel is obviously a serious security risk.
- This makes it impossible to build an OS install image that works om multiple boards/SoCs.
I would really like to understand this better. The whole thing is a complete mystery to me.
Firstly I have sometimes fiddled with booting other OSes using FIT. It seemed OK. I can't see why it only works with Linux.
Secondly, I don't expect that U-Boot itself would be in the FIT.
Thirdly, do you really want the kernel and initrd to be separate? At least in the systems I have used, they are built together, even having the same name, e.g.:
initrd.img-5.10.40-1rodete1-amd64 System.map-5.10.40-1rodete1-amd64 vmlinuz-5.10.28-1rodete2-amd64
Finally, for the firmware components, do you mean system firmware? If so, I would expect it to be more convenient to distribute updates to that separately, although I suppose they could be combined with the kernel if the combinatorial explosion can be contained. What is the problem, exactly? (If you mean peripheral firmware, I would expect fwupd to handle that.)
What exactly is impossible? Can you please be more specific?
FIT is just a container. It seems to have been rejected by the EFI crew at some point. Perhaps I just need to try to use it with one of the distros out there, to actually understand what is going on here. But any help is appreciated.
EFI_LOADER is required by EBBR, a new boot standard which aims to bring in UEFI protocols to U-Boot. But EBRR is not required for booting. U-Boot already provides support for FIT, the 'bootm' command and a suitable hand-off to Linux. EBRR has made the decision to create a parallel infrastructure, e.g. does not use FIT, nor U-Boot's signing infrastructure.
EFI_LOADER is required to boot FreeBSD and OpenBSD on several platforms as well as generic Linux distros. For example OpenBSD/armv7, OpenBSD/arm64 and OpenBSD/riscv64 all rely on EFI_LOADER to boot and have done so for the last 4 years. The fact that ARM has embraced UEFI as an embedded boot standard and branded it EBBR really isn't all that relevant.
To be clear here, I like EFI_LOADER. I too do wish some other technologies had become dominant for technical rather than inertia reasons, but here we are. Having played around with it on aarch64, there are some pretty nice comes-along-with parts to it.
What I hadn't seen, and am only a little skeptical of still, is how far backwards in generations it's going to be used on. The general wish is that users nor off the shelf OS groups need to rebuild U-Boot for a given board, and instead it just works. The number of new designs for 32bit parts is no where near the number of new designs for 64bit parts. So what we're seeing in U-Boot now is people updating support on their older designs, and not necessarily caring about using EFI_LOADER.
In a reply to one of the patches in this series, Heinrich mentions a few problems that need resolving (devices for partitions and file handles). Both of those features should first be added to U-Boot, so EFI can then use that support. In general, EFI has tried to work beside driver model, creating its own parallel tables, etc. I have tried to influence this at various points along the way, including at the start and I'm happy to dig out those threads if it helps. But I wasn't kidding. it really needs to be addressed. I would love to see Linaro (for example) organise something here and take this on. I am very happy to help.
Regards, Simon
On 6/28/21 4:18 PM, Simon Glass wrote:
Hi Tom, Mark,
On Mon, 28 Jun 2021 at 07:37, Tom Rini trini@konsulko.com wrote:
On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Sun, 27 Jun 2021 19:48:34 -0600
It has come to light that EFI_LOADER adds an extraordinary amount of code to U-Boot. For example, with nokia_rx51 the size delta is about 90KB. About 170 boards explicitly disable the option, but is is clear that many more could, thus saving image size and boot time.
EFI_LOADER used to be a lot smaller. It is great to see that over the years UEFI support has become more complete, but a lot of that new code implements features that are not at all essential for just booting an OS from storage. If that growth leads to the suggestion to disable EFI_LOADER completely by default, we're putting the cart before the horse.
Well, I see I forgot to prefix my patch with RFC, but I hadn't found EFI_LOADER being used in the wild on armv7, but wasn't sure about the BSD families. I did see that Debian doesn't use it, and that Armbian doesn't even use it on aarch64.
The current situation is affecting U-Boot's image as a svelt bootloader.
Really? I know UEFI has a bad reputation in the Open Source world, and some of its Microsoft-isms are really annoying (yay UCS-2). But it works, it provides a standardized approach across several platforms (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally I'd wish the industry had standardized on Open Firmware instead, but that ship sailed a long time ago...
I find it hard to imagine that 90k is a serious amount of storage for something that is going to include a multi-MB Linux kernel. This isn't code that lives in SPL or TPL where severe size restrictions apply.
In one of those cases where I need to pop back in to the other (Nokia N900 specific) thread and see if the big size reduction really was just disabling EFI_LOADER, it's perhaps just one of those "fun" things about Kconfig and anything other than "make oldconfig" for spotting new config options that default to enabled.
Yes it will be interesting to see what you find there. My results on nokia_rx51 were something like this:
default arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0 rodata +10989.0 text +109846.0
without ebbr arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 rodata +5333.0 text +29712.0
with various other things: CONFIG_OF_LIBFDT_ASSUME_MASK=7 # CONFIG_OF_TRANSLATE is not set # CONFIG_SIMPLE_BUS is not set # CONFIG_TI_SYSC is not set # CONFIG_CMD_FDT is not set
arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rodata+3274.0 text +15552.0
(Mark, in the same email:)
FIT simply isn't fit for purpose (pun intended). It only really works for booting Linux, and forces people to combine u-boot, kernel, initial ramdisk and other firmware components into a single image. That is really undesirable as:
- This makes it sigificantly harder to update individual components of such an image. Making it hard to update a kernel is obviously a serious security risk.
- This makes it impossible to build an OS install image that works om multiple boards/SoCs.
I would really like to understand this better. The whole thing is a complete mystery to me.
Firstly I have sometimes fiddled with booting other OSes using FIT. It seemed OK. I can't see why it only works with Linux.
Secondly, I don't expect that U-Boot itself would be in the FIT.
Thirdly, do you really want the kernel and initrd to be separate? At least in the systems I have used, they are built together, even having the same name, e.g.:
initrd.img-5.10.40-1rodete1-amd64 System.map-5.10.40-1rodete1-amd64 vmlinuz-5.10.28-1rodete2-amd64
I have not hit any distro that builds FIT images. All install vmlinux and initrd as separate files.
Why would you want to change that?
Finally, for the firmware components, do you mean system firmware? If so, I would expect it to be more convenient to distribute updates to that separately, although I suppose they could be combined with the kernel if the combinatorial explosion can be contained. What is the problem, exactly? (If you mean peripheral firmware, I would expect fwupd to handle that.)
What exactly is impossible? Can you please be more specific?
FIT is just a container. It seems to have been rejected by the EFI crew at some point. Perhaps I just need to try to use it with one of the distros out there, to actually understand what is going on here. But any help is appreciated.
FIT and EFI are orthogonal. A FIT image can contain an EFI binary. See CONFIG_BOOTM_EFI.
EFI_LOADER is required by EBBR, a new boot standard which aims to bring in UEFI protocols to U-Boot. But EBRR is not required for booting. U-Boot already provides support for FIT, the 'bootm' command and a suitable hand-off to Linux. EBRR has made the decision to create a parallel infrastructure, e.g. does not use FIT, nor U-Boot's signing infrastructure.
EFI_LOADER is required to boot FreeBSD and OpenBSD on several platforms as well as generic Linux distros. For example OpenBSD/armv7, OpenBSD/arm64 and OpenBSD/riscv64 all rely on EFI_LOADER to boot and have done so for the last 4 years. The fact that ARM has embraced UEFI as an embedded boot standard and branded it EBBR really isn't all that relevant.
To be clear here, I like EFI_LOADER. I too do wish some other technologies had become dominant for technical rather than inertia reasons, but here we are. Having played around with it on aarch64, there are some pretty nice comes-along-with parts to it.
What I hadn't seen, and am only a little skeptical of still, is how far backwards in generations it's going to be used on. The general wish is that users nor off the shelf OS groups need to rebuild U-Boot for a given board, and instead it just works. The number of new designs for 32bit parts is no where near the number of new designs for 64bit parts. So what we're seeing in U-Boot now is people updating support on their older designs, and not necessarily caring about using EFI_LOADER.
In a reply to one of the patches in this series, Heinrich mentions a few problems that need resolving (devices for partitions and file handles). Both of those features should first be added to U-Boot, so EFI can then use that support. In general, EFI has tried to work beside driver model, creating its own parallel tables, etc.
Could you, please, be a bit more specific. Please, indicate which data structures you would like to integrate into the driver model.
EDK II shows that a driver model completely based on UEFI protocols is possible. As long as we don't follow that road we will have separate APIs for the UEFI world and U-Boot's internal use and we will have to keep track of objects that exist only in the one world or the other.
What we definitively need is a better integration between probing and removing U-Boot devices and their representation in the UEFI world.
Another area that might deserve attention is memory allocation. AllocatePool() consuming whole memory pages is quite a waste.
I have tried to influence this at various points along the way, including at the start and I'm happy to dig out those threads if it helps. But I wasn't kidding. it really needs to be addressed. I would love to see Linaro (for example) organise something here and take this on. I am very happy to help.
The starting point would be comparing the DM and UEFI object models and pointing out which objects can be mapped and which cannot.
Best regards
Heinrich
Hi Heinrich,
On Mon, 28 Jun 2021 at 09:20, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 6/28/21 4:18 PM, Simon Glass wrote:
Hi Tom, Mark,
On Mon, 28 Jun 2021 at 07:37, Tom Rini trini@konsulko.com wrote:
On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Sun, 27 Jun 2021 19:48:34 -0600
It has come to light that EFI_LOADER adds an extraordinary amount of code to U-Boot. For example, with nokia_rx51 the size delta is about 90KB. About 170 boards explicitly disable the option, but is is clear that many more could, thus saving image size and boot time.
EFI_LOADER used to be a lot smaller. It is great to see that over the years UEFI support has become more complete, but a lot of that new code implements features that are not at all essential for just booting an OS from storage. If that growth leads to the suggestion to disable EFI_LOADER completely by default, we're putting the cart before the horse.
Well, I see I forgot to prefix my patch with RFC, but I hadn't found EFI_LOADER being used in the wild on armv7, but wasn't sure about the BSD families. I did see that Debian doesn't use it, and that Armbian doesn't even use it on aarch64.
The current situation is affecting U-Boot's image as a svelt bootloader.
Really? I know UEFI has a bad reputation in the Open Source world, and some of its Microsoft-isms are really annoying (yay UCS-2). But it works, it provides a standardized approach across several platforms (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally I'd wish the industry had standardized on Open Firmware instead, but that ship sailed a long time ago...
I find it hard to imagine that 90k is a serious amount of storage for something that is going to include a multi-MB Linux kernel. This isn't code that lives in SPL or TPL where severe size restrictions apply.
In one of those cases where I need to pop back in to the other (Nokia N900 specific) thread and see if the big size reduction really was just disabling EFI_LOADER, it's perhaps just one of those "fun" things about Kconfig and anything other than "make oldconfig" for spotting new config options that default to enabled.
Yes it will be interesting to see what you find there. My results on nokia_rx51 were something like this:
default arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0 rodata +10989.0 text +109846.0
without ebbr arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 rodata +5333.0 text +29712.0
with various other things: CONFIG_OF_LIBFDT_ASSUME_MASK=7 # CONFIG_OF_TRANSLATE is not set # CONFIG_SIMPLE_BUS is not set # CONFIG_TI_SYSC is not set # CONFIG_CMD_FDT is not set
arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rodata+3274.0 text +15552.0
(Mark, in the same email:)
FIT simply isn't fit for purpose (pun intended). It only really works for booting Linux, and forces people to combine u-boot, kernel, initial ramdisk and other firmware components into a single image. That is really undesirable as:
- This makes it sigificantly harder to update individual components of such an image. Making it hard to update a kernel is obviously a serious security risk.
- This makes it impossible to build an OS install image that works om multiple boards/SoCs.
I would really like to understand this better. The whole thing is a complete mystery to me.
Firstly I have sometimes fiddled with booting other OSes using FIT. It seemed OK. I can't see why it only works with Linux.
Secondly, I don't expect that U-Boot itself would be in the FIT.
Thirdly, do you really want the kernel and initrd to be separate? At least in the systems I have used, they are built together, even having the same name, e.g.:
initrd.img-5.10.40-1rodete1-amd64 System.map-5.10.40-1rodete1-amd64 vmlinuz-5.10.28-1rodete2-amd64
I have not hit any distro that builds FIT images. All install vmlinux and initrd as separate files.
Why would you want to change that?
Well there is no point in having two files if one will do. Also it allows for a hash / signature check.
Finally, for the firmware components, do you mean system firmware? If so, I would expect it to be more convenient to distribute updates to that separately, although I suppose they could be combined with the kernel if the combinatorial explosion can be contained. What is the problem, exactly? (If you mean peripheral firmware, I would expect fwupd to handle that.)
What exactly is impossible? Can you please be more specific?
FIT is just a container. It seems to have been rejected by the EFI crew at some point. Perhaps I just need to try to use it with one of the distros out there, to actually understand what is going on here. But any help is appreciated.
FIT and EFI are orthogonal. A FIT image can contain an EFI binary. See CONFIG_BOOTM_EFI.
(I think that is a different topic; FIT can of course contain any image)
EFI_LOADER is required by EBBR, a new boot standard which aims to bring in UEFI protocols to U-Boot. But EBRR is not required for booting. U-Boot already provides support for FIT, the 'bootm' command and a suitable hand-off to Linux. EBRR has made the decision to create a parallel infrastructure, e.g. does not use FIT, nor U-Boot's signing infrastructure.
EFI_LOADER is required to boot FreeBSD and OpenBSD on several platforms as well as generic Linux distros. For example OpenBSD/armv7, OpenBSD/arm64 and OpenBSD/riscv64 all rely on EFI_LOADER to boot and have done so for the last 4 years. The fact that ARM has embraced UEFI as an embedded boot standard and branded it EBBR really isn't all that relevant.
To be clear here, I like EFI_LOADER. I too do wish some other technologies had become dominant for technical rather than inertia reasons, but here we are. Having played around with it on aarch64, there are some pretty nice comes-along-with parts to it.
What I hadn't seen, and am only a little skeptical of still, is how far backwards in generations it's going to be used on. The general wish is that users nor off the shelf OS groups need to rebuild U-Boot for a given board, and instead it just works. The number of new designs for 32bit parts is no where near the number of new designs for 64bit parts. So what we're seeing in U-Boot now is people updating support on their older designs, and not necessarily caring about using EFI_LOADER.
In a reply to one of the patches in this series, Heinrich mentions a few problems that need resolving (devices for partitions and file handles). Both of those features should first be added to U-Boot, so EFI can then use that support. In general, EFI has tried to work beside driver model, creating its own parallel tables, etc.
Could you, please, be a bit more specific. Please, indicate which data structures you would like to integrate into the driver model.
As a starting point, all the struct efi_device_path* things should be generated on the fly from DM, rather than existing in parallel.
EDK II shows that a driver model completely based on UEFI protocols is possible. As long as we don't follow that road we will have separate APIs for the UEFI world and U-Boot's internal use and we will have to keep track of objects that exist only in the one world or the other.
What we definitively need is a better integration between probing and removing U-Boot devices and their representation in the UEFI world.
That is the crux of the problem. The approach taken by UEFI (of duplicating everything) needs to change.
Another area that might deserve attention is memory allocation. AllocatePool() consuming whole memory pages is quite a waste.
I have tried to influence this at various points along the way, including at the start and I'm happy to dig out those threads if it helps. But I wasn't kidding. it really needs to be addressed. I would love to see Linaro (for example) organise something here and take this on. I am very happy to help.
The starting point would be comparing the DM and UEFI object models and pointing out which objects can be mapped and which cannot.
In my book there are three categories:
- can - cannot at present, but should be soon - should not
Regards, Simon
On 6/28/21 6:26 PM, Simon Glass wrote:
Hi Heinrich,
On Mon, 28 Jun 2021 at 09:20, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 6/28/21 4:18 PM, Simon Glass wrote:
Hi Tom, Mark,
On Mon, 28 Jun 2021 at 07:37, Tom Rini trini@konsulko.com wrote:
On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Sun, 27 Jun 2021 19:48:34 -0600
It has come to light that EFI_LOADER adds an extraordinary amount of code to U-Boot. For example, with nokia_rx51 the size delta is about 90KB. About 170 boards explicitly disable the option, but is is clear that many more could, thus saving image size and boot time.
EFI_LOADER used to be a lot smaller. It is great to see that over the years UEFI support has become more complete, but a lot of that new code implements features that are not at all essential for just booting an OS from storage. If that growth leads to the suggestion to disable EFI_LOADER completely by default, we're putting the cart before the horse.
Well, I see I forgot to prefix my patch with RFC, but I hadn't found EFI_LOADER being used in the wild on armv7, but wasn't sure about the BSD families. I did see that Debian doesn't use it, and that Armbian doesn't even use it on aarch64.
The current situation is affecting U-Boot's image as a svelt bootloader.
Really? I know UEFI has a bad reputation in the Open Source world, and some of its Microsoft-isms are really annoying (yay UCS-2). But it works, it provides a standardized approach across several platforms (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally I'd wish the industry had standardized on Open Firmware instead, but that ship sailed a long time ago...
I find it hard to imagine that 90k is a serious amount of storage for something that is going to include a multi-MB Linux kernel. This isn't code that lives in SPL or TPL where severe size restrictions apply.
In one of those cases where I need to pop back in to the other (Nokia N900 specific) thread and see if the big size reduction really was just disabling EFI_LOADER, it's perhaps just one of those "fun" things about Kconfig and anything other than "make oldconfig" for spotting new config options that default to enabled.
Yes it will be interesting to see what you find there. My results on nokia_rx51 were something like this:
default arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0 rodata +10989.0 text +109846.0
without ebbr arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 rodata +5333.0 text +29712.0
with various other things: CONFIG_OF_LIBFDT_ASSUME_MASK=7 # CONFIG_OF_TRANSLATE is not set # CONFIG_SIMPLE_BUS is not set # CONFIG_TI_SYSC is not set # CONFIG_CMD_FDT is not set
arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rodata+3274.0 text +15552.0
(Mark, in the same email:)
FIT simply isn't fit for purpose (pun intended). It only really works for booting Linux, and forces people to combine u-boot, kernel, initial ramdisk and other firmware components into a single image. That is really undesirable as:
- This makes it sigificantly harder to update individual components of such an image. Making it hard to update a kernel is obviously a serious security risk.
- This makes it impossible to build an OS install image that works om multiple boards/SoCs.
I would really like to understand this better. The whole thing is a complete mystery to me.
Firstly I have sometimes fiddled with booting other OSes using FIT. It seemed OK. I can't see why it only works with Linux.
Secondly, I don't expect that U-Boot itself would be in the FIT.
Thirdly, do you really want the kernel and initrd to be separate? At least in the systems I have used, they are built together, even having the same name, e.g.:
initrd.img-5.10.40-1rodete1-amd64 System.map-5.10.40-1rodete1-amd64 vmlinuz-5.10.28-1rodete2-amd64
I have not hit any distro that builds FIT images. All install vmlinux and initrd as separate files.
Why would you want to change that?
Well there is no point in having two files if one will do. Also it allows for a hash / signature check.
Finally, for the firmware components, do you mean system firmware? If so, I would expect it to be more convenient to distribute updates to that separately, although I suppose they could be combined with the kernel if the combinatorial explosion can be contained. What is the problem, exactly? (If you mean peripheral firmware, I would expect fwupd to handle that.)
What exactly is impossible? Can you please be more specific?
FIT is just a container. It seems to have been rejected by the EFI crew at some point. Perhaps I just need to try to use it with one of the distros out there, to actually understand what is going on here. But any help is appreciated.
FIT and EFI are orthogonal. A FIT image can contain an EFI binary. See CONFIG_BOOTM_EFI.
(I think that is a different topic; FIT can of course contain any image)
EFI_LOADER is required by EBBR, a new boot standard which aims to bring in UEFI protocols to U-Boot. But EBRR is not required for booting. U-Boot already provides support for FIT, the 'bootm' command and a suitable hand-off to Linux. EBRR has made the decision to create a parallel infrastructure, e.g. does not use FIT, nor U-Boot's signing infrastructure.
EFI_LOADER is required to boot FreeBSD and OpenBSD on several platforms as well as generic Linux distros. For example OpenBSD/armv7, OpenBSD/arm64 and OpenBSD/riscv64 all rely on EFI_LOADER to boot and have done so for the last 4 years. The fact that ARM has embraced UEFI as an embedded boot standard and branded it EBBR really isn't all that relevant.
To be clear here, I like EFI_LOADER. I too do wish some other technologies had become dominant for technical rather than inertia reasons, but here we are. Having played around with it on aarch64, there are some pretty nice comes-along-with parts to it.
What I hadn't seen, and am only a little skeptical of still, is how far backwards in generations it's going to be used on. The general wish is that users nor off the shelf OS groups need to rebuild U-Boot for a given board, and instead it just works. The number of new designs for 32bit parts is no where near the number of new designs for 64bit parts. So what we're seeing in U-Boot now is people updating support on their older designs, and not necessarily caring about using EFI_LOADER.
In a reply to one of the patches in this series, Heinrich mentions a few problems that need resolving (devices for partitions and file handles). Both of those features should first be added to U-Boot, so EFI can then use that support. In general, EFI has tried to work beside driver model, creating its own parallel tables, etc.
Could you, please, be a bit more specific. Please, indicate which data structures you would like to integrate into the driver model.
As a starting point, all the struct efi_device_path* things should be generated on the fly from DM, rather than existing in parallel.
The driver model does not describe all devices in the lifetime of an UEFI application. Applications like iPXE create handles and install there own device paths on them.
When a U-Boot device is probed a UEFI handle should be created and the device path protocol has to be installed. I hope this is what you mean by "on the fly".
Be aware that the device path protocol can be replaced by a UEFI application by calling ReinstallProtocol() at any time. So to be UEFI compliant you cannot create device paths upon access. Let's assume you did not mean this by "on the fly".
After all device paths have to exist as data structures in parallel to the currrent driver model. But we can change how we create them.
EDK II shows that a driver model completely based on UEFI protocols is possible. As long as we don't follow that road we will have separate APIs for the UEFI world and U-Boot's internal use and we will have to keep track of objects that exist only in the one world or the other.
What we definitively need is a better integration between probing and removing U-Boot devices and their representation in the UEFI world.
That is the crux of the problem. The approach taken by UEFI (of duplicating everything) needs to change.
Another area that might deserve attention is memory allocation. AllocatePool() consuming whole memory pages is quite a waste.
I have tried to influence this at various points along the way, including at the start and I'm happy to dig out those threads if it helps. But I wasn't kidding. it really needs to be addressed. I would love to see Linaro (for example) organise something here and take this on. I am very happy to help.
The starting point would be comparing the DM and UEFI object models and pointing out which objects can be mapped and which cannot.
In my book there are three categories:
- can
- cannot at present, but should be soon
- should not
'Cannot be mapped because not defined in the UEFI spec' is missing in your scheme. E.g. there is a RNG protocol but no such thing as a RNG device defined in the UEFI spec.
Best regards
Heinrich
Hi Heinrich,
On Mon, 28 Jun 2021 at 11:10, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 6/28/21 6:26 PM, Simon Glass wrote:
Hi Heinrich,
On Mon, 28 Jun 2021 at 09:20, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 6/28/21 4:18 PM, Simon Glass wrote:
Hi Tom, Mark,
On Mon, 28 Jun 2021 at 07:37, Tom Rini trini@konsulko.com wrote:
On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote:
> From: Simon Glass sjg@chromium.org > Date: Sun, 27 Jun 2021 19:48:34 -0600 > > It has come to light that EFI_LOADER adds an extraordinary amount of > code to U-Boot. For example, with nokia_rx51 the size delta is about > 90KB. About 170 boards explicitly disable the option, but is is clear > that many more could, thus saving image size and boot time.
EFI_LOADER used to be a lot smaller. It is great to see that over the years UEFI support has become more complete, but a lot of that new code implements features that are not at all essential for just booting an OS from storage. If that growth leads to the suggestion to disable EFI_LOADER completely by default, we're putting the cart before the horse.
Well, I see I forgot to prefix my patch with RFC, but I hadn't found EFI_LOADER being used in the wild on armv7, but wasn't sure about the BSD families. I did see that Debian doesn't use it, and that Armbian doesn't even use it on aarch64.
> The current situation is affecting U-Boot's image as a svelt bootloader.
Really? I know UEFI has a bad reputation in the Open Source world, and some of its Microsoft-isms are really annoying (yay UCS-2). But it works, it provides a standardized approach across several platforms (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally I'd wish the industry had standardized on Open Firmware instead, but that ship sailed a long time ago...
I find it hard to imagine that 90k is a serious amount of storage for something that is going to include a multi-MB Linux kernel. This isn't code that lives in SPL or TPL where severe size restrictions apply.
In one of those cases where I need to pop back in to the other (Nokia N900 specific) thread and see if the big size reduction really was just disabling EFI_LOADER, it's perhaps just one of those "fun" things about Kconfig and anything other than "make oldconfig" for spotting new config options that default to enabled.
Yes it will be interesting to see what you find there. My results on nokia_rx51 were something like this:
default arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0 rodata +10989.0 text +109846.0
without ebbr arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 rodata +5333.0 text +29712.0
with various other things: CONFIG_OF_LIBFDT_ASSUME_MASK=7 # CONFIG_OF_TRANSLATE is not set # CONFIG_SIMPLE_BUS is not set # CONFIG_TI_SYSC is not set # CONFIG_CMD_FDT is not set
arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rodata+3274.0 text +15552.0
(Mark, in the same email:)
FIT simply isn't fit for purpose (pun intended). It only really works for booting Linux, and forces people to combine u-boot, kernel, initial ramdisk and other firmware components into a single image. That is really undesirable as:
- This makes it sigificantly harder to update individual components of such an image. Making it hard to update a kernel is obviously a serious security risk.
- This makes it impossible to build an OS install image that works om multiple boards/SoCs.
I would really like to understand this better. The whole thing is a complete mystery to me.
Firstly I have sometimes fiddled with booting other OSes using FIT. It seemed OK. I can't see why it only works with Linux.
Secondly, I don't expect that U-Boot itself would be in the FIT.
Thirdly, do you really want the kernel and initrd to be separate? At least in the systems I have used, they are built together, even having the same name, e.g.:
initrd.img-5.10.40-1rodete1-amd64 System.map-5.10.40-1rodete1-amd64 vmlinuz-5.10.28-1rodete2-amd64
I have not hit any distro that builds FIT images. All install vmlinux and initrd as separate files.
Why would you want to change that?
Well there is no point in having two files if one will do. Also it allows for a hash / signature check.
Finally, for the firmware components, do you mean system firmware? If so, I would expect it to be more convenient to distribute updates to that separately, although I suppose they could be combined with the kernel if the combinatorial explosion can be contained. What is the problem, exactly? (If you mean peripheral firmware, I would expect fwupd to handle that.)
What exactly is impossible? Can you please be more specific?
FIT is just a container. It seems to have been rejected by the EFI crew at some point. Perhaps I just need to try to use it with one of the distros out there, to actually understand what is going on here. But any help is appreciated.
FIT and EFI are orthogonal. A FIT image can contain an EFI binary. See CONFIG_BOOTM_EFI.
(I think that is a different topic; FIT can of course contain any image)
> EFI_LOADER is required by EBBR, a new boot standard which aims to > bring in UEFI protocols to U-Boot. But EBRR is not required for > booting. U-Boot already provides support for FIT, the 'bootm' command > and a suitable hand-off to Linux. EBRR has made the decision to create > a parallel infrastructure, e.g. does not use FIT, nor U-Boot's signing > infrastructure.
EFI_LOADER is required to boot FreeBSD and OpenBSD on several platforms as well as generic Linux distros. For example OpenBSD/armv7, OpenBSD/arm64 and OpenBSD/riscv64 all rely on EFI_LOADER to boot and have done so for the last 4 years. The fact that ARM has embraced UEFI as an embedded boot standard and branded it EBBR really isn't all that relevant.
To be clear here, I like EFI_LOADER. I too do wish some other technologies had become dominant for technical rather than inertia reasons, but here we are. Having played around with it on aarch64, there are some pretty nice comes-along-with parts to it.
What I hadn't seen, and am only a little skeptical of still, is how far backwards in generations it's going to be used on. The general wish is that users nor off the shelf OS groups need to rebuild U-Boot for a given board, and instead it just works. The number of new designs for 32bit parts is no where near the number of new designs for 64bit parts. So what we're seeing in U-Boot now is people updating support on their older designs, and not necessarily caring about using EFI_LOADER.
In a reply to one of the patches in this series, Heinrich mentions a few problems that need resolving (devices for partitions and file handles). Both of those features should first be added to U-Boot, so EFI can then use that support. In general, EFI has tried to work beside driver model, creating its own parallel tables, etc.
Could you, please, be a bit more specific. Please, indicate which data structures you would like to integrate into the driver model.
As a starting point, all the struct efi_device_path* things should be generated on the fly from DM, rather than existing in parallel.
The driver model does not describe all devices in the lifetime of an UEFI application. Applications like iPXE create handles and install there own device paths on them.
That is the core of the problem. If UEFI wants to create something, it should do so using core DM calls, not build parallel structures.
When a U-Boot device is probed a UEFI handle should be created and the device path protocol has to be installed. I hope this is what you mean by "on the fly".
Be aware that the device path protocol can be replaced by a UEFI application by calling ReinstallProtocol() at any time. So to be UEFI compliant you cannot create device paths upon access. Let's assume you did not mean this by "on the fly".
After all device paths have to exist as data structures in parallel to the currrent driver model. But we can change how we create them.
This is the piece that is incorrect, I think. U-Boot should encompass the required features so that there is no need for these tables, except in special situations. So rather than EFI being a bolt-on, it becomes more like another view. For example, devices can have some extra EFI information, if it truly is useless for DM (e.g. UUIDs), but it should be attached to the device, not in a parallel table.
By 'on the fly' I mean that in most cases, EFI requests can be satisfied by doing DM calls and by providing DM information in a format that EFI expects. With that as a general principle, there will be less duplication and more consistency.
But getting rid of storing struct efi_device_path... would be a good exercise to nut out the problems.
EDK II shows that a driver model completely based on UEFI protocols is possible. As long as we don't follow that road we will have separate APIs for the UEFI world and U-Boot's internal use and we will have to keep track of objects that exist only in the one world or the other.
What we definitively need is a better integration between probing and removing U-Boot devices and their representation in the UEFI world.
That is the crux of the problem. The approach taken by UEFI (of duplicating everything) needs to change.
Another area that might deserve attention is memory allocation. AllocatePool() consuming whole memory pages is quite a waste.
I have tried to influence this at various points along the way, including at the start and I'm happy to dig out those threads if it helps. But I wasn't kidding. it really needs to be addressed. I would love to see Linaro (for example) organise something here and take this on. I am very happy to help.
The starting point would be comparing the DM and UEFI object models and pointing out which objects can be mapped and which cannot.
In my book there are three categories:
- can
- cannot at present, but should be soon
- should not
'Cannot be mapped because not defined in the UEFI spec' is missing in your scheme. E.g. there is a RNG protocol but no such thing as a RNG device defined in the UEFI spec.
Are you talking about things not in the spec? If so, I don't think they are relevant to this discussion. Or are you just trying to be fully complete?
Regards, Simon
On Mon, Jun 28, 2021 at 10:26:35AM -0600, Simon Glass wrote:
Hi Heinrich,
On Mon, 28 Jun 2021 at 09:20, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 6/28/21 4:18 PM, Simon Glass wrote:
Hi Tom, Mark,
On Mon, 28 Jun 2021 at 07:37, Tom Rini trini@konsulko.com wrote:
On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Sun, 27 Jun 2021 19:48:34 -0600
It has come to light that EFI_LOADER adds an extraordinary amount of code to U-Boot. For example, with nokia_rx51 the size delta is about 90KB. About 170 boards explicitly disable the option, but is is clear that many more could, thus saving image size and boot time.
EFI_LOADER used to be a lot smaller. It is great to see that over the years UEFI support has become more complete, but a lot of that new code implements features that are not at all essential for just booting an OS from storage. If that growth leads to the suggestion to disable EFI_LOADER completely by default, we're putting the cart before the horse.
Well, I see I forgot to prefix my patch with RFC, but I hadn't found EFI_LOADER being used in the wild on armv7, but wasn't sure about the BSD families. I did see that Debian doesn't use it, and that Armbian doesn't even use it on aarch64.
The current situation is affecting U-Boot's image as a svelt bootloader.
Really? I know UEFI has a bad reputation in the Open Source world, and some of its Microsoft-isms are really annoying (yay UCS-2). But it works, it provides a standardized approach across several platforms (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally I'd wish the industry had standardized on Open Firmware instead, but that ship sailed a long time ago...
I find it hard to imagine that 90k is a serious amount of storage for something that is going to include a multi-MB Linux kernel. This isn't code that lives in SPL or TPL where severe size restrictions apply.
In one of those cases where I need to pop back in to the other (Nokia N900 specific) thread and see if the big size reduction really was just disabling EFI_LOADER, it's perhaps just one of those "fun" things about Kconfig and anything other than "make oldconfig" for spotting new config options that default to enabled.
Yes it will be interesting to see what you find there. My results on nokia_rx51 were something like this:
default arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0 rodata +10989.0 text +109846.0
without ebbr arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 rodata +5333.0 text +29712.0
with various other things: CONFIG_OF_LIBFDT_ASSUME_MASK=7 # CONFIG_OF_TRANSLATE is not set # CONFIG_SIMPLE_BUS is not set # CONFIG_TI_SYSC is not set # CONFIG_CMD_FDT is not set
arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rodata+3274.0 text +15552.0
(Mark, in the same email:)
FIT simply isn't fit for purpose (pun intended). It only really works for booting Linux, and forces people to combine u-boot, kernel, initial ramdisk and other firmware components into a single image. That is really undesirable as:
- This makes it sigificantly harder to update individual components of such an image. Making it hard to update a kernel is obviously a serious security risk.
- This makes it impossible to build an OS install image that works om multiple boards/SoCs.
I would really like to understand this better. The whole thing is a complete mystery to me.
Firstly I have sometimes fiddled with booting other OSes using FIT. It seemed OK. I can't see why it only works with Linux.
Secondly, I don't expect that U-Boot itself would be in the FIT.
Thirdly, do you really want the kernel and initrd to be separate? At least in the systems I have used, they are built together, even having the same name, e.g.:
initrd.img-5.10.40-1rodete1-amd64 System.map-5.10.40-1rodete1-amd64 vmlinuz-5.10.28-1rodete2-amd64
I have not hit any distro that builds FIT images. All install vmlinux and initrd as separate files.
Why would you want to change that?
Well there is no point in having two files if one will do. Also it allows for a hash / signature check.
The question of "how great would it be and how many problems would it have solved if FIT images had become popular" is one for another time. It will always have its use cases and users but never the broad adoption many of us felt it should have. Bringing it up in this context won't change that.
I'm saying this because I think there are some important technical questions within U-Boot to resolve because the EFI loader part of U-Boot is critical to our long term future. And DM is an important part of our internal design and we're (probably later than I should have) pulling out the parts that haven't been updated so that we can deliver on some of the overall promise of DM better, too.
Hi Tom,
On Mon, 28 Jun 2021 at 11:27, Tom Rini trini@konsulko.com wrote:
On Mon, Jun 28, 2021 at 10:26:35AM -0600, Simon Glass wrote:
Hi Heinrich,
On Mon, 28 Jun 2021 at 09:20, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 6/28/21 4:18 PM, Simon Glass wrote:
Hi Tom, Mark,
On Mon, 28 Jun 2021 at 07:37, Tom Rini trini@konsulko.com wrote:
On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote:
> From: Simon Glass sjg@chromium.org > Date: Sun, 27 Jun 2021 19:48:34 -0600 > > It has come to light that EFI_LOADER adds an extraordinary amount of > code to U-Boot. For example, with nokia_rx51 the size delta is about > 90KB. About 170 boards explicitly disable the option, but is is clear > that many more could, thus saving image size and boot time.
EFI_LOADER used to be a lot smaller. It is great to see that over the years UEFI support has become more complete, but a lot of that new code implements features that are not at all essential for just booting an OS from storage. If that growth leads to the suggestion to disable EFI_LOADER completely by default, we're putting the cart before the horse.
Well, I see I forgot to prefix my patch with RFC, but I hadn't found EFI_LOADER being used in the wild on armv7, but wasn't sure about the BSD families. I did see that Debian doesn't use it, and that Armbian doesn't even use it on aarch64.
> The current situation is affecting U-Boot's image as a svelt bootloader.
Really? I know UEFI has a bad reputation in the Open Source world, and some of its Microsoft-isms are really annoying (yay UCS-2). But it works, it provides a standardized approach across several platforms (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally I'd wish the industry had standardized on Open Firmware instead, but that ship sailed a long time ago...
I find it hard to imagine that 90k is a serious amount of storage for something that is going to include a multi-MB Linux kernel. This isn't code that lives in SPL or TPL where severe size restrictions apply.
In one of those cases where I need to pop back in to the other (Nokia N900 specific) thread and see if the big size reduction really was just disabling EFI_LOADER, it's perhaps just one of those "fun" things about Kconfig and anything other than "make oldconfig" for spotting new config options that default to enabled.
Yes it will be interesting to see what you find there. My results on nokia_rx51 were something like this:
default arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0 rodata +10989.0 text +109846.0
without ebbr arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 rodata +5333.0 text +29712.0
with various other things: CONFIG_OF_LIBFDT_ASSUME_MASK=7 # CONFIG_OF_TRANSLATE is not set # CONFIG_SIMPLE_BUS is not set # CONFIG_TI_SYSC is not set # CONFIG_CMD_FDT is not set
arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rodata+3274.0 text +15552.0
(Mark, in the same email:)
FIT simply isn't fit for purpose (pun intended). It only really works for booting Linux, and forces people to combine u-boot, kernel, initial ramdisk and other firmware components into a single image. That is really undesirable as:
- This makes it sigificantly harder to update individual components of such an image. Making it hard to update a kernel is obviously a serious security risk.
- This makes it impossible to build an OS install image that works om multiple boards/SoCs.
I would really like to understand this better. The whole thing is a complete mystery to me.
Firstly I have sometimes fiddled with booting other OSes using FIT. It seemed OK. I can't see why it only works with Linux.
Secondly, I don't expect that U-Boot itself would be in the FIT.
Thirdly, do you really want the kernel and initrd to be separate? At least in the systems I have used, they are built together, even having the same name, e.g.:
initrd.img-5.10.40-1rodete1-amd64 System.map-5.10.40-1rodete1-amd64 vmlinuz-5.10.28-1rodete2-amd64
I have not hit any distro that builds FIT images. All install vmlinux and initrd as separate files.
Why would you want to change that?
Well there is no point in having two files if one will do. Also it allows for a hash / signature check.
The question of "how great would it be and how many problems would it have solved if FIT images had become popular" is one for another time. It will always have its use cases and users but never the broad adoption many of us felt it should have. Bringing it up in this context won't change that.
I see Peter's reply below so will make time to dig into this and understand the problems with FIT better. I feel that EFI comes with all sorts of problems so I'm far from convinced, at this point. Sorry.
I'm saying this because I think there are some important technical questions within U-Boot to resolve because the EFI loader part of U-Boot is critical to our long term future. And DM is an important part of our internal design and we're (probably later than I should have) pulling out the parts that haven't been updated so that we can deliver on some of the overall promise of DM better, too.
Yes, migration has certainly been slow. As you know I mostly stopped pushing it a few years back when I saw all the reluctance. I'm very pleased you are taking that on and I think it will help a lot.
If what you say comes to pass, it is even more important that EFI is more integrated, rather than being a bolt on. Thanks largely to Heinrich, the tests are in quite good shape, so refactoring should be feasible.
Regards, Simon
On Mon, Jun 28, 2021 at 12:08:27PM -0600, Simon Glass wrote:
Hi Tom,
On Mon, 28 Jun 2021 at 11:27, Tom Rini trini@konsulko.com wrote:
On Mon, Jun 28, 2021 at 10:26:35AM -0600, Simon Glass wrote:
Hi Heinrich,
On Mon, 28 Jun 2021 at 09:20, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 6/28/21 4:18 PM, Simon Glass wrote:
Hi Tom, Mark,
On Mon, 28 Jun 2021 at 07:37, Tom Rini trini@konsulko.com wrote:
On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote: >> From: Simon Glass sjg@chromium.org >> Date: Sun, 27 Jun 2021 19:48:34 -0600 >> >> It has come to light that EFI_LOADER adds an extraordinary amount of >> code to U-Boot. For example, with nokia_rx51 the size delta is about >> 90KB. About 170 boards explicitly disable the option, but is is clear >> that many more could, thus saving image size and boot time. > > EFI_LOADER used to be a lot smaller. It is great to see that over the > years UEFI support has become more complete, but a lot of that new > code implements features that are not at all essential for just > booting an OS from storage. If that growth leads to the suggestion to > disable EFI_LOADER completely by default, we're putting the cart > before the horse.
Well, I see I forgot to prefix my patch with RFC, but I hadn't found EFI_LOADER being used in the wild on armv7, but wasn't sure about the BSD families. I did see that Debian doesn't use it, and that Armbian doesn't even use it on aarch64.
>> The current situation is affecting U-Boot's image as a svelt bootloader. > > Really? I know UEFI has a bad reputation in the Open Source world, > and some of its Microsoft-isms are really annoying (yay UCS-2). But > it works, it provides a standardized approach across several platforms > (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally > I'd wish the industry had standardized on Open Firmware instead, but > that ship sailed a long time ago... > > I find it hard to imagine that 90k is a serious amount of storage for > something that is going to include a multi-MB Linux kernel. This > isn't code that lives in SPL or TPL where severe size restrictions > apply.
In one of those cases where I need to pop back in to the other (Nokia N900 specific) thread and see if the big size reduction really was just disabling EFI_LOADER, it's perhaps just one of those "fun" things about Kconfig and anything other than "make oldconfig" for spotting new config options that default to enabled.
Yes it will be interesting to see what you find there. My results on nokia_rx51 were something like this:
default arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0 rodata +10989.0 text +109846.0
without ebbr arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 rodata +5333.0 text +29712.0
with various other things: CONFIG_OF_LIBFDT_ASSUME_MASK=7 # CONFIG_OF_TRANSLATE is not set # CONFIG_SIMPLE_BUS is not set # CONFIG_TI_SYSC is not set # CONFIG_CMD_FDT is not set
arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rodata+3274.0 text +15552.0
(Mark, in the same email:)
> FIT simply isn't fit for purpose (pun intended). It only really works > for booting Linux, and forces people to combine u-boot, kernel, > initial ramdisk and other firmware components into a single image. > That is really undesirable as: > - This makes it sigificantly harder to update individual components of > such an image. Making it hard to update a kernel is obviously a > serious security risk. > - This makes it impossible to build an OS install image that works om > multiple boards/SoCs.
I would really like to understand this better. The whole thing is a complete mystery to me.
Firstly I have sometimes fiddled with booting other OSes using FIT. It seemed OK. I can't see why it only works with Linux.
Secondly, I don't expect that U-Boot itself would be in the FIT.
Thirdly, do you really want the kernel and initrd to be separate? At least in the systems I have used, they are built together, even having the same name, e.g.:
initrd.img-5.10.40-1rodete1-amd64 System.map-5.10.40-1rodete1-amd64 vmlinuz-5.10.28-1rodete2-amd64
I have not hit any distro that builds FIT images. All install vmlinux and initrd as separate files.
Why would you want to change that?
Well there is no point in having two files if one will do. Also it allows for a hash / signature check.
The question of "how great would it be and how many problems would it have solved if FIT images had become popular" is one for another time. It will always have its use cases and users but never the broad adoption many of us felt it should have. Bringing it up in this context won't change that.
I see Peter's reply below so will make time to dig into this and understand the problems with FIT better. I feel that EFI comes with all sorts of problems so I'm far from convinced, at this point. Sorry.
It seems to me that we are discussing three different things: - the code size increase by enabling UEFI interfaces - how the UEFI interface be implemented on U-Boot - The primary (or default/standard) boot mechanism in the future
I don't think they are totally independent, but we'd better distinguish them some how in the following discussions.
I'm saying this because I think there are some important technical questions within U-Boot to resolve because the EFI loader part of U-Boot is critical to our long term future. And DM is an important part of our internal design and we're (probably later than I should have) pulling out the parts that haven't been updated so that we can deliver on some of the overall promise of DM better, too.
Yes, migration has certainly been slow. As you know I mostly stopped pushing it a few years back when I saw all the reluctance. I'm very pleased you are taking that on and I think it will help a lot.
I posted this patch[1] two years ago and I thought that we had had some sort of consensus that UEFI interfaces be integrated more elegantly with DM in the future.
So I was a bit surprised with Heinrich's recent patch.
In [1], I was trying to define all the UEFI handles, including some protocols?, as DM objects. I thought that it was the best way for unifying the two worlds even if there are no corresponding *notions* in the existing DM objects.
[1] https://lists.denx.de/pipermail/u-boot/2019-February/357923.html
-Takahiro Akashi
If what you say comes to pass, it is even more important that EFI is more integrated, rather than being a bolt on. Thanks largely to Heinrich, the tests are in quite good shape, so refactoring should be feasible.
Regards, Simon
On 6/29/21 2:56 PM, AKASHI Takahiro wrote:
On Mon, Jun 28, 2021 at 12:08:27PM -0600, Simon Glass wrote:
Hi Tom,
On Mon, 28 Jun 2021 at 11:27, Tom Rini trini@konsulko.com wrote:
On Mon, Jun 28, 2021 at 10:26:35AM -0600, Simon Glass wrote:
Hi Heinrich,
On Mon, 28 Jun 2021 at 09:20, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 6/28/21 4:18 PM, Simon Glass wrote:
Hi Tom, Mark,
On Mon, 28 Jun 2021 at 07:37, Tom Rini trini@konsulko.com wrote: > > On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote: >>> From: Simon Glass sjg@chromium.org >>> Date: Sun, 27 Jun 2021 19:48:34 -0600 >>> >>> It has come to light that EFI_LOADER adds an extraordinary amount of >>> code to U-Boot. For example, with nokia_rx51 the size delta is about >>> 90KB. About 170 boards explicitly disable the option, but is is clear >>> that many more could, thus saving image size and boot time. >> >> EFI_LOADER used to be a lot smaller. It is great to see that over the >> years UEFI support has become more complete, but a lot of that new >> code implements features that are not at all essential for just >> booting an OS from storage. If that growth leads to the suggestion to >> disable EFI_LOADER completely by default, we're putting the cart >> before the horse. > > Well, I see I forgot to prefix my patch with RFC, but I hadn't found > EFI_LOADER being used in the wild on armv7, but wasn't sure about the > BSD families. I did see that Debian doesn't use it, and that Armbian > doesn't even use it on aarch64. > >>> The current situation is affecting U-Boot's image as a svelt bootloader. >> >> Really? I know UEFI has a bad reputation in the Open Source world, >> and some of its Microsoft-isms are really annoying (yay UCS-2). But >> it works, it provides a standardized approach across several platforms >> (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally >> I'd wish the industry had standardized on Open Firmware instead, but >> that ship sailed a long time ago... >> >> I find it hard to imagine that 90k is a serious amount of storage for >> something that is going to include a multi-MB Linux kernel. This >> isn't code that lives in SPL or TPL where severe size restrictions >> apply. > > In one of those cases where I need to pop back in to the other (Nokia > N900 specific) thread and see if the big size reduction really was just > disabling EFI_LOADER, it's perhaps just one of those "fun" things about > Kconfig and anything other than "make oldconfig" for spotting new config > options that default to enabled.
Yes it will be interesting to see what you find there. My results on nokia_rx51 were something like this:
default arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0 rodata +10989.0 text +109846.0
without ebbr arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 rodata +5333.0 text +29712.0
with various other things: CONFIG_OF_LIBFDT_ASSUME_MASK=7 # CONFIG_OF_TRANSLATE is not set # CONFIG_SIMPLE_BUS is not set # CONFIG_TI_SYSC is not set # CONFIG_CMD_FDT is not set
arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rodata+3274.0 text +15552.0
(Mark, in the same email:) >> FIT simply isn't fit for purpose (pun intended). It only really works >> for booting Linux, and forces people to combine u-boot, kernel, >> initial ramdisk and other firmware components into a single image. >> That is really undesirable as: >> - This makes it sigificantly harder to update individual components of >> such an image. Making it hard to update a kernel is obviously a >> serious security risk. >> - This makes it impossible to build an OS install image that works om >> multiple boards/SoCs.
I would really like to understand this better. The whole thing is a complete mystery to me.
Firstly I have sometimes fiddled with booting other OSes using FIT. It seemed OK. I can't see why it only works with Linux.
Secondly, I don't expect that U-Boot itself would be in the FIT.
Thirdly, do you really want the kernel and initrd to be separate? At least in the systems I have used, they are built together, even having the same name, e.g.:
initrd.img-5.10.40-1rodete1-amd64 System.map-5.10.40-1rodete1-amd64 vmlinuz-5.10.28-1rodete2-amd64
I have not hit any distro that builds FIT images. All install vmlinux and initrd as separate files.
Why would you want to change that?
Well there is no point in having two files if one will do. Also it allows for a hash / signature check.
The question of "how great would it be and how many problems would it have solved if FIT images had become popular" is one for another time. It will always have its use cases and users but never the broad adoption many of us felt it should have. Bringing it up in this context won't change that.
I see Peter's reply below so will make time to dig into this and understand the problems with FIT better. I feel that EFI comes with all sorts of problems so I'm far from convinced, at this point. Sorry.
It seems to me that we are discussing three different things:
- the code size increase by enabling UEFI interfaces
- how the UEFI interface be implemented on U-Boot
- The primary (or default/standard) boot mechanism in the future
I don't think they are totally independent, but we'd better distinguish them some how in the following discussions.
I'm saying this because I think there are some important technical questions within U-Boot to resolve because the EFI loader part of U-Boot is critical to our long term future. And DM is an important part of our internal design and we're (probably later than I should have) pulling out the parts that haven't been updated so that we can deliver on some of the overall promise of DM better, too.
Yes, migration has certainly been slow. As you know I mostly stopped pushing it a few years back when I saw all the reluctance. I'm very pleased you are taking that on and I think it will help a lot.
I posted this patch[1] two years ago and I thought that we had had some sort of consensus that UEFI interfaces be integrated more elegantly with DM in the future.
So I was a bit surprised with Heinrich's recent patch.
In [1], I was trying to define all the UEFI handles, including some protocols?, as DM objects. I thought that it was the best way for unifying the two worlds even if there are no corresponding *notions* in the existing DM objects.
[1] https://lists.denx.de/pipermail/u-boot/2019-February/357923.html
-Takahiro Akashi
You wrote yourself: "bootefi doesn't work with this patch set yet".
Your series completely disregarded UEFI and DM logic, e.g. you defined DM devices per protocol.
You tried to integrate UEFI and DM world at an inappropriate level: Instead of changing DM block device uclass you touched individual drivers like USB and SCSI completely disregarding all other block device classes.
Best regards
Heinrich
If what you say comes to pass, it is even more important that EFI is more integrated, rather than being a bolt on. Thanks largely to Heinrich, the tests are in quite good shape, so refactoring should be feasible.
Regards, Simon
On Tue, Jun 29, 2021 at 04:01:38PM +0200, Heinrich Schuchardt wrote:
On 6/29/21 2:56 PM, AKASHI Takahiro wrote:
On Mon, Jun 28, 2021 at 12:08:27PM -0600, Simon Glass wrote:
Hi Tom,
On Mon, 28 Jun 2021 at 11:27, Tom Rini trini@konsulko.com wrote:
On Mon, Jun 28, 2021 at 10:26:35AM -0600, Simon Glass wrote:
Hi Heinrich,
On Mon, 28 Jun 2021 at 09:20, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 6/28/21 4:18 PM, Simon Glass wrote: > Hi Tom, Mark, > > On Mon, 28 Jun 2021 at 07:37, Tom Rini trini@konsulko.com wrote: > > > > On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote: > > > > From: Simon Glass sjg@chromium.org > > > > Date: Sun, 27 Jun 2021 19:48:34 -0600 > > > > > > > > It has come to light that EFI_LOADER adds an extraordinary amount of > > > > code to U-Boot. For example, with nokia_rx51 the size delta is about > > > > 90KB. About 170 boards explicitly disable the option, but is is clear > > > > that many more could, thus saving image size and boot time. > > > > > > EFI_LOADER used to be a lot smaller. It is great to see that over the > > > years UEFI support has become more complete, but a lot of that new > > > code implements features that are not at all essential for just > > > booting an OS from storage. If that growth leads to the suggestion to > > > disable EFI_LOADER completely by default, we're putting the cart > > > before the horse. > > > > Well, I see I forgot to prefix my patch with RFC, but I hadn't found > > EFI_LOADER being used in the wild on armv7, but wasn't sure about the > > BSD families. I did see that Debian doesn't use it, and that Armbian > > doesn't even use it on aarch64. > > > > > > The current situation is affecting U-Boot's image as a svelt bootloader. > > > > > > Really? I know UEFI has a bad reputation in the Open Source world, > > > and some of its Microsoft-isms are really annoying (yay UCS-2). But > > > it works, it provides a standardized approach across several platforms > > > (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally > > > I'd wish the industry had standardized on Open Firmware instead, but > > > that ship sailed a long time ago... > > > > > > I find it hard to imagine that 90k is a serious amount of storage for > > > something that is going to include a multi-MB Linux kernel. This > > > isn't code that lives in SPL or TPL where severe size restrictions > > > apply. > > > > In one of those cases where I need to pop back in to the other (Nokia > > N900 specific) thread and see if the big size reduction really was just > > disabling EFI_LOADER, it's perhaps just one of those "fun" things about > > Kconfig and anything other than "make oldconfig" for spotting new config > > options that default to enabled. > > Yes it will be interesting to see what you find there. My results on > nokia_rx51 were something like this: > > default > arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0 > rodata +10989.0 text +109846.0 > > without ebbr > arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 > rodata +5333.0 text +29712.0 > > with various other things: > CONFIG_OF_LIBFDT_ASSUME_MASK=7 > # CONFIG_OF_TRANSLATE is not set > # CONFIG_SIMPLE_BUS is not set > # CONFIG_TI_SYSC is not set > # CONFIG_CMD_FDT is not set > > arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rodata > +3274.0 text +15552.0 > > (Mark, in the same email:) > > > FIT simply isn't fit for purpose (pun intended). It only really works > > > for booting Linux, and forces people to combine u-boot, kernel, > > > initial ramdisk and other firmware components into a single image. > > > That is really undesirable as: > > > - This makes it sigificantly harder to update individual components of > > > such an image. Making it hard to update a kernel is obviously a > > > serious security risk. > > > - This makes it impossible to build an OS install image that works om > > > multiple boards/SoCs. > > > I would really like to understand this better. The whole thing is a > complete mystery to me. > > Firstly I have sometimes fiddled with booting other OSes using FIT. It > seemed OK. I can't see why it only works with Linux. > > Secondly, I don't expect that U-Boot itself would be in the FIT. > > Thirdly, do you really want the kernel and initrd to be separate? At > least in the systems I have used, they are built together, even having > the same name, e.g.: > > initrd.img-5.10.40-1rodete1-amd64 > System.map-5.10.40-1rodete1-amd64 > vmlinuz-5.10.28-1rodete2-amd64
I have not hit any distro that builds FIT images. All install vmlinux and initrd as separate files.
Why would you want to change that?
Well there is no point in having two files if one will do. Also it allows for a hash / signature check.
The question of "how great would it be and how many problems would it have solved if FIT images had become popular" is one for another time. It will always have its use cases and users but never the broad adoption many of us felt it should have. Bringing it up in this context won't change that.
I see Peter's reply below so will make time to dig into this and understand the problems with FIT better. I feel that EFI comes with all sorts of problems so I'm far from convinced, at this point. Sorry.
It seems to me that we are discussing three different things:
- the code size increase by enabling UEFI interfaces
- how the UEFI interface be implemented on U-Boot
- The primary (or default/standard) boot mechanism in the future
I don't think they are totally independent, but we'd better distinguish them some how in the following discussions.
I'm saying this because I think there are some important technical questions within U-Boot to resolve because the EFI loader part of U-Boot is critical to our long term future. And DM is an important part of our internal design and we're (probably later than I should have) pulling out the parts that haven't been updated so that we can deliver on some of the overall promise of DM better, too.
Yes, migration has certainly been slow. As you know I mostly stopped pushing it a few years back when I saw all the reluctance. I'm very pleased you are taking that on and I think it will help a lot.
I posted this patch[1] two years ago and I thought that we had had some sort of consensus that UEFI interfaces be integrated more elegantly with DM in the future.
So I was a bit surprised with Heinrich's recent patch.
In [1], I was trying to define all the UEFI handles, including some protocols?, as DM objects. I thought that it was the best way for unifying the two worlds even if there are no corresponding *notions* in the existing DM objects.
[1] https://lists.denx.de/pipermail/u-boot/2019-February/357923.html
-Takahiro Akashi
You wrote yourself: "bootefi doesn't work with this patch set yet".
Your series completely disregarded UEFI and DM logic, e.g. you defined DM devices per protocol.
You tried to integrate UEFI and DM world at an inappropriate level: Instead of changing DM block device uclass you touched individual drivers like USB and SCSI completely disregarding all other block device classes.
Yes, I can agree, but the point is not there. Why not discuss how UEFI and DM be integrated instead as Simon suggested?
-Takahiro Akashi
Best regards
Heinrich
If what you say comes to pass, it is even more important that EFI is more integrated, rather than being a bolt on. Thanks largely to Heinrich, the tests are in quite good shape, so refactoring should be feasible.
Regards, Simon
From: Simon Glass sjg@chromium.org Date: Mon, 28 Jun 2021 08:18:26 -0600
Hi Tom, Mark,
On Mon, 28 Jun 2021 at 07:37, Tom Rini trini@konsulko.com wrote:
On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Sun, 27 Jun 2021 19:48:34 -0600
It has come to light that EFI_LOADER adds an extraordinary amount of code to U-Boot. For example, with nokia_rx51 the size delta is about 90KB. About 170 boards explicitly disable the option, but is is clear that many more could, thus saving image size and boot time.
EFI_LOADER used to be a lot smaller. It is great to see that over the years UEFI support has become more complete, but a lot of that new code implements features that are not at all essential for just booting an OS from storage. If that growth leads to the suggestion to disable EFI_LOADER completely by default, we're putting the cart before the horse.
Well, I see I forgot to prefix my patch with RFC, but I hadn't found EFI_LOADER being used in the wild on armv7, but wasn't sure about the BSD families. I did see that Debian doesn't use it, and that Armbian doesn't even use it on aarch64.
The current situation is affecting U-Boot's image as a svelt bootloader.
Really? I know UEFI has a bad reputation in the Open Source world, and some of its Microsoft-isms are really annoying (yay UCS-2). But it works, it provides a standardized approach across several platforms (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally I'd wish the industry had standardized on Open Firmware instead, but that ship sailed a long time ago...
I find it hard to imagine that 90k is a serious amount of storage for something that is going to include a multi-MB Linux kernel. This isn't code that lives in SPL or TPL where severe size restrictions apply.
In one of those cases where I need to pop back in to the other (Nokia N900 specific) thread and see if the big size reduction really was just disabling EFI_LOADER, it's perhaps just one of those "fun" things about Kconfig and anything other than "make oldconfig" for spotting new config options that default to enabled.
Yes it will be interesting to see what you find there. My results on nokia_rx51 were something like this:
default arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0 rodata +10989.0 text +109846.0
without ebbr arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 rodata +5333.0 text +29712.0
with various other things: CONFIG_OF_LIBFDT_ASSUME_MASK=7 # CONFIG_OF_TRANSLATE is not set # CONFIG_SIMPLE_BUS is not set # CONFIG_TI_SYSC is not set # CONFIG_CMD_FDT is not set
arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rodata+3274.0 text +15552.0
(Mark, in the same email:)
FIT simply isn't fit for purpose (pun intended). It only really works for booting Linux, and forces people to combine u-boot, kernel, initial ramdisk and other firmware components into a single image. That is really undesirable as:
- This makes it sigificantly harder to update individual components of such an image. Making it hard to update a kernel is obviously a serious security risk.
- This makes it impossible to build an OS install image that works om multiple boards/SoCs.
I would really like to understand this better. The whole thing is a complete mystery to me.
Firstly I have sometimes fiddled with booting other OSes using FIT. It seemed OK. I can't see why it only works with Linux.
Well, you could of course rework the boot flow of other OSes such that booting them includes some sort of FIT if you really wanted to. I But an OS like OpenBSD comes with its own bootloader that is essential in the boot flow. On OpenBSD armv7/arm64/riscv64 it adds some essential properties to the device tree. Besides, the kernel itself relies on a valid EFI memory map.
Secondly, I don't expect that U-Boot itself would be in the FIT.
So the FIT would only contain the OS kernel and other OS components? What about the FIT that is used on some arm64 platforms to combine U-Boot and TF-A? I guess you can have multiple FITs...
Thirdly, do you really want the kernel and initrd to be separate? At least in the systems I have used, they are built together, even having the same name, e.g.:
initrd.img-5.10.40-1rodete1-amd64 System.map-5.10.40-1rodete1-amd64 vmlinuz-5.10.28-1rodete2-amd64
I don't really use Linux on these platforms. But I'd expect the normal package management tools of my Linux distribution to build those as necessary and place them in the root file system where the bootloader picks them up. And as a distro developer, I'd like to have the same approach work on all Linux systems, regardless the specific firmware they're running (EDK2, U-Boot or something completely different). Ideally that wouldn't even depend on the architecture.
Now Armbian takes a different approach, and does treat most systems they provide as special snowflakes, providing flash images for each board. But that doesn't scale and makes for a fairly crappy user experience. They don't always support booting a mainline kernel. And updating the kernel often requires installing special packages.
Finally, for the firmware components, do you mean system firmware? If so, I would expect it to be more convenient to distribute updates to that separately, although I suppose they could be combined with the kernel if the combinatorial explosion can be contained. What is the problem, exactly? (If you mean peripheral firmware, I would expect fwupd to handle that.)
I guess I mean system firmware. Essentially everything that runs on the system before my OS bootloader runs. So for me, U-Boot is part of the system firmware even if it sometimes happens to live on removable media.
What exactly is impossible? Can you please be more specific?
So let me explain what we want for OpenBSD. We really want a uniform user experience across platforms, and don't want to maintain different codepaths for special snowflake platforms that might exist for a specific architecture.
Installing OpenBSD on a machine should be as simple as dd'ing the installer to some boot media, plugging it in and powering the machine on. Now this is somewhat tricky to achieve on some hardware targetted by U-Boot as they don't come with usable system firmware on the board itself. But on those boards you can mostly get away with having U-Boot on uSD or eMMC and the OS installer on USB.
Updating the OpenBSD kernel should be as simple as copying the kernel to /bsd. Since the root filesystem uses the UFS/FFS filesystem, this means that whatever we use as a bootloader must be able to read from that filesystem. To make sure the kernel is properly seeded with entropy, the OpenBSD bootloader has some additional tricks up its sleeve. It will replace a special segment in the kernel with random data before handing control to the kernel. On platforms that support it, it will try to use a firmware-provided RNG to do this (and EFI supports this) but also mix in some random data from a file on the UFS/FFS filesystem. It will actually mark that file as "used" after reading it to throw a warning when the file is reused when the machine is rebooted (it should have been filled with fresh new entropy). So you really need to use the OpenBSD bootloader instead loading an OpenBSD kernel directly from system firmware.
Updating the OpenBSD bootloader should be as simple as running installboot(8) from within the OS.
This all works on pretty much any architecture that OpenBSD supports. And right now, thanks to EFI_LOADER support in U-Boot, we have a nearly uniform boot flow on amd64, arm64, armv7 and riscv64.
FIT is just a container. It seems to have been rejected by the EFI crew at some point. Perhaps I just need to try to use it with one of the distros out there, to actually understand what is going on here. But any help is appreciated.
It just doesn't make sense for us to use a container just because the system firmware (U-Boot) insists on it. The kernel lives in the root UFS/FFS filesystem and the bootloader lives on an MS-DOS filesystem on the root disk.
EFI_LOADER is required by EBBR, a new boot standard which aims to bring in UEFI protocols to U-Boot. But EBRR is not required for booting. U-Boot already provides support for FIT, the 'bootm' command and a suitable hand-off to Linux. EBRR has made the decision to create a parallel infrastructure, e.g. does not use FIT, nor U-Boot's signing infrastructure.
EFI_LOADER is required to boot FreeBSD and OpenBSD on several platforms as well as generic Linux distros. For example OpenBSD/armv7, OpenBSD/arm64 and OpenBSD/riscv64 all rely on EFI_LOADER to boot and have done so for the last 4 years. The fact that ARM has embraced UEFI as an embedded boot standard and branded it EBBR really isn't all that relevant.
To be clear here, I like EFI_LOADER. I too do wish some other technologies had become dominant for technical rather than inertia reasons, but here we are. Having played around with it on aarch64, there are some pretty nice comes-along-with parts to it.
What I hadn't seen, and am only a little skeptical of still, is how far backwards in generations it's going to be used on. The general wish is that users nor off the shelf OS groups need to rebuild U-Boot for a given board, and instead it just works. The number of new designs for 32bit parts is no where near the number of new designs for 64bit parts. So what we're seeing in U-Boot now is people updating support on their older designs, and not necessarily caring about using EFI_LOADER.
In a reply to one of the patches in this series, Heinrich mentions a few problems that need resolving (devices for partitions and file handles). Both of those features should first be added to U-Boot, so EFI can then use that support. In general, EFI has tried to work beside driver model, creating its own parallel tables, etc. I have tried to influence this at various points along the way, including at the start and I'm happy to dig out those threads if it helps. But I wasn't kidding. it really needs to be addressed. I would love to see Linaro (for example) organise something here and take this on. I am very happy to help.
Regards, Simon
Hi Mark,
On Mon, 28 Jun 2021 at 11:49, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Mon, 28 Jun 2021 08:18:26 -0600
Hi Tom, Mark,
On Mon, 28 Jun 2021 at 07:37, Tom Rini trini@konsulko.com wrote:
On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Sun, 27 Jun 2021 19:48:34 -0600
It has come to light that EFI_LOADER adds an extraordinary amount of code to U-Boot. For example, with nokia_rx51 the size delta is about 90KB. About 170 boards explicitly disable the option, but is is clear that many more could, thus saving image size and boot time.
EFI_LOADER used to be a lot smaller. It is great to see that over the years UEFI support has become more complete, but a lot of that new code implements features that are not at all essential for just booting an OS from storage. If that growth leads to the suggestion to disable EFI_LOADER completely by default, we're putting the cart before the horse.
Well, I see I forgot to prefix my patch with RFC, but I hadn't found EFI_LOADER being used in the wild on armv7, but wasn't sure about the BSD families. I did see that Debian doesn't use it, and that Armbian doesn't even use it on aarch64.
The current situation is affecting U-Boot's image as a svelt bootloader.
Really? I know UEFI has a bad reputation in the Open Source world, and some of its Microsoft-isms are really annoying (yay UCS-2). But it works, it provides a standardized approach across several platforms (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally I'd wish the industry had standardized on Open Firmware instead, but that ship sailed a long time ago...
I find it hard to imagine that 90k is a serious amount of storage for something that is going to include a multi-MB Linux kernel. This isn't code that lives in SPL or TPL where severe size restrictions apply.
In one of those cases where I need to pop back in to the other (Nokia N900 specific) thread and see if the big size reduction really was just disabling EFI_LOADER, it's perhaps just one of those "fun" things about Kconfig and anything other than "make oldconfig" for spotting new config options that default to enabled.
Yes it will be interesting to see what you find there. My results on nokia_rx51 were something like this:
default arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0 rodata +10989.0 text +109846.0
without ebbr arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 rodata +5333.0 text +29712.0
with various other things: CONFIG_OF_LIBFDT_ASSUME_MASK=7 # CONFIG_OF_TRANSLATE is not set # CONFIG_SIMPLE_BUS is not set # CONFIG_TI_SYSC is not set # CONFIG_CMD_FDT is not set
arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rodata+3274.0 text +15552.0
(Mark, in the same email:)
FIT simply isn't fit for purpose (pun intended). It only really works for booting Linux, and forces people to combine u-boot, kernel, initial ramdisk and other firmware components into a single image. That is really undesirable as:
- This makes it sigificantly harder to update individual components of such an image. Making it hard to update a kernel is obviously a serious security risk.
- This makes it impossible to build an OS install image that works om multiple boards/SoCs.
I would really like to understand this better. The whole thing is a complete mystery to me.
Firstly I have sometimes fiddled with booting other OSes using FIT. It seemed OK. I can't see why it only works with Linux.
Well, you could of course rework the boot flow of other OSes such that booting them includes some sort of FIT if you really wanted to. I But an OS like OpenBSD comes with its own bootloader that is essential in the boot flow. On OpenBSD armv7/arm64/riscv64 it adds some essential properties to the device tree. Besides, the kernel itself relies on a valid EFI memory map.
(thanks for taking the time to reply with so much detail)
That's news to me; when did that happen? Anyway, I doubt that adds a lot of code.
Secondly, I don't expect that U-Boot itself would be in the FIT.
So the FIT would only contain the OS kernel and other OS components? What about the FIT that is used on some arm64 platforms to combine U-Boot and TF-A? I guess you can have multiple FITs...
Thirdly, do you really want the kernel and initrd to be separate? At least in the systems I have used, they are built together, even having the same name, e.g.:
initrd.img-5.10.40-1rodete1-amd64 System.map-5.10.40-1rodete1-amd64 vmlinuz-5.10.28-1rodete2-amd64
I don't really use Linux on these platforms. But I'd expect the normal package management tools of my Linux distribution to build those as necessary and place them in the root file system where the bootloader picks them up. And as a distro developer, I'd like to have the same approach work on all Linux systems, regardless the specific firmware they're running (EDK2, U-Boot or something completely different). Ideally that wouldn't even depend on the architecture.
Now Armbian takes a different approach, and does treat most systems they provide as special snowflakes, providing flash images for each board. But that doesn't scale and makes for a fairly crappy user experience. They don't always support booting a mainline kernel. And updating the kernel often requires installing special packages.
I don't think it is a requirement that things have to be special snowflakes. There are a few common boot flows to support and we can put that support in U-Boot and in userspace, without needing to make everything special.
Finally, for the firmware components, do you mean system firmware? If so, I would expect it to be more convenient to distribute updates to that separately, although I suppose they could be combined with the kernel if the combinatorial explosion can be contained. What is the problem, exactly? (If you mean peripheral firmware, I would expect fwupd to handle that.)
I guess I mean system firmware. Essentially everything that runs on the system before my OS bootloader runs. So for me, U-Boot is part of the system firmware even if it sometimes happens to live on removable media.
What exactly is impossible? Can you please be more specific?
So let me explain what we want for OpenBSD. We really want a uniform user experience across platforms, and don't want to maintain different codepaths for special snowflake platforms that might exist for a specific architecture.
Installing OpenBSD on a machine should be as simple as dd'ing the installer to some boot media, plugging it in and powering the machine on. Now this is somewhat tricky to achieve on some hardware targetted by U-Boot as they don't come with usable system firmware on the board itself. But on those boards you can mostly get away with having U-Boot on uSD or eMMC and the OS installer on USB.
Updating the OpenBSD kernel should be as simple as copying the kernel to /bsd. Since the root filesystem uses the UFS/FFS filesystem, this means that whatever we use as a bootloader must be able to read from that filesystem. To make sure the kernel is properly seeded with entropy, the OpenBSD bootloader has some additional tricks up its sleeve. It will replace a special segment in the kernel with random data before handing control to the kernel. On platforms that support it, it will try to use a firmware-provided RNG to do this (and EFI supports this) but also mix in some random data from a file on the UFS/FFS filesystem. It will actually mark that file as "used" after reading it to throw a warning when the file is reused when the machine is rebooted (it should have been filled with fresh new entropy). So you really need to use the OpenBSD bootloader instead loading an OpenBSD kernel directly from system firmware.
Updating the OpenBSD bootloader should be as simple as running installboot(8) from within the OS.
This all works on pretty much any architecture that OpenBSD supports. And right now, thanks to EFI_LOADER support in U-Boot, we have a nearly uniform boot flow on amd64, arm64, armv7 and riscv64.
OK I see. Really it sounds like you have a pre-kernel loader. The functionality (some fresh random data) could just as easily be provided by U-Boot directly, with vastly less code and complexity. But I do understand that trying to design across a whole system is a pain, and it is attractive to try to use what hooks exist already to do what you want.
How do you do verified boot?
FIT is just a container. It seems to have been rejected by the EFI crew at some point. Perhaps I just need to try to use it with one of the distros out there, to actually understand what is going on here. But any help is appreciated.
It just doesn't make sense for us to use a container just because the system firmware (U-Boot) insists on it. The kernel lives in the root UFS/FFS filesystem and the bootloader lives on an MS-DOS filesystem on the root disk.
It isn't so much that U-Boot insists on it. It is quite happy to load a kernel and initrd separately. But it does make verification harder and I assume it makes upgrades harder since there are multiple files to install. FIT is just such a nice format for packaging kernels and related things. It sounds like you could use FIT and everything you said above would still be true.
[..]
Regards, Simon
From: Simon Glass sjg@chromium.org Date: Fri, 2 Jul 2021 13:05:20 -0600 Cc: Tom Rini trini@konsulko.com, U-Boot Mailing List u-boot@lists.denx.de, Pali Rohár pali@kernel.org, Heinrich Schuchardt xypron.glpk@gmx.de, Ilias Apalodimas ilias.apalodimas@linaro.org, Alex Graf agraf@csgraf.de, Masahiro Yamada yamada.masahiro@socionext.com Content-Type: text/plain; charset="UTF-8"
Hi Mark,
On Mon, 28 Jun 2021 at 11:49, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Mon, 28 Jun 2021 08:18:26 -0600
Hi Tom, Mark,
On Mon, 28 Jun 2021 at 07:37, Tom Rini trini@konsulko.com wrote:
On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Sun, 27 Jun 2021 19:48:34 -0600
It has come to light that EFI_LOADER adds an extraordinary amount of code to U-Boot. For example, with nokia_rx51 the size delta is about 90KB. About 170 boards explicitly disable the option, but is is clear that many more could, thus saving image size and boot time.
EFI_LOADER used to be a lot smaller. It is great to see that over the years UEFI support has become more complete, but a lot of that new code implements features that are not at all essential for just booting an OS from storage. If that growth leads to the suggestion to disable EFI_LOADER completely by default, we're putting the cart before the horse.
Well, I see I forgot to prefix my patch with RFC, but I hadn't found EFI_LOADER being used in the wild on armv7, but wasn't sure about the BSD families. I did see that Debian doesn't use it, and that Armbian doesn't even use it on aarch64.
The current situation is affecting U-Boot's image as a svelt bootloader.
Really? I know UEFI has a bad reputation in the Open Source world, and some of its Microsoft-isms are really annoying (yay UCS-2). But it works, it provides a standardized approach across several platforms (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally I'd wish the industry had standardized on Open Firmware instead, but that ship sailed a long time ago...
I find it hard to imagine that 90k is a serious amount of storage for something that is going to include a multi-MB Linux kernel. This isn't code that lives in SPL or TPL where severe size restrictions apply.
In one of those cases where I need to pop back in to the other (Nokia N900 specific) thread and see if the big size reduction really was just disabling EFI_LOADER, it's perhaps just one of those "fun" things about Kconfig and anything other than "make oldconfig" for spotting new config options that default to enabled.
Yes it will be interesting to see what you find there. My results on nokia_rx51 were something like this:
default arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0 rodata +10989.0 text +109846.0
without ebbr arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 rodata +5333.0 text +29712.0
with various other things: CONFIG_OF_LIBFDT_ASSUME_MASK=7 # CONFIG_OF_TRANSLATE is not set # CONFIG_SIMPLE_BUS is not set # CONFIG_TI_SYSC is not set # CONFIG_CMD_FDT is not set
arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rodata+3274.0 text +15552.0
(Mark, in the same email:)
FIT simply isn't fit for purpose (pun intended). It only really works for booting Linux, and forces people to combine u-boot, kernel, initial ramdisk and other firmware components into a single image. That is really undesirable as:
- This makes it sigificantly harder to update individual components of such an image. Making it hard to update a kernel is obviously a serious security risk.
- This makes it impossible to build an OS install image that works om multiple boards/SoCs.
I would really like to understand this better. The whole thing is a complete mystery to me.
Firstly I have sometimes fiddled with booting other OSes using FIT. It seemed OK. I can't see why it only works with Linux.
Well, you could of course rework the boot flow of other OSes such that booting them includes some sort of FIT if you really wanted to. I But an OS like OpenBSD comes with its own bootloader that is essential in the boot flow. On OpenBSD armv7/arm64/riscv64 it adds some essential properties to the device tree. Besides, the kernel itself relies on a valid EFI memory map.
(thanks for taking the time to reply with so much detail)
That's news to me; when did that happen? Anyway, I doubt that adds a lot of code.
Shortly after EFI_LOADER support was added to U-Boot and there was a clear consensus that EFI_LOADER support was going to be enabled by default on armv7 and armv8 targets. My initial commit of the EFI bootloader for armv7 is from May 2016.
Secondly, I don't expect that U-Boot itself would be in the FIT.
So the FIT would only contain the OS kernel and other OS components? What about the FIT that is used on some arm64 platforms to combine U-Boot and TF-A? I guess you can have multiple FITs...
Thirdly, do you really want the kernel and initrd to be separate? At least in the systems I have used, they are built together, even having the same name, e.g.:
initrd.img-5.10.40-1rodete1-amd64 System.map-5.10.40-1rodete1-amd64 vmlinuz-5.10.28-1rodete2-amd64
I don't really use Linux on these platforms. But I'd expect the normal package management tools of my Linux distribution to build those as necessary and place them in the root file system where the bootloader picks them up. And as a distro developer, I'd like to have the same approach work on all Linux systems, regardless the specific firmware they're running (EDK2, U-Boot or something completely different). Ideally that wouldn't even depend on the architecture.
Now Armbian takes a different approach, and does treat most systems they provide as special snowflakes, providing flash images for each board. But that doesn't scale and makes for a fairly crappy user experience. They don't always support booting a mainline kernel. And updating the kernel often requires installing special packages.
I don't think it is a requirement that things have to be special snowflakes. There are a few common boot flows to support and we can put that support in U-Boot and in userspace, without needing to make everything special.
Finally, for the firmware components, do you mean system firmware? If so, I would expect it to be more convenient to distribute updates to that separately, although I suppose they could be combined with the kernel if the combinatorial explosion can be contained. What is the problem, exactly? (If you mean peripheral firmware, I would expect fwupd to handle that.)
I guess I mean system firmware. Essentially everything that runs on the system before my OS bootloader runs. So for me, U-Boot is part of the system firmware even if it sometimes happens to live on removable media.
What exactly is impossible? Can you please be more specific?
So let me explain what we want for OpenBSD. We really want a uniform user experience across platforms, and don't want to maintain different codepaths for special snowflake platforms that might exist for a specific architecture.
Installing OpenBSD on a machine should be as simple as dd'ing the installer to some boot media, plugging it in and powering the machine on. Now this is somewhat tricky to achieve on some hardware targetted by U-Boot as they don't come with usable system firmware on the board itself. But on those boards you can mostly get away with having U-Boot on uSD or eMMC and the OS installer on USB.
Updating the OpenBSD kernel should be as simple as copying the kernel to /bsd. Since the root filesystem uses the UFS/FFS filesystem, this means that whatever we use as a bootloader must be able to read from that filesystem. To make sure the kernel is properly seeded with entropy, the OpenBSD bootloader has some additional tricks up its sleeve. It will replace a special segment in the kernel with random data before handing control to the kernel. On platforms that support it, it will try to use a firmware-provided RNG to do this (and EFI supports this) but also mix in some random data from a file on the UFS/FFS filesystem. It will actually mark that file as "used" after reading it to throw a warning when the file is reused when the machine is rebooted (it should have been filled with fresh new entropy). So you really need to use the OpenBSD bootloader instead loading an OpenBSD kernel directly from system firmware.
Updating the OpenBSD bootloader should be as simple as running installboot(8) from within the OS.
This all works on pretty much any architecture that OpenBSD supports. And right now, thanks to EFI_LOADER support in U-Boot, we have a nearly uniform boot flow on amd64, arm64, armv7 and riscv64.
OK I see. Really it sounds like you have a pre-kernel loader. The functionality (some fresh random data) could just as easily be provided by U-Boot directly, with vastly less code and complexity. But I do understand that trying to design across a whole system is a pain, and it is attractive to try to use what hooks exist already to do what you want.
What do you mean with vastly less code and complexity. At this point 70% of the OpenBSD bootloader code is shared between most of the architectures OpenBSD runs on (alpha, amd64, arm64, armv7, hppa, i386, powerpc, riscv64, sh, sparc64). And on platforms that support UEFI (amd64, arm64, armv7 and riscv64) this is closer to 95% shared code.
Having OS-dependent code in U-Boot doesn't work. FreeBSD tried that with the U-Boot API. It was never enabled by default, and got broken all the time.
How do you do verified boot?
We don't. I don't think it makes sense for an Open Source OS where people like to tinker with things. And it gets in the way of some of our own security features. OpenBSD relinks the kernel upon every boot as a defence against attacks that depend on the kernel address space layout. Doing that in an environment where all code needs to be signed is a big challenge.
There is a comany that has products based on OpenBSD. They do verified boot. I'm not really familliar with the details, but presumably they turned off address space randomization and I believe it is based on EFI_LOADER support. Patrick Wildt contributed patches to implement this to U-Boot before the Linaro folks did their full-blown UEFI-based implementation.
FIT is just a container. It seems to have been rejected by the EFI crew at some point. Perhaps I just need to try to use it with one of the distros out there, to actually understand what is going on here. But any help is appreciated.
It just doesn't make sense for us to use a container just because the system firmware (U-Boot) insists on it. The kernel lives in the root UFS/FFS filesystem and the bootloader lives on an MS-DOS filesystem on the root disk.
It isn't so much that U-Boot insists on it. It is quite happy to load a kernel and initrd separately. But it does make verification harder and I assume it makes upgrades harder since there are multiple files to install. FIT is just such a nice format for packaging kernels and related things. It sounds like you could use FIT and everything you said above would still be true.
It would mean a kernel update would need to update the FIT container. But only on boards that use U-Boot to boot, since nobody else supports it. That isn't helpful to us.
Cheers,
Mark
On Fri, Jul 02, 2021 at 09:48:27PM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Fri, 2 Jul 2021 13:05:20 -0600 Cc: Tom Rini trini@konsulko.com, U-Boot Mailing List u-boot@lists.denx.de, Pali Rohár pali@kernel.org, Heinrich Schuchardt xypron.glpk@gmx.de, Ilias Apalodimas ilias.apalodimas@linaro.org, Alex Graf agraf@csgraf.de, Masahiro Yamada yamada.masahiro@socionext.com Content-Type: text/plain; charset="UTF-8"
Hi Mark,
On Mon, 28 Jun 2021 at 11:49, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Mon, 28 Jun 2021 08:18:26 -0600
Hi Tom, Mark,
On Mon, 28 Jun 2021 at 07:37, Tom Rini trini@konsulko.com wrote:
On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote:
> From: Simon Glass sjg@chromium.org > Date: Sun, 27 Jun 2021 19:48:34 -0600 > > It has come to light that EFI_LOADER adds an extraordinary amount of > code to U-Boot. For example, with nokia_rx51 the size delta is about > 90KB. About 170 boards explicitly disable the option, but is is clear > that many more could, thus saving image size and boot time.
EFI_LOADER used to be a lot smaller. It is great to see that over the years UEFI support has become more complete, but a lot of that new code implements features that are not at all essential for just booting an OS from storage. If that growth leads to the suggestion to disable EFI_LOADER completely by default, we're putting the cart before the horse.
Well, I see I forgot to prefix my patch with RFC, but I hadn't found EFI_LOADER being used in the wild on armv7, but wasn't sure about the BSD families. I did see that Debian doesn't use it, and that Armbian doesn't even use it on aarch64.
> The current situation is affecting U-Boot's image as a svelt bootloader.
Really? I know UEFI has a bad reputation in the Open Source world, and some of its Microsoft-isms are really annoying (yay UCS-2). But it works, it provides a standardized approach across several platforms (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally I'd wish the industry had standardized on Open Firmware instead, but that ship sailed a long time ago...
I find it hard to imagine that 90k is a serious amount of storage for something that is going to include a multi-MB Linux kernel. This isn't code that lives in SPL or TPL where severe size restrictions apply.
In one of those cases where I need to pop back in to the other (Nokia N900 specific) thread and see if the big size reduction really was just disabling EFI_LOADER, it's perhaps just one of those "fun" things about Kconfig and anything other than "make oldconfig" for spotting new config options that default to enabled.
Yes it will be interesting to see what you find there. My results on nokia_rx51 were something like this:
default arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0 rodata +10989.0 text +109846.0
without ebbr arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 rodata +5333.0 text +29712.0
with various other things: CONFIG_OF_LIBFDT_ASSUME_MASK=7 # CONFIG_OF_TRANSLATE is not set # CONFIG_SIMPLE_BUS is not set # CONFIG_TI_SYSC is not set # CONFIG_CMD_FDT is not set
arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rodata+3274.0 text +15552.0
(Mark, in the same email:)
FIT simply isn't fit for purpose (pun intended). It only really works for booting Linux, and forces people to combine u-boot, kernel, initial ramdisk and other firmware components into a single image. That is really undesirable as:
- This makes it sigificantly harder to update individual components of such an image. Making it hard to update a kernel is obviously a serious security risk.
- This makes it impossible to build an OS install image that works om multiple boards/SoCs.
I would really like to understand this better. The whole thing is a complete mystery to me.
Firstly I have sometimes fiddled with booting other OSes using FIT. It seemed OK. I can't see why it only works with Linux.
Well, you could of course rework the boot flow of other OSes such that booting them includes some sort of FIT if you really wanted to. I But an OS like OpenBSD comes with its own bootloader that is essential in the boot flow. On OpenBSD armv7/arm64/riscv64 it adds some essential properties to the device tree. Besides, the kernel itself relies on a valid EFI memory map.
(thanks for taking the time to reply with so much detail)
That's news to me; when did that happen? Anyway, I doubt that adds a lot of code.
Shortly after EFI_LOADER support was added to U-Boot and there was a clear consensus that EFI_LOADER support was going to be enabled by default on armv7 and armv8 targets. My initial commit of the EFI bootloader for armv7 is from May 2016.
Secondly, I don't expect that U-Boot itself would be in the FIT.
So the FIT would only contain the OS kernel and other OS components? What about the FIT that is used on some arm64 platforms to combine U-Boot and TF-A? I guess you can have multiple FITs...
Thirdly, do you really want the kernel and initrd to be separate? At least in the systems I have used, they are built together, even having the same name, e.g.:
initrd.img-5.10.40-1rodete1-amd64 System.map-5.10.40-1rodete1-amd64 vmlinuz-5.10.28-1rodete2-amd64
I don't really use Linux on these platforms. But I'd expect the normal package management tools of my Linux distribution to build those as necessary and place them in the root file system where the bootloader picks them up. And as a distro developer, I'd like to have the same approach work on all Linux systems, regardless the specific firmware they're running (EDK2, U-Boot or something completely different). Ideally that wouldn't even depend on the architecture.
Now Armbian takes a different approach, and does treat most systems they provide as special snowflakes, providing flash images for each board. But that doesn't scale and makes for a fairly crappy user experience. They don't always support booting a mainline kernel. And updating the kernel often requires installing special packages.
I don't think it is a requirement that things have to be special snowflakes. There are a few common boot flows to support and we can put that support in U-Boot and in userspace, without needing to make everything special.
Finally, for the firmware components, do you mean system firmware? If so, I would expect it to be more convenient to distribute updates to that separately, although I suppose they could be combined with the kernel if the combinatorial explosion can be contained. What is the problem, exactly? (If you mean peripheral firmware, I would expect fwupd to handle that.)
I guess I mean system firmware. Essentially everything that runs on the system before my OS bootloader runs. So for me, U-Boot is part of the system firmware even if it sometimes happens to live on removable media.
What exactly is impossible? Can you please be more specific?
So let me explain what we want for OpenBSD. We really want a uniform user experience across platforms, and don't want to maintain different codepaths for special snowflake platforms that might exist for a specific architecture.
Installing OpenBSD on a machine should be as simple as dd'ing the installer to some boot media, plugging it in and powering the machine on. Now this is somewhat tricky to achieve on some hardware targetted by U-Boot as they don't come with usable system firmware on the board itself. But on those boards you can mostly get away with having U-Boot on uSD or eMMC and the OS installer on USB.
Updating the OpenBSD kernel should be as simple as copying the kernel to /bsd. Since the root filesystem uses the UFS/FFS filesystem, this means that whatever we use as a bootloader must be able to read from that filesystem. To make sure the kernel is properly seeded with entropy, the OpenBSD bootloader has some additional tricks up its sleeve. It will replace a special segment in the kernel with random data before handing control to the kernel. On platforms that support it, it will try to use a firmware-provided RNG to do this (and EFI supports this) but also mix in some random data from a file on the UFS/FFS filesystem. It will actually mark that file as "used" after reading it to throw a warning when the file is reused when the machine is rebooted (it should have been filled with fresh new entropy). So you really need to use the OpenBSD bootloader instead loading an OpenBSD kernel directly from system firmware.
Updating the OpenBSD bootloader should be as simple as running installboot(8) from within the OS.
This all works on pretty much any architecture that OpenBSD supports. And right now, thanks to EFI_LOADER support in U-Boot, we have a nearly uniform boot flow on amd64, arm64, armv7 and riscv64.
OK I see. Really it sounds like you have a pre-kernel loader. The functionality (some fresh random data) could just as easily be provided by U-Boot directly, with vastly less code and complexity. But I do understand that trying to design across a whole system is a pain, and it is attractive to try to use what hooks exist already to do what you want.
What do you mean with vastly less code and complexity. At this point 70% of the OpenBSD bootloader code is shared between most of the architectures OpenBSD runs on (alpha, amd64, arm64, armv7, hppa, i386, powerpc, riscv64, sh, sparc64). And on platforms that support UEFI (amd64, arm64, armv7 and riscv64) this is closer to 95% shared code.
Having OS-dependent code in U-Boot doesn't work. FreeBSD tried that with the U-Boot API. It was never enabled by default, and got broken all the time.
That's good to know and I believe validates why we want EFI_LOADER as much as possible. This is a good example of how real world OSes can make use of this to reduce their own overhead. And I think this also shows why we need EFI_LOADER, the U-boot API was never being sufficiently tested and most importantly never had anyone championing it's usage. That's not the case with the EFI API.
How do you do verified boot?
We don't. I don't think it makes sense for an Open Source OS where people like to tinker with things. And it gets in the way of some of our own security features. OpenBSD relinks the kernel upon every boot as a defence against attacks that depend on the kernel address space layout. Doing that in an environment where all code needs to be signed is a big challenge.
There is a comany that has products based on OpenBSD. They do verified boot. I'm not really familliar with the details, but presumably they turned off address space randomization and I believe it is based on EFI_LOADER support. Patrick Wildt contributed patches to implement this to U-Boot before the Linaro folks did their full-blown UEFI-based implementation.
That's good to know, thanks!
Hi Mark,
On Fri, 2 Jul 2021 at 13:48, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Fri, 2 Jul 2021 13:05:20 -0600 Cc: Tom Rini trini@konsulko.com, U-Boot Mailing List u-boot@lists.denx.de, Pali Rohár pali@kernel.org, Heinrich Schuchardt xypron.glpk@gmx.de, Ilias Apalodimas ilias.apalodimas@linaro.org, Alex Graf agraf@csgraf.de, Masahiro Yamada yamada.masahiro@socionext.com Content-Type: text/plain; charset="UTF-8"
Hi Mark,
On Mon, 28 Jun 2021 at 11:49, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Mon, 28 Jun 2021 08:18:26 -0600
Hi Tom, Mark,
On Mon, 28 Jun 2021 at 07:37, Tom Rini trini@konsulko.com wrote:
On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote:
> From: Simon Glass sjg@chromium.org > Date: Sun, 27 Jun 2021 19:48:34 -0600 > > It has come to light that EFI_LOADER adds an extraordinary amount of > code to U-Boot. For example, with nokia_rx51 the size delta is about > 90KB. About 170 boards explicitly disable the option, but is is clear > that many more could, thus saving image size and boot time.
EFI_LOADER used to be a lot smaller. It is great to see that over the years UEFI support has become more complete, but a lot of that new code implements features that are not at all essential for just booting an OS from storage. If that growth leads to the suggestion to disable EFI_LOADER completely by default, we're putting the cart before the horse.
Well, I see I forgot to prefix my patch with RFC, but I hadn't found EFI_LOADER being used in the wild on armv7, but wasn't sure about the BSD families. I did see that Debian doesn't use it, and that Armbian doesn't even use it on aarch64.
> The current situation is affecting U-Boot's image as a svelt bootloader.
Really? I know UEFI has a bad reputation in the Open Source world, and some of its Microsoft-isms are really annoying (yay UCS-2). But it works, it provides a standardized approach across several platforms (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally I'd wish the industry had standardized on Open Firmware instead, but that ship sailed a long time ago...
I find it hard to imagine that 90k is a serious amount of storage for something that is going to include a multi-MB Linux kernel. This isn't code that lives in SPL or TPL where severe size restrictions apply.
In one of those cases where I need to pop back in to the other (Nokia N900 specific) thread and see if the big size reduction really was just disabling EFI_LOADER, it's perhaps just one of those "fun" things about Kconfig and anything other than "make oldconfig" for spotting new config options that default to enabled.
Yes it will be interesting to see what you find there. My results on nokia_rx51 were something like this:
default arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0 rodata +10989.0 text +109846.0
without ebbr arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 rodata +5333.0 text +29712.0
with various other things: CONFIG_OF_LIBFDT_ASSUME_MASK=7 # CONFIG_OF_TRANSLATE is not set # CONFIG_SIMPLE_BUS is not set # CONFIG_TI_SYSC is not set # CONFIG_CMD_FDT is not set
arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rodata+3274.0 text +15552.0
(Mark, in the same email:)
FIT simply isn't fit for purpose (pun intended). It only really works for booting Linux, and forces people to combine u-boot, kernel, initial ramdisk and other firmware components into a single image. That is really undesirable as:
- This makes it sigificantly harder to update individual components of such an image. Making it hard to update a kernel is obviously a serious security risk.
- This makes it impossible to build an OS install image that works om multiple boards/SoCs.
I would really like to understand this better. The whole thing is a complete mystery to me.
Firstly I have sometimes fiddled with booting other OSes using FIT. It seemed OK. I can't see why it only works with Linux.
Well, you could of course rework the boot flow of other OSes such that booting them includes some sort of FIT if you really wanted to. I But an OS like OpenBSD comes with its own bootloader that is essential in the boot flow. On OpenBSD armv7/arm64/riscv64 it adds some essential properties to the device tree. Besides, the kernel itself relies on a valid EFI memory map.
(thanks for taking the time to reply with so much detail)
That's news to me; when did that happen? Anyway, I doubt that adds a lot of code.
Shortly after EFI_LOADER support was added to U-Boot and there was a clear consensus that EFI_LOADER support was going to be enabled by default on armv7 and armv8 targets. My initial commit of the EFI bootloader for armv7 is from May 2016.
OK, I am sad to hear that Linux is getting into a state where it cannot boot without EFI.
Secondly, I don't expect that U-Boot itself would be in the FIT.
So the FIT would only contain the OS kernel and other OS components? What about the FIT that is used on some arm64 platforms to combine U-Boot and TF-A? I guess you can have multiple FITs...
Thirdly, do you really want the kernel and initrd to be separate? At least in the systems I have used, they are built together, even having the same name, e.g.:
initrd.img-5.10.40-1rodete1-amd64 System.map-5.10.40-1rodete1-amd64 vmlinuz-5.10.28-1rodete2-amd64
I don't really use Linux on these platforms. But I'd expect the normal package management tools of my Linux distribution to build those as necessary and place them in the root file system where the bootloader picks them up. And as a distro developer, I'd like to have the same approach work on all Linux systems, regardless the specific firmware they're running (EDK2, U-Boot or something completely different). Ideally that wouldn't even depend on the architecture.
Now Armbian takes a different approach, and does treat most systems they provide as special snowflakes, providing flash images for each board. But that doesn't scale and makes for a fairly crappy user experience. They don't always support booting a mainline kernel. And updating the kernel often requires installing special packages.
I don't think it is a requirement that things have to be special snowflakes. There are a few common boot flows to support and we can put that support in U-Boot and in userspace, without needing to make everything special.
Finally, for the firmware components, do you mean system firmware? If so, I would expect it to be more convenient to distribute updates to that separately, although I suppose they could be combined with the kernel if the combinatorial explosion can be contained. What is the problem, exactly? (If you mean peripheral firmware, I would expect fwupd to handle that.)
I guess I mean system firmware. Essentially everything that runs on the system before my OS bootloader runs. So for me, U-Boot is part of the system firmware even if it sometimes happens to live on removable media.
What exactly is impossible? Can you please be more specific?
So let me explain what we want for OpenBSD. We really want a uniform user experience across platforms, and don't want to maintain different codepaths for special snowflake platforms that might exist for a specific architecture.
Installing OpenBSD on a machine should be as simple as dd'ing the installer to some boot media, plugging it in and powering the machine on. Now this is somewhat tricky to achieve on some hardware targetted by U-Boot as they don't come with usable system firmware on the board itself. But on those boards you can mostly get away with having U-Boot on uSD or eMMC and the OS installer on USB.
Updating the OpenBSD kernel should be as simple as copying the kernel to /bsd. Since the root filesystem uses the UFS/FFS filesystem, this means that whatever we use as a bootloader must be able to read from that filesystem. To make sure the kernel is properly seeded with entropy, the OpenBSD bootloader has some additional tricks up its sleeve. It will replace a special segment in the kernel with random data before handing control to the kernel. On platforms that support it, it will try to use a firmware-provided RNG to do this (and EFI supports this) but also mix in some random data from a file on the UFS/FFS filesystem. It will actually mark that file as "used" after reading it to throw a warning when the file is reused when the machine is rebooted (it should have been filled with fresh new entropy). So you really need to use the OpenBSD bootloader instead loading an OpenBSD kernel directly from system firmware.
Updating the OpenBSD bootloader should be as simple as running installboot(8) from within the OS.
This all works on pretty much any architecture that OpenBSD supports. And right now, thanks to EFI_LOADER support in U-Boot, we have a nearly uniform boot flow on amd64, arm64, armv7 and riscv64.
OK I see. Really it sounds like you have a pre-kernel loader. The functionality (some fresh random data) could just as easily be provided by U-Boot directly, with vastly less code and complexity. But I do understand that trying to design across a whole system is a pain, and it is attractive to try to use what hooks exist already to do what you want.
What do you mean with vastly less code and complexity. At this point 70% of the OpenBSD bootloader code is shared between most of the architectures OpenBSD runs on (alpha, amd64, arm64, armv7, hppa, i386, powerpc, riscv64, sh, sparc64). And on platforms that support UEFI (amd64, arm64, armv7 and riscv64) this is closer to 95% shared code.
I mean that IMO EFI makes the boot process extremely complex and non-deterministic. Perhaps no two devices are the same. It allows vendors to create arbitrary and proprietary features in between firmware and the OS with no shared code repo and no shared specifications or tests. From the side of distributions I can see what that is a nice feature, but I don't think it helps the industry.
Having OS-dependent code in U-Boot doesn't work. FreeBSD tried that with the U-Boot API. It was never enabled by default, and got broken all the time.
I was not suggesting OS-dependent code, just a set of defined features, so that if something is needed, it is specified and implemented, if supported. This isn't so different from EFI anyway, since what is actually supported can vary by platform. Overall I see a failure of imagination, perhaps due to the overall complexity of this space, with so many vendors, boards, etc.
How do you do verified boot?
We don't. I don't think it makes sense for an Open Source OS where people like to tinker with things. And it gets in the way of some of our own security features. OpenBSD relinks the kernel upon every boot as a defence against attacks that depend on the kernel address space layout. Doing that in an environment where all code needs to be signed is a big challenge.
There is a comany that has products based on OpenBSD. They do verified boot. I'm not really familliar with the details, but presumably they turned off address space randomization and I believe it is based on EFI_LOADER support. Patrick Wildt contributed patches to implement this to U-Boot before the Linaro folks did their full-blown UEFI-based implementation.
OK.
FIT is just a container. It seems to have been rejected by the EFI crew at some point. Perhaps I just need to try to use it with one of the distros out there, to actually understand what is going on here. But any help is appreciated.
It just doesn't make sense for us to use a container just because the system firmware (U-Boot) insists on it. The kernel lives in the root UFS/FFS filesystem and the bootloader lives on an MS-DOS filesystem on the root disk.
It isn't so much that U-Boot insists on it. It is quite happy to load a kernel and initrd separately. But it does make verification harder and I assume it makes upgrades harder since there are multiple files to install. FIT is just such a nice format for packaging kernels and related things. It sounds like you could use FIT and everything you said above would still be true.
It would mean a kernel update would need to update the FIT container. But only on boards that use U-Boot to boot, since nobody else supports it. That isn't helpful to us.
It is ironic that we have added 90KB of EFI support to U-Boot, but we apparently cannot add 20KB of FIT support to UEFI. This seems like some sort of failure of the open-source process.
Regards, Simon
On 6/28/21 3:37 PM, Tom Rini wrote:
On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote:
From: Simon Glass sjg@chromium.org Date: Sun, 27 Jun 2021 19:48:34 -0600
It has come to light that EFI_LOADER adds an extraordinary amount of code to U-Boot. For example, with nokia_rx51 the size delta is about 90KB. About 170 boards explicitly disable the option, but is is clear that many more could, thus saving image size and boot time.
EFI_LOADER used to be a lot smaller. It is great to see that over the years UEFI support has become more complete, but a lot of that new code implements features that are not at all essential for just booting an OS from storage. If that growth leads to the suggestion to disable EFI_LOADER completely by default, we're putting the cart before the horse.
Well, I see I forgot to prefix my patch with RFC, but I hadn't found EFI_LOADER being used in the wild on armv7, but wasn't sure about the BSD families. I did see that Debian doesn't use it, and that Armbian doesn't even use it on aarch64.
Debian and Ubuntu both offer booting via UEFI and GRUB on armv7 (see https://packages.ubuntu.com/hirsute/grub-efi-arm). You could use package flash-kernel instead if you wanted to avoid UEFI. It is just a question of how you decide to install your system. If you want the installer to automatically install GRUB, you must invoke it via UEFI.
Armbian uses the Debian repos. That lets you boot Armbian using UEFI and GRUB if you want to.
SUSE is another distro relying on UEFI and GRUB.
The current situation is affecting U-Boot's image as a svelt bootloader.
Really? I know UEFI has a bad reputation in the Open Source world, and some of its Microsoft-isms are really annoying (yay UCS-2). But it works, it provides a standardized approach across several platforms (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally I'd wish the industry had standardized on Open Firmware instead, but that ship sailed a long time ago...
I find it hard to imagine that 90k is a serious amount of storage for something that is going to include a multi-MB Linux kernel. This isn't code that lives in SPL or TPL where severe size restrictions apply.
In one of those cases where I need to pop back in to the other (Nokia N900 specific) thread and see if the big size reduction really was just disabling EFI_LOADER, it's perhaps just one of those "fun" things about Kconfig and anything other than "make oldconfig" for spotting new config options that default to enabled.
EFI_LOADER is required by EBBR, a new boot standard which aims to bring in UEFI protocols to U-Boot. But EBRR is not required for booting. U-Boot already provides support for FIT, the 'bootm' command and a suitable hand-off to Linux. EBRR has made the decision to create a parallel infrastructure, e.g. does not use FIT, nor U-Boot's signing infrastructure.
EFI_LOADER is required to boot FreeBSD and OpenBSD on several platforms as well as generic Linux distros. For example OpenBSD/armv7, OpenBSD/arm64 and OpenBSD/riscv64 all rely on EFI_LOADER to boot and have done so for the last 4 years. The fact that ARM has embraced UEFI as an embedded boot standard and branded it EBBR really isn't all that relevant.
To be clear here, I like EFI_LOADER. I too do wish some other technologies had become dominant for technical rather than inertia reasons, but here we are. Having played around with it on aarch64, there are some pretty nice comes-along-with parts to it.
What I hadn't seen, and am only a little skeptical of still, is how far backwards in generations it's going to be used on. The general wish is that users nor off the shelf OS groups need to rebuild U-Boot for a given board, and instead it just works. The number of new designs for 32bit parts is no where near the number of new designs for 64bit parts. So what we're seeing in U-Boot now is people updating support on their older designs, and not necessarily caring about using EFI_LOADER.
The question is not how old your board is. My i.MX6 Wandboard (bought 2013) and my Allwinner A20 Banana Pi (bought 2014) both run fine with UEFI and GRUB on Debian. The major divide is between systems running a distribution and IoT devices where you build your image via Yocto, OpenWRT, or the like.
Best regards
Heinrich
participants (6)
-
AKASHI Takahiro -
Heinrich Schuchardt -
Ilias Apalodimas -
Mark Kettenis -
Simon Glass -
Tom Rini