Message-ID: <CALHNRZ8sqCpUMyCFP99b7nHu2onojZ0EY6YGQZ9RMP0kH8jWzw@mail.gmail.com>
Date: Wed, 11 Feb 2026 09:10:39 -0600
From: Aaron Kling <webgeek1234@...il.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Bjorn Andersson <andersson@...nel.org>, Konrad Dybcio <konradybcio@...nel.org>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Kumar Sharma <quic_vksharma@...cinc.com>, linux-arm-msm@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Pavan Kondeti <pavan.kondeti@....qualcomm.com>
Subject: Re: [PATCH v2] arm64: dts: qcom: sm8550: Fix DTBO boot failure

On Mon, Feb 9, 2026 at 1:51 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>
> On 08/02/2026 16:10, Aaron Kling wrote:
> > On Sun, Feb 8, 2026 at 3:07 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
> >>
> >> On 08/02/2026 02:16, Aaron Kling via B4 Relay wrote:
> >>> From: Pavan Kondeti <pavan.kondeti@....qualcomm.com>
> >>>
> >>> 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@...il.com>
> >>> Signed-off-by: Aaron Kling <webgeek1234@...il.com>
> >>> ---
> >>> 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.

Also, the vast majority of devices can't replace the bootloader. This
isn't an option, the devices are fused. The qrd and hdk are not
available to consumers. There are a handful of qcs8550 devices like
what I'm using that are unfused and thus are able to replace abl, but
I would prefer not not add that extra step for users to install my
project. Plus, I am trying to not just make changes that only affect
my devices, when they could be generic and benefit all devices using
the soc.

Aaron

Powered by blists - more mailing lists