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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <osqwux5xkf4337gahljlkdvoeek6sudxcee3xqb5kp2ngqhwzj@6tz6xjj3cozl>
Date: Sat, 31 Jan 2026 12:33:59 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Aaron Kling <webgeek1234@...il.com>,
        Pavan Kondeti <pavan.kondeti@....qualcomm.com>
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 3/3] arm64: dts: qcom: sm8550: Fix DTBO boot failure

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@....qualcomm.com> wrote:
> >
> > On Thu, Jan 29, 2026 at 01:46:32AM -0600, 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:
> > >
> > > * 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@...il.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