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

[Aaron Kling]

On Fri, Feb 13, 2026 at 10:02 PM Bjorn Andersson <andersson@xxxxxxxxxx> wrote:
>
> 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...

Thank you.

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

Very well. When I put together a submission for these devices, I will
add a device specific patch for this then. This series can be marked
as rejected or however that works.

Aaron