Hi Ricardo, On Wed, 20 May 2026 at 11:33, Ricardo de Araujo (Salveti) <[email protected]> wrote: > > 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).
This is great to hear - I certainly welcome Qualcomm's U-Boot efforts! > > > > 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. Regards, Simon
