On 6/28/21 3:48 AM, Simon Glass wrote:
Add a new Kconfig option for EBBR so that the naming is more explicit. Make EFI_LOADER depend on it.
Avoid enabling the options (EBBR / EFI_LOADER) by default, to save space.
NAK
Operating systems like Fedora, OpenBSD, FreeBSD require UEFI support.
See discussion in https://lists.denx.de/pipermail/u-boot/2021-June/452947.html
Also add dependencies on driver model and OF_CONTROL, since boards which have not migrated to these should not be using new features like EBBR.
Only supporting devices using the driver model in the UEFI sub-system is fine with me. CONFIG_BLK=y is another possible requirement.
We still have 101 defconfigs not using CONFIG_DM=y. Shouldn't they be eliminated?
We have a low number of boards using CONFIG_DM=y and CONFIG_OF_CONTROL=n. Shouldn't they be moved to CONFIG_OF_CONTROL=y and that symbol be eliminated?
armadillo-800eva_defconfig cm_t335_defconfig colibri_pxa270_defconfig devkit3250_defconfig devkit8000_defconfig ids8313_defconfig integratorap_cm720t_defconfig integratorap_cm920t_defconfig integratorap_cm926ejs_defconfig integratorap_cm946es_defconfig integratorcp_cm1136_defconfig integratorcp_cm920t_defconfig integratorcp_cm926ejs_defconfig integratorcp_cm946es_defconfig kmcoge4_defconfig kzm9g_defconfig mx6memcal_defconfig nokia_rx51_defconfig snapper9260_defconfig snapper9g20_defconfig sniper_defconfig vexpress_aemv8a_semi_defconfig work_92105_defconfig xtfpga_defconfig
We have 274 defconfigs with CONFIG_PARTITIONS=y and CONFIG_BLK=n. Shouldn't they be converted or eliminated?
The unwillingness to use driver model has resulted in the duplication of driver model code in EFI, which is part of the reason for this bloat.
Could you, please, point out where you see possibilities for code reduction.
We started with a situation where many boards were not using the driver model. It is only this year that Tom started to eliminate boards that don't adher to the driver model in some areas.
The semantics used in UEFI and in the rest of U-Boot differ in many aspects. Here are some examples:
* partitions are handled in UEFI like sub-devices but the driver model does not cover partitions yet * to expose partitions UEFI requires fully probed block devices but U-Boot tries to probe upon first usage * UEFI uses file handles but U-Boot does not know this concept
Best regards
Heinrich