[PATCH] configs: layerscape: Disable the EFI_LOADER feature
From: Hou Zhiqiang Zhiqiang.Hou@nxp.com
The feature BOOTENV_SHARED_EFI is not supported on layerscape boards, it didn't result kernel boot crash previously since there isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of 'boot_efi_binary'.
But since the commit f3866909e350 ("distro_bootcmd: call EFI bootmgr even without having /EFI/boot"), it will cause kernel boot crash as there isn't a valid fdt_addr and it finially uses the device tree blob of U-Boot and further cause errors.
As this feature is enabled by default for armv7 and armv8, so disable it explicitly to avoid calling the 'scan_dev_for_efi'.
Signed-off-by: Hou Zhiqiang Zhiqiang.Hou@nxp.com --- configs/ls1012a2g5rdb_qspi_defconfig | 1 + configs/ls1012a2g5rdb_tfa_defconfig | 1 + configs/ls1012afrdm_qspi_defconfig | 1 + configs/ls1012afrdm_tfa_defconfig | 1 + configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig | 1 + configs/ls1012afrwy_qspi_defconfig | 1 + configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig | 1 + configs/ls1012afrwy_tfa_defconfig | 1 + configs/ls1012aqds_qspi_defconfig | 1 + configs/ls1012aqds_tfa_SECURE_BOOT_defconfig | 1 + configs/ls1012aqds_tfa_defconfig | 1 + configs/ls1012ardb_qspi_SECURE_BOOT_defconfig | 1 + configs/ls1012ardb_qspi_defconfig | 1 + configs/ls1012ardb_tfa_SECURE_BOOT_defconfig | 1 + configs/ls1012ardb_tfa_defconfig | 1 + configs/ls1021aiot_qspi_defconfig | 1 + configs/ls1021aiot_sdcard_defconfig | 1 + configs/ls1021aqds_ddr4_nor_defconfig | 1 + configs/ls1021aqds_ddr4_nor_lpuart_defconfig | 1 + configs/ls1021aqds_nand_defconfig | 1 + configs/ls1021aqds_nor_SECURE_BOOT_defconfig | 1 + configs/ls1021aqds_nor_defconfig | 1 + configs/ls1021aqds_nor_lpuart_defconfig | 1 + configs/ls1021aqds_qspi_defconfig | 1 + configs/ls1021aqds_sdcard_ifc_defconfig | 1 + configs/ls1021aqds_sdcard_qspi_defconfig | 1 + configs/ls1021atsn_qspi_defconfig | 1 + configs/ls1021atsn_sdcard_defconfig | 1 + configs/ls1021atwr_nor_SECURE_BOOT_defconfig | 1 + configs/ls1021atwr_nor_defconfig | 1 + configs/ls1021atwr_nor_lpuart_defconfig | 1 + configs/ls1021atwr_qspi_defconfig | 1 + configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig | 1 + configs/ls1021atwr_sdcard_ifc_defconfig | 1 + configs/ls1021atwr_sdcard_qspi_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/ls1046afrwy_tfa_SECURE_BOOT_defconfig | 1 + configs/ls1046afrwy_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_defconfig | 1 + configs/ls1088aqds_qspi_SECURE_BOOT_defconfig | 1 + configs/ls1088aqds_qspi_defconfig | 1 + configs/ls1088aqds_sdcard_ifc_defconfig | 1 + configs/ls1088aqds_sdcard_qspi_defconfig | 1 + configs/ls1088aqds_tfa_defconfig | 1 + configs/ls1088ardb_qspi_SECURE_BOOT_defconfig | 1 + configs/ls1088ardb_qspi_defconfig | 1 + configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig | 1 + configs/ls1088ardb_sdcard_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 | 1 + configs/lx2162aqds_tfa_SECURE_BOOT_defconfig | 1 + configs/lx2162aqds_tfa_defconfig | 1 + configs/lx2162aqds_tfa_verified_boot_defconfig | 1 + 110 files changed, 110 insertions(+)
diff --git a/configs/ls1012a2g5rdb_qspi_defconfig b/configs/ls1012a2g5rdb_qspi_defconfig index 6ddc9737ae..551f6855fa 100644 --- a/configs/ls1012a2g5rdb_qspi_defconfig +++ b/configs/ls1012a2g5rdb_qspi_defconfig @@ -60,3 +60,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1012a2g5rdb_tfa_defconfig b/configs/ls1012a2g5rdb_tfa_defconfig index 66aec34ad0..35a9a9acd7 100644 --- a/configs/ls1012a2g5rdb_tfa_defconfig +++ b/configs/ls1012a2g5rdb_tfa_defconfig @@ -60,3 +60,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1012afrdm_qspi_defconfig b/configs/ls1012afrdm_qspi_defconfig index 27a73931b5..2c874e186f 100644 --- a/configs/ls1012afrdm_qspi_defconfig +++ b/configs/ls1012afrdm_qspi_defconfig @@ -62,3 +62,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1012afrdm_tfa_defconfig b/configs/ls1012afrdm_tfa_defconfig index d17f1e28ed..76a64ab3a3 100644 --- a/configs/ls1012afrdm_tfa_defconfig +++ b/configs/ls1012afrdm_tfa_defconfig @@ -62,3 +62,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig b/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig index 15937902b8..6e68aa3ca7 100644 --- a/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig @@ -64,3 +64,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1012afrwy_qspi_defconfig b/configs/ls1012afrwy_qspi_defconfig index 8ad3cd8e42..91b7fffc53 100644 --- a/configs/ls1012afrwy_qspi_defconfig +++ b/configs/ls1012afrwy_qspi_defconfig @@ -65,3 +65,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig b/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig index ca20e3727f..226b382ec9 100644 --- a/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig @@ -64,3 +64,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1012afrwy_tfa_defconfig b/configs/ls1012afrwy_tfa_defconfig index dff72e78c3..f5c2245a82 100644 --- a/configs/ls1012afrwy_tfa_defconfig +++ b/configs/ls1012afrwy_tfa_defconfig @@ -70,3 +70,4 @@ CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y CONFIG_USB_ETHER_RTL8152=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1012aqds_qspi_defconfig b/configs/ls1012aqds_qspi_defconfig index 1771f1a8a6..645519cb70 100644 --- a/configs/ls1012aqds_qspi_defconfig +++ b/configs/ls1012aqds_qspi_defconfig @@ -85,3 +85,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1012aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1012aqds_tfa_SECURE_BOOT_defconfig index 8f6ca820a2..e3e10e8948 100644 --- a/configs/ls1012aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1012aqds_tfa_SECURE_BOOT_defconfig @@ -76,3 +76,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1012aqds_tfa_defconfig b/configs/ls1012aqds_tfa_defconfig index fcd53196c0..1ee4c6ce28 100644 --- a/configs/ls1012aqds_tfa_defconfig +++ b/configs/ls1012aqds_tfa_defconfig @@ -85,3 +85,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig b/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig index 4d3dc20568..824fbee499 100644 --- a/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig @@ -68,3 +68,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1012ardb_qspi_defconfig b/configs/ls1012ardb_qspi_defconfig index 79668a534c..79d9519d79 100644 --- a/configs/ls1012ardb_qspi_defconfig +++ b/configs/ls1012ardb_qspi_defconfig @@ -70,3 +70,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1012ardb_tfa_SECURE_BOOT_defconfig b/configs/ls1012ardb_tfa_SECURE_BOOT_defconfig index 6f66a512b1..60146a9cfc 100644 --- a/configs/ls1012ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1012ardb_tfa_SECURE_BOOT_defconfig @@ -69,3 +69,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1012ardb_tfa_defconfig b/configs/ls1012ardb_tfa_defconfig index c52359e51d..2c6475ca99 100644 --- a/configs/ls1012ardb_tfa_defconfig +++ b/configs/ls1012ardb_tfa_defconfig @@ -69,3 +69,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021aiot_qspi_defconfig b/configs/ls1021aiot_qspi_defconfig index 31209e4feb..a78cbd5882 100644 --- a/configs/ls1021aiot_qspi_defconfig +++ b/configs/ls1021aiot_qspi_defconfig @@ -56,3 +56,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021aiot_sdcard_defconfig b/configs/ls1021aiot_sdcard_defconfig index e541c9c69b..8c1149160a 100644 --- a/configs/ls1021aiot_sdcard_defconfig +++ b/configs/ls1021aiot_sdcard_defconfig @@ -61,3 +61,4 @@ CONFIG_FSL_QSPI=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021aqds_ddr4_nor_defconfig b/configs/ls1021aqds_ddr4_nor_defconfig index 8bfbac2b65..7cf45381ca 100644 --- a/configs/ls1021aqds_ddr4_nor_defconfig +++ b/configs/ls1021aqds_ddr4_nor_defconfig @@ -70,3 +70,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_STORAGE=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021aqds_ddr4_nor_lpuart_defconfig b/configs/ls1021aqds_ddr4_nor_lpuart_defconfig index 433d3c63c8..5347a1c7d7 100644 --- a/configs/ls1021aqds_ddr4_nor_lpuart_defconfig +++ b/configs/ls1021aqds_ddr4_nor_lpuart_defconfig @@ -70,3 +70,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_STORAGE=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021aqds_nand_defconfig b/configs/ls1021aqds_nand_defconfig index 62973791e0..bde1bb16b8 100644 --- a/configs/ls1021aqds_nand_defconfig +++ b/configs/ls1021aqds_nand_defconfig @@ -85,3 +85,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_STORAGE=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021aqds_nor_SECURE_BOOT_defconfig b/configs/ls1021aqds_nor_SECURE_BOOT_defconfig index f145d150fe..5bccbf8844 100644 --- a/configs/ls1021aqds_nor_SECURE_BOOT_defconfig +++ b/configs/ls1021aqds_nor_SECURE_BOOT_defconfig @@ -69,3 +69,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_USB_STORAGE=y CONFIG_RSA=y CONFIG_SPL_RSA=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021aqds_nor_defconfig b/configs/ls1021aqds_nor_defconfig index e0e34e75b5..234ea9ce7e 100644 --- a/configs/ls1021aqds_nor_defconfig +++ b/configs/ls1021aqds_nor_defconfig @@ -71,3 +71,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_STORAGE=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021aqds_nor_lpuart_defconfig b/configs/ls1021aqds_nor_lpuart_defconfig index 44d33e5faa..cf0c21cc85 100644 --- a/configs/ls1021aqds_nor_lpuart_defconfig +++ b/configs/ls1021aqds_nor_lpuart_defconfig @@ -71,3 +71,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_STORAGE=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021aqds_qspi_defconfig b/configs/ls1021aqds_qspi_defconfig index 80d5ef8411..0eda4ace43 100644 --- a/configs/ls1021aqds_qspi_defconfig +++ b/configs/ls1021aqds_qspi_defconfig @@ -70,3 +70,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_STORAGE=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021aqds_sdcard_ifc_defconfig b/configs/ls1021aqds_sdcard_ifc_defconfig index f4d2082174..94ba839433 100644 --- a/configs/ls1021aqds_sdcard_ifc_defconfig +++ b/configs/ls1021aqds_sdcard_ifc_defconfig @@ -84,3 +84,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_STORAGE=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021aqds_sdcard_qspi_defconfig b/configs/ls1021aqds_sdcard_qspi_defconfig index d535ee601e..c200e3fe9d 100644 --- a/configs/ls1021aqds_sdcard_qspi_defconfig +++ b/configs/ls1021aqds_sdcard_qspi_defconfig @@ -82,3 +82,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_STORAGE=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021atsn_qspi_defconfig b/configs/ls1021atsn_qspi_defconfig index 17f7eea088..248e5ac837 100644 --- a/configs/ls1021atsn_qspi_defconfig +++ b/configs/ls1021atsn_qspi_defconfig @@ -62,3 +62,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021atsn_sdcard_defconfig b/configs/ls1021atsn_sdcard_defconfig index a434530248..a72046dc3f 100644 --- a/configs/ls1021atsn_sdcard_defconfig +++ b/configs/ls1021atsn_sdcard_defconfig @@ -73,3 +73,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021atwr_nor_SECURE_BOOT_defconfig b/configs/ls1021atwr_nor_SECURE_BOOT_defconfig index 4896c5b70a..a670df59c2 100644 --- a/configs/ls1021atwr_nor_SECURE_BOOT_defconfig +++ b/configs/ls1021atwr_nor_SECURE_BOOT_defconfig @@ -63,3 +63,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_SPL_RSA=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021atwr_nor_defconfig b/configs/ls1021atwr_nor_defconfig index 1a9b3e1574..f341528881 100644 --- a/configs/ls1021atwr_nor_defconfig +++ b/configs/ls1021atwr_nor_defconfig @@ -65,3 +65,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021atwr_nor_lpuart_defconfig b/configs/ls1021atwr_nor_lpuart_defconfig index 5171c1bdbd..56ef49669e 100644 --- a/configs/ls1021atwr_nor_lpuart_defconfig +++ b/configs/ls1021atwr_nor_lpuart_defconfig @@ -66,3 +66,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021atwr_qspi_defconfig b/configs/ls1021atwr_qspi_defconfig index 79ebf4c077..e8f4a4c497 100644 --- a/configs/ls1021atwr_qspi_defconfig +++ b/configs/ls1021atwr_qspi_defconfig @@ -68,3 +68,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig b/configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig index d721729819..28ea071b24 100644 --- a/configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig +++ b/configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig @@ -77,3 +77,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_SPL_RSA=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021atwr_sdcard_ifc_defconfig b/configs/ls1021atwr_sdcard_ifc_defconfig index 430f89b711..7b863dd319 100644 --- a/configs/ls1021atwr_sdcard_ifc_defconfig +++ b/configs/ls1021atwr_sdcard_ifc_defconfig @@ -78,3 +78,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1021atwr_sdcard_qspi_defconfig b/configs/ls1021atwr_sdcard_qspi_defconfig index fe1caa2716..73f5ef18ef 100644 --- a/configs/ls1021atwr_sdcard_qspi_defconfig +++ b/configs/ls1021atwr_sdcard_qspi_defconfig @@ -79,3 +79,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig index f033b18520..c2871a39df 100644 --- a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig @@ -91,3 +91,4 @@ CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y CONFIG_VIDEO=y CONFIG_VIDEO_LS_HDP_LOAD=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1028aqds_tfa_defconfig b/configs/ls1028aqds_tfa_defconfig index 1f70fe34cc..37cda256a1 100644 --- a/configs/ls1028aqds_tfa_defconfig +++ b/configs/ls1028aqds_tfa_defconfig @@ -96,3 +96,4 @@ CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y CONFIG_VIDEO=y CONFIG_VIDEO_LS_HDP_LOAD=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1028aqds_tfa_lpuart_defconfig b/configs/ls1028aqds_tfa_lpuart_defconfig index bc5f8f4f32..36a164c9d8 100644 --- a/configs/ls1028aqds_tfa_lpuart_defconfig +++ b/configs/ls1028aqds_tfa_lpuart_defconfig @@ -94,3 +94,4 @@ CONFIG_WDT=y CONFIG_WDT_SP805=y CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig index de82f5b210..ec5c04e0b0 100644 --- a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig @@ -86,3 +86,4 @@ CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y CONFIG_VIDEO=y CONFIG_VIDEO_LS_HDP_LOAD=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig index 8ce9da5b4f..0c3f26cf63 100644 --- a/configs/ls1028ardb_tfa_defconfig +++ b/configs/ls1028ardb_tfa_defconfig @@ -95,3 +95,4 @@ CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y CONFIG_VIDEO=y CONFIG_VIDEO_LS_HDP_LOAD=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1043aqds_defconfig b/configs/ls1043aqds_defconfig index e55ad96bd5..6640b00df0 100644 --- a/configs/ls1043aqds_defconfig +++ b/configs/ls1043aqds_defconfig @@ -70,3 +70,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1043aqds_lpuart_defconfig b/configs/ls1043aqds_lpuart_defconfig index 9388c244e4..cf1b1eb998 100644 --- a/configs/ls1043aqds_lpuart_defconfig +++ b/configs/ls1043aqds_lpuart_defconfig @@ -72,3 +72,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1043aqds_nand_defconfig b/configs/ls1043aqds_nand_defconfig index 6440dbc98e..a3f1e46ab8 100644 --- a/configs/ls1043aqds_nand_defconfig +++ b/configs/ls1043aqds_nand_defconfig @@ -86,3 +86,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1043aqds_nor_ddr3_defconfig b/configs/ls1043aqds_nor_ddr3_defconfig index f51d662a2f..60cc9389d0 100644 --- a/configs/ls1043aqds_nor_ddr3_defconfig +++ b/configs/ls1043aqds_nor_ddr3_defconfig @@ -71,3 +71,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1043aqds_qspi_defconfig b/configs/ls1043aqds_qspi_defconfig index e2fe794955..9ecf79561a 100644 --- a/configs/ls1043aqds_qspi_defconfig +++ b/configs/ls1043aqds_qspi_defconfig @@ -68,3 +68,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1043aqds_sdcard_ifc_defconfig b/configs/ls1043aqds_sdcard_ifc_defconfig index bf5d1e5139..85061ed181 100644 --- a/configs/ls1043aqds_sdcard_ifc_defconfig +++ b/configs/ls1043aqds_sdcard_ifc_defconfig @@ -87,3 +87,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1043aqds_sdcard_qspi_defconfig b/configs/ls1043aqds_sdcard_qspi_defconfig index f9e9cafd92..52fa657fcd 100644 --- a/configs/ls1043aqds_sdcard_qspi_defconfig +++ b/configs/ls1043aqds_sdcard_qspi_defconfig @@ -81,3 +81,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig index 56da287fdf..438d2c7357 100644 --- a/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig @@ -74,3 +74,4 @@ CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_RSA_SOFTWARE_EXP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1043aqds_tfa_defconfig b/configs/ls1043aqds_tfa_defconfig index 52643f87e8..364998a36c 100644 --- a/configs/ls1043aqds_tfa_defconfig +++ b/configs/ls1043aqds_tfa_defconfig @@ -81,3 +81,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1043ardb_SECURE_BOOT_defconfig b/configs/ls1043ardb_SECURE_BOOT_defconfig index 2dcfd8b091..bc485831ae 100644 --- a/configs/ls1043ardb_SECURE_BOOT_defconfig +++ b/configs/ls1043ardb_SECURE_BOOT_defconfig @@ -63,3 +63,4 @@ CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_RSA_SOFTWARE_EXP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1043ardb_defconfig b/configs/ls1043ardb_defconfig index 108d8e9289..08cd85b7c4 100644 --- a/configs/ls1043ardb_defconfig +++ b/configs/ls1043ardb_defconfig @@ -63,3 +63,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1043ardb_nand_SECURE_BOOT_defconfig b/configs/ls1043ardb_nand_SECURE_BOOT_defconfig index 3ca7dac9e8..28b75089d1 100644 --- a/configs/ls1043ardb_nand_SECURE_BOOT_defconfig +++ b/configs/ls1043ardb_nand_SECURE_BOOT_defconfig @@ -83,3 +83,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1043ardb_nand_defconfig b/configs/ls1043ardb_nand_defconfig index fb530544b2..6606b1559d 100644 --- a/configs/ls1043ardb_nand_defconfig +++ b/configs/ls1043ardb_nand_defconfig @@ -82,3 +82,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y # CONFIG_SPL_USE_TINY_PRINTF is not set CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig b/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig index 06c1ce5053..03fa354117 100644 --- a/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig +++ b/configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig @@ -82,3 +82,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1043ardb_sdcard_defconfig b/configs/ls1043ardb_sdcard_defconfig index 87abc07807..1cf6486c90 100644 --- a/configs/ls1043ardb_sdcard_defconfig +++ b/configs/ls1043ardb_sdcard_defconfig @@ -82,3 +82,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y # CONFIG_SPL_USE_TINY_PRINTF is not set CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1043ardb_tfa_SECURE_BOOT_defconfig b/configs/ls1043ardb_tfa_SECURE_BOOT_defconfig index 9796b84eff..c5272dff84 100644 --- a/configs/ls1043ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1043ardb_tfa_SECURE_BOOT_defconfig @@ -64,3 +64,4 @@ CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_RSA_SOFTWARE_EXP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1043ardb_tfa_defconfig b/configs/ls1043ardb_tfa_defconfig index de3db3e2c4..f4efaee35f 100644 --- a/configs/ls1043ardb_tfa_defconfig +++ b/configs/ls1043ardb_tfa_defconfig @@ -67,3 +67,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1046afrwy_tfa_SECURE_BOOT_defconfig b/configs/ls1046afrwy_tfa_SECURE_BOOT_defconfig index 0a0c7ec36f..545999c5a9 100644 --- a/configs/ls1046afrwy_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1046afrwy_tfa_SECURE_BOOT_defconfig @@ -62,3 +62,4 @@ CONFIG_USB_ETHER_ASIX88179=y CONFIG_USB_ETHER_RTL8152=y CONFIG_RSA=y CONFIG_NXP_ESBC=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1046afrwy_tfa_defconfig b/configs/ls1046afrwy_tfa_defconfig index add3001615..b6c470c102 100644 --- a/configs/ls1046afrwy_tfa_defconfig +++ b/configs/ls1046afrwy_tfa_defconfig @@ -69,3 +69,4 @@ CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y CONFIG_USB_ETHER_RTL8152=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1046aqds_SECURE_BOOT_defconfig b/configs/ls1046aqds_SECURE_BOOT_defconfig index f75cca28eb..3efa073719 100644 --- a/configs/ls1046aqds_SECURE_BOOT_defconfig +++ b/configs/ls1046aqds_SECURE_BOOT_defconfig @@ -71,3 +71,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1046aqds_defconfig b/configs/ls1046aqds_defconfig index 592916b92d..5dd43c8af9 100644 --- a/configs/ls1046aqds_defconfig +++ b/configs/ls1046aqds_defconfig @@ -73,3 +73,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1046aqds_lpuart_defconfig b/configs/ls1046aqds_lpuart_defconfig index 38f285fa10..f384ddbf04 100644 --- a/configs/ls1046aqds_lpuart_defconfig +++ b/configs/ls1046aqds_lpuart_defconfig @@ -75,3 +75,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1046aqds_nand_defconfig b/configs/ls1046aqds_nand_defconfig index 9194eff14b..0d0f9a4a61 100644 --- a/configs/ls1046aqds_nand_defconfig +++ b/configs/ls1046aqds_nand_defconfig @@ -81,3 +81,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1046aqds_qspi_defconfig b/configs/ls1046aqds_qspi_defconfig index 4753881cdb..19c4699b71 100644 --- a/configs/ls1046aqds_qspi_defconfig +++ b/configs/ls1046aqds_qspi_defconfig @@ -71,3 +71,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1046aqds_sdcard_ifc_defconfig b/configs/ls1046aqds_sdcard_ifc_defconfig index 0f2e9c02a0..61cee5a575 100644 --- a/configs/ls1046aqds_sdcard_ifc_defconfig +++ b/configs/ls1046aqds_sdcard_ifc_defconfig @@ -91,3 +91,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1046aqds_sdcard_qspi_defconfig b/configs/ls1046aqds_sdcard_qspi_defconfig index 0d6bea6305..878fc19708 100644 --- a/configs/ls1046aqds_sdcard_qspi_defconfig +++ b/configs/ls1046aqds_sdcard_qspi_defconfig @@ -86,3 +86,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1046aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1046aqds_tfa_SECURE_BOOT_defconfig index 141857c2af..c4552643fe 100644 --- a/configs/ls1046aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1046aqds_tfa_SECURE_BOOT_defconfig @@ -73,3 +73,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1046aqds_tfa_defconfig b/configs/ls1046aqds_tfa_defconfig index 9d5c941fb6..f0cba2b8d8 100644 --- a/configs/ls1046aqds_tfa_defconfig +++ b/configs/ls1046aqds_tfa_defconfig @@ -83,3 +83,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1046ardb_emmc_defconfig b/configs/ls1046ardb_emmc_defconfig index 82218142a5..5aca0e0dce 100644 --- a/configs/ls1046ardb_emmc_defconfig +++ b/configs/ls1046ardb_emmc_defconfig @@ -84,3 +84,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig b/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig index ce84ef901f..68cee38aaa 100644 --- a/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig @@ -67,3 +67,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1046ardb_qspi_defconfig b/configs/ls1046ardb_qspi_defconfig index af3fd114e2..ad56e1c301 100644 --- a/configs/ls1046ardb_qspi_defconfig +++ b/configs/ls1046ardb_qspi_defconfig @@ -70,3 +70,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1046ardb_qspi_spl_defconfig b/configs/ls1046ardb_qspi_spl_defconfig index 0f3e03aaf8..a2369711ce 100644 --- a/configs/ls1046ardb_qspi_spl_defconfig +++ b/configs/ls1046ardb_qspi_spl_defconfig @@ -89,3 +89,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_SPL_GZIP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig b/configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig index 5caf24f800..4d41e164f2 100644 --- a/configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig +++ b/configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig @@ -81,3 +81,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1046ardb_sdcard_defconfig b/configs/ls1046ardb_sdcard_defconfig index 0d5ada4313..028dae8d8f 100644 --- a/configs/ls1046ardb_sdcard_defconfig +++ b/configs/ls1046ardb_sdcard_defconfig @@ -83,3 +83,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig b/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig index 599849ac27..b80af97939 100644 --- a/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig @@ -66,3 +66,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1046ardb_tfa_defconfig b/configs/ls1046ardb_tfa_defconfig index e9e2efb210..63f65c01c7 100644 --- a/configs/ls1046ardb_tfa_defconfig +++ b/configs/ls1046ardb_tfa_defconfig @@ -71,3 +71,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1088aqds_defconfig b/configs/ls1088aqds_defconfig index b67901e267..0d64b512ad 100644 --- a/configs/ls1088aqds_defconfig +++ b/configs/ls1088aqds_defconfig @@ -75,3 +75,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig b/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig index 52a3455102..ee861f71f4 100644 --- a/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig @@ -76,3 +76,4 @@ CONFIG_USB_GADGET=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1088aqds_qspi_defconfig b/configs/ls1088aqds_qspi_defconfig index c3af322634..c98763ed0d 100644 --- a/configs/ls1088aqds_qspi_defconfig +++ b/configs/ls1088aqds_qspi_defconfig @@ -77,3 +77,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_GADGET=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1088aqds_sdcard_ifc_defconfig b/configs/ls1088aqds_sdcard_ifc_defconfig index 2331e3e63d..c6c8f331b0 100644 --- a/configs/ls1088aqds_sdcard_ifc_defconfig +++ b/configs/ls1088aqds_sdcard_ifc_defconfig @@ -83,3 +83,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1088aqds_sdcard_qspi_defconfig b/configs/ls1088aqds_sdcard_qspi_defconfig index c94182b0a8..065b1bf7d8 100644 --- a/configs/ls1088aqds_sdcard_qspi_defconfig +++ b/configs/ls1088aqds_sdcard_qspi_defconfig @@ -86,3 +86,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_GADGET=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1088aqds_tfa_defconfig b/configs/ls1088aqds_tfa_defconfig index 2d4e8967ed..032ed3bf15 100644 --- a/configs/ls1088aqds_tfa_defconfig +++ b/configs/ls1088aqds_tfa_defconfig @@ -102,3 +102,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_GADGET=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig b/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig index db696f91f2..978a7224aa 100644 --- a/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig @@ -78,3 +78,4 @@ CONFIG_USB_GADGET=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1088ardb_qspi_defconfig b/configs/ls1088ardb_qspi_defconfig index 4bacce171e..ba36fea98f 100644 --- a/configs/ls1088ardb_qspi_defconfig +++ b/configs/ls1088ardb_qspi_defconfig @@ -79,3 +79,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_GADGET=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig b/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig index 24e4ba7229..7aa3204912 100644 --- a/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig @@ -86,3 +86,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_RSA=y CONFIG_SPL_RSA=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1088ardb_sdcard_qspi_defconfig b/configs/ls1088ardb_sdcard_qspi_defconfig index b38ef7b07d..289bcd3ead 100644 --- a/configs/ls1088ardb_sdcard_qspi_defconfig +++ b/configs/ls1088ardb_sdcard_qspi_defconfig @@ -88,3 +88,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_GADGET=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig b/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig index 4952d7cd0e..06d6e7ce0d 100644 --- a/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1088ardb_tfa_SECURE_BOOT_defconfig @@ -87,3 +87,4 @@ CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_RSA_SOFTWARE_EXP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig index 2e99e337c8..81a30bdee2 100644 --- a/configs/ls1088ardb_tfa_defconfig +++ b/configs/ls1088ardb_tfa_defconfig @@ -94,3 +94,4 @@ CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y CONFIG_USB_ETHER_RTL8152=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls2080aqds_SECURE_BOOT_defconfig b/configs/ls2080aqds_SECURE_BOOT_defconfig index e6ff8b8456..59f17a20d2 100644 --- a/configs/ls2080aqds_SECURE_BOOT_defconfig +++ b/configs/ls2080aqds_SECURE_BOOT_defconfig @@ -69,3 +69,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls2080aqds_defconfig b/configs/ls2080aqds_defconfig index 31d79cc184..6baabf133e 100644 --- a/configs/ls2080aqds_defconfig +++ b/configs/ls2080aqds_defconfig @@ -70,3 +70,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls2080aqds_nand_defconfig b/configs/ls2080aqds_nand_defconfig index 20166062ee..fd70851c15 100644 --- a/configs/ls2080aqds_nand_defconfig +++ b/configs/ls2080aqds_nand_defconfig @@ -77,3 +77,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls2080aqds_qspi_defconfig b/configs/ls2080aqds_qspi_defconfig index c1e49b5cfe..e5121ef00e 100644 --- a/configs/ls2080aqds_qspi_defconfig +++ b/configs/ls2080aqds_qspi_defconfig @@ -69,3 +69,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls2080aqds_sdcard_defconfig b/configs/ls2080aqds_sdcard_defconfig index d866966954..bb9ec59650 100644 --- a/configs/ls2080aqds_sdcard_defconfig +++ b/configs/ls2080aqds_sdcard_defconfig @@ -76,3 +76,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls2080ardb_SECURE_BOOT_defconfig b/configs/ls2080ardb_SECURE_BOOT_defconfig index be3b5ab7fe..fe08e41f24 100644 --- a/configs/ls2080ardb_SECURE_BOOT_defconfig +++ b/configs/ls2080ardb_SECURE_BOOT_defconfig @@ -67,3 +67,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls2080ardb_defconfig b/configs/ls2080ardb_defconfig index dd77b4ab98..d31d614d06 100644 --- a/configs/ls2080ardb_defconfig +++ b/configs/ls2080ardb_defconfig @@ -68,3 +68,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls2080ardb_nand_defconfig b/configs/ls2080ardb_nand_defconfig index 50ac69b4a2..dbbba68c62 100644 --- a/configs/ls2080ardb_nand_defconfig +++ b/configs/ls2080ardb_nand_defconfig @@ -73,3 +73,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls2081ardb_defconfig b/configs/ls2081ardb_defconfig index 1bcfcde247..94286c0f07 100644 --- a/configs/ls2081ardb_defconfig +++ b/configs/ls2081ardb_defconfig @@ -66,3 +66,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls2088aqds_tfa_defconfig b/configs/ls2088aqds_tfa_defconfig index 060b21e5b1..1f3bf2b749 100644 --- a/configs/ls2088aqds_tfa_defconfig +++ b/configs/ls2088aqds_tfa_defconfig @@ -91,3 +91,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls2088ardb_qspi_SECURE_BOOT_defconfig b/configs/ls2088ardb_qspi_SECURE_BOOT_defconfig index 41bab9bfc9..6fdf89f82e 100644 --- a/configs/ls2088ardb_qspi_SECURE_BOOT_defconfig +++ b/configs/ls2088ardb_qspi_SECURE_BOOT_defconfig @@ -68,3 +68,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_RSA=y CONFIG_RSA_SOFTWARE_EXP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls2088ardb_qspi_defconfig b/configs/ls2088ardb_qspi_defconfig index 581ceb7d19..d97b0c76a7 100644 --- a/configs/ls2088ardb_qspi_defconfig +++ b/configs/ls2088ardb_qspi_defconfig @@ -73,3 +73,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls2088ardb_tfa_SECURE_BOOT_defconfig b/configs/ls2088ardb_tfa_SECURE_BOOT_defconfig index c5bfb18862..722e7b4f22 100644 --- a/configs/ls2088ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls2088ardb_tfa_SECURE_BOOT_defconfig @@ -84,3 +84,4 @@ CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_RSA_SOFTWARE_EXP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/ls2088ardb_tfa_defconfig b/configs/ls2088ardb_tfa_defconfig index de57235284..1bc25acf81 100644 --- a/configs/ls2088ardb_tfa_defconfig +++ b/configs/ls2088ardb_tfa_defconfig @@ -89,3 +89,4 @@ CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig b/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig index eb1aa453fe..faeefa0666 100644 --- a/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig @@ -88,3 +88,4 @@ CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_RSA_SOFTWARE_EXP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/lx2160aqds_tfa_defconfig b/configs/lx2160aqds_tfa_defconfig index 0fbfc6e199..d17429810d 100644 --- a/configs/lx2160aqds_tfa_defconfig +++ b/configs/lx2160aqds_tfa_defconfig @@ -94,3 +94,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_WDT=y CONFIG_WDT_SBSA=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig b/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig index 8c915b516b..cda1613910 100644 --- a/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig @@ -79,3 +79,4 @@ CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_RSA_SOFTWARE_EXP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/lx2160ardb_tfa_defconfig b/configs/lx2160ardb_tfa_defconfig index 2aa5c0e841..37edf9e406 100644 --- a/configs/lx2160ardb_tfa_defconfig +++ b/configs/lx2160ardb_tfa_defconfig @@ -89,3 +89,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_WDT=y CONFIG_WDT_SBSA=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/lx2160ardb_tfa_stmm_defconfig b/configs/lx2160ardb_tfa_stmm_defconfig index 1b06124269..757102366f 100644 --- a/configs/lx2160ardb_tfa_stmm_defconfig +++ b/configs/lx2160ardb_tfa_stmm_defconfig @@ -87,3 +87,4 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_EFI_MM_COMM_TEE=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig b/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig index 2ecd6b404a..309848e55e 100644 --- a/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig @@ -90,3 +90,4 @@ CONFIG_RSA=y CONFIG_SPL_RSA=y CONFIG_RSA_SOFTWARE_EXP=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/lx2162aqds_tfa_defconfig b/configs/lx2162aqds_tfa_defconfig index d0d3384047..ea168404f5 100644 --- a/configs/lx2162aqds_tfa_defconfig +++ b/configs/lx2162aqds_tfa_defconfig @@ -97,3 +97,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_WDT=y CONFIG_WDT_SBSA=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n diff --git a/configs/lx2162aqds_tfa_verified_boot_defconfig b/configs/lx2162aqds_tfa_verified_boot_defconfig index b9261251c1..809558cfc2 100644 --- a/configs/lx2162aqds_tfa_verified_boot_defconfig +++ b/configs/lx2162aqds_tfa_verified_boot_defconfig @@ -98,3 +98,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_WDT=y CONFIG_WDT_SBSA=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_EFI_LOADER=n
On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
From: Hou Zhiqiang Zhiqiang.Hou@nxp.com
The feature BOOTENV_SHARED_EFI is not supported on layerscape boards, it didn't result kernel boot crash previously since there isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of 'boot_efi_binary'.
But since the commit f3866909e350 ("distro_bootcmd: call EFI bootmgr even without having /EFI/boot"), it will cause kernel boot crash as there isn't a valid fdt_addr and it finially uses the device tree blob of U-Boot and further cause errors.
As this feature is enabled by default for armv7 and armv8, so disable it explicitly to avoid calling the 'scan_dev_for_efi'.
I'm not thrilled with this. Why isn't the solution to get and keep in sync the device trees, so that the tree U-Boot has is valid for the kernel? I'm also open to discussing f3866909e350 more. But I'm really opposed to disabling EFI_LOADER on modern platforms as that will make adoption of U-Boot in device harder I feel.
Am 2021-07-22 17:26, schrieb Tom Rini:
On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
From: Hou Zhiqiang Zhiqiang.Hou@nxp.com
The feature BOOTENV_SHARED_EFI is not supported on layerscape boards, it didn't result kernel boot crash previously since there isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of 'boot_efi_binary'.
But since the commit f3866909e350 ("distro_bootcmd: call EFI bootmgr even without having /EFI/boot"), it will cause kernel boot crash as there isn't a valid fdt_addr and it finially uses the device tree blob of U-Boot and further cause errors.
As this feature is enabled by default for armv7 and armv8, so disable it explicitly to avoid calling the 'scan_dev_for_efi'.
I'm not thrilled with this. Why isn't the solution to get and keep in sync the device trees, so that the tree U-Boot has is valid for the kernel? I'm also open to discussing f3866909e350 more. But I'm really opposed to disabling EFI_LOADER on modern platforms as that will make adoption of U-Boot in device harder I feel.
I don't know whats going on with the NXP boards, but the sl28 is a layerscape board it is working pretty well with EFI boot.
So why don't you fix the root cause instead of disabling this feature?
-michael
On Thu, Jul 22, 2021 at 07:00:31PM +0200, Michael Walle wrote:
Am 2021-07-22 17:26, schrieb Tom Rini:
On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
From: Hou Zhiqiang Zhiqiang.Hou@nxp.com
The feature BOOTENV_SHARED_EFI is not supported on layerscape boards, it didn't result kernel boot crash previously since there isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of 'boot_efi_binary'.
But since the commit f3866909e350 ("distro_bootcmd: call EFI bootmgr even without having /EFI/boot"), it will cause kernel boot crash as there isn't a valid fdt_addr and it finially uses the device tree blob of U-Boot and further cause errors.
As this feature is enabled by default for armv7 and armv8, so disable it explicitly to avoid calling the 'scan_dev_for_efi'.
I'm not thrilled with this. Why isn't the solution to get and keep in sync the device trees, so that the tree U-Boot has is valid for the kernel? I'm also open to discussing f3866909e350 more. But I'm really opposed to disabling EFI_LOADER on modern platforms as that will make adoption of U-Boot in device harder I feel.
I don't know whats going on with the NXP boards, but the sl28 is a layerscape board it is working pretty well with EFI boot.
So why don't you fix the root cause instead of disabling this feature?
Having thought a bit more on this, if the U-Boot run-time DTB causes the kernel to fail that would seem to be a rather big failing on the whole "DTB is ABI" thing, would it not? I'm not saying that's not what's happening, rather I'm noting that it's not supposed to happen and old DTB + new kernel should work.
Am 2021-07-22 19:02, schrieb Tom Rini:
On Thu, Jul 22, 2021 at 07:00:31PM +0200, Michael Walle wrote:
Am 2021-07-22 17:26, schrieb Tom Rini:
On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
From: Hou Zhiqiang Zhiqiang.Hou@nxp.com
The feature BOOTENV_SHARED_EFI is not supported on layerscape boards, it didn't result kernel boot crash previously since there isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of 'boot_efi_binary'.
But since the commit f3866909e350 ("distro_bootcmd: call EFI bootmgr even without having /EFI/boot"), it will cause kernel boot crash as there isn't a valid fdt_addr and it finially uses the device tree blob of U-Boot and further cause errors.
As this feature is enabled by default for armv7 and armv8, so disable it explicitly to avoid calling the 'scan_dev_for_efi'.
I'm not thrilled with this. Why isn't the solution to get and keep in sync the device trees, so that the tree U-Boot has is valid for the kernel? I'm also open to discussing f3866909e350 more. But I'm really opposed to disabling EFI_LOADER on modern platforms as that will make adoption of U-Boot in device harder I feel.
I don't know whats going on with the NXP boards, but the sl28 is a layerscape board it is working pretty well with EFI boot.
So why don't you fix the root cause instead of disabling this feature?
Having thought a bit more on this, if the U-Boot run-time DTB causes the kernel to fail that would seem to be a rather big failing on the whole "DTB is ABI" thing, would it not?
The u-boot dtb isn't really compatible with the kernel dtb, is it? Eg. the DSA binding is different, the USB binding (might be) is different, eg. I tried to get the dwc3 driver to work on the LS1028A and it seems that u-boot (intentionally) needs subnodes to the actual device node in the DTB, just to load a usb peripheral or usb host mode driver for the subnode. Thus even, that is an implementation detail which should have never ended up in the DTB. The enetc binding is different AFAIK.
TBH, I'm suprised that the u-boot dtb is passed to linux if there is no other available.
I'm not saying that's not what's happening, rather I'm noting that it's not supposed to happen and old DTB + new kernel should work.
-michael
On Thu, Jul 22, 2021 at 07:08:33PM +0200, Michael Walle wrote:
Am 2021-07-22 19:02, schrieb Tom Rini:
On Thu, Jul 22, 2021 at 07:00:31PM +0200, Michael Walle wrote:
Am 2021-07-22 17:26, schrieb Tom Rini:
On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
From: Hou Zhiqiang Zhiqiang.Hou@nxp.com
The feature BOOTENV_SHARED_EFI is not supported on layerscape boards, it didn't result kernel boot crash previously since there isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of 'boot_efi_binary'.
But since the commit f3866909e350 ("distro_bootcmd: call EFI bootmgr even without having /EFI/boot"), it will cause kernel boot crash as there isn't a valid fdt_addr and it finially uses the device tree blob of U-Boot and further cause errors.
As this feature is enabled by default for armv7 and armv8, so disable it explicitly to avoid calling the 'scan_dev_for_efi'.
I'm not thrilled with this. Why isn't the solution to get and keep in sync the device trees, so that the tree U-Boot has is valid for the kernel? I'm also open to discussing f3866909e350 more. But I'm really opposed to disabling EFI_LOADER on modern platforms as that will make adoption of U-Boot in device harder I feel.
I don't know whats going on with the NXP boards, but the sl28 is a layerscape board it is working pretty well with EFI boot.
So why don't you fix the root cause instead of disabling this feature?
Having thought a bit more on this, if the U-Boot run-time DTB causes the kernel to fail that would seem to be a rather big failing on the whole "DTB is ABI" thing, would it not?
The u-boot dtb isn't really compatible with the kernel dtb, is it? Eg.
It's supposed to be. You're supposed to take the kernel dts files, add in as few tweaks as possible (i.e. u-boot,dm-spl and so on). It's a description of the hardware. If you have to make one device tree for the kernel and another slightly different device tree for U-Boot, we've just made it harder for people to add boards, not easier.
the DSA binding is different, the USB binding (might be) is different, eg. I tried to get the dwc3 driver to work on the LS1028A and it seems that u-boot (intentionally) needs subnodes to the actual device node in the DTB, just to load a usb peripheral or usb host mode driver for the subnode. Thus even, that is an implementation detail which should have never ended up in the DTB. The enetc binding is different AFAIK.
There might be a few other I would think minor tweaks for things like since we don't really support OTG, but that should not cause the kernel to blow up horribly and should be done in such a way that the kernel handles it, or we fix it up again to "neutral" before booting the kernel.
TBH, I'm suprised that the u-boot dtb is passed to linux if there is no other available.
Yes, I think we're now reaching the "surprise" state of EFI support where EFI has a spot for the device tree and if we don't specify one at "bootefi" (or similar) time, the current run time tree populates the spot. This is fine on platforms where we're passed a device tree already for example (think Pi) or other platforms where the dts files are kept in sync well (I think stm32 is a good example here). Much more mixed results elsewhere, apparently.
On Thu, Jul 22, 2021 at 2:00 PM Michael Walle michael@walle.cc wrote:
I don't know whats going on with the NXP boards, but the sl28 is a layerscape board it is working pretty well with EFI boot.
So why don't you fix the root cause instead of disabling this feature?
Agreed.
Besides that, the way to disable this option is not correct.
It should be:
# CONFIG_EFI_LOADER is not set
instead of
CONFIG_EFI_LOADER=n
Hi Fabio,
-----Original Message----- From: Fabio Estevam festevam@gmail.com Sent: 2021年7月23日 1:10 To: Michael Walle michael@walle.cc Cc: Tom Rini trini@konsulko.com; Z.Q. Hou zhiqiang.hou@nxp.com; Heinrich Schuchardt xypron.glpk@gmx.de; U-Boot-Denx u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
On Thu, Jul 22, 2021 at 2:00 PM Michael Walle michael@walle.cc wrote:
I don't know whats going on with the NXP boards, but the sl28 is a layerscape board it is working pretty well with EFI boot.
So why don't you fix the root cause instead of disabling this feature?
Agreed.
Besides that, the way to disable this option is not correct.
It should be:
# CONFIG_EFI_LOADER is not set
instead of
CONFIG_EFI_LOADER=n
Thanks for the correction!
Regards, Zhiqiang
Hi Michael,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: 2021年7月23日 1:01 To: Tom Rini trini@konsulko.com Cc: Z.Q. Hou zhiqiang.hou@nxp.com; Heinrich Schuchardt xypron.glpk@gmx.de; u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
Am 2021-07-22 17:26, schrieb Tom Rini:
On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
From: Hou Zhiqiang Zhiqiang.Hou@nxp.com
The feature BOOTENV_SHARED_EFI is not supported on layerscape
boards,
it didn't result kernel boot crash previously since there isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of 'boot_efi_binary'.
But since the commit f3866909e350 ("distro_bootcmd: call EFI bootmgr even without having /EFI/boot"), it will cause kernel boot crash as there isn't a valid fdt_addr and it finially uses the device tree blob of U-Boot and further cause errors.
As this feature is enabled by default for armv7 and armv8, so disable it explicitly to avoid calling the 'scan_dev_for_efi'.
I'm not thrilled with this. Why isn't the solution to get and keep in sync the device trees, so that the tree U-Boot has is valid for the kernel? I'm also open to discussing f3866909e350 more. But I'm really opposed to disabling EFI_LOADER on modern platforms as that will make adoption of U-Boot in device harder I feel.
I don't know whats going on with the NXP boards, but the sl28 is a layerscape board it is working pretty well with EFI boot.
Do you mean the EFI boot work well on sl28? Or the EFI boot doesn't break other boot ways?
In my case, there are 4 MMC partitions and a boot script with boot images in the 2nd partition, while nothing in the 1st partition. So the expected boot flow is the 'bootcmd_mmc0' scan the 1st partition and find it's not bootable and then the 2nd partition and boot with the script. But actually the 'scan_dev_for_efi' got problem when scan the 1st partition, as the u-boot DTB is used in 'bootefi bootmgr' and result in some error related to the DTB.
Actually, if give a readable but invalid 'fdt_addr' in env, the EFI boot can also be skipped during the scan of the 1st partition. Actually on some Layerscape boards the provided env 'fdt_addr' with a non-readable address, and on other boards a readable 'fdt_addr'. Seems the patch author copy them from somewhere but didn't cause issue that time. But this is just a workaround, the EFI boot should not cause problem during the scan phase when there isn't needed components in one of these partitions.
Thanks, Zhiqiang
So why don't you fix the root cause instead of disabling this feature?
-michael
Am 2021-07-26 09:01, schrieb Z.Q. Hou:
Hi Michael,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: 2021年7月23日 1:01 To: Tom Rini trini@konsulko.com Cc: Z.Q. Hou zhiqiang.hou@nxp.com; Heinrich Schuchardt xypron.glpk@gmx.de; u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
Am 2021-07-22 17:26, schrieb Tom Rini:
On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
From: Hou Zhiqiang Zhiqiang.Hou@nxp.com
The feature BOOTENV_SHARED_EFI is not supported on layerscape
boards,
it didn't result kernel boot crash previously since there isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of 'boot_efi_binary'.
But since the commit f3866909e350 ("distro_bootcmd: call EFI bootmgr even without having /EFI/boot"), it will cause kernel boot crash as there isn't a valid fdt_addr and it finially uses the device tree blob of U-Boot and further cause errors.
As this feature is enabled by default for armv7 and armv8, so disable it explicitly to avoid calling the 'scan_dev_for_efi'.
I'm not thrilled with this. Why isn't the solution to get and keep in sync the device trees, so that the tree U-Boot has is valid for the kernel? I'm also open to discussing f3866909e350 more. But I'm really opposed to disabling EFI_LOADER on modern platforms as that will make adoption of U-Boot in device harder I feel.
I don't know whats going on with the NXP boards, but the sl28 is a layerscape board it is working pretty well with EFI boot.
Do you mean the EFI boot work well on sl28?
This, for example, I can boot the debian installer out-of-the-box, given that the fdtfile variable is set correctly.
Or the EFI boot doesn't break other boot ways?
In my case, there are 4 MMC partitions and a boot script with boot images in the 2nd partition, while nothing in the 1st partition. So the expected boot flow is the 'bootcmd_mmc0' scan the 1st partition and find it's not bootable and then the 2nd partition and boot with the script. But actually the 'scan_dev_for_efi' got problem when scan the 1st partition, as the u-boot DTB is used in 'bootefi bootmgr' and result in some error related to the DTB.
As mentioned in the other mail, I'm not sure why "bootefi bootmgr" does something at all, because AFAIK it needs the BootOrder/BootNext variables. Heinrich, please correct me if I'm wrong.
Actually, if give a readable but invalid 'fdt_addr' in env, the EFI boot can also be skipped during the scan of the 1st partition. Actually on some Layerscape boards the provided env 'fdt_addr' with a non-readable address, and on other boards a readable 'fdt_addr'. Seems the patch author copy them from somewhere but didn't cause issue that time. But this is just a workaround, the EFI boot should not cause problem during the scan phase when there isn't needed components in one of these partitions.
What exactly is going wrong? Is linux booting at all? Or does the bootloader abort?
And why don't you fix the fdt_addr then? Shouldn't it be unset if there is no actual device tree present in a ROM section? (I don't say there isn't another underlying problem when you use an invalid fdt_addr).
-michael
Hi Micheal,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: 2021年7月26日 15:13 To: Z.Q. Hou zhiqiang.hou@nxp.com Cc: Tom Rini trini@konsulko.com; Heinrich Schuchardt xypron.glpk@gmx.de; u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
Am 2021-07-26 09:01, schrieb Z.Q. Hou:
Hi Michael,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: 2021年7月23日 1:01 To: Tom Rini trini@konsulko.com Cc: Z.Q. Hou zhiqiang.hou@nxp.com; Heinrich Schuchardt xypron.glpk@gmx.de; u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
Am 2021-07-22 17:26, schrieb Tom Rini:
On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
From: Hou Zhiqiang Zhiqiang.Hou@nxp.com
The feature BOOTENV_SHARED_EFI is not supported on layerscape
boards,
it didn't result kernel boot crash previously since there isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of 'boot_efi_binary'.
But since the commit f3866909e350 ("distro_bootcmd: call EFI bootmgr even without having /EFI/boot"), it will cause kernel boot crash as there isn't a valid fdt_addr and it finially uses the device tree blob of U-Boot and further cause errors.
As this feature is enabled by default for armv7 and armv8, so disable it explicitly to avoid calling the 'scan_dev_for_efi'.
I'm not thrilled with this. Why isn't the solution to get and keep in sync the device trees, so that the tree U-Boot has is valid for the kernel? I'm also open to discussing f3866909e350 more. But I'm really opposed to disabling EFI_LOADER on modern platforms as that will make adoption of U-Boot in device harder I feel.
I don't know whats going on with the NXP boards, but the sl28 is a layerscape board it is working pretty well with EFI boot.
Do you mean the EFI boot work well on sl28?
This, for example, I can boot the debian installer out-of-the-box, given that the fdtfile variable is set correctly.
Oh, we are talking on different case.
Or the EFI boot doesn't break other boot ways?
In my case, there are 4 MMC partitions and a boot script with boot images in the 2nd partition, while nothing in the 1st partition. So the expected boot flow is the 'bootcmd_mmc0' scan the 1st partition and find it's not bootable and then the 2nd partition and boot with the script. But actually the 'scan_dev_for_efi' got problem when scan the 1st partition, as the u-boot DTB is used in 'bootefi bootmgr' and result in some error related to the DTB.
As mentioned in the other mail, I'm not sure why "bootefi bootmgr" does something at all, because AFAIK it needs the BootOrder/BootNext variables. Heinrich, please correct me if I'm wrong.
I'm not familiar with EFI boot, In this case, the 'scan_dev_for_efi' calls 'run boot_efi_bootmgr' then 'bootefi bootmgr', seems it doesn't check if the needed components exist. Is the cmd 'scan_dev_for_efi' wrong?
Actually, if give a readable but invalid 'fdt_addr' in env, the EFI boot can also be skipped during the scan of the 1st partition. Actually on some Layerscape boards the provided env 'fdt_addr' with a non-readable address, and on other boards a readable 'fdt_addr'. Seems the patch author copy them from somewhere but didn't cause issue that time. But this is just a workaround, the EFI boot should not cause problem during the scan phase when there isn't needed components in one of these partitions.
What exactly is going wrong? Is linux booting at all? Or does the bootloader abort?
Pasted the log below, the direct cause seems the u-boot DTB doesn't have /cpus node.
=> run bootcmd_mmc0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk esdhc@1560000.blk... Found 5 disks No EFI system partition couldn't find /cpus "Synchronous Abort" handler, esr 0x96000006 elr: 0000000082004a6c lr : 0000000082004a30 (reloc) elr: 00000000fbd25a6c lr : 00000000fbd25a30 x0 : 0000000087f00a88 x1 : 000000001cfbfd5e x2 : efbeaddeefbeadde x3 : 00000000efbeadde x4 : 00000000fffffffc x5 : 0000000087f037d2 x6 : 0000000000000a58 x7 : 0000000000000003 x8 : 0000000087f00000 x9 : 0000000000000008 x10: 0000000000000a44 x11: 00000000fbc17c6c x12: 00000000000009e4 x13: 0000000000000000 x14: 0000000087f00000 x15: 00000000fbc180d8 x16: 00000000fbd742d0 x17: 0000000000000000 x18: 00000000fbc1cdb0 x19: 00000000000009e4 x20: 0000000087f00000 x21: 00000000fbdb3404 x22: 00000000fbdb4a97 x23: 0000000000000018 x24: 00000000fbde5d44 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 00000000fbc5ba60 x29: 00000000fbc17d30
Code: a94153f3 a9425bf5 a8c47bfd d65f03c0 (b8617803) Resetting CPU ...
And why don't you fix the fdt_addr then? Shouldn't it be unset if there is no actual device tree present in a ROM section? (I don't say there isn't another underlying problem when you use an invalid fdt_addr).
The problem shown in above log is triggered when unset the fdt_addr. If it not unset, the SError is triggered when to check the magic of the fdt header.
Thanks, Zhiqiang
-michael
On Mon, Jul 26, 2021 at 07:37:53AM +0000, Z.Q. Hou wrote:
Hi Micheal,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: 2021年7月26日 15:13 To: Z.Q. Hou zhiqiang.hou@nxp.com Cc: Tom Rini trini@konsulko.com; Heinrich Schuchardt xypron.glpk@gmx.de; u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
Am 2021-07-26 09:01, schrieb Z.Q. Hou:
Hi Michael,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: 2021年7月23日 1:01 To: Tom Rini trini@konsulko.com Cc: Z.Q. Hou zhiqiang.hou@nxp.com; Heinrich Schuchardt xypron.glpk@gmx.de; u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
Am 2021-07-22 17:26, schrieb Tom Rini:
On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
From: Hou Zhiqiang Zhiqiang.Hou@nxp.com
The feature BOOTENV_SHARED_EFI is not supported on layerscape
boards,
it didn't result kernel boot crash previously since there isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of 'boot_efi_binary'.
But since the commit f3866909e350 ("distro_bootcmd: call EFI bootmgr even without having /EFI/boot"), it will cause kernel boot crash as there isn't a valid fdt_addr and it finially uses the device tree blob of U-Boot and further cause errors.
As this feature is enabled by default for armv7 and armv8, so disable it explicitly to avoid calling the 'scan_dev_for_efi'.
I'm not thrilled with this. Why isn't the solution to get and keep in sync the device trees, so that the tree U-Boot has is valid for the kernel? I'm also open to discussing f3866909e350 more. But I'm really opposed to disabling EFI_LOADER on modern platforms as that will make adoption of U-Boot in device harder I feel.
I don't know whats going on with the NXP boards, but the sl28 is a layerscape board it is working pretty well with EFI boot.
Do you mean the EFI boot work well on sl28?
This, for example, I can boot the debian installer out-of-the-box, given that the fdtfile variable is set correctly.
Oh, we are talking on different case.
Or the EFI boot doesn't break other boot ways?
In my case, there are 4 MMC partitions and a boot script with boot images in the 2nd partition, while nothing in the 1st partition. So the expected boot flow is the 'bootcmd_mmc0' scan the 1st partition and find it's not bootable and then the 2nd partition and boot with the script. But actually the 'scan_dev_for_efi' got problem when scan the 1st partition, as the u-boot DTB is used in 'bootefi bootmgr' and result in some error related to the DTB.
As mentioned in the other mail, I'm not sure why "bootefi bootmgr" does something at all, because AFAIK it needs the BootOrder/BootNext variables. Heinrich, please correct me if I'm wrong.
I'm not familiar with EFI boot, In this case, the 'scan_dev_for_efi' calls 'run boot_efi_bootmgr' then 'bootefi bootmgr', seems it doesn't check if the needed components exist. Is the cmd 'scan_dev_for_efi' wrong?
I'll let Heinrich comment on this part.
Actually, if give a readable but invalid 'fdt_addr' in env, the EFI boot can also be skipped during the scan of the 1st partition. Actually on some Layerscape boards the provided env 'fdt_addr' with a non-readable address, and on other boards a readable 'fdt_addr'. Seems the patch author copy them from somewhere but didn't cause issue that time. But this is just a workaround, the EFI boot should not cause problem during the scan phase when there isn't needed components in one of these partitions.
What exactly is going wrong? Is linux booting at all? Or does the bootloader abort?
Pasted the log below, the direct cause seems the u-boot DTB doesn't have /cpus node.
=> run bootcmd_mmc0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk esdhc@1560000.blk... Found 5 disks No EFI system partition couldn't find /cpus "Synchronous Abort" handler, esr 0x96000006 elr: 0000000082004a6c lr : 0000000082004a30 (reloc) elr: 00000000fbd25a6c lr : 00000000fbd25a30 x0 : 0000000087f00a88 x1 : 000000001cfbfd5e x2 : efbeaddeefbeadde x3 : 00000000efbeadde x4 : 00000000fffffffc x5 : 0000000087f037d2 x6 : 0000000000000a58 x7 : 0000000000000003 x8 : 0000000087f00000 x9 : 0000000000000008 x10: 0000000000000a44 x11: 00000000fbc17c6c x12: 00000000000009e4 x13: 0000000000000000 x14: 0000000087f00000 x15: 00000000fbc180d8 x16: 00000000fbd742d0 x17: 0000000000000000 x18: 00000000fbc1cdb0 x19: 00000000000009e4 x20: 0000000087f00000 x21: 00000000fbdb3404 x22: 00000000fbdb4a97 x23: 0000000000000018 x24: 00000000fbde5d44 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 00000000fbc5ba60 x29: 00000000fbc17d30
Code: a94153f3 a9425bf5 a8c47bfd d65f03c0 (b8617803) Resetting CPU ...
And why don't you fix the fdt_addr then? Shouldn't it be unset if there is no actual device tree present in a ROM section? (I don't say there isn't another underlying problem when you use an invalid fdt_addr).
The problem shown in above log is triggered when unset the fdt_addr.
OK, so that shows a problem to fix. If there's not a valid device tree found, that error needs to be handled and not ignored.
If it not unset, the SError is triggered when to check the magic of the fdt header.
Sorry, which is the SError?
Hi Tom,
-----Original Message----- From: Tom Rini trini@konsulko.com Sent: 2021年7月26日 20:29 To: Z.Q. Hou zhiqiang.hou@nxp.com Cc: Michael Walle michael@walle.cc; Heinrich Schuchardt xypron.glpk@gmx.de; u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
On Mon, Jul 26, 2021 at 07:37:53AM +0000, Z.Q. Hou wrote:
Hi Micheal,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: 2021年7月26日 15:13 To: Z.Q. Hou zhiqiang.hou@nxp.com Cc: Tom Rini trini@konsulko.com; Heinrich Schuchardt xypron.glpk@gmx.de; u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
Am 2021-07-26 09:01, schrieb Z.Q. Hou:
Hi Michael,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: 2021年7月23日 1:01 To: Tom Rini trini@konsulko.com Cc: Z.Q. Hou zhiqiang.hou@nxp.com; Heinrich Schuchardt xypron.glpk@gmx.de; u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
Am 2021-07-22 17:26, schrieb Tom Rini:
On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
> From: Hou Zhiqiang Zhiqiang.Hou@nxp.com > > The feature BOOTENV_SHARED_EFI is not supported on layerscape
boards,
> it didn't result kernel boot crash previously since there > isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of
'boot_efi_binary'.
> > But since the commit f3866909e350 ("distro_bootcmd: call EFI > bootmgr even without having /EFI/boot"), it will cause kernel > boot crash as there isn't a valid fdt_addr and it finially > uses the device tree blob of U-Boot and further cause errors. > > As this feature is enabled by default for armv7 and armv8, so > disable it explicitly to avoid calling the 'scan_dev_for_efi'.
I'm not thrilled with this. Why isn't the solution to get and keep in sync the device trees, so that the tree U-Boot has is valid for the kernel? I'm also open to discussing f3866909e350 more. But I'm really opposed to disabling EFI_LOADER on modern platforms as that will make adoption of U-Boot in device harder I
feel.
I don't know whats going on with the NXP boards, but the sl28 is a layerscape board it is working pretty well with EFI boot.
Do you mean the EFI boot work well on sl28?
This, for example, I can boot the debian installer out-of-the-box, given that the fdtfile variable is set correctly.
Oh, we are talking on different case.
Or the EFI boot doesn't break other boot ways?
In my case, there are 4 MMC partitions and a boot script with boot images in the 2nd partition, while nothing in the 1st partition. So the expected boot flow is the 'bootcmd_mmc0' scan the 1st partition and find it's not bootable and then the 2nd partition and boot with the script. But actually the 'scan_dev_for_efi' got problem when scan the 1st partition, as the u-boot DTB is used in 'bootefi bootmgr' and result in some error related to the DTB.
As mentioned in the other mail, I'm not sure why "bootefi bootmgr" does something at all, because AFAIK it needs the BootOrder/BootNext variables. Heinrich, please correct me if I'm wrong.
I'm not familiar with EFI boot, In this case, the 'scan_dev_for_efi' calls 'run
boot_efi_bootmgr' then 'bootefi bootmgr', seems it doesn't check if the needed components exist.
Is the cmd 'scan_dev_for_efi' wrong?
I'll let Heinrich comment on this part.
Actually, if give a readable but invalid 'fdt_addr' in env, the EFI boot can also be skipped during the scan of the 1st partition. Actually on some Layerscape boards the provided env 'fdt_addr' with a non-readable address, and on other boards a readable 'fdt_addr'. Seems the patch author copy them from somewhere but didn't cause issue that time. But this is just a workaround, the EFI boot should not cause problem during the scan phase when there isn't needed components in one of these partitions.
What exactly is going wrong? Is linux booting at all? Or does the bootloader abort?
Pasted the log below, the direct cause seems the u-boot DTB doesn't have
/cpus node.
=> run bootcmd_mmc0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk esdhc@1560000.blk... Found 5 disks No EFI system partition couldn't find /cpus "Synchronous Abort" handler, esr 0x96000006 elr: 0000000082004a6c lr : 0000000082004a30 (reloc) elr: 00000000fbd25a6c lr : 00000000fbd25a30 x0 : 0000000087f00a88 x1 : 000000001cfbfd5e x2 : efbeaddeefbeadde x3 : 00000000efbeadde x4 : 00000000fffffffc x5 : 0000000087f037d2 x6 : 0000000000000a58 x7 : 0000000000000003 x8 : 0000000087f00000 x9 : 0000000000000008 x10: 0000000000000a44 x11: 00000000fbc17c6c x12: 00000000000009e4 x13: 0000000000000000 x14: 0000000087f00000 x15: 00000000fbc180d8 x16: 00000000fbd742d0 x17: 0000000000000000 x18: 00000000fbc1cdb0 x19: 00000000000009e4 x20: 0000000087f00000 x21: 00000000fbdb3404 x22: 00000000fbdb4a97 x23: 0000000000000018 x24: 00000000fbde5d44 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 00000000fbc5ba60 x29: 00000000fbc17d30
Code: a94153f3 a9425bf5 a8c47bfd d65f03c0 (b8617803) Resetting CPU ...
And why don't you fix the fdt_addr then? Shouldn't it be unset if there is
no
actual device tree present in a ROM section? (I don't say there isn't
another
underlying problem when you use an invalid fdt_addr).
The problem shown in above log is triggered when unset the fdt_addr.
OK, so that shows a problem to fix. If there's not a valid device tree found, that error needs to be handled and not ignored.
Drop this patch if the problem can be fix.
If it not unset, the SError is triggered when to check the magic of the fdt
header.
Sorry, which is the SError?
I didn't paste that error log.
Thanks, Zhiqiang
-- Tom
On Tue, Jul 27, 2021 at 05:42:51AM +0000, Z.Q. Hou wrote:
Hi Tom,
-----Original Message----- From: Tom Rini trini@konsulko.com Sent: 2021年7月26日 20:29 To: Z.Q. Hou zhiqiang.hou@nxp.com Cc: Michael Walle michael@walle.cc; Heinrich Schuchardt xypron.glpk@gmx.de; u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
On Mon, Jul 26, 2021 at 07:37:53AM +0000, Z.Q. Hou wrote:
Hi Micheal,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: 2021年7月26日 15:13 To: Z.Q. Hou zhiqiang.hou@nxp.com Cc: Tom Rini trini@konsulko.com; Heinrich Schuchardt xypron.glpk@gmx.de; u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
Am 2021-07-26 09:01, schrieb Z.Q. Hou:
Hi Michael,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: 2021年7月23日 1:01 To: Tom Rini trini@konsulko.com Cc: Z.Q. Hou zhiqiang.hou@nxp.com; Heinrich Schuchardt xypron.glpk@gmx.de; u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
Am 2021-07-22 17:26, schrieb Tom Rini: > On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote: > >> From: Hou Zhiqiang Zhiqiang.Hou@nxp.com >> >> The feature BOOTENV_SHARED_EFI is not supported on layerscape boards, >> it didn't result kernel boot crash previously since there >> isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of
'boot_efi_binary'.
>> >> But since the commit f3866909e350 ("distro_bootcmd: call EFI >> bootmgr even without having /EFI/boot"), it will cause kernel >> boot crash as there isn't a valid fdt_addr and it finially >> uses the device tree blob of U-Boot and further cause errors. >> >> As this feature is enabled by default for armv7 and armv8, so >> disable it explicitly to avoid calling the 'scan_dev_for_efi'. > > I'm not thrilled with this. Why isn't the solution to get and > keep in sync the device trees, so that the tree U-Boot has is > valid for the kernel? I'm also open to discussing f3866909e350 > more. But I'm really opposed to disabling EFI_LOADER on modern > platforms as that will make adoption of U-Boot in device harder I
feel.
I don't know whats going on with the NXP boards, but the sl28 is a layerscape board it is working pretty well with EFI boot.
Do you mean the EFI boot work well on sl28?
This, for example, I can boot the debian installer out-of-the-box, given that the fdtfile variable is set correctly.
Oh, we are talking on different case.
Or the EFI boot doesn't break other boot ways?
In my case, there are 4 MMC partitions and a boot script with boot images in the 2nd partition, while nothing in the 1st partition. So the expected boot flow is the 'bootcmd_mmc0' scan the 1st partition and find it's not bootable and then the 2nd partition and boot with the script. But actually the 'scan_dev_for_efi' got problem when scan the 1st partition, as the u-boot DTB is used in 'bootefi bootmgr' and result in some error related to the DTB.
As mentioned in the other mail, I'm not sure why "bootefi bootmgr" does something at all, because AFAIK it needs the BootOrder/BootNext variables. Heinrich, please correct me if I'm wrong.
I'm not familiar with EFI boot, In this case, the 'scan_dev_for_efi' calls 'run
boot_efi_bootmgr' then 'bootefi bootmgr', seems it doesn't check if the needed components exist.
Is the cmd 'scan_dev_for_efi' wrong?
I'll let Heinrich comment on this part.
Actually, if give a readable but invalid 'fdt_addr' in env, the EFI boot can also be skipped during the scan of the 1st partition. Actually on some Layerscape boards the provided env 'fdt_addr' with a non-readable address, and on other boards a readable 'fdt_addr'. Seems the patch author copy them from somewhere but didn't cause issue that time. But this is just a workaround, the EFI boot should not cause problem during the scan phase when there isn't needed components in one of these partitions.
What exactly is going wrong? Is linux booting at all? Or does the bootloader abort?
Pasted the log below, the direct cause seems the u-boot DTB doesn't have
/cpus node.
=> run bootcmd_mmc0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk esdhc@1560000.blk... Found 5 disks No EFI system partition couldn't find /cpus "Synchronous Abort" handler, esr 0x96000006 elr: 0000000082004a6c lr : 0000000082004a30 (reloc) elr: 00000000fbd25a6c lr : 00000000fbd25a30 x0 : 0000000087f00a88 x1 : 000000001cfbfd5e x2 : efbeaddeefbeadde x3 : 00000000efbeadde x4 : 00000000fffffffc x5 : 0000000087f037d2 x6 : 0000000000000a58 x7 : 0000000000000003 x8 : 0000000087f00000 x9 : 0000000000000008 x10: 0000000000000a44 x11: 00000000fbc17c6c x12: 00000000000009e4 x13: 0000000000000000 x14: 0000000087f00000 x15: 00000000fbc180d8 x16: 00000000fbd742d0 x17: 0000000000000000 x18: 00000000fbc1cdb0 x19: 00000000000009e4 x20: 0000000087f00000 x21: 00000000fbdb3404 x22: 00000000fbdb4a97 x23: 0000000000000018 x24: 00000000fbde5d44 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 00000000fbc5ba60 x29: 00000000fbc17d30
Code: a94153f3 a9425bf5 a8c47bfd d65f03c0 (b8617803) Resetting CPU ...
And why don't you fix the fdt_addr then? Shouldn't it be unset if there is
no
actual device tree present in a ROM section? (I don't say there isn't
another
underlying problem when you use an invalid fdt_addr).
The problem shown in above log is triggered when unset the fdt_addr.
OK, so that shows a problem to fix. If there's not a valid device tree found, that error needs to be handled and not ignored.
Drop this patch if the problem can be fix.
Yes, it certainly seems like this should be fixed? Are you going to investigate?
-----Original Message----- From: Tom Rini trini@konsulko.com Sent: 2021年7月27日 21:08 To: Z.Q. Hou zhiqiang.hou@nxp.com Cc: Michael Walle michael@walle.cc; Heinrich Schuchardt xypron.glpk@gmx.de; u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
On Tue, Jul 27, 2021 at 05:42:51AM +0000, Z.Q. Hou wrote:
Hi Tom,
-----Original Message----- From: Tom Rini trini@konsulko.com Sent: 2021年7月26日 20:29 To: Z.Q. Hou zhiqiang.hou@nxp.com Cc: Michael Walle michael@walle.cc; Heinrich Schuchardt xypron.glpk@gmx.de; u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
On Mon, Jul 26, 2021 at 07:37:53AM +0000, Z.Q. Hou wrote:
Hi Micheal,
-----Original Message----- From: Michael Walle michael@walle.cc Sent: 2021年7月26日 15:13 To: Z.Q. Hou zhiqiang.hou@nxp.com Cc: Tom Rini trini@konsulko.com; Heinrich Schuchardt xypron.glpk@gmx.de; u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
Am 2021-07-26 09:01, schrieb Z.Q. Hou:
Hi Michael,
> -----Original Message----- > From: Michael Walle michael@walle.cc > Sent: 2021年7月23日 1:01 > To: Tom Rini trini@konsulko.com > Cc: Z.Q. Hou zhiqiang.hou@nxp.com; Heinrich Schuchardt > xypron.glpk@gmx.de; u-boot@lists.denx.de; Priyanka Jain > priyanka.jain@nxp.com > Subject: Re: [PATCH] configs: layerscape: Disable the > EFI_LOADER feature > > Am 2021-07-22 17:26, schrieb Tom Rini: > > On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote: > > > >> From: Hou Zhiqiang Zhiqiang.Hou@nxp.com > >> > >> The feature BOOTENV_SHARED_EFI is not supported on > >> layerscape > boards, > >> it didn't result kernel boot crash previously since there > >> isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of
'boot_efi_binary'.
> >> > >> But since the commit f3866909e350 ("distro_bootcmd: call > >> EFI bootmgr even without having /EFI/boot"), it will cause > >> kernel boot crash as there isn't a valid fdt_addr and it > >> finially uses the device tree blob of U-Boot and further cause
errors.
> >> > >> As this feature is enabled by default for armv7 and armv8, > >> so disable it explicitly to avoid calling the 'scan_dev_for_efi'. > > > > I'm not thrilled with this. Why isn't the solution to get > > and keep in sync the device trees, so that the tree U-Boot > > has is valid for the kernel? I'm also open to discussing > > f3866909e350 more. But I'm really opposed to disabling > > EFI_LOADER on modern platforms as that will make adoption > > of U-Boot in device harder I
feel.
> > I don't know whats going on with the NXP boards, but the sl28 > is a layerscape board it is working pretty well with EFI boot.
Do you mean the EFI boot work well on sl28?
This, for example, I can boot the debian installer out-of-the-box, given that the fdtfile variable is set correctly.
Oh, we are talking on different case.
Or the EFI boot doesn't break other boot ways?
In my case, there are 4 MMC partitions and a boot script with boot images in the 2nd partition, while nothing in the 1st partition. So the expected boot flow is the 'bootcmd_mmc0' scan the 1st partition and find it's not bootable and then the 2nd partition and boot with the script. But actually the 'scan_dev_for_efi' got problem when scan the 1st partition, as the u-boot DTB is used in 'bootefi bootmgr' and result in some error
related to the DTB.
As mentioned in the other mail, I'm not sure why "bootefi bootmgr" does something at all, because AFAIK it needs the BootOrder/BootNext variables. Heinrich, please correct me if I'm
wrong.
I'm not familiar with EFI boot, In this case, the 'scan_dev_for_efi' calls 'run
boot_efi_bootmgr' then 'bootefi bootmgr', seems it doesn't check if the needed components exist.
Is the cmd 'scan_dev_for_efi' wrong?
I'll let Heinrich comment on this part.
Actually, if give a readable but invalid 'fdt_addr' in env, the EFI boot can also be skipped during the scan of the 1st partition. Actually on some Layerscape boards the provided env 'fdt_addr' with a non-readable address, and on other boards a readable 'fdt_addr'. Seems the patch author copy them from somewhere but didn't cause issue that time. But this is just a workaround, the EFI boot should not cause problem during the scan phase when there isn't needed components in one of these
partitions.
What exactly is going wrong? Is linux booting at all? Or does the bootloader abort?
Pasted the log below, the direct cause seems the u-boot DTB doesn't have
/cpus node.
=> run bootcmd_mmc0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk esdhc@1560000.blk... Found 5 disks No EFI system partition couldn't find /cpus "Synchronous Abort" handler, esr 0x96000006 elr: 0000000082004a6c lr : 0000000082004a30 (reloc) elr: 00000000fbd25a6c lr : 00000000fbd25a30 x0 : 0000000087f00a88 x1 : 000000001cfbfd5e x2 : efbeaddeefbeadde x3 : 00000000efbeadde x4 : 00000000fffffffc x5 : 0000000087f037d2 x6 : 0000000000000a58 x7 : 0000000000000003 x8 : 0000000087f00000 x9 : 0000000000000008 x10: 0000000000000a44 x11: 00000000fbc17c6c x12: 00000000000009e4 x13: 0000000000000000 x14: 0000000087f00000 x15: 00000000fbc180d8 x16: 00000000fbd742d0 x17: 0000000000000000 x18: 00000000fbc1cdb0 x19: 00000000000009e4 x20: 0000000087f00000 x21: 00000000fbdb3404 x22: 00000000fbdb4a97 x23: 0000000000000018 x24: 00000000fbde5d44 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 00000000fbc5ba60 x29: 00000000fbc17d30
Code: a94153f3 a9425bf5 a8c47bfd d65f03c0 (b8617803) Resetting
CPU ...
And why don't you fix the fdt_addr then? Shouldn't it be unset if there is
no
actual device tree present in a ROM section? (I don't say there isn't
another
underlying problem when you use an invalid fdt_addr).
The problem shown in above log is triggered when unset the fdt_addr.
OK, so that shows a problem to fix. If there's not a valid device tree found, that error needs to be handled and not ignored.
Drop this patch if the problem can be fix.
Yes, it certainly seems like this should be fixed? Are you going to investigate?
No plan to dig deep.
Thanks, Zhiqiang
-- Tom
On Mon, Jul 26, 2021 at 07:37:53AM +0000, Z.Q. Hou wrote:
Hi Micheal,
Pasted the log below, the direct cause seems the u-boot DTB doesn't have /cpus node.
=> run bootcmd_mmc0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk esdhc@1560000.blk... Found 5 disks No EFI system partition couldn't find /cpus "Synchronous Abort" handler, esr 0x96000006 elr: 0000000082004a6c lr : 0000000082004a30 (reloc) elr: 00000000fbd25a6c lr : 00000000fbd25a30 x0 : 0000000087f00a88 x1 : 000000001cfbfd5e x2 : efbeaddeefbeadde x3 : 00000000efbeadde x4 : 00000000fffffffc x5 : 0000000087f037d2 x6 : 0000000000000a58 x7 : 0000000000000003 x8 : 0000000087f00000 x9 : 0000000000000008 x10: 0000000000000a44 x11: 00000000fbc17c6c x12: 00000000000009e4 x13: 0000000000000000 x14: 0000000087f00000 x15: 00000000fbc180d8 x16: 00000000fbd742d0 x17: 0000000000000000 x18: 00000000fbc1cdb0 x19: 00000000000009e4 x20: 0000000087f00000 x21: 00000000fbdb3404 x22: 00000000fbdb4a97 x23: 0000000000000018 x24: 00000000fbde5d44 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 00000000fbc5ba60 x29: 00000000fbc17d30
Code: a94153f3 a9425bf5 a8c47bfd d65f03c0 (b8617803) Resetting CPU ...
And why don't you fix the fdt_addr then? Shouldn't it be unset if there is no actual device tree present in a ROM section? (I don't say there isn't another underlying problem when you use an invalid fdt_addr).
The problem shown in above log is triggered when unset the fdt_addr.
On which platform are you seeing this issue?
I have tested v2021.07 on ls1043a-rdb and it doesn't reproduce.
Board is booting from NOR and I have two mmc partitions: Device Start End Sectors Size Type /dev/mmcblk0p1 2048 1048576 1046529 511M Linux filesystem /dev/mmcblk0p2 1050624 15523806 14473183 6.9G Linux filesystem
=> run bootcmd_mmc0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Scanning disk esdhc@1560000.blk... Found 3 disks No EFI system partition PCIe1: pcie@3400000 disabled PCIe2: pcie@3500000 Root Complex: no link PCIe3: pcie@3600000 Root Complex: no link WARNING failed to get smmu node: FDT_ERR_NOTFOUND WARNING failed to get smmu node: FDT_ERR_NOTFOUND BootOrder not defined EFI boot manager: Cannot load any image Scanning mmc 0:2... WARNING failed to get smmu node: FDT_ERR_NOTFOUND WARNING failed to get smmu node: FDT_ERR_NOTFOUND BootOrder not defined EFI boot manager: Cannot load any image =>
I still don't see the issue even if I remove fdt_addr: => setenv fdt_addr => run bootcmd_mmc0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... WARNING failed to get smmu node: FDT_ERR_NOTFOUND WARNING failed to get smmu node: FDT_ERR_NOTFOUND BootOrder not defined EFI boot manager: Cannot load any image Scanning mmc 0:2... WARNING failed to get smmu node: FDT_ERR_NOTFOUND WARNING failed to get smmu node: FDT_ERR_NOTFOUND BootOrder not defined EFI boot manager: Cannot load any image =>
If it not unset, the SError is triggered when to check the magic of the fdt header.
Thanks, Zhiqiang
-michael
BR, Yousaf
-----Original Message----- From: Mian Yousaf Kaukab ykaukab@suse.de Sent: 2021年8月3日 22:52 To: Z.Q. Hou zhiqiang.hou@nxp.com Cc: Michael Walle michael@walle.cc; Tom Rini trini@konsulko.com; Heinrich Schuchardt xypron.glpk@gmx.de; u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
On Mon, Jul 26, 2021 at 07:37:53AM +0000, Z.Q. Hou wrote:
Hi Micheal,
Pasted the log below, the direct cause seems the u-boot DTB doesn't have
/cpus node.
=> run bootcmd_mmc0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk esdhc@1560000.blk... Found 5 disks No EFI system partition couldn't find /cpus "Synchronous Abort" handler, esr 0x96000006 elr: 0000000082004a6c lr : 0000000082004a30 (reloc) elr: 00000000fbd25a6c lr : 00000000fbd25a30 x0 : 0000000087f00a88 x1 : 000000001cfbfd5e x2 : efbeaddeefbeadde x3 : 00000000efbeadde x4 : 00000000fffffffc x5 : 0000000087f037d2 x6 : 0000000000000a58 x7 : 0000000000000003 x8 : 0000000087f00000 x9 : 0000000000000008 x10: 0000000000000a44 x11: 00000000fbc17c6c x12: 00000000000009e4 x13: 0000000000000000 x14: 0000000087f00000 x15: 00000000fbc180d8 x16: 00000000fbd742d0 x17: 0000000000000000 x18: 00000000fbc1cdb0 x19: 00000000000009e4 x20: 0000000087f00000 x21: 00000000fbdb3404 x22: 00000000fbdb4a97 x23: 0000000000000018 x24: 00000000fbde5d44 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 00000000fbc5ba60 x29: 00000000fbc17d30
Code: a94153f3 a9425bf5 a8c47bfd d65f03c0 (b8617803) Resetting CPU ...
And why don't you fix the fdt_addr then? Shouldn't it be unset if there is
no
actual device tree present in a ROM section? (I don't say there isn't
another
underlying problem when you use an invalid fdt_addr).
The problem shown in above log is triggered when unset the fdt_addr.
On which platform are you seeing this issue?
I have tested v2021.07 on ls1043a-rdb and it doesn't reproduce.
On LS1043ARDB, the fdt_addr points to the NOR flash, so no this issue. Reproduce on LS1046ARDB, on which no NOR flash is mapped to that space.
Board is booting from NOR and I have two mmc partitions: Device Start End Sectors Size Type /dev/mmcblk0p1 2048 1048576 1046529 511M Linux filesystem /dev/mmcblk0p2 1050624 15523806 14473183 6.9G Linux filesystem
=> run bootcmd_mmc0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Scanning disk esdhc@1560000.blk... Found 3 disks No EFI system partition PCIe1: pcie@3400000 disabled PCIe2: pcie@3500000 Root Complex: no link PCIe3: pcie@3600000 Root Complex: no link WARNING failed to get smmu node: FDT_ERR_NOTFOUND WARNING failed to get smmu node: FDT_ERR_NOTFOUND BootOrder not defined EFI boot manager: Cannot load any image Scanning mmc 0:2... WARNING failed to get smmu node: FDT_ERR_NOTFOUND WARNING failed to get smmu node: FDT_ERR_NOTFOUND BootOrder not defined EFI boot manager: Cannot load any image =>
I still don't see the issue even if I remove fdt_addr: => setenv fdt_addr => run bootcmd_mmc0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... WARNING failed to get smmu node: FDT_ERR_NOTFOUND WARNING failed to get smmu node: FDT_ERR_NOTFOUND BootOrder not defined EFI boot manager: Cannot load any image Scanning mmc 0:2... WARNING failed to get smmu node: FDT_ERR_NOTFOUND WARNING failed to get smmu node: FDT_ERR_NOTFOUND BootOrder not defined EFI boot manager: Cannot load any image =>
Dig deeper, it's a NXP internal patch that results in the SError, upsteam doesn't have this problem. The SError is triggered during the DT setup phase of bootefi when using the u-boot packaged fdt. To resolve the 'Sync Abort' issue, I'll send a patch to remove the 'fdt_addr' env, it was added by mistake since the DTB is loaded from boot filesystem instead of hardware ROM.
Thanks, Zhiqiang
If it not unset, the SError is triggered when to check the magic of the fdt
header.
Thanks, Zhiqiang
-michael
BR, Yousaf
Hi Tom,
-----Original Message----- From: Tom Rini trini@konsulko.com Sent: 2021年7月22日 23:26 To: Z.Q. Hou zhiqiang.hou@nxp.com; Michael Walle michael@walle.cc; Heinrich Schuchardt xypron.glpk@gmx.de Cc: u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
From: Hou Zhiqiang Zhiqiang.Hou@nxp.com
The feature BOOTENV_SHARED_EFI is not supported on layerscape boards, it didn't result kernel boot crash previously since there isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of 'boot_efi_binary'.
But since the commit f3866909e350 ("distro_bootcmd: call EFI bootmgr even without having /EFI/boot"), it will cause kernel boot crash as there isn't a valid fdt_addr and it finially uses the device tree blob of U-Boot and further cause errors.
As this feature is enabled by default for armv7 and armv8, so disable it explicitly to avoid calling the 'scan_dev_for_efi'.
I'm not thrilled with this. Why isn't the solution to get and keep in sync the device trees, so that the tree U-Boot has is valid for the kernel? I'm also open to discussing f3866909e350 more. But I'm really opposed to disabling EFI_LOADER on modern platforms as that will make adoption of U-Boot in device harder I feel.
I think it doesn't make sense for the platforms on which the EFI boot is not planed. As there isn't EFI boot needed components in the search path, finally the EFI boot will be skipped. I don't want to look into the EFI boot process, so I trend to disable the feature, is it acceptable?
Thanks, Zhiqiang
-- Tom
Am 2021-07-26 08:18, schrieb Z.Q. Hou:
Hi Tom,
-----Original Message----- From: Tom Rini trini@konsulko.com Sent: 2021年7月22日 23:26 To: Z.Q. Hou zhiqiang.hou@nxp.com; Michael Walle michael@walle.cc; Heinrich Schuchardt xypron.glpk@gmx.de Cc: u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
From: Hou Zhiqiang Zhiqiang.Hou@nxp.com
The feature BOOTENV_SHARED_EFI is not supported on layerscape boards, it didn't result kernel boot crash previously since there isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of 'boot_efi_binary'.
But since the commit f3866909e350 ("distro_bootcmd: call EFI bootmgr even without having /EFI/boot"), it will cause kernel boot crash as there isn't a valid fdt_addr and it finially uses the device tree blob of U-Boot and further cause errors.
As this feature is enabled by default for armv7 and armv8, so disable it explicitly to avoid calling the 'scan_dev_for_efi'.
I'm not thrilled with this. Why isn't the solution to get and keep in sync the device trees, so that the tree U-Boot has is valid for the kernel? I'm also open to discussing f3866909e350 more. But I'm really opposed to disabling EFI_LOADER on modern platforms as that will make adoption of U-Boot in device harder I feel.
I think it doesn't make sense for the platforms on which the EFI boot is not planed. As there isn't EFI boot needed components in the search path, finally the EFI boot will be skipped. I don't want to look into the EFI boot process, so I trend to disable the feature, is it acceptable?
Actually, from a customer point of view, this is really annoying. These platforms should be reference implenention and you're skipping an important feature, that is booting a generic linux distribution.
Anyway, I don't understand why the efi bootmgr boots on your board at all. AFAIK it needs the BootOrder/BootNext EFI variables, no?
-michael
On Mon, Jul 26, 2021 at 06:18:45AM +0000, Z.Q. Hou wrote:
Hi Tom,
-----Original Message----- From: Tom Rini trini@konsulko.com Sent: 2021年7月22日 23:26 To: Z.Q. Hou zhiqiang.hou@nxp.com; Michael Walle michael@walle.cc; Heinrich Schuchardt xypron.glpk@gmx.de Cc: u-boot@lists.denx.de; Priyanka Jain priyanka.jain@nxp.com Subject: Re: [PATCH] configs: layerscape: Disable the EFI_LOADER feature
On Thu, Jul 22, 2021 at 02:25:59PM +0800, Zhiqiang Hou wrote:
From: Hou Zhiqiang Zhiqiang.Hou@nxp.com
The feature BOOTENV_SHARED_EFI is not supported on layerscape boards, it didn't result kernel boot crash previously since there isn't the efi/boot/"BOOTEFI_NAME" and it skip calling of 'boot_efi_binary'.
But since the commit f3866909e350 ("distro_bootcmd: call EFI bootmgr even without having /EFI/boot"), it will cause kernel boot crash as there isn't a valid fdt_addr and it finially uses the device tree blob of U-Boot and further cause errors.
As this feature is enabled by default for armv7 and armv8, so disable it explicitly to avoid calling the 'scan_dev_for_efi'.
I'm not thrilled with this. Why isn't the solution to get and keep in sync the device trees, so that the tree U-Boot has is valid for the kernel? I'm also open to discussing f3866909e350 more. But I'm really opposed to disabling EFI_LOADER on modern platforms as that will make adoption of U-Boot in device harder I feel.
I think it doesn't make sense for the platforms on which the EFI boot is not planed. As there isn't EFI boot needed components in the search path, finally the EFI boot will be skipped. I don't want to look into the EFI boot process, so I trend to disable the feature, is it acceptable?
I'm pretty confused then. What are you planning to support on these platforms since a whole lot of the aarch64 ecosystem assumes EFI+DT if it's not EFI+ACPI for boot. That includes I think all of the Linux distributions out there except Armbian (maybe?) and for Yocto-based images it depends on how you configure it (it is quite happy to make grub-efi images). So it seems like there's a number of issues of which this seems to be working around them.
participants (6)
-
Fabio Estevam -
Mian Yousaf Kaukab -
Michael Walle -
Tom Rini -
Z.Q. Hou -
Zhiqiang Hou