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

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