Re: Adreno 829 (SM8845) zap shader: PAS init rejected by TZ under Gunyah

Re: Adreno 829 (SM8845) zap shader: PAS init rejected by TZ under Gunyah

[Rob Clark]

+ Sumit who would know more about the PAS stuff

BR,
-R

On Wed, Oct 14, 2026 at 12:42 PM VENKAT YADLAPATI
<venkat.yadlapati@hotmail.com> wrote:
>
> Hi,
>
> I am bringing up mainline on a Motorola Signature (SM8845 "alor", a
> Kaanapali derivative with an Adreno 829 / gen8_9_0, chip id 0x44030a00).
> It is a retail, secure-boot phone running Gunyah, with the shipped
> firmware (A171WVH.21-16-16). Display, UFS, USB and the ADSP work.
>
> For the GPU I added a gen8_9_0 entry modelled on the A840 one (2 slices,
> 2432 KiB GMEM, gen80900 firmware). The SQE/GMU/AQE firmware loads and the
> GMU boots (v5.3.25), but loading the zap shader fails: the PAS init call
> for PAS id 13 (0x42000201) returns a0 = 0xffcfffbb, i.e. -EINVAL. The zap
> is the one shipped in the same vendor image (gen80900_zap.mbn).
>
> What I checked so far:
>
> - qcom_scm_pas_supported(13) returns true, and other PAS images load
>   fine through the same path: the ADSP (PAS 36 + 1) boots.
> - Moving the metadata buffer above 4 GiB, loading the zap after the ADSP,
>   and skipping the CP SMMU aperture call change nothing. Passing an SHM
>   bridge (tzmem) buffer gives a different error (0xffcffff6), so I assume
>   the hypervisor bridges the plain buffer itself and 0x...bb comes from TZ.
> - On the same device, the Android 6.18 GKI kernel with KGSL loads the
>   zap with the identical sequence: PAS init(13) -> mem_setup(13,
>   0x9959a000) -> auth_and_reset(13). The only GPU related secure calls
>   before it are qcom_scm_gpu_init_regs (mask 0xb) and a series of
>   MP_ASSIGN calls handing KGSL's secure buffers and secure page tables to
>   VMID_CP_PIXEL. Assigning a page to CP_PIXEL before the zap load on
>   mainline does not help.
>
> Is there a precondition in TZ for the GPU PAS on Gunyah based production
> devices (for example a secure context bank on the GPU SMMU, or something
> KGSL does at probe), or is the zap expected to work the same way as on
> the Kaanapali QRD? Any hint on what 0xffcfffbb means would help too.
>
> A second, unrelated question about naming before I post the SoC patches:
> SM8845 differs from SM8850 enough to need its own TLMM driver (205 GPIOs,
> different pin functions and GPIO->PDC wakeup map), an extra PDC range, a
> gpucc variant and its own GPU, so I describe it as a separate SoC on top
> of kaanapali.dtsi (like purwa on hamoa). For now I used the downstream
> codename "alor" (pinctrl-alor.c, qcom,alor-tlmm, qcom,alor-pdc,
> qcom,alor-gpucc, alor.dtsi). Since kaanapali itself is not the
> downstream name of SM8850, is there an upstream codename planned for
> SM8845, or should I use "alor" (or plain sm8845)?
>
> I plan to post that series soon (TLMM driver and binding, PDC, gpucc
> variant, SoC dtsi, and the A829 support once the zap issue is sorted
> out), followed by the Motorola Signature board. If Qualcomm already has
> SM8845 patches in the queue, please let me know so I don't duplicate the
> work.
>
> Thanks,
> Venkat Yadlapati

Re: Adreno 829 (SM8845) zap shader: PAS init rejected by TZ under Gunyah

[Venkat Yadlapati]

Rob Clark wrote:
> + Sumit who would know more about the PAS stuff
>
> BR,
> -R

Thanks Rob.

Hi Sumit,

Some new data. 0xffcfffbb is QTEE PIL error 0x300045 (the hypervisor
log shows "pil_init_image_to_tz [300045]").

With a boot-time trace of all SMCs on the stock Android 6.12 kernel on
the same phone, Android hits the same error: PAS init for video (9) at
1.9 s returns 0xffcfffbb. IPA (15) at 2.5 s, video at 4.9 s and the GPU
zap (13) at 5.2 s then succeed, all after qseecomd has started and
registered its listeners. The ADSP loads fine without any of that, on
Android and on mainline.

