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: <CAF6AEGv_MbP-ssR9k2TEP4Bcpyto0V3F6uXkESRT3rjg2U71AA@mail.gmail.com>
Date: Tue, 18 Mar 2025 10:17:07 -0700
From: Rob Clark <robdclark@...il.com>
To: Georg Gottleuber <g.gottleuber@...edocomputers.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>, 
	Konrad Dybcio <konrad.dybcio@....qualcomm.com>, Georg Gottleuber <ggo@...edocomputers.com>, 
	Bjorn Andersson <andersson@...nel.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	wse@...edocomputers.com, cs@...edocomputers.com
Subject: Re: [PATCH] arm64: dts: qcom: Add device tree for TUXEDO Elite 14 Gen1

On Tue, Mar 18, 2025 at 8:28 AM Georg Gottleuber
<g.gottleuber@...edocomputers.com> wrote:
>
> Am 07.03.25 um 07:45 schrieb Dmitry Baryshkov:
> [...]
> >>> diff --git a/arch/arm64/boot/dts/qcom/x1e80100-tuxedo-elite-14-gen1.dts b/arch/arm64/boot/dts/qcom/x1e80100-tuxedo-elite-14-gen1.dts
> >>> new file mode 100644
> >>> index 000000000000..86bdec4a2dd8
> >>> --- /dev/null
> >>> +++ b/arch/arm64/boot/dts/qcom/x1e80100-tuxedo-elite-14-gen1.dts
> >>
> >>> +&gpu {
> >>> +       status = "okay";
> >>> +
> >>> +       zap-shader {
> >>> +               firmware-name = "qcom/a740_zap.mbn";
> >>
> >> Are the laptop's OEM key/security fuses not blown?
> >
> > Can this laptop use "qcom/x1e80100/gen70500_zap.mbn" which is already a
> > part of linux-firmware?
>
> It seems so.
>
> Because there were no logs about loading zap.mbn, I activated dyndbg
> (dyndbg="file drivers/base/firmware_loader/main.c +fmp"). See attachment
> for dmesg output. But GUI freezes after sddm login.

Hmm, if zap were incorrectly signed, the error would come after
firmware_loader.  You should see something with "Unable to authorize
the image" (`dmesg | grep drm` would show it).

As Konrad mentioned, make sure you have mesa v24.3 or later, v24.2 is
missing some needed fixes

BR,
-R

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