On 4/2/24 10:44 AM, Bartosz Golaszewski wrote:
On Sat, Mar 30, 2024 at 8:16 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
On Fri, 29 Mar 2024 20:57:52 +0100, Maximilian Luz <luzmaximilian@xxxxxxxxx> said:
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
sc8180x-primus' support upstream is quite flaky. The board boots 50% of time.
However it's true that with SHM bridge it gets to:
mount: mounting efivarfs on /sys/firmware/efi/efivars failed: Operation not supported
and stops 100% of the time. Without SHM bridge I cannot boot it either because
I suppose I need the patch you sent yesterday. I haven't had the time to
rebase it yet, it's quite intrusive to my series.
I can confirm that with that patch the board still boots but still 50% of the
time.
Bart
Hi!
I was under the impression that until v8, the series worked on sc8180x
but I'm seeing that even v7 has the same issue with SHM Bridge on
sc8180x-primus. Could you confirm? Because I'm not sure if I should
track the differences or the whole thing was broken for this platform
from the beginning.
Hi, sorry for the delay.
Unfortunately I haven't had the time to test anything since v3. I don't
remember all the details, but based on what I wrote back then, enabling
the SHM bridge option did not lead to this result.
I can try to test v7 (and others) on the weekend.
Best regards,
Max
