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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CALHNRZ8j4XWg_oVdPTTp+RPhsEtYrjR3iGusACgoa76dGL0U3A@mail.gmail.com>
Date: Mon, 2 Feb 2026 22:42:20 -0600
From: Aaron Kling <webgeek1234@...il.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Pavan Kondeti <pavan.kondeti@....qualcomm.com>, 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
Subject: Re: [PATCH 3/3] arm64: dts: qcom: sm8550: Fix DTBO boot failure

On Sat, Jan 31, 2026 at 4:34 AM Dmitry Baryshkov
<dmitry.baryshkov@....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@....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.

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