All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/7] efi: Various tidy-ups and drop the default
@ 2021-06-28  1:48 Simon Glass
  2021-06-28  1:48 ` [PATCH 1/7] configs: Resync with savedefconfig Simon Glass
                   ` (7 more replies)
  0 siblings, 8 replies; 34+ messages in thread
From: Simon Glass @ 2021-06-28  1:48 UTC (permalink / raw)
  To: U-Boot Mailing List
  Cc: Pali Rohár, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
	Simon Glass, Alexander Graf, Masahiro Yamada

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(-)

-- 
2.32.0.93.g670b81a890-goog


^ permalink raw reply	[flat|nested] 34+ messages in thread
* [PATCH 1/7] configs: Resync with savedefconfig
  2021-06-28  1:48 [PATCH 0/7] efi: Various tidy-ups and drop the default Simon Glass
@ 2021-06-28  1:48 ` Simon Glass
  2021-06-28  1:48 ` [PATCH 2/7] Makefile: Drop include/asm directory as well as symlink Simon Glass
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 34+ messages in thread
From: Simon Glass @ 2021-06-28  1:48 UTC (permalink / raw)
  To: U-Boot Mailing List
  Cc: Pali Rohár, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
	Simon Glass

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
-- 
2.32.0.93.g670b81a890-goog


^ permalink raw reply related	[flat|nested] 34+ messages in thread
* [PATCH 2/7] Makefile: Drop include/asm directory as well as symlink
  2021-06-28  1:48 [PATCH 0/7] efi: Various tidy-ups and drop the default Simon Glass
  2021-06-28  1:48 ` [PATCH 1/7] configs: Resync with savedefconfig Simon Glass
@ 2021-06-28  1:48 ` Simon Glass
  2021-06-28  1:48 ` [PATCH 3/7] disk: Tidy up #ifdefs in part_efi Simon Glass
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 34+ messages in thread
From: Simon Glass @ 2021-06-28  1:48 UTC (permalink / raw)
  To: U-Boot Mailing List
  Cc: Pali Rohár, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
	Simon Glass, Masahiro Yamada

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 \
-- 
2.32.0.93.g670b81a890-goog


^ permalink raw reply related	[flat|nested] 34+ messages in thread
* [PATCH 3/7] disk: Tidy up #ifdefs in part_efi
  2021-06-28  1:48 [PATCH 0/7] efi: Various tidy-ups and drop the default Simon Glass
  2021-06-28  1:48 ` [PATCH 1/7] configs: Resync with savedefconfig Simon Glass
  2021-06-28  1:48 ` [PATCH 2/7] Makefile: Drop include/asm directory as well as symlink Simon Glass
@ 2021-06-28  1:48 ` Simon Glass
  2021-06-28 11:20   ` Heinrich Schuchardt
  2021-06-28  1:48 ` [PATCH 4/7] Use LIB_UUID with ACPIGEN and FS_BTRFS Simon Glass
                   ` (4 subsequent siblings)
  7 siblings, 1 reply; 34+ messages in thread
From: Simon Glass @ 2021-06-28  1:48 UTC (permalink / raw)
  To: U-Boot Mailing List
  Cc: Pali Rohár, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
	Simon Glass

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 */
-- 
2.32.0.93.g670b81a890-goog


^ permalink raw reply related	[flat|nested] 34+ messages in thread
* [PATCH 4/7] Use LIB_UUID with ACPIGEN and FS_BTRFS
  2021-06-28  1:48 [PATCH 0/7] efi: Various tidy-ups and drop the default Simon Glass
                   ` (2 preceding siblings ...)
  2021-06-28  1:48 ` [PATCH 3/7] disk: Tidy up #ifdefs in part_efi Simon Glass
@ 2021-06-28  1:48 ` Simon Glass
  2021-06-28  1:48 ` [PATCH 5/7] Allow efi_loader header to be included always Simon Glass
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 34+ messages in thread
From: Simon Glass @ 2021-06-28  1:48 UTC (permalink / raw)
  To: U-Boot Mailing List
  Cc: Pali Rohár, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
	Simon Glass

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
-- 
2.32.0.93.g670b81a890-goog


^ permalink raw reply related	[flat|nested] 34+ messages in thread
* [PATCH 5/7] Allow efi_loader header to be included always
  2021-06-28  1:48 [PATCH 0/7] efi: Various tidy-ups and drop the default Simon Glass
                   ` (3 preceding siblings ...)
  2021-06-28  1:48 ` [PATCH 4/7] Use LIB_UUID with ACPIGEN and FS_BTRFS Simon Glass
@ 2021-06-28  1:48 ` Simon Glass
  2021-06-28 11:02   ` Heinrich Schuchardt
  2021-06-28  1:48 ` [PATCH 6/7] lib: Create a new Kconfig option for charset conversion Simon Glass
                   ` (2 subsequent siblings)
  7 siblings, 1 reply; 34+ messages in thread
From: Simon Glass @ 2021-06-28  1:48 UTC (permalink / raw)
  To: U-Boot Mailing List
  Cc: Pali Rohár, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
	Simon Glass

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.
  *
-- 
2.32.0.93.g670b81a890-goog


^ permalink raw reply related	[flat|nested] 34+ messages in thread
* [PATCH 6/7] lib: Create a new Kconfig option for charset conversion
  2021-06-28  1:48 [PATCH 0/7] efi: Various tidy-ups and drop the default Simon Glass
                   ` (4 preceding siblings ...)
  2021-06-28  1:48 ` [PATCH 5/7] Allow efi_loader header to be included always Simon Glass
@ 2021-06-28  1:48 ` Simon Glass
  2021-06-28 10:37   ` Heinrich Schuchardt
  2021-06-28  1:48 ` [PATCH 7/7] efi: Make EBBR optional Simon Glass
  2021-06-28  8:38 ` [PATCH 0/7] efi: Various tidy-ups and drop the default Mark Kettenis
  7 siblings, 1 reply; 34+ messages in thread
From: Simon Glass @ 2021-06-28  1:48 UTC (permalink / raw)
  To: U-Boot Mailing List
  Cc: Pali Rohár, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
	Simon Glass

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
-- 
2.32.0.93.g670b81a890-goog


^ permalink raw reply related	[flat|nested] 34+ messages in thread
* [PATCH 7/7] efi: Make EBBR optional
  2021-06-28  1:48 [PATCH 0/7] efi: Various tidy-ups and drop the default Simon Glass
                   ` (5 preceding siblings ...)
  2021-06-28  1:48 ` [PATCH 6/7] lib: Create a new Kconfig option for charset conversion Simon Glass
@ 2021-06-28  1:48 ` Simon Glass
  2021-06-28  9:48   ` Heinrich Schuchardt
  2021-06-28  8:38 ` [PATCH 0/7] efi: Various tidy-ups and drop the default Mark Kettenis
  7 siblings, 1 reply; 34+ messages in thread
