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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sat, 12 Jun 2021 21:39:23 +0200
From:   Konrad Dybcio <konrad.dybcio@...ainline.org>
To:     Rob Clark <robdclark@...il.com>
Cc:     ~postmarketos/upstreaming@...ts.sr.ht,
        Martin Botka <martin.botka@...ainline.org>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...ainline.org>,
        Marijn Suijten <marijn.suijten@...ainline.org>,
        jamipkettunen@...ainline.org, Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] arm64: dts: qcom: sm8250: Disable Adreno and Venus by
 default


On 11.06.2021 20:54, Rob Clark wrote:
> On Fri, Jun 11, 2021 at 4:35 AM Konrad Dybcio
> <konrad.dybcio@...ainline.org> wrote:
>> Components that rely on proprietary (not to mention signed!) firmware should
>> not be enabled by default, as lack of the aforementioned firmware could cause
>> various issues, from random errors to straight-up failing to boot.
> I admit I probably don't test much without fw, but I think maybe
> *that* is the issue to solve instead.
>
> Taking a guess, I think the situation is that you have *some* of the
> fw (ie. the unsigned parts coming from linux-firmware) but not
> specifically the zap fw.  So adreno_zap_shader_load() returns -ENODEV,
> which is interpreted to mean "this is a platform that doesn't need zap
> to take GPU out of secure mode", and then things go boom when we try
> to write RBBM_SECVID_TRUST_CNTL ?

While we're not yet there to test that out on A6xx-equipped platforms,

my experience with lack ofAdreno firmware so far has been like so:


no ZAP, wrong ZAP address in the DT, bad ZAP - either a lockup or a reboot


no pm4/pfp - mostly a sane failing route with GPU just not activating after all,

yet still I can recall having some problems that I probably won't be able to

reproduce right now


no GMU fw - as stated before, can't really test properly just yet



Konrad

Powered by blists - more mailing lists