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

[Val Packett]

On 2/16/26 11:27 PM, Aaron Kling wrote:
> 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:
[…]
> > > > > 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.
[…]
> > 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"
> > :(

What everyone (well, postmarketOS community at least) has been doing 
when running mainline kernels on ABL devices is `fastboot erase 
dtbo`(*). Which is why we don't have any DTBO target nodes anywhere 
upstream.

If you want to intentionally use ABL DTBO, and you're absolutely sure 
you **don't** reference these nodes in the DTBOs you're making, then 
indeed it might be some "runtime overlay" coming from ABL code.. but 
have you tried adding these nodes in the DTBOs themselves?

Wait, also, what is the build process for your DTBOs? Could there be 
some weird Android build thing that inserts references to these nodes? 
Have you tried decompiling them with dtc and looking at the resulting dts?

Also have you looked into intermediate bootloaders as an alternative? 
postmarketOS uses lk2nd on ancient devices and U-Boot on modern ones; 
these bootloaders can dynamically choose (or even modify) a DTB based on 
runtime detection (like ABL cmdline). Might be hard/strange to fit that 
into the Android world but well, that's Android's fault :)


(*) except on some old SoCs where we need a "blank" dtbo that just has 
qcom,board-id! https://github.com/barni2000/dtbo-lk2nd (cursed)

~val