From: Simon Glass @ 2021-06-28  1:48 UTC (permalink / raw)
  To: U-Boot Mailing List
  Cc: Pali Rohár, Heinrich Schuchardt, Ilias Apalodimas, Tom Rini,
	Simon Glass, Alexander Graf

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
-- 
2.32.0.93.g670b81a890-goog


^ permalink raw reply related	[flat|nested] 34+ messages in thread
* Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
  2021-06-28  1:48 [PATCH 0/7] efi: Various tidy-ups and drop the default Simon Glass
                   ` (6 preceding siblings ...)
  2021-06-28  1:48 ` [PATCH 7/7] efi: Make EBBR optional Simon Glass
@ 2021-06-28  8:38 ` Mark Kettenis
  2021-06-28  8:59   ` Ilias Apalodimas
  2021-06-28 13:37   ` Tom Rini
  7 siblings, 2 replies; 34+ messages in thread
From: Mark Kettenis @ 2021-06-28  8:38 UTC (permalink / raw)
  To: Simon Glass
  Cc: u-boot, pali, xypron.glpk, ilias.apalodimas, trini, sjg, agraf,
	yamada.masahiro

> 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
> 
> 

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
  2021-06-28  8:38 ` [PATCH 0/7] efi: Various tidy-ups and drop the default Mark Kettenis
@ 2021-06-28  8:59   ` Ilias Apalodimas
  2021-06-28 13:37   ` Tom Rini
  1 sibling, 0 replies; 34+ messages in thread
