On Thu, May 21, 2026 at 12:32 PM Casey Connolly <[email protected]> wrote: > On 20/05/2026 18:32, Ricardo de Araujo (Salveti) 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. > > If the idea is to have qcom docs suggest using upstream u-boot directly, > I'd propose submitting a config fragment and a custom .env for the > dragonwing platforms. > > I'd also strongly recommend against bootflow, you can just chain > commands together "bootefi bootmgr; bootm ..." to implement fallbacks.
Would it be fine to change the patch to add bootflow after "bootefi bootmgr" then? > > 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). > > I'd expect those products to fork U-Boot already and/or send specific > support for their board configuration upstream. They will probably all reuse qcom_defconfig, which uses board/qualcomm/default.env, and that is why I wanted to have bootflow available there by default. > > Since FIT is already widely known and used in u-boot, I think it is > > good to also support it by default here. > > Appeals to popularity go directly against the point from my last email, > booting without EFI might be justified for your product but that doesn't > mean the /reference/ Qualcomm env in upstream U-Boot should support it. > > The reference env upstream is there primarily for testing. I would say this is more a personal preference, my thinking was having both enabled and available by default to facilitate the life of every developer/user. Thanks, Ricardo
