ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
<\[m]>
that's a lot of compute 🙂
sally has quit [Remote host closed the connection]
<\[m]>
oh ok, didn't check the cpu propelry
<\[m]>
i guess for 250 euro myes 😄
minecrell has quit [Ping timeout: 480 seconds]
minecrell has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
ravikant_ has joined #aarch64-laptops
ravikant_ has quit []
chrisl has joined #aarch64-laptops
icecream95 has joined #aarch64-laptops
<icecream95>
maz: I think you looked at pseudocode for the wrong variant... PACIA is UNDEF when PAuth is not implemented, but PACIA1716, PACIASP, and PACIAZ are NOPs
<icecream95>
I guess the only reason that plain PACIA isn't also in the hint space is because there wasn't enough space... so only the three special-case opcodes can be used without checking for the feature
chrisl has quit [Ping timeout: 480 seconds]
<icecream95>
gwolf: So the original code is fine; PACIA1716 was designed to be used without checking for whether PAC is available
<icecream95>
The assembler will check whether features are enabled, so it should be hard to screw up and use the wrong instruction unless -march/-mcpu flags are used
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
agl has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<icecream95>
Annoyingly the firmware for the vivobook fills memory on boot with zeroes or random numbers (which pass statistical tests, so not just DRAM losing state) which means I can't persist trace buffers over a reboot. At least I still have the EFI framebuffer to print to
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
<albsen[m]>
Jens Glathe: 6.13-6 is booting up successfully.
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
jglathe_angrybox has joined #aarch64-laptops
<jhovold>
JensGlathe[m]: the t14s ebs() failure mitigation hack still "helps", I wouldn't be able to use miy machine without it
<jhovold>
it just doesn't "fix" the underlying issue, it can only make you hit it less often
<jhovold>
but even that may depend on the build and fw version, use it if it helps, try removing it if ebs() fails almost every time
<JensGlathe[m]>
jhovold: We seem to have both cases, as you described. It is a bit boot entry dependent.
<jhovold>
we still depend on qualcomm and lenovo to fix their firmware
<JensGlathe[m]>
I had no issues regarding this for a few months now, but I have other devices, not T14s
<jhovold>
which other machines are you seeing this with? just the devkit?
<JensGlathe[m]>
I had it on the HP Omnibook X14, got mitigated with newer versions of grob from the ubuntu-concept-x1e PPA
<JensGlathe[m]>
With DevKit I've never seen this issue
<JensGlathe[m]>
likewise with ThinkBook 16
<jhovold>
and what where the symptoms the omibook? to be sure it is the same issue
alfredo has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
On the Omnibook it was KB not working in grub, sometimes stalling in EBS
<jhovold>
stalling as in temporarily, or hanging?
<jhovold>
sounds slightly different, even if I did see the keyboard not responding in grub anymore *after* a failed EBS()
lucanis has joined #aarch64-laptops
<JensGlathe[m]>
hanging. So no long pause, but system not doing anything until I get bored
<jhovold>
with sd-boot the keyboard still works...
<JensGlathe[m]>
yeah I switched to sd-boot out of desperation, only to find that with Ubuntu 24.10 installed grub suddenly worked
<jhovold>
ok, thanks, sounds related enough
<jhovold>
and you didn't do any fw updates that may have fixed the keyboard issue for example?
<JensGlathe[m]>
HP released a firmware upgrade since then (F10), that issue hasn't shown up since
<jhovold>
ok, possibly a different issue after all then, at least if no one else is hitting this on the HP anymore
pabs has quit [Read error: No route to host]
pabs has joined #aarch64-laptops
SpieringsAE has joined #aarch64-laptops
<albsen[m]>
Jens Glathe: a different observation; am I supposed to be able to see battery status with 6.13? when I try to get it using cat on qcom-batterymgr-../status it says not available
<JensGlathe[m]>
yes usually it should. Firmwares loaded?
<albsen[m]>
how do I check?
<JensGlathe[m]>
sudo dmesg|grep "Loaded FW"
<albsen[m]>
no entry, looks like its not loaded
<JensGlathe[m]>
I have "dyndbg=file drivers/base/firmware_loader/main.c +p" in my kernel parameters
<jhovold>
then the firmware is not available when (first) trying to start the adsp (e.g. in your initramfs)
<jhovold>
may be related, not sure if it ends up retrying and that you can recover from that without side effects
<jhovold>
do you also have: "remoteproc remoteproc0: Booting fw image qcom/x1e80100/adsp.mbn, size 22235528"
<jhovold>
later on, I mean
<jhovold>
or similar, for the t14s, path will be different
<albsen[m]>
jhovold: I can see now, its expecting it not in /lib/firmware/qcom/LENOVO/21N1/ but in /lib/firmware/qcom/x1e80100/LENOVO/21N1/
<maz>
icecream95: dang! of course you're right. wrong page of the spec. /me hides...
<albsen[m]>
in the wiki it not mentioning "x1e80100"
<icecream95>
/unhide maz
alfredo has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<albsen[m]>
thx jhovold and Jens Glathe that worked, placed all the firmware files in /lib/firmware/qcom/x1e80100/LENOVO/21N1/ and ran sudo update-initramfs -u now I have a battery indicator
jglathe_angrybox has quit [Remote host closed the connection]
<JensGlathe[m]>
Hmm these multiple touchpad definitions in the dts seem to be sort of a lottery, or I'm holding it wrong
<JensGlathe[m]>
Found mine (@0x2c) but it doesn't come up every time with multiple def, but no issue if its only one
<JensGlathe[m]>
I used the definition from the T14s
chrisl has joined #aarch64-laptops
<bamse>
JensGlathe[m]: that is indeed the case, we speculatively probe both...and hopefully you find one of them would any problems
<bamse>
JensGlathe[m]: the correct solution would of course be to pass a DT to the OS that properly describe the hardware
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
For the Thinkbook 16 there are 4 variants in acpi
<JensGlathe[m]>
And they have these odd identifiers, can we see them in our non-acpi? Like syn0645
chrisl has joined #aarch64-laptops
<bamse>
ugh, and then the touchscreens are generally both/all listed in the ACPI with STA-methods to in runtime determine which one to active in the running device
<bamse>
touchpads...
chrisl has quit [Ping timeout: 480 seconds]
jhovold has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
mbuhl has quit [Remote host closed the connection]