On Mon, Jun 28, 2021 at 11:48:00AM +0200, Heinrich Schuchardt wrote:
On 6/28/21 3:48 AM, Simon Glass wrote:
Add a new Kconfig option for EBBR so that the naming is more explicit. Make EFI_LOADER depend on it.
Avoid enabling the options (EBBR / EFI_LOADER) by default, to save space.
NAK
Operating systems like Fedora, OpenBSD, FreeBSD require UEFI support.
See discussion in https://lists.denx.de/pipermail/u-boot/2021-June/452947.html
I also think this is taking things in the wrong direction. It was an intentional "make EFI_LOADER default when supported" when we introduced it, and I still think that's the right overall choice. There's a whole lot of non-customization going on when reference designs are converted to products or other reference designs.
Also add dependencies on driver model and OF_CONTROL, since boards which have not migrated to these should not be using new features like EBBR.
Only supporting devices using the driver model in the UEFI sub-system is fine with me. CONFIG_BLK=y is another possible requirement.
Adding these would be good. And may allow for the code to be simplified?
We still have 101 defconfigs not using CONFIG_DM=y. Shouldn't they be eliminated?
They will be eliminated after v2022.01, following the same 2 years of "the deadline has passed" that's being used by the board removals I've been posting so far this year.
We have a low number of boards using CONFIG_DM=y and CONFIG_OF_CONTROL=n. Shouldn't they be moved to CONFIG_OF_CONTROL=y and that symbol be eliminated?
No, we don't require OF_CONTROL intentionally so that other smaller mechanisms can be used.
[snip]
We have 274 defconfigs with CONFIG_PARTITIONS=y and CONFIG_BLK=n. Shouldn't they be converted or eliminated?
Some number of them will be, I think there's one or two actual funny cases on how that code is used however.