On mainline, qcomtee works (QTEE 5.2.0) and I ran qtee_supplicant from
minkipc (time, TA autoload, FS, GPFS and RPMB listeners), but PAS init
for 13 still fails. qseecomd additionally registers GPT, output
protection, secure processor and interrupt listeners.

Which listener or QTEE state does PIL init depend on for these
subsystems, and is there a way to provide it from mainline?

Thanks,
Venkat

Re: Adreno 829 (SM8845) zap shader: PAS init rejected by TZ under Gunyah

[Venkat Yadlapati]

Venkat Yadlapati wrote:
> Which listener or QTEE state does PIL init depend on for these
> subsystems, and is there a way to provide it from mainline?

Hi Sumit, Rob,

Please disregard my question, it was my mistake: the zap shader I
loaded was signed with the wrong key.

The stock vendor partition carries two copies of the GPU firmware.
/vendor/firmware/gen80900_zap.mbn is signed with the Qualcomm
"SECTOOLS SECP384R1 CURVE TEST ROOT". Android loads the copy from the
modem partition (/vendor/firmware_mnt/image/gen80900_zap.mbn), which is
signed by the OEM. I had packaged the first one, and the production TZ
rejects it with 0x300045.

The early Android failure I described was the same thing: the video
driver probed before the modem partition was mounted and picked up
the test-signed /vendor/firmware/vpu40_1v.mbn. The later successes
after qseecomd started were a coincidence, PAS loads keep working on
Android with qseecomd and keymint stopped.

With the OEM-signed zap, PAS init for 13 succeeds on mainline without
any QTEE listener.

Sorry for the noise, and thanks for looking.

Venkat

Re: Adreno 829 (SM8845) zap shader: PAS init rejected by TZ under Gunyah

[James Wilson]

On Thu Oct 15, 2026 at 6:46 PM IST, Rob Clark wrote:
> + Sumit who would know more about the PAS stuff
>
> BR,
> -R
>
> On Wed, Oct 14, 2026 at 12:42 PM VENKAT YADLAPATI
> <venkat.yadlapati@hotmail.com> wrote:
>>
>> Hi,
>>
>> I am bringing up mainline on a Motorola Signature (SM8845 "alor", a
>> Kaanapali derivative with an Adreno 829 / gen8_9_0, chip id 0x44030a00).
>> It is a retail, secure-boot phone running Gunyah, with the shipped
>> firmware (A171WVH.21-16-16). Display, UFS, USB and the ADSP work.
>>
>> For the GPU I added a gen8_9_0 entry modelled on the A840 one (2 slices,
>> 2432 KiB GMEM, gen80900 firmware). The SQE/GMU/AQE firmware loads and the
>> GMU boots (v5.3.25), but loading the zap shader fails: the PAS init call
>> for PAS id 13 (0x42000201) returns a0 = 0xffcfffbb, i.e. -EINVAL. The zap
>> is the one shipped in the same vendor image (gen80900_zap.mbn).
>>
>> What I checked so far:
>>
>> - qcom_scm_pas_supported(13) returns true, and other PAS images load
>>   fine through the same path: the ADSP (PAS 36 + 1) boots.
>> - Moving the metadata buffer above 4 GiB, loading the zap after the ADSP,
>>   and skipping the CP SMMU aperture call change nothing. Passing an SHM
>>   bridge (tzmem) buffer gives a different error (0xffcffff6), so I assume
>>   the hypervisor bridges the plain buffer itself and 0x...bb comes from TZ.
>> - On the same device, the Android 6.18 GKI kernel with KGSL loads the
>>   zap with the identical sequence: PAS init(13) -> mem_setup(13,
>>   0x9959a000) -> auth_and_reset(13). The only GPU related secure calls
>>   before it are qcom_scm_gpu_init_regs (mask 0xb) and a series of
>>   MP_ASSIGN calls handing KGSL's secure buffers and secure page tables to
>>   VMID_CP_PIXEL. Assigning a page to CP_PIXEL before the zap load on
>>   mainline does not help.
>>
>> Is there a precondition in TZ for the GPU PAS on Gunyah based production
>> devices (for example a secure context bank on the GPU SMMU, or something
>> KGSL does at probe), or is the zap expected to work the same way as on
>> the Kaanapali QRD? Any hint on what 0xffcfffbb means would help too.
>>
>> A second, unrelated question about naming before I post the SoC patches:
>> SM8845 differs from SM8850 enough to need its own TLMM driver (205 GPIOs,
>> different pin functions and GPIO->PDC wakeup map), an extra PDC range, a
>> gpucc variant and its own GPU, so I describe it as a separate SoC on top
>> of kaanapali.dtsi (like purwa on hamoa). For now I used the downstream
>> codename "alor" (pinctrl-alor.c, qcom,alor-tlmm, qcom,alor-pdc,
>> qcom,alor-gpucc, alor.dtsi). Since kaanapali itself is not the
>> downstream name of SM8850, is there an upstream codename planned for
>> SM8845, or should I use "alor" (or plain sm8845)?
>>
>> I plan to post that series soon (TLMM driver and binding, PDC, gpucc
>> variant, SoC dtsi, and the A829 support once the zap issue is sorted
>> out), followed by the Motorola Signature board. If Qualcomm already has
>> SM8845 patches in the queue, please let me know so I don't duplicate the
>> work.

