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.
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).
>
> 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.
Sorry I'm not more helpful here.
>
> Thanks,
>
> Ricardo
--
// Casey (she/her)