From: Ilias Apalodimas @ 2021-06-28  8:59 UTC (permalink / raw)
  To: Mark Kettenis
  Cc: Simon Glass, u-boot, pali, xypron.glpk, trini, agraf, yamada.masahiro

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

[...]

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 7/7] efi: Make EBBR optional
  2021-06-28  1:48 ` [PATCH 7/7] efi: Make EBBR optional Simon Glass
@ 2021-06-28  9:48   ` Heinrich Schuchardt
  2021-06-28 13:48     ` Tom Rini
  0 siblings, 1 reply; 34+ messages in thread
From: Heinrich Schuchardt @ 2021-06-28  9:48 UTC (permalink / raw)
  To: Simon Glass
  Cc: Pali Rohár, Ilias Apalodimas, Tom Rini, Alexander Graf,
	U-Boot Mailing List

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


^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 6/7] lib: Create a new Kconfig option for charset conversion
  2021-06-28  1:48 ` [PATCH 6/7] lib: Create a new Kconfig option for charset conversion Simon Glass
@ 2021-06-28 10:37   ` Heinrich Schuchardt
  0 siblings, 0 replies; 34+ messages in thread
From: Heinrich Schuchardt @ 2021-06-28 10:37 UTC (permalink / raw)
  To: Simon Glass
  Cc: Pali Rohár, Ilias Apalodimas, Tom Rini, U-Boot Mailing List,
	Faiz Abbas

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 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
>


^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 5/7] Allow efi_loader header to be included always
  2021-06-28  1:48 ` [PATCH 5/7] Allow efi_loader header to be included always Simon Glass
@ 2021-06-28 11:02   ` Heinrich Schuchardt
  0 siblings, 0 replies; 34+ messages in thread
From: Heinrich Schuchardt @ 2021-06-28 11:02 UTC (permalink / raw)
  To: Simon Glass
  Cc: Pali Rohár, Ilias Apalodimas, Tom Rini, U-Boot Mailing List,
	Alexander Graf

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);
>   /* 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.
>    *
>


^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 3/7] disk: Tidy up #ifdefs in part_efi
  2021-06-28  1:48 ` [PATCH 3/7] disk: Tidy up #ifdefs in part_efi Simon Glass
@ 2021-06-28 11:20   ` Heinrich Schuchardt
  2021-06-28 13:50     ` Tom Rini
  0 siblings, 1 reply; 34+ messages in thread
From: Heinrich Schuchardt @ 2021-06-28 11:20 UTC (permalink / raw)
  To: Simon Glass, U-Boot Mailing List
  Cc: Pali Rohár, Ilias Apalodimas, Tom Rini

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 */
>


^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
  2021-06-28  8:38 ` [PATCH 0/7] efi: Various tidy-ups and drop the default Mark Kettenis
  2021-06-28  8:59   ` Ilias Apalodimas
@ 2021-06-28 13:37   ` Tom Rini
  2021-06-28 14:18     ` Simon Glass
  2021-06-28 14:25     ` Heinrich Schuchardt
  1 sibling, 2 replies; 34+ messages in thread
From: Tom Rini @ 2021-06-28 13:37 UTC (permalink / raw)
  To: Mark Kettenis
  Cc: Simon Glass, u-boot, pali, xypron.glpk, ilias.apalodimas, agraf,
	yamada.masahiro

[-- Attachment #1: Type: text/plain, Size: 3648 bytes --]

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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 7/7] efi: Make EBBR optional
  2021-06-28  9:48   ` Heinrich Schuchardt
@ 2021-06-28 13:48     ` Tom Rini
  0 siblings, 0 replies; 34+ messages in thread
From: Tom Rini @ 2021-06-28 13:48 UTC (permalink / raw)
  To: Heinrich Schuchardt
  Cc: Simon Glass, Pali Rohár, Ilias Apalodimas, Alexander Graf,
	U-Boot Mailing List

[-- Attachment #1: Type: text/plain, Size: 1970 bytes --]

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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 3/7] disk: Tidy up #ifdefs in part_efi
  2021-06-28 11:20   ` Heinrich Schuchardt
