On Wed, May 20, 2026 at 12:08 PM Casey Connolly <[email protected]> wrote: > On 18/05/2026 21:15, Ricardo de Araujo (Salveti) wrote: > > On Mon, May 18, 2026 at 4:59 AM Casey Connolly > > <[email protected]> wrote: > >> > >> Hi Ricardo, > >> > >> On 14/05/2026 22:57, Ricardo Salveti wrote: > >>> The Qualcomm default environment currently boots only with > >>> 'bootefi bootmgr'. This bypasses the standard boot flow used to > >>> discover extlinux and script boot entries, which are commonly used > >>> for FIT-based Linux boots. > >> > >> We intentionally don't support these alternative boot methods upstream > >> as they aren't standardised or supported by typical distros. There are > >> also plenty of inconsistencies in Linux userspace depending on if SMBIOS > >> (DMI data) is provide or not as well as EFI runtime services. > >> > >> Could you explain a bit more why you want to support extlinux and custom > >> scripts? > > > > My main use case is for the target to automatically find and load fit > > images by default (based on the config used), which is a quite common > > use case for embedded distributions and products (see that it is also > > enabled by default on several other platforms in u-boot). > > That's understandable, and yeah I'm aware that embedded distros have and > continue to use this approach. I'm kinda wary of (and should have > disabled) bootflow, the code for it is a challenge to understand and it > has caused me headaches in the past. But aside from that, the default > environments we ship upstream are the ones that are actively maintained > and used, for qcom that's EFI. > > I'd love it if we /did/ actually directly have users of upstream U-Boot, > but as it stands today anyone shipping it will be making some > customisations to it.
We expect to have meta-qcom and u-boot upstream supporting both FIT and EFI-based boots, the end user can decide which one to use, and that is why bootflow is useful here. I agree that EFI is more suitable for generic distributions, but we expect that some embedded products will leverage FIT directly, and disable EFI entirely (e.g. faster boot, reduced complexity, etc). Since FIT is already widely known and used in u-boot, I think it is good to also support it by default here. > In any case, the other reason I'm wary to use any other boot methods by > default is because as I mentioned we don't support them upstream, and I > don't want to have to care if a change breaks FIT booting (for example). I don't think that there is anything blocking us to support it directly from upstream, and I expect that pure upstream should be fully functional quite soon on multiple targets (some even including SPL support). > > As u-boot provides support for bootflow, supporting several mechanisms > > which are probed at runtime (including EFI boot), I believe it is a > > better default as it supports a wider range of use cases. > > In general supporting more usecases is better, but when it's something > like how to boot the OS I do think it's much better to push folks > towards standardising and EFI is that standard. > > Just because products and embedded distros today use other boot methods > doesn't necessarily mean it's a good thing and to me at least it's clear > that we should just switch to EFI... > > There's no reason not to adopt something like UKI, or even to write an > EFI app that implements FIT booting.... But yeah, it's easy enough to > carry a patch or point to a custom .env file if need-be. That would be up to the user I would say, and FIT is widely used in u-boot on other targets. From the u-boot side I believe both should be supported, I don't think FIT support will be removed from u-boot. Thanks, Ricardo
