Hi Tom, On Fri, 2 Jul 2021 at 14:19, Tom Rini <tr...@konsulko.com> wrote: > > On Fri, Jul 02, 2021 at 02:04:40PM -0600, Simon Glass wrote: > > Hi Mark, > > > > On Fri, 2 Jul 2021 at 13:50, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > > > > > From: Simon Glass <s...@chromium.org> > > > > Date: Fri, 2 Jul 2021 12:36:11 -0600 > > > > > > > > It has come to light that EFI_LOADER adds an extraordinary amount of > > > > code to U-Boot. For example, with nokia_rx51 the size delta is about > > > > 90KB. About 170 boards explicitly disable the option, but is is clear > > > > that many more could, thus saving image size and boot time. > > > > > > > > The current situation is affecting U-Boot's image as a svelt bootloader. > > > > > > > > EFI_LOADER is required by EBBR, a new boot standard which aims to > > > > bring in UEFI protocols to U-Boot. But EBRR is not required for > > > > booting. U-Boot already provides support for FIT, the 'bootm' command > > > > and a suitable hand-off to Linux. EBRR has made the decision to create > > > > a parallel infrastructure, e.g. does not use FIT, nor U-Boot's signing > > > > infrastructure. > > > > > > > > EBBR should be truly optional, enabled only by boards that use it. Most > > > > don't use it but it is enabled anyway. The default boot path should be > > > > one that makes use of the existing U-Boot support. > > > > > > > > To try to retify this situation, this series adds a new Kconfig option > > > > for EBBR so that the naming is more explicit. Then EFI_LOADER is updated > > > > to depend on it. > > > > > > > > The final patch makes EBBR optional. For now, only sandbox enables EBBR. > > > > Other boards can be added as needed, presumably by distributions that > > > > require it. Another approach would be to add 'CONFIG_EBBR=y' to the > > > > .config before building, in the build system. That might be more > > > > friendly > > > > to U-Boot users. > > > > > > > > This series also fixes a minor issue noticed during testing. > > > > > > I don't understand why you're pushing this series in a form that > > > still disables EFI_LOADER by default after last weeks discussions. > > > > I moved the change to non-default to the last patch. Even if that is > > not a good idea, the rest of the series stands. > > > > But more specifically to your question, I have not seen any discussion > > about the size issues identified. Nor has there been any comment on my > > suggestion in the cover letter for distros to define CONFIG_EBBR > > themselves when building U-Boot. I still think turning it off by > > default makes sense given the current situation. > > It's not "distros", it's board vendors. And then SoM vendors. And > their customers. Based on what I see, the default values get re-used > 95% of the time, or more. The things we want to Just Work need to be > enabled by default. What distros want is for vendors to include > firmware in non-volatile storage, not to rebuild every board firmware > and have to ship that, and even less to have to tell users to > reconfigure things and then build. > > It's also at this point counter-productive. If you want to run an off > the shelf distro on aarch64, it's almost certainly going to use > EFI_LOADER. What I wasn't sure about was armv7, but that was confirmed > to be used by default in Fedora and OpenBSD and encouraged (I'll assume > I just didn't find the right install media) for Debian. I'd rather talk > with someone in Armbian about why they don't use EFI_LOADER than try and > convince Fedora to go and use extlinux.conf more (and that leaves out > entirely *BSD which is not what I want to do either!).
I don't know why Armbian is different and I am not going to advocate for extlinux.conf either. There's got to be a better way. Regards, Simon
