Re: [PATCH v9 00/13] firmware: qcom: qseecom: convert to using the TZ allocator
From: Maximilian Luz
Date: Fri Mar 29 2024 - 15:58:13 EST
On 3/29/24 8:46 PM, Bartosz Golaszewski wrote:
On Fri, 29 Mar 2024 at 20:39, Maximilian Luz <luzmaximilian@xxxxxxxxx> wrote:
On 3/29/24 8:26 PM, Bartosz Golaszewski wrote:
On Fri, 29 Mar 2024 at 20:22, Maximilian Luz <luzmaximilian@xxxxxxxxx> wrote:
On 3/29/24 8:07 PM, Bartosz Golaszewski wrote:
Both with and without SHM bridge?
With CONFIG_QCOM_TZMEM_MODE_GENERIC=y (and the upcoming fix) everything
works. With CONFIG_QCOM_TZMEM_MODE_SHMBRIDGE=y things unfortunately
still get stuck at boot (regardless of the fix). I think that's
happening even before anything efivar related should come up.
This is on X13s? I will get one in 3 weeks. Can you get the bootlog
somehow? Does the laptop have any serial console?
Surface Pro X (sc8180x), but it should be similar enough to the X13s in
that regard. At least from what people with access to the X13s told me,
the qseecom stuff seems to behave the same.
Unfortunately I don't have a direct serial console. Best I have is
USB-serial, but it's not even getting there. I'll have to try and see if
I can get some more info on the screen.
I have access to a sc8180x-primus board, does it make sense to test
with this one? If so, could you give me instructions on how to do it?
I guess it's worth a shot.
From what I can tell, there shouldn't be any patches in my tree that
would conflict with it. So I guess it should just be building it with
CONFIG_QCOM_TZMEM_MODE_SHMBRIDGE=y and booting.
I am currently testing it on top of a patched v6.8 tree though (but that
should just contain patches to get the Pro X running). You can find the
full tree at
https://github.com/linux-surface/kernel/tree/spx/v6.8
The last commit is the fix I mentioned, so you might want to revert
that, since the shmem issue triggers regardless of that and it prevents
your series from applying cleanly.
Best regards,
Max