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. Thanks, Ricardo