Hello Venkat,

I wanted to let you know, that I'm also working on SM8845 SoC bring up.
I have the SM8845 specific clock, pinctrl, interconnect drivers and much
of the dtsi ready.

No MDSS/DPU or GPU yet though, which you seem to have working.

Best,
James

>>
>> Thanks,
>> Venkat Yadlapati

Re: Adreno 829 (SM8845) zap shader: PAS init rejected by TZ under Gunyah

[Venkat Yadlapati]

Hi James,

Thanks for the heads up. To avoid duplicating work, here is what I have
on a Motorola Signature (SM8845 "alor"), none of it posted yet:

 - TLMM driver and binding (205 GPIOs, own GPIO->PDC wakeup map), alor PDC
 - SoC dtsi on top of kaanapali.dtsi, plus the board DT
 - gpucc variant, A829 catalog, panel, touch, DSI1
 - UFS, USB, SMMU, charging, audio and modem work on hardware

I used the downstream codename "alor" for compatibles and file names.
What do you use?

Do you want to post the SoC base (clock, pinctrl, interconnect, dtsi)
and I rebase on it? I would first diff my TLMM/PDC against yours. Or I
post TLMM/PDC since it is tested on hardware, your call.

Separately: I carry a hack disabling icc-rpmh QoS programming, because
with it the display dies at boot. Do you have a tree with your
interconnect driver that I can test?

Venkat

Re: Adreno 829 (SM8845) zap shader: PAS init rejected by TZ under Gunyah

[James Wilson]

On Fri Oct 23, 2026 at 8:40 PM IST, Venkat Yadlapati wrote:
> Hi James,
>
> Thanks for the heads up. To avoid duplicating work, here is what I have
> on a Motorola Signature (SM8845 "alor"), none of it posted yet:
>
>  - TLMM driver and binding (205 GPIOs, own GPIO->PDC wakeup map), alor PDC
>  - SoC dtsi on top of kaanapali.dtsi, plus the board DT
>  - gpucc variant, A829 catalog, panel, touch, DSI1
>  - UFS, USB, SMMU, charging, audio and modem work on hardware
>
> I used the downstream codename "alor" for compatibles and file names.
> What do you use?
>
> Do you want to post the SoC base (clock, pinctrl, interconnect, dtsi)
> and I rebase on it? I would first diff my TLMM/PDC against yours. Or I
> post TLMM/PDC since it is tested on hardware, your call.

Hello Venkat,

Sounds good. Give me some days to clean up on my side, then I will share
my patches with you.

Best,
James

>
> Separately: I carry a hack disabling icc-rpmh QoS programming, because
> with it the display dies at boot. Do you have a tree with your
> interconnect driver that I can test?
>
> Venkat

Re: Adreno 829 (SM8845) zap shader: PAS init rejected by TZ under Gunyah

[Konrad Dybcio]

On 10/23/26 5:10 PM, Venkat Yadlapati wrote:
> Hi James,
> 
> Thanks for the heads up. To avoid duplicating work, here is what I have
> on a Motorola Signature (SM8845 "alor"), none of it posted yet:
> 
>  - TLMM driver and binding (205 GPIOs, own GPIO->PDC wakeup map), alor PDC
>  - SoC dtsi on top of kaanapali.dtsi, plus the board DT
>  - gpucc variant, A829 catalog, panel, touch, DSI1
>  - UFS, USB, SMMU, charging, audio and modem work on hardware
> 
> I used the downstream codename "alor" for compatibles and file names.
> What do you use?

Please use the name "molokai"

Konrad

> Do you want to post the SoC base (clock, pinctrl, interconnect, dtsi)
> and I rebase on it? I would first diff my TLMM/PDC against yours. Or I
> post TLMM/PDC since it is tested on hardware, your call.
> 
> Separately: I carry a hack disabling icc-rpmh QoS programming, because
> with it the display dies at boot. Do you have a tree with your
> interconnect driver that I can test?
> 
> Venkat