On 21/05/2026 19:07, Ricardo de Araujo (Salveti) wrote:
> 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?
If anything I'd rather disable bootflow entirely by default. How do you
actually load the FIT image to boot? Is it combined with extlinux?
>
>>> 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.
Do you have a list of boards? I don't think any of the Dragonwing boards
use qcom_defconfig currently, maybe they #include it? they also will
need CONFIG_QCOM_GENERATE_MBN once the MBN support is merged, so even if
we can get it down to a single config for all of them (which would be
awesome!) I don't think it should be qcom_defconfig. The need for
supporting non-EFI boot methods is additional justification for that.
>
>>> 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.
The community devs over in the #u-boot-qcom IRC channel are also focused
on EFI as far as I'm aware. To a large degree yes it's personal
preference, when there are no technical reasons justifying a change then
that's typically what it boils down to.
I'm strongly in favour of having Qualcomms dev boards be well supported
upstream to the point where there's no need to have a fork and users can
just run upstream, I'm very glad that ya'll are working towards that
goal. I'm also glad that there has been communication and discussion
about how to architecture some parts of this so that it can land
upstream and you don't have to make breaking changes later.
I think part of what we're running up against here is that
qcom_defconfig and the default environment don't really have a defined
scope with regards to what platforms and configurations are supported.
I'll share my thoughts here and maybe we can build on that?
To me it should be a maximally compatible baseline *horizontally* that
runs on as many platforms as possible with as many universal features as
possible (e.g. capsule updates, fastboot, usb, networking...) while
being minimally *deep*.
So the image it creates requires different post-processing for every
different platform/board (be that building an Android boot image or
baking it into an MBN). The image can boot with EFI and gets you to a
working system but it won't handle PXE boot or expose a UI that can be
navigated with volume keys on a phone. It doesn't support every
filesystem or have secureboot, and so on.
If you want additional features to support a specific board or usecase
more deeply (like emitting .mbn files directly, booting in a
non-standard way, storing the u-boot env on a partition) then you have
to make some changes to the build configuration.
Attempting to enable/use bootflow in the most generic qcom_defconfig
might improve things for the platforms/configurations you care about but
it's also a level of vertical integration that does have an impact on
other platforms that use the same configuration.
To pick an arbitrary example, bootflow has an "Android" boot method,
it's quite possible that on some dev boards or phones U-Boot might then
attempt to boot Android from one of the boot partitions, this could
result in the device booting to a broken state, infinitely booting
U-Boot (if it's chainloaded), crashing, crashlooping, maybe U-Boot tries
to update the slot status and touches something on the misc partition
that makes ABL crashloop and potentially hard bricks a phone (since many
vendors don't provide signed firehose or even a way to access EDL) so
someones perfectly fine device becomes landfill.
I don't know how likely any of those outcomes are, but given how
crash-heavy all of the non-EFI boot paths are I'd really rather not
tempt fate.
Hence, I'd feel much more comfortable if we all worked to minimise
unnecessary scope, having board/usecase specific configurations is
absolutely the best way to do that and as a bonus make it much easier to
justify a lot of quality of life improvements that only make sense in
specific cases.
That's why I would much rather see a dragonwing defconfig and default
environment where we don't have to worry about some change breaking
someone else with a completely different setup.
>
> Thanks,
>
> Ricardo
--
// Casey (she/her)
