Re: [PATCH v2] arm64: dts: qcom: sm8550: Fix DTBO boot failure

[Bjorn Andersson]

On Fri, Feb 13, 2026 at 04:50:25PM -0600, Aaron Kling wrote:
> On Fri, Feb 13, 2026 at 2:34 PM Bjorn Andersson <andersson@xxxxxxxxxx> wrote:
> >
> > On Wed, Feb 11, 2026 at 09:10:39AM -0600, Aaron Kling wrote:
> > > On Mon, Feb 9, 2026 at 1:51 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> > > >
> > > > On 08/02/2026 16:10, Aaron Kling wrote:
> > > > > On Sun, Feb 8, 2026 at 3:07 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> > > > >>
> > > > >> On 08/02/2026 02:16, Aaron Kling via B4 Relay wrote:
> > > > >>> From: Pavan Kondeti <pavan.kondeti@xxxxxxxxxxxxxxxx>
> > > > >>>
> > > > >>> ABL requires certain things in the base dtb to apply a dtbo. Namely:
> > > > >>>
> > > > >>> * A label named qcom_tzlog must exist, but doesn't have to contain any
> > > > >>>   specific properties
> > > > >>> * The timer node must have a label named arch_timer
> > > > >>>
> > > > >>> This aligns the sm8550 soc dtsi with those requirements. Without these
> > > > >>> in the base dtb, when ABL attempts to apply any dtbo, it will fail to
> > > > >>> the bootloader menu.
> > > > >>>
> > > > >>
> > > > >> Incomplete DCO chain.
> > > > >>
> > > > >>> Co-authored-by: Aaron Kling <webgeek1234@xxxxxxxxx>
> > > > >>> Signed-off-by: Aaron Kling <webgeek1234@xxxxxxxxx>
> > > > >>> ---
> > > > >>> With a current mainline sm8550 base dtb, ABL will fail to apply any dtbo
> > > > >>> and fail back to the bootloader menu. There are two changes needed:
> > > > >>
> > > > >> Since when? We were testing SM8550 (me on QRD) all the time and there
> > > > >> was no problem.
> > > > >>
> > > > >> You need to provide details which hardware needs it, if this is about to
> > > > >> expected, but honestly, we don't add such nodes/labels for downstream
> > > > >> bootloader. Qualcomm should fix the bootloder instead.
> > > > >
> > > > > This discussion has been ongoing in a couple places. It is needed on
> > > > > all semi-recent recent qcom socs. See this chain [0] on my sm8550
> > > >
> > > >
> > > > Explanation must be in this commit, not in other places.
> > > >
> > > > > questions thread and the previous revision of this series [1]. This
> > > > > has been a known issue for a while, see this comment [2] on the gunyah
> > > > > watchdog series, which is what the series was based on.
> > > >
> > > > But that [2] still speaks about overlay. You are suppose to boot
> > > > standard kernel with typical setup - concatenated DTB.
> > > >
> > > > If you want some other ways, like choosing overlays by ABL or whatever
> > > > else, you need to fix ABL.
> > > >
> > > > You want to use some custom boot way of ABL, but it's broken... yet it
> > > > is no reason to add these properties. What if I want to boot DTJUNK
> > > > files via my custom ABJUNK - can I add such things to upstream? No.
> > > >
> > > > You cannot add properties to support custom boot of ABL if that boot is
> > > > broken.
> > >
> > > My use case here is an open source Android rom. I would like to think
> > > that android would be a supported use case. Not necessarily a driving
> > > force for decisions, but at least supported. And I'm using the
> > > standard boot image v4 setup with dtb on vendor_boot and dtbo's on the
> > > dedicated partition. This isn't some weird and wacko setup, it's what
> > > the vast majority of devices this soc is used in are designed for.
> > >
> >
> > Android isn't a weird and wacko setup; but I'm guessing that the
> > proposed changes aren't related to running Android, nor are they related
> > to dependencies of the overlays, but it rather relate to some
> > runtime-generated overlay that ABL wants to apply?
> 
> I honestly can't say what the underlying cause is. A couple of us have
> looked at the public abl source and weren't able to find what causes
> this issue. We just know that this issue happens when abl tries to
> apply a dtbo off the dtbo partition. So yes, in technicality this is
> not an android specific issue. I mention android because having a dtbo
> is generally expected in the aosp setup. In my specific use case, I
> have four devices from the same odm, where it's simple to split the
> common part into a dts, then the device specific parts into dtso's,
> allowing for a single software build to support all four devices.
> Requiring everything to be baked into a dts would require separate
> vendor_boot images per device, and thus completely separate build
> targets.

Your use of overlays is very reasonable.

It is an Android-specific issue, because you store and apply those
overlays using the Android bootloader and its way of doing things.

If you run e.g. Debian on your 8550 you could still use overlays to
solve your problem, but you wouldn't want abl and/or vendor_boot.

> 
> > Fixing ABL to be resilient against such failure cases certainly seems
> > like the right thing to do. But I'm guessing that you're on some device
> > where you can't change the ABL?
> 
> My devices are unfused, and thus I could change ABL. Two problems,
> however. 1) we can't find the necessary changes to make to fix the
> problem. And 2) this problem is more universal. Per [0], this affects
> 8550 and 8750 using the qcom baseline abl. By extrapolation, all odm
> copies will also have this problem. This has also been observed on a
> sm7635 phone. It appears to affect all baseline abl copies since at
> least sm8550.

It's fair to assume that there's leverage between the different
platforms, there shouldn't be much hardware-specifics in ABL.

> 
> > If that is the case, then I'm open to a pragmatic solution where you add
> > such workarounds to the specific dts that needs it, with clear
> > documentation of the circumstances.
> 
> > PS. Not all SM8550 runs Android, not all SM8550 has that specific
> > version of ABL, so therefor the change does not belong in sm8550.dtsi.
> 
> Ideally would be getting this fixed in the baseline abl code by qcom,
> since this issue seems to be continuing.

Sounds like it, but I don't know what it is that ABL is expecting to be
able to insert. [0] seems to mostly say "I added this and then it works"
:(

> That's not something I can affect, however.

I can ask the team to read this thread...

> But I disagree about making this device specific,
> because the vast majority of devices are affected by this, it would be
> the exception to not be affected, from what I can tell. And on more
> soc's than sm8550, but qcs8550 is the only qcom soc I am currently
> working on.

I understand your argument, but I don't want top-level quirks for things
that is device-specific.

Regards,
Bjorn

> 
> Aaron
> 
> [0] https://lore.kernel.org/all/91002189-9d9e-48a2-8424-c42705fed3f8@xxxxxxxxxxx/