On Fri, May 22, 2026 at 10:10 AM Casey Connolly
<[email protected]> wrote:
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:
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.