@ 2021-06-28 13:50     ` Tom Rini
  2021-06-28 16:18       ` Heinrich Schuchardt
  0 siblings, 1 reply; 34+ messages in thread
From: Tom Rini @ 2021-06-28 13:50 UTC (permalink / raw)
  To: Heinrich Schuchardt, Michal Simek
  Cc: Simon Glass, U-Boot Mailing List, Pali Rohár, Ilias Apalodimas

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

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?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
  2021-06-28 13:37   ` Tom Rini
@ 2021-06-28 14:18     ` Simon Glass
  2021-06-28 15:20       ` Heinrich Schuchardt
  2021-06-28 17:49       ` Mark Kettenis
  2021-06-28 14:25     ` Heinrich Schuchardt
  1 sibling, 2 replies; 34+ messages in thread
From: Simon Glass @ 2021-06-28 14:18 UTC (permalink / raw)
  To: Tom Rini
  Cc: Mark Kettenis, U-Boot Mailing List, Pali Rohár,
	Heinrich Schuchardt, Ilias Apalodimas, Alex Graf,
	Masahiro Yamada

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

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
  2021-06-28 13:37   ` Tom Rini
  2021-06-28 14:18     ` Simon Glass
@ 2021-06-28 14:25     ` Heinrich Schuchardt
  1 sibling, 0 replies; 34+ messages in thread
From: Heinrich Schuchardt @ 2021-06-28 14:25 UTC (permalink / raw)
  To: Tom Rini
  Cc: Simon Glass, u-boot, pali, ilias.apalodimas, agraf,
	yamada.masahiro, Mark Kettenis

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


^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
  2021-06-28 14:18     ` Simon Glass
@ 2021-06-28 15:20       ` Heinrich Schuchardt
  2021-06-28 16:26         ` Simon Glass
  2021-06-28 17:49       ` Mark Kettenis
  1 sibling, 1 reply; 34+ messages in thread
From: Heinrich Schuchardt @ 2021-06-28 15:20 UTC (permalink / raw)
  To: Simon Glass, Tom Rini
  Cc: Mark Kettenis, U-Boot Mailing List, Pali Rohár,
	Ilias Apalodimas, Alex Graf, Masahiro Yamada

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

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 3/7] disk: Tidy up #ifdefs in part_efi
  2021-06-28 13:50     ` Tom Rini
@ 2021-06-28 16:18       ` Heinrich Schuchardt
  0 siblings, 0 replies; 34+ messages in thread
From: Heinrich Schuchardt @ 2021-06-28 16:18 UTC (permalink / raw)
  To: Tom Rini, Michal Simek
  Cc: Simon Glass, U-Boot Mailing List, Pali Rohár, Ilias Apalodimas

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

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
  2021-06-28 15:20       ` Heinrich Schuchardt
@ 2021-06-28 16:26         ` Simon Glass
  2021-06-28 17:09           ` Heinrich Schuchardt
  2021-06-28 17:27           ` Tom Rini
  0 siblings, 2 replies; 34+ messages in thread
From: Simon Glass @ 2021-06-28 16:26 UTC (permalink / raw)
  To: Heinrich Schuchardt
  Cc: Tom Rini, Mark Kettenis, U-Boot Mailing List, Pali Rohár,
	Ilias Apalodimas, Alex Graf, Masahiro Yamada

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

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
  2021-06-28 16:26         ` Simon Glass
@ 2021-06-28 17:09           ` Heinrich Schuchardt
  2021-06-28 18:02             ` Simon Glass
  2021-06-28 17:27           ` Tom Rini
  1 sibling, 1 reply; 34+ messages in thread
From: Heinrich Schuchardt @ 2021-06-28 17:09 UTC (permalink / raw)
  To: Simon Glass
  Cc: Tom Rini, Mark Kettenis, U-Boot Mailing List, Pali Rohár,
	Ilias Apalodimas, Alex Graf, Masahiro Yamada

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

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
  2021-06-28 16:26         ` Simon Glass
  2021-06-28 17:09           ` Heinrich Schuchardt
@ 2021-06-28 17:27           ` Tom Rini
  2021-06-28 18:08             ` Simon Glass
  1 sibling, 1 reply; 34+ messages in thread
