[PATCH] board/qualcomm: use bootflow for default boot

[Neil Armstrong]

On 5/26/26 16:33, Casey Connolly wrote:
> 
> 
> On 23/05/2026 01:53, Ricardo de Araujo (Salveti) wrote:
>> On Fri, May 22, 2026 at 10:10 AM Casey Connolly
>> <casey.connolly at linaro.org> wrote:
>>> On 21/05/2026 19:07, Ricardo de Araujo (Salveti) wrote:
>>>> On Thu, May 21, 2026 at 12:32 PM Casey Connolly
>>>> <casey.connolly at linaro.org> wrote:
>>>>> 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?
>>
>> You can load with extlinux or via a boot script (often the preferred
>> option as you can add boot specific logic to it to support a/b
>> selection and so on).
>>
>>>>>> 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?
>>
>> Yeah, it is included directly at the moment:
>>
>> configs/qcm6490_defconfig:#include "qcom_defconfig"
>> configs/qcom_qcs8300_defconfig:#include "qcom_defconfig"
>> configs/qcom_qcs615_defconfig:#include "qcom_defconfig"
>> configs/qcom_qcs9100_defconfig:#include "qcom_defconfig"
>>
>>> 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.
>>
>> The board level config can contain whatever that is specific for them
>> at that point (e.g. mbn header version), now the boot mechanics would
>> probably be more generic.
>>
>>>>>> 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.
>>
>> While that is possible, it depends on the boot methods that are
>> enabled by default in the config, and from my perspective it is ok to
>> assume that it should try all the boot methods which are enabled.
>> Currently we do have several methods enabled (by default), but they
>> are not leveraged by the default boot command and environment.
>>
>> The methods I have with standard qcm6490_defconfig:
>>
>>    - CONFIG_BOOTMETH_EXTLINUX=y
>>    - CONFIG_BOOTMETH_SCRIPT=y
>>    - CONFIG_BOOTMETH_EFILOADER=y
>>    - CONFIG_BOOTMETH_EFI_BOOTMGR=y
>>    - CONFIG_BOOTMETH_EXTLINUX_PXE=y
>>
>> So if we enable bootflow by default (could as well be the second
>> option after trying efi boot), the behavior will depend on the methods
>> that are enabled, and we can disable options that are not necessarily
>> known to work.
>>
>>> 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.
>>
>> Having a dedicated default configuration for dragonwind should be
>> perfectly fine (and included by the dragonwing targets by default), as
>> we can probably assume that u-boot would be supported natively instead
>> of chainloaded.
>>
>> If you are OK with that I can send another set to create a specific
>> dragonwind configuration file that could support a wider range of use
>> cases by default.
> 
> I think that would be the best way to go here. It technically isn't
> necessary to set CONFIG_TEXT_BASE once my tooling rework is merged since
> U-Boot is PIE and mkmbn sets the appropriate load address. So you could
> have a single qcom_dragonwing_defconfig and just pass DEVICE_TREE=... to
> make. Maybe that level of commonisation can come later though.
> 
> I'd propose adding a qcom-dragonwing.config fragment in the configs/ dir
> and having the boards all #include it.
> 
> To clarify the boot methods situation, could you explicitly unset
> BOOTSTD and bootflow/bootmeth and enable them in the dragonwing
> fragment, then you can add a dragonwing.env and I think that neatly
> makes space for all of the dragonwing specific functionality you want.
> 
> That all being said, I would still very much prefer you avoid standard
> boot or at least try to keep the scope small, but I understand it seems
> to be the best way to support extlinux/FIT and I don't want to block
> that (though I do still question the merits over just sticking with EFI).
> 
> You should also update board/qualcomm/MAINTAINERS, maybe merge all the
> dragonwing stuff together, add "N: dragonwing" and list a few folks who
> are active on the list and willing to maintain this support going forwards.
> 
> I'd like to get Neil's input on this but barring any issues on his side
> I think this is the right way to go.

Yeah I agree this is the best way to go

> 
> Thanks for taking the time to discuss this and find a good middleground
> to move forwards.
> 
>>
>> Thanks,
>>
>> Ricardo
>