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

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

[Aaron Kling via B4 Relay]

From: Pavan Kondeti <pavan.kondeti@oss.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.

Co-authored-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.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:

* Add a label named qcom_tzlog
* Add a label named arch_timer to the timer node
---
Changes in v2:
- Drop tz log changes
- Add tz log label to a generic node
- Link to v1: https://lore.kernel.org/r/20260129-sm8550-abl-dtbo-v1-0-abca3be14024@gmail.com
---
 arch/arm64/boot/dts/qcom/sm8550.dtsi | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index e3f93f4f412ded9583a6bc9215185a0daf5f1b57..04ea1a4a015aa5a4fd615e068b6f18b7c336607c 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -32,7 +32,8 @@ / {
 	#address-cells = <2>;
 	#size-cells = <2>;
 
-	chosen { };
+	// This label is required by ABL to apply a dtbo
+	qcom_tzlog: chosen { };
 
 	clocks {
 		xo_board: xo-board {
@@ -6756,7 +6757,8 @@ trip-point2 {
 		};
 	};
 
-	timer {
+	// This label is required by ABL to apply a dtbo
+	arch_timer: timer {
 		compatible = "arm,armv8-timer";
 		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
 			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,

---
base-commit: 3f24e4edcd1b8981c6b448ea2680726dedd87279
change-id: 20260128-sm8550-abl-dtbo-96288634f00d

Best regards,
-- 
Aaron Kling <webgeek1234@gmail.com>

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

[Krzysztof Kozlowski]

On 08/02/2026 02:16, Aaron Kling via B4 Relay wrote:
> From: Pavan Kondeti <pavan.kondeti@oss.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@gmail.com>
> Signed-off-by: Aaron Kling <webgeek1234@gmail.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.


Best regards,
Krzysztof

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

[Aaron Kling]

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

My current understanding is that the qcom_tzlog and arch_timer labels
are required period for abl to apply a dtbo. And this setup will only
work flashing a unit from a downstream dtb to mainline with this
change if said unit is removed from all external power and fully
powered off. For this to work without a cold restart, the scm node
needs renamed to qcom_scm. This latter part was rejected during v1.

Aaron

[0] https://lore.kernel.org/linux-arm-msm/aa90c5ca-72d7-48fb-b3b6-4be8a51dc0cc@oss.qualcomm.com/
[1] https://lore.kernel.org/linux-arm-msm/20260129-sm8550-abl-dtbo-v1-0-abca3be14024@gmail.com/
[2] https://lore.kernel.org/all/91002189-9d9e-48a2-8424-c42705fed3f8@quicinc.com/

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

[Bjorn Andersson]

On Sat, Feb 07, 2026 at 07:16:03PM -0600, Aaron Kling via B4 Relay wrote:
> From: Pavan Kondeti <pavan.kondeti@oss.qualcomm.com>
> 
> ABL requires certain things in the base dtb to apply a dtbo.

What if I don't need/want a dtbo? Or are you referring to some specific
overlay that ABL attempts to apply?

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

I don't consider this to be a property of the SM8550 SoC, but rather
ABL shipping on specific devices - where ABL can't be replaced/fixed.

It's been a while since I booted SM8550 with the unmodified ABL (as I
always use abl2esp these days), but I don't remember having this problem
on the MTP...

Can we push this down to those specific devices that manifest this
problem and does not allow replacing ABL?

> Co-authored-by: Aaron Kling <webgeek1234@gmail.com>
> Signed-off-by: Aaron Kling <webgeek1234@gmail.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:
> 
> * Add a label named qcom_tzlog
> * Add a label named arch_timer to the timer node

You said that in the commit message.

Regards,
Bjorn

> ---
> Changes in v2:
> - Drop tz log changes
> - Add tz log label to a generic node
> - Link to v1: https://lore.kernel.org/r/20260129-sm8550-abl-dtbo-v1-0-abca3be14024@gmail.com
> ---
>  arch/arm64/boot/dts/qcom/sm8550.dtsi | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> index e3f93f4f412ded9583a6bc9215185a0daf5f1b57..04ea1a4a015aa5a4fd615e068b6f18b7c336607c 100644
> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> @@ -32,7 +32,8 @@ / {
>  	#address-cells = <2>;
>  	#size-cells = <2>;
>  
> -	chosen { };
> +	// This label is required by ABL to apply a dtbo
> +	qcom_tzlog: chosen { };
>  
>  	clocks {
>  		xo_board: xo-board {
> @@ -6756,7 +6757,8 @@ trip-point2 {
>  		};
>  	};
>  
> -	timer {
> +	// This label is required by ABL to apply a dtbo
> +	arch_timer: timer {
>  		compatible = "arm,armv8-timer";
>  		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
>  			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
> 
> ---
> base-commit: 3f24e4edcd1b8981c6b448ea2680726dedd87279
> change-id: 20260128-sm8550-abl-dtbo-96288634f00d
> 
> Best regards,
> -- 
> Aaron Kling <webgeek1234@gmail.com>
> 
> 

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

[Krzysztof Kozlowski]

On 08/02/2026 16:10, Aaron Kling wrote:
> On Sun, Feb 8, 2026 at 3:07 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 08/02/2026 02:16, Aaron Kling via B4 Relay wrote:
>>> From: Pavan Kondeti <pavan.kondeti@oss.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@gmail.com>
>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.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 current understanding is that the qcom_tzlog and arch_timer labels
> are required period for abl to apply a dtbo. And this setup will only


Best regards,
Krzysztof

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

[Aaron Kling]

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

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

[Krzysztof Kozlowski]

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

Android required in the past a lot of out of tree code and for years did
not care about mainlining these, so I do not care about Android really.
It's a fork, which for years decided to be separate, so we are not bound
by fork rules. Whatever the fork now wants to do together with upstream,
the fork must adjust, not upstream.


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

On downstream trees. With ABL designed for downstream trees. With
engineers designing all this WITHOUT single consultation with upstream,
so sorry, this is wacko in upstream :)


> 
> Also, the vast majority of devices can't replace the bootloader. This

We all were running Androids as well when upstreaming all Qualcomm
flagship models and we did not have to replace the bootloader. We did
not need any of such changes like here. Although maybe our devices had a
bit different bootloader - this I don't know. It was ABL for downstream
Android, though.

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

... and why standard way, like we all were doing this, of booting
QCS8550 does not work? You append the DTB.

Anyway, this is not 2010 anymore, so vendors and bootloaders if they
want to ask for something MUST:
1. Obey DT spec and upstream recommendations for the DTS they use
2. Follow standard industry interfaces (and "foo_bar" requirement is not
standard industry interface)

I know that you cannot change ABL so the actual complain goes to
Qualcomm and/or Google.

Best regards,
Krzysztof

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

[Bjorn Andersson]

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

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?

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?

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.

Regards,
Bjorn

> 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

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

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

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

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@kernel.org> 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@kernel.org> 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@kernel.org> 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