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

[Aaron Kling]

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.

> 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.

> 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. That's not something I can
affect, however. 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.

Aaron

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