[PATCH 0/3] arm64: dts: qcom: sm8550: Fix DTBO boot failure

[PATCH 0/3] arm64: dts: qcom: sm8550: Fix DTBO boot failure

[Aaron Kling via B4 Relay]

With a current mainline sm8550 base dtb, ABL will fail to apply any dtbo
and fail back to the bootloader menu. There are three changes needed:

* Add the tz-log node and a label named qcom_tzlog
* Rename the scm node to qcom_scm
* Add a label named arch_timer to the timer node

The tz-log binding doc and node are sourced from CLO commits. The other
changes are sourced from a lkml message and attributed to the author of
the message.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
Kuldeep Singh (1):
      dt-bindings: firmware: Add tz-log doc

Lei Chen (1):
      arm64: dts: qcom: sm8550: Add tz-log node

Pavan Kondeti (1):
      arm64: dts: qcom: sm8550: Fix DTBO boot failure

 .../devicetree/bindings/firmware/qcom,tz-log.yaml  | 66 ++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/sm8550.dtsi               | 12 +++-
 2 files changed, 76 insertions(+), 2 deletions(-)
---
base-commit: 3f24e4edcd1b8981c6b448ea2680726dedd87279
change-id: 20260128-sm8550-abl-dtbo-96288634f00d

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

[PATCH 1/3] dt-bindings: firmware: Add tz-log doc

[Aaron Kling via B4 Relay]

From: Kuldeep Singh <quic_kuldsing@quicinc.com>

Add device-tree bindings for qcom tz-log. Exposes a debug
interface for accessing and displaying diagnostic information
related to secure code(Trustzone/QSEE).

Signed-off-by: Kuldeep Singh <quic_kuldsing@quicinc.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
 .../devicetree/bindings/firmware/qcom,tz-log.yaml  | 66 ++++++++++++++++++++++
 1 file changed, 66 insertions(+)

diff --git a/Documentation/devicetree/bindings/firmware/qcom,tz-log.yaml b/Documentation/devicetree/bindings/firmware/qcom,tz-log.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..e5c67ca1546c2d10f4c3b5979bf7b8a1a7dd2132
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/qcom,tz-log.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/qcom,tz-log.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TZLOG (Trust Zone log)
+
+maintainers:
+  - Vikas Kumar Sharma <quic_vksharma@quicinc.com>
+
+description:
+  This exposes a debug interface for accessing and displaying diagnostic information
+  related to secure code (Trustzone/QSEE).
+
+properties:
+  compatible:
+    const: qcom,tz-log
+
+  reg:
+    maxItems: 1
+
+  qcom,hyplog-enabled:
+    type: boolean
+    description: Indicates(boolean) if driver supports HYP logger service.
+
+  hyplog-address-offset:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: Register offset to get the HYP log base address.
+
+  hyplog-size-offset:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: Register offset to get the HYP log size parameter.
+
+  rmlog-address:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: Register offset to get resource manager log base address.
+
+  rmlog-size:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: Register offset to get the resource manager log size parameter.
+
+  tmecrashdump-address-offset:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: Define tme crashump DDR region starting offset.
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        qcom_tzlog: tz-log@146bf720 {
+            compatible = "qcom,tz-log";
+            reg = <0x0 0x146bf720 0x0 0x3000>;
+            qcom,hyplog-enabled;
+            hyplog-address-offset = <0x410>;
+            hyplog-size-offset = <0x414>;
+        };
+    };

-- 
2.52.0

Re: [PATCH 1/3] dt-bindings: firmware: Add tz-log doc

[Rob Herring]

On Thu, Jan 29, 2026 at 01:46:30AM -0600, Aaron Kling wrote:
> From: Kuldeep Singh <quic_kuldsing@quicinc.com>
> 
> Add device-tree bindings for qcom tz-log. Exposes a debug
> interface for accessing and displaying diagnostic information
> related to secure code(Trustzone/QSEE).

$vendor * $firmware-component would be a lot of bindings which doesn't 
scale. This should be something cross-vendor and cross-component. 