From: Tom Rini @ 2021-06-28 17:27 UTC (permalink / raw)
  To: Simon Glass
  Cc: Heinrich Schuchardt, Mark Kettenis, U-Boot Mailing List,
	Pali Rohár, Ilias Apalodimas, Alex Graf, Masahiro Yamada

[-- Attachment #1: Type: text/plain, Size: 5673 bytes --]

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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
  2021-06-28 14:18     ` Simon Glass
  2021-06-28 15:20       ` Heinrich Schuchardt
@ 2021-06-28 17:49       ` Mark Kettenis
  2021-07-02 19:05         ` Simon Glass
  1 sibling, 1 reply; 34+ messages in thread
From: Mark Kettenis @ 2021-06-28 17:49 UTC (permalink / raw)
  To: Simon Glass
  Cc: trini, u-boot, pali, xypron.glpk, ilias.apalodimas, agraf,
	yamada.masahiro

> 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
> 

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
  2021-06-28 17:09           ` Heinrich Schuchardt
@ 2021-06-28 18:02             ` Simon Glass
  0 siblings, 0 replies; 34+ messages in thread
From: Simon Glass @ 2021-06-28 18:02 UTC (permalink / raw)
  To: Heinrich Schuchardt
  Cc: Tom Rini, Mark Kettenis, U-Boot Mailing List, Pali Rohár,
	Ilias Apalodimas, Alex Graf, Masahiro Yamada

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

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
  2021-06-28 17:27           ` Tom Rini
@ 2021-06-28 18:08             ` Simon Glass
  2021-06-29 12:56               ` AKASHI Takahiro
  0 siblings, 1 reply; 34+ messages in thread
From: Simon Glass @ 2021-06-28 18:08 UTC (permalink / raw)
  To: Tom Rini
  Cc: Heinrich Schuchardt, Mark Kettenis, U-Boot Mailing List,
	Pali Rohár, Ilias Apalodimas, Alex Graf, Masahiro Yamada

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

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
  2021-06-28 18:08             ` Simon Glass
@ 2021-06-29 12:56               ` AKASHI Takahiro
  2021-06-29 14:01                 ` Heinrich Schuchardt
  0 siblings, 1 reply; 34+ messages in thread
From: AKASHI Takahiro @ 2021-06-29 12:56 UTC (permalink / raw)
  To: Simon Glass
  Cc: Tom Rini, Heinrich Schuchardt, Mark Kettenis,
	U-Boot Mailing List, Pali Roh??r, Ilias Apalodimas, Alex Graf,
	Masahiro Yamada

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

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
  2021-06-29 12:56               ` AKASHI Takahiro
@ 2021-06-29 14:01                 ` Heinrich Schuchardt
  2021-06-29 14:14                   ` AKASHI Takahiro
  0 siblings, 1 reply; 34+ messages in thread
From: Heinrich Schuchardt @ 2021-06-29 14:01 UTC (permalink / raw)
  To: AKASHI Takahiro, Simon Glass, Tom Rini, Mark Kettenis,
	U-Boot Mailing List, Pali Roh??r, Ilias Apalodimas, Alex Graf,
	Masahiro Yamada

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


^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
  2021-06-29 14:01                 ` Heinrich Schuchardt
@ 2021-06-29 14:14                   ` AKASHI Takahiro
  0 siblings, 0 replies; 34+ messages in thread
From: AKASHI Takahiro @ 2021-06-29 14:14 UTC (permalink / raw)
  To: Heinrich Schuchardt
  Cc: Simon Glass, Tom Rini, Mark Kettenis, U-Boot Mailing List,
	Pali Roh??r, Ilias Apalodimas, Alex Graf, Masahiro Yamada

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
> 

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
  2021-06-28 17:49       ` Mark Kettenis
@ 2021-07-02 19:05         ` Simon Glass
  2021-07-02 19:48           ` Mark Kettenis
  0 siblings, 1 reply; 34+ messages in thread
From: Simon Glass @ 2021-07-02 19:05 UTC (permalink / raw)
  To: Mark Kettenis
  Cc: Tom Rini, U-Boot Mailing List, Pali Rohár,
	Heinrich Schuchardt, Ilias Apalodimas, Alex Graf,
	Masahiro Yamada

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

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
  2021-07-02 19:05         ` Simon Glass
@ 2021-07-02 19:48           ` Mark Kettenis
  2021-07-02 20:09             ` Tom Rini
  2021-07-02 20:47             ` Simon Glass
  0 siblings, 2 replies; 34+ messages in thread
From: Mark Kettenis @ 2021-07-02 19:48 UTC (permalink / raw)
  To: Simon Glass
  Cc: trini, u-boot, pali, xypron.glpk, ilias.apalodimas, agraf,
	yamada.masahiro

> 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

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
  2021-07-02 19:48           ` Mark Kettenis
@ 2021-07-02 20:09             ` Tom Rini
  2021-07-02 20:47             ` Simon Glass
  1 sibling, 0 replies; 34+ messages in thread
From: Tom Rini @ 2021-07-02 20:09 UTC (permalink / raw)
  To: Mark Kettenis
  Cc: Simon Glass, u-boot, pali, xypron.glpk, ilias.apalodimas, agraf,
	yamada.masahiro

[-- Attachment #1: Type: text/plain, Size: 12742 bytes --]

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!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
  2021-07-02 19:48           ` Mark Kettenis
  2021-07-02 20:09             ` Tom Rini
@ 2021-07-02 20:47             ` Simon Glass
  1 sibling, 0 replies; 34+ messages in thread
From: Simon Glass @ 2021-07-02 20:47 UTC (permalink / raw)
  To: Mark Kettenis
  Cc: Tom Rini, U-Boot Mailing List, Pali Rohár,
	Heinrich Schuchardt, Ilias Apalodimas, Alex Graf,
	Masahiro Yamada

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

^ permalink raw reply	[flat|nested] 34+ messages in thread
end of thread, other threads:[~2021-07-02 20:47 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-28  1:48 [PATCH 0/7] efi: Various tidy-ups and drop the default Simon Glass
2021-06-28  1:48 ` [PATCH 1/7] configs: Resync with savedefconfig Simon Glass
2021-06-28  1:48 ` [PATCH 2/7] Makefile: Drop include/asm directory as well as symlink Simon Glass
2021-06-28  1:48 ` [PATCH 3/7] disk: Tidy up #ifdefs in part_efi Simon Glass
2021-06-28 11:20   ` Heinrich Schuchardt
2021-06-28 13:50     ` Tom Rini
2021-06-28 16:18       ` Heinrich Schuchardt
2021-06-28  1:48 ` [PATCH 4/7] Use LIB_UUID with ACPIGEN and FS_BTRFS Simon Glass
2021-06-28  1:48 ` [PATCH 5/7] Allow efi_loader header to be included always Simon Glass
2021-06-28 11:02   ` Heinrich Schuchardt
2021-06-28  1:48 ` [PATCH 6/7] lib: Create a new Kconfig option for charset conversion Simon Glass
2021-06-28 10:37   ` Heinrich Schuchardt
2021-06-28  1:48 ` [PATCH 7/7] efi: Make EBBR optional Simon Glass
2021-06-28  9:48   ` Heinrich Schuchardt
2021-06-28 13:48     ` Tom Rini
2021-06-28  8:38 ` [PATCH 0/7] efi: Various tidy-ups and drop the default Mark Kettenis
2021-06-28  8:59   ` Ilias Apalodimas
2021-06-28 13:37   ` Tom Rini
2021-06-28 14:18     ` Simon Glass
2021-06-28 15:20       ` Heinrich Schuchardt
2021-06-28 16:26         ` Simon Glass
2021-06-28 17:09           ` Heinrich Schuchardt
2021-06-28 18:02             ` Simon Glass
2021-06-28 17:27           ` Tom Rini
2021-06-28 18:08             ` Simon Glass
2021-06-29 12:56               ` AKASHI Takahiro
2021-06-29 14:01                 ` Heinrich Schuchardt
2021-06-29 14:14                   ` AKASHI Takahiro
2021-06-28 17:49       ` Mark Kettenis
2021-07-02 19:05         ` Simon Glass
2021-07-02 19:48           ` Mark Kettenis
2021-07-02 20:09             ` Tom Rini
2021-07-02 20:47             ` Simon Glass
2021-06-28 14:25     ` Heinrich Schuchardt

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.