> 
> Signed-off-by: Kuldeep Singh <quic_kuldsing@quicinc.com>
> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> ---
>  .../devicetree/bindings/firmware/qcom,tz-log.yaml  | 66 ++++++++++++++++++++++
>  1 file changed, 66 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/firmware/qcom,tz-log.yaml b/Documentation/devicetree/bindings/firmware/qcom,tz-log.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..e5c67ca1546c2d10f4c3b5979bf7b8a1a7dd2132
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/qcom,tz-log.yaml
> @@ -0,0 +1,66 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/qcom,tz-log.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TZLOG (Trust Zone log)
> +
> +maintainers:
> +  - Vikas Kumar Sharma <quic_vksharma@quicinc.com>
> +
> +description:
> +  This exposes a debug interface for accessing and displaying diagnostic information
> +  related to secure code (Trustzone/QSEE).
> +
> +properties:
> +  compatible:
> +    const: qcom,tz-log
> +
> +  reg:
> +    maxItems: 1
> +
> +  qcom,hyplog-enabled:
> +    type: boolean
> +    description: Indicates(boolean) if driver supports HYP logger service.
> +
> +  hyplog-address-offset:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description: Register offset to get the HYP log base address.
> +
> +  hyplog-size-offset:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description: Register offset to get the HYP log size parameter.
> +
> +  rmlog-address:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description: Register offset to get resource manager log base address.
> +
> +  rmlog-size:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description: Register offset to get the resource manager log size parameter.
> +
> +  tmecrashdump-address-offset:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description: Define tme crashump DDR region starting offset.

Wouldn't 'reg' for all of this? Though I have no clue what's in 'reg' 
region.

> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    soc {
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +
> +        qcom_tzlog: tz-log@146bf720 {
> +            compatible = "qcom,tz-log";
> +            reg = <0x0 0x146bf720 0x0 0x3000>;
> +            qcom,hyplog-enabled;
> +            hyplog-address-offset = <0x410>;
> +            hyplog-size-offset = <0x414>;
> +        };
> +    };
> 
> -- 
> 2.52.0
> 

[PATCH 2/3] arm64: dts: qcom: sm8550: Add tz-log node

[Aaron Kling via B4 Relay]

From: Lei Chen <quic_chenlei@quicinc.com>

Add DT node to enable tz-log driver.

Signed-off-by: Lei Chen <quic_chenlei@quicinc.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
 arch/arm64/boot/dts/qcom/sm8550.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index e3f93f4f412ded9583a6bc9215185a0daf5f1b57..740e3c238e8ed0f162dd168291f6e307ace66e80 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -5136,6 +5136,14 @@ data-pins {
 			};
 		};
 
+		qcom_tzlog: tz-log@146aa720 {
+			compatible = "qcom,tz-log";
+			reg = <0 0x146aa720 0 0x3000>;
+			qcom,hyplog-enabled;
+			hyplog-address-offset = <0x410>;
+			hyplog-size-offset = <0x414>;
+		};
+
 		apps_smmu: iommu@15000000 {
 			compatible = "qcom,sm8550-smmu-500", "qcom,smmu-500", "arm,mmu-500";
 			reg = <0 0x15000000 0 0x100000>;

-- 
2.52.0

Re: [PATCH 2/3] arm64: dts: qcom: sm8550: Add tz-log node

[Konrad Dybcio]

On 1/29/26 8:46 AM, Aaron Kling via B4 Relay wrote:
> From: Lei Chen <quic_chenlei@quicinc.com>
> 
> Add DT node to enable tz-log driver.
> 
> Signed-off-by: Lei Chen <quic_chenlei@quicinc.com>
> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> ---

It's nice that you preserved the original authorship.

Please extend the rather lackluster commit message to explain the
"why", which is notably different from the original downstream
addition, since your goal here is to mainly appease a grumpy
bootloader.

>  arch/arm64/boot/dts/qcom/sm8550.dtsi | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> index e3f93f4f412ded9583a6bc9215185a0daf5f1b57..740e3c238e8ed0f162dd168291f6e307ace66e80 100644
> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> @@ -5136,6 +5136,14 @@ data-pins {
>  			};
>  		};
>  
> +		qcom_tzlog: tz-log@146aa720 {

If we were to implement qcom,tz-log upstream, this would definitely
not be a node randomly in the middle of /soc, rather a child of
imem, most likely.

Could you please check whether adding a qcom_tzlog label to *any*
node makes the BL happy enough? Does it need the properties that
this node has?

Konrad

Re: [PATCH 2/3] arm64: dts: qcom: sm8550: Add tz-log node

[Aaron Kling]

On Fri, Jan 30, 2026 at 4:59 AM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 1/29/26 8:46 AM, Aaron Kling via B4 Relay wrote:
> > From: Lei Chen <quic_chenlei@quicinc.com>
> >
> > Add DT node to enable tz-log driver.
> >
> > Signed-off-by: Lei Chen <quic_chenlei@quicinc.com>
> > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > ---
>
> It's nice that you preserved the original authorship.
>
> Please extend the rather lackluster commit message to explain the
> "why", which is notably different from the original downstream
> addition, since your goal here is to mainly appease a grumpy
> bootloader.
>
> >  arch/arm64/boot/dts/qcom/sm8550.dtsi | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > index e3f93f4f412ded9583a6bc9215185a0daf5f1b57..740e3c238e8ed0f162dd168291f6e307ace66e80 100644
> > --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > @@ -5136,6 +5136,14 @@ data-pins {
> >                       };
> >               };
> >
> > +             qcom_tzlog: tz-log@146aa720 {
>
> If we were to implement qcom,tz-log upstream, this would definitely
> not be a node randomly in the middle of /soc, rather a child of
> imem, most likely.
>
> Could you please check whether adding a qcom_tzlog label to *any*
> node makes the BL happy enough? Does it need the properties that
> this node has?

It does appear that ABL doesn't care about the path name, only the
label. And given that the original change that worked had the label
pointing at an empty node, it doesn't fail if all the properties are
missing. I moved the node underneath an sram node and the bootloader
loaded my dtbo just fine.

The imem/sram node, though... The numbers don't add up. Per the
downstream dt, qcom,msm-imem@146aa000 has size 0x1000. Then
tz-log@146AA720 has size 0x3000. Which... starts within the imem
range, then blasts quite far outside of it. So... what should this end
up looking like?

I should also note that an empty node at /soc@0/tz-log fails dt schema
checks. I presume that adding any warnings would immediately get a
patch nuked from orbit, which is why I fetched a real binding and node
from CLO.

Aaron

Re: [PATCH 2/3] arm64: dts: qcom: sm8550: Add tz-log node

[Konrad Dybcio]

On 2/3/26 5:25 AM, Aaron Kling wrote:
> On Fri, Jan 30, 2026 at 4:59 AM Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
>>
>> On 1/29/26 8:46 AM, Aaron Kling via B4 Relay wrote:
>>> From: Lei Chen <quic_chenlei@quicinc.com>
>>>
>>> Add DT node to enable tz-log driver.
>>>
>>> Signed-off-by: Lei Chen <quic_chenlei@quicinc.com>
>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
>>> ---
>>
>> It's nice that you preserved the original authorship.
>>
>> Please extend the rather lackluster commit message to explain the
>> "why", which is notably different from the original downstream
>> addition, since your goal here is to mainly appease a grumpy
>> bootloader.
>>
>>>  arch/arm64/boot/dts/qcom/sm8550.dtsi | 8 ++++++++
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
>>> index e3f93f4f412ded9583a6bc9215185a0daf5f1b57..740e3c238e8ed0f162dd168291f6e307ace66e80 100644
>>> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
>>> @@ -5136,6 +5136,14 @@ data-pins {
>>>                       };
>>>               };
>>>
>>> +             qcom_tzlog: tz-log@146aa720 {
>>
>> If we were to implement qcom,tz-log upstream, this would definitely
>> not be a node randomly in the middle of /soc, rather a child of
>> imem, most likely.
>>
>> Could you please check whether adding a qcom_tzlog label to *any*
>> node makes the BL happy enough? Does it need the properties that
>> this node has?
> 
> It does appear that ABL doesn't care about the path name, only the
> label. And given that the original change that worked had the label
> pointing at an empty node, it doesn't fail if all the properties are
> missing. I moved the node underneath an sram node and the bootloader
> loaded my dtbo just fine.
> 
> The imem/sram node, though... The numbers don't add up. Per the
> downstream dt, qcom,msm-imem@146aa000 has size 0x1000. Then
> tz-log@146AA720 has size 0x3000. Which... starts within the imem
> range, then blasts quite far outside of it. So... what should this end
> up looking like?

The real SYSTEM_IMEM range is base=0x14680000 len=0x2c000, not all of
which is accessible to the OS

Perhaps it's high time for me to respin:

https://lore.kernel.org/linux-arm-msm/20250523-topic-ipa_mem_dts-v1-9-f7aa94fac1ab@oss.qualcomm.com/

> I should also note that an empty node at /soc@0/tz-log fails dt schema
> checks. I presume that adding any warnings would immediately get a
> patch nuked from orbit, which is why I fetched a real binding and node
> from CLO.

I don't know if that'll be acceptable by others, but if all we need
is a label *somewhere*, I wouldn't be totally opposed to doing something
like:

/* The bootloader fails to apply DTBOs if this specific label is absent */
qcom_tzlog: aliases { ... };

Konrad

Re: [PATCH 2/3] arm64: dts: qcom: sm8550: Add tz-log node

[Aaron Kling]

On Tue, Feb 3, 2026 at 3:28 AM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 2/3/26 5:25 AM, Aaron Kling wrote:
> > On Fri, Jan 30, 2026 at 4:59 AM Konrad Dybcio
> > <konrad.dybcio@oss.qualcomm.com> wrote:
> >>
> >> On 1/29/26 8:46 AM, Aaron Kling via B4 Relay wrote:
> >>> From: Lei Chen <quic_chenlei@quicinc.com>
> >>>
> >>> Add DT node to enable tz-log driver.
> >>>
> >>> Signed-off-by: Lei Chen <quic_chenlei@quicinc.com>
> >>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> >>> ---
> >>
> >> It's nice that you preserved the original authorship.
> >>
> >> Please extend the rather lackluster commit message to explain the
> >> "why", which is notably different from the original downstream
> >> addition, since your goal here is to mainly appease a grumpy
> >> bootloader.
> >>
> >>>  arch/arm64/boot/dts/qcom/sm8550.dtsi | 8 ++++++++
> >>>  1 file changed, 8 insertions(+)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> >>> index e3f93f4f412ded9583a6bc9215185a0daf5f1b57..740e3c238e8ed0f162dd168291f6e307ace66e80 100644
> >>> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> >>> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> >>> @@ -5136,6 +5136,14 @@ data-pins {
> >>>                       };
> >>>               };
> >>>
> >>> +             qcom_tzlog: tz-log@146aa720 {
> >>
> >> If we were to implement qcom,tz-log upstream, this would definitely
> >> not be a node randomly in the middle of /soc, rather a child of
> >> imem, most likely.
> >>
> >> Could you please check whether adding a qcom_tzlog label to *any*
> >> node makes the BL happy enough? Does it need the properties that
> >> this node has?
> >
> > It does appear that ABL doesn't care about the path name, only the
> > label. And given that the original change that worked had the label
> > pointing at an empty node, it doesn't fail if all the properties are
> > missing. I moved the node underneath an sram node and the bootloader
> > loaded my dtbo just fine.
> >
> > The imem/sram node, though... The numbers don't add up. Per the
> > downstream dt, qcom,msm-imem@146aa000 has size 0x1000. Then
> > tz-log@146AA720 has size 0x3000. Which... starts within the imem
> > range, then blasts quite far outside of it. So... what should this end
> > up looking like?
>
> The real SYSTEM_IMEM range is base=0x14680000 len=0x2c000, not all of
> which is accessible to the OS
>
> Perhaps it's high time for me to respin:
>
> https://lore.kernel.org/linux-arm-msm/20250523-topic-ipa_mem_dts-v1-9-f7aa94fac1ab@oss.qualcomm.com/
>
> > I should also note that an empty node at /soc@0/tz-log fails dt schema
> > checks. I presume that adding any warnings would immediately get a
> > patch nuked from orbit, which is why I fetched a real binding and node
> > from CLO.
>
> I don't know if that'll be acceptable by others, but if all we need
> is a label *somewhere*, I wouldn't be totally opposed to doing something
> like:
>
> /* The bootloader fails to apply DTBOs if this specific label is absent */
> qcom_tzlog: aliases { ... };

I verified this by tacking the label to the chosen node in the sm8550
dtsi and abl carried on just fine. If this doesn't get a blocking
comment in the next day or so, I'll drop these two tz-log commits, and
fold this into the 'fix dtbos' patch, and send a v2.

Aaron

Re: [PATCH 2/3] arm64: dts: qcom: sm8550: Add tz-log node

[Rob Herring]

On Mon, Feb 02, 2026 at 10:25:23PM -0600, Aaron Kling wrote:
> On Fri, Jan 30, 2026 at 4:59 AM Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
> >
> > On 1/29/26 8:46 AM, Aaron Kling via B4 Relay wrote:
> > > From: Lei Chen <quic_chenlei@quicinc.com>
> > >
> > > Add DT node to enable tz-log driver.
> > >
> > > Signed-off-by: Lei Chen <quic_chenlei@quicinc.com>
> > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > > ---
> >
> > It's nice that you preserved the original authorship.
> >
> > Please extend the rather lackluster commit message to explain the
> > "why", which is notably different from the original downstream
> > addition, since your goal here is to mainly appease a grumpy
> > bootloader.
> >
> > >  arch/arm64/boot/dts/qcom/sm8550.dtsi | 8 ++++++++
> > >  1 file changed, 8 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > > index e3f93f4f412ded9583a6bc9215185a0daf5f1b57..740e3c238e8ed0f162dd168291f6e307ace66e80 100644
> > > --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > > @@ -5136,6 +5136,14 @@ data-pins {
> > >                       };
> > >               };
> > >
> > > +             qcom_tzlog: tz-log@146aa720 {
> >
> > If we were to implement qcom,tz-log upstream, this would definitely
> > not be a node randomly in the middle of /soc, rather a child of
> > imem, most likely.
> >
> > Could you please check whether adding a qcom_tzlog label to *any*
> > node makes the BL happy enough? Does it need the properties that
> > this node has?
> 
> It does appear that ABL doesn't care about the path name, only the
> label. And given that the original change that worked had the label
> pointing at an empty node, it doesn't fail if all the properties are
> missing. I moved the node underneath an sram node and the bootloader
> loaded my dtbo just fine.
> 
> The imem/sram node, though... The numbers don't add up. Per the
> downstream dt, qcom,msm-imem@146aa000 has size 0x1000. Then
> tz-log@146AA720 has size 0x3000. Which... starts within the imem
> range, then blasts quite far outside of it. So... what should this end
> up looking like?
> 
> I should also note that an empty node at /soc@0/tz-log fails dt schema
> checks. I presume that adding any warnings would immediately get a
> patch nuked from orbit, which is why I fetched a real binding and node
> from CLO.

That's simply because tz-log has no addresss but is on a MMIO bus. Can't 
you just do:

/{
  qcom_tzlog: tz-log {};
};

With some note explaining the stupidity.

Rob

Re: [PATCH 2/3] arm64: dts: qcom: sm8550: Add tz-log node

[Rob Herring]

On Fri, Jan 30, 2026 at 11:59:15AM +0100, Konrad Dybcio wrote:
> On 1/29/26 8:46 AM, Aaron Kling via B4 Relay wrote:
> > From: Lei Chen <quic_chenlei@quicinc.com>
> > 
> > Add DT node to enable tz-log driver.
> > 
> > Signed-off-by: Lei Chen <quic_chenlei@quicinc.com>
> > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > ---
> 
> It's nice that you preserved the original authorship.
> 
> Please extend the rather lackluster commit message to explain the
> "why", which is notably different from the original downstream
> addition, since your goal here is to mainly appease a grumpy
> bootloader.

Humm, that's certainly good to know. Though I don't think it will help 
the case for this binding.

Rob

Re: [PATCH 2/3] arm64: dts: qcom: sm8550: Add tz-log node

[Konrad Dybcio]

On 2/9/26 6:07 PM, Rob Herring wrote:
> On Fri, Jan 30, 2026 at 11:59:15AM +0100, Konrad Dybcio wrote:
>> On 1/29/26 8:46 AM, Aaron Kling via B4 Relay wrote:
>>> From: Lei Chen <quic_chenlei@quicinc.com>
>>>
>>> Add DT node to enable tz-log driver.
>>>
>>> Signed-off-by: Lei Chen <quic_chenlei@quicinc.com>
>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
>>> ---
>>
>> It's nice that you preserved the original authorship.
>>
>> Please extend the rather lackluster commit message to explain the
>> "why", which is notably different from the original downstream
>> addition, since your goal here is to mainly appease a grumpy
>> bootloader.
> 
> Humm, that's certainly good to know. Though I don't think it will help 
> the case for this binding.

FYI I'm not really interested in having *that* binding upstream, the
patch contributor first believed that it'd be necessary for the
bootloader to consume it (refusing to boot otherwise), but as we figured
out in another branch of this(?) thread, simply a label was enough

Konrad

[PATCH 3/3] 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:

* The scm node must be named qcom_scm
* 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.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
 arch/arm64/boot/dts/qcom/sm8550.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 740e3c238e8ed0f162dd168291f6e307ace66e80..d7cc20e1931904e7c603b800089f00955ecec3b7 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -329,7 +329,7 @@ cluster_sleep_1: cluster-sleep-1 {
 	};
 
 	firmware {
-		scm: scm {
+		scm: qcom_scm {
 			compatible = "qcom,scm-sm8550", "qcom,scm";
 			qcom,dload-mode = <&tcsr 0x19000>;
 			interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
@@ -6764,7 +6764,7 @@ trip-point2 {
 		};
 	};
 
-	timer {
+	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>,

-- 
2.52.0

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

[Dmitry Baryshkov]

On Thu, Jan 29, 2026 at 01:46:32AM -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. Namely:
> 
> * The scm node must be named qcom_scm
> * 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.
> 
> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>

Did Pavan provide an SoB to the patch?

> ---
>  arch/arm64/boot/dts/qcom/sm8550.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> index 740e3c238e8ed0f162dd168291f6e307ace66e80..d7cc20e1931904e7c603b800089f00955ecec3b7 100644
> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> @@ -329,7 +329,7 @@ cluster_sleep_1: cluster-sleep-1 {
>  	};
>  
>  	firmware {
> -		scm: scm {
> +		scm: qcom_scm {

This one is a definite no-go. Device nodes can't use underscores in
names. It has been told to Qualcomm for ages. If we didn't comply, it
doesn't give us a permission to break the rules.

>  			compatible = "qcom,scm-sm8550", "qcom,scm";
>  			qcom,dload-mode = <&tcsr 0x19000>;
>  			interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
> @@ -6764,7 +6764,7 @@ trip-point2 {
>  		};
>  	};
>  
> -	timer {
> +	arch_timer: timer {

Please add a comment, otherwise somebody might decide to drop the unused
label.

>  		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>,
> 
> -- 
> 2.52.0
> 
> 

-- 
With best wishes
Dmitry

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

[Aaron Kling]

On Sat, Jan 31, 2026 at 1:47 AM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> On Thu, Jan 29, 2026 at 01:46:32AM -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. Namely:
> >
> > * The scm node must be named qcom_scm
> > * 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.
> >
> > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
>
> Did Pavan provide an SoB to the patch?

No. The change comes from the gunyah watchdog discussion here [0].

>
> > ---
> >  arch/arm64/boot/dts/qcom/sm8550.dtsi | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > index 740e3c238e8ed0f162dd168291f6e307ace66e80..d7cc20e1931904e7c603b800089f00955ecec3b7 100644
> > --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > @@ -329,7 +329,7 @@ cluster_sleep_1: cluster-sleep-1 {
> >       };
> >
> >       firmware {
> > -             scm: scm {
> > +             scm: qcom_scm {
>
> This one is a definite no-go. Device nodes can't use underscores in
> names. It has been told to Qualcomm for ages. If we didn't comply, it
> doesn't give us a permission to break the rules.

I have not been able to make ABL load a dtbo without this change so
far, though I have had a suggestion from off list that I may need to
try a different method of flashing changes. I have not yet had time to
do so yet, however. Given this list came from a Qualcomm employee and
worked as advertised, my tendency is to believe that it is the minimal
required.

The devices I am working on are not fused and thus I do have the
capability to use a custom ABL with fixes. However, doing so would
make the user transition from the stock os to a custom one more
complicated. Plus this affects many devices that are fused and thus do
not have such an option.

In the likely case that the bootloader dtbo functionality does indeed
require this change, and the mainline kernel cannot accept it, then
what are the options? My use case involves using out of tree dtbs that
include the mainline dtsi's. I could do a delete-node on scm and add
it back as qcom_scm, but I would very highly prefer not to. The less
downstream changes I have to carry, the less work I need to do to keep
up to date. And on the other side, getting android vendors to update
their ABL seems extremely unlikely.

>
> >                       compatible = "qcom,scm-sm8550", "qcom,scm";
> >                       qcom,dload-mode = <&tcsr 0x19000>;
> >                       interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
> > @@ -6764,7 +6764,7 @@ trip-point2 {
> >               };
> >       };
> >
> > -     timer {
> > +     arch_timer: timer {
>
> Please add a comment, otherwise somebody might decide to drop the unused
> label.

Ack.

Aaron

[0] https://lore.kernel.org/all/91002189-9d9e-48a2-8424-c42705fed3f8@quicinc.com/

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

[Dmitry Baryshkov]

On Sat, Jan 31, 2026 at 03:09:12AM -0600, Aaron Kling wrote:
> On Sat, Jan 31, 2026 at 1:47 AM Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
> >
> > On Thu, Jan 29, 2026 at 01:46:32AM -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. Namely:
> > >
> > > * The scm node must be named qcom_scm
> > > * 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.
> > >
> > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> >
> > Did Pavan provide an SoB to the patch?
> 
> No. The change comes from the gunyah watchdog discussion here [0].

Pavan, can we please get your SoB?

> 
> >
> > > ---
> > >  arch/arm64/boot/dts/qcom/sm8550.dtsi | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > > index 740e3c238e8ed0f162dd168291f6e307ace66e80..d7cc20e1931904e7c603b800089f00955ecec3b7 100644
> > > --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > > @@ -329,7 +329,7 @@ cluster_sleep_1: cluster-sleep-1 {
> > >       };
> > >
> > >       firmware {
> > > -             scm: scm {
> > > +             scm: qcom_scm {
> >
> > This one is a definite no-go. Device nodes can't use underscores in
> > names. It has been told to Qualcomm for ages. If we didn't comply, it
> > doesn't give us a permission to break the rules.
> 
> I have not been able to make ABL load a dtbo without this change so
> far, though I have had a suggestion from off list that I may need to
> try a different method of flashing changes. I have not yet had time to
> do so yet, however. Given this list came from a Qualcomm employee and
> worked as advertised, my tendency is to believe that it is the minimal
> required.

I understand your point. But I'd really not encourage my colleagues into
thinking that it is okay (oh, it was landed for sm8550, so it's fine to
do it in future). And I can foresee this pattern to continue, because
even the latest downstream DTs I can see the qcom_scm node.

> The devices I am working on are not fused and thus I do have the
> capability to use a custom ABL with fixes. However, doing so would
> make the user transition from the stock os to a custom one more
> complicated. Plus this affects many devices that are fused and thus do
> not have such an option.

I understand this intention (and the pain of fused devices).

> 
> In the likely case that the bootloader dtbo functionality does indeed
> require this change, and the mainline kernel cannot accept it, then
> what are the options? My use case involves using out of tree dtbs that
> include the mainline dtsi's. I could do a delete-node on scm and add
> it back as qcom_scm, but I would very highly prefer not to. The less
> downstream changes I have to carry, the less work I need to do to keep
> up to date. And on the other side, getting android vendors to update
> their ABL seems extremely unlikely.

If you have an out-of-tree dts/dtb, then the easiest way might be to
have #define scm qcom_scm in your file. Sorry about it :-(

> > >                       compatible = "qcom,scm-sm8550", "qcom,scm";
> > >                       qcom,dload-mode = <&tcsr 0x19000>;
> > >                       interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
> > > @@ -6764,7 +6764,7 @@ trip-point2 {
> > >               };
> > >       };
> > >
> > > -     timer {
> > > +     arch_timer: timer {
> >
> > Please add a comment, otherwise somebody might decide to drop the unused
> > label.
> 
> Ack.
> 
> Aaron
> 
> [0] https://lore.kernel.org/all/91002189-9d9e-48a2-8424-c42705fed3f8@quicinc.com/

-- 
With best wishes
Dmitry

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

[Aaron Kling]

On Sat, Jan 31, 2026 at 4:34 AM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> On Sat, Jan 31, 2026 at 03:09:12AM -0600, Aaron Kling wrote:
> > On Sat, Jan 31, 2026 at 1:47 AM Dmitry Baryshkov
> > <dmitry.baryshkov@oss.qualcomm.com> wrote:
> > >
> > > On Thu, Jan 29, 2026 at 01:46:32AM -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. Namely:
> > > >
> > > > * The scm node must be named qcom_scm
> > > > * 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.
> > > >
> > > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > >
> > > Did Pavan provide an SoB to the patch?
> >
> > No. The change comes from the gunyah watchdog discussion here [0].
>
> Pavan, can we please get your SoB?
>
> >
> > >
> > > > ---
> > > >  arch/arm64/boot/dts/qcom/sm8550.dtsi | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > > > index 740e3c238e8ed0f162dd168291f6e307ace66e80..d7cc20e1931904e7c603b800089f00955ecec3b7 100644
> > > > --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > > > +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > > > @@ -329,7 +329,7 @@ cluster_sleep_1: cluster-sleep-1 {
> > > >       };
> > > >
> > > >       firmware {
> > > > -             scm: scm {
> > > > +             scm: qcom_scm {
> > >
> > > This one is a definite no-go. Device nodes can't use underscores in
> > > names. It has been told to Qualcomm for ages. If we didn't comply, it
> > > doesn't give us a permission to break the rules.
> >
> > I have not been able to make ABL load a dtbo without this change so
> > far, though I have had a suggestion from off list that I may need to
> > try a different method of flashing changes. I have not yet had time to
> > do so yet, however. Given this list came from a Qualcomm employee and
> > worked as advertised, my tendency is to believe that it is the minimal
> > required.
>
> I understand your point. But I'd really not encourage my colleagues into
> thinking that it is okay (oh, it was landed for sm8550, so it's fine to
> do it in future). And I can foresee this pattern to continue, because
> even the latest downstream DTs I can see the qcom_scm node.

After further testing, it turns out that this change is not entirely
required. Alexander Koskovich pointed out that some things apparently
get cached by ABL and don't get cleared unless all external power
sources are removed from the device and it is powered off. Previously,
I was flashing new images, then doing normal reboots, and seeing the
failures. However, if I leave the scm node as-is in mainline, flash
that, fully power off the unit, then attempt to boot, the unit boots
as expected. However, the other two changes in the series, namely the
tz-log and timer labels, are still required. Not having this change
will unfortunately make user install instructions more complex, but
that is something we can handle. And the rest of the changes should be
mainline admissible. I will drop this part of the patch in the next
revision.

Aaron