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
<steev>
travmurav[m]: thanks :) the pmos boot worked a treat :D - i suppose i COULD fix up the boot entry to point to kali not debian, but meh
<steev>
bamse: how do you workaround the a640_gmu spam on the flex 5g?
<steev>
but hey, 6.11-rc1 on the flex 5g, no external patches is pretty nice
<steev>
jenneron[m]: the a680 firmware doesn't cause graphics glitches for you?
<Nios34[m]>
Although that didn't work, but that does look cool
<steev>
it does have a cyberpunk aesthetic, alas, the text is unreadable
<steev>
i can deal with the software rendering, but i swear that this was working previously (and i'm guessing it works in pmos)
<steev>
doesn't work with a630_gmu, nor a660_gmu
<steev>
nor a650
<steev>
the xiaomi pad 5 firmware a640_gmu.bin does the same thing
louist103 has quit [Remote host closed the connection]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
indy has joined #aarch64-laptops
<travmurav[m]>
steev: cool, nice
<steveej[m]>
will the kernel choose /lib/firmware/qca/hpnv21g.b8c over /lib/firmware/qca/hpnv21.bin if both are available? or should i just overwrite the latter with the former?
<steveej[m]>
ah, jhovold actually answered this yesterday for me already:
<steveej[m]>
> rename it as whatever name the current linux driver loads (e.g. hpnv21.bin, or similar)
<jhovold>
steveej[m]: you need to replace hpnv21.bin for now
<jhovold>
right
<steveej[m]>
thanks!
<steveej[m]>
i'm trying it right now, can't notice any difference yet so i probably made a mistake
<steveej[m]>
(yes, i had a typo in the fw install pkg)
<steveej[m]>
this going to be so great so i don't have to carry around my laptop whenever i do house chores 😆
<jhovold>
:)
<steveej[m]>
feels like an invisible leash
<steveej[m]>
btw., can i get the kernel to reload the firmware post-boot or do i need reboot?
<jhovold>
i think the bt fw is loaded on every power on of the bt controller so that should be doable
<jhovold>
but better to just reboot
<jhovold>
steev: yes, it is the g variant we want, but both of those windows files give similar results last time I checked
<jhovold>
steveej[m]: that checksum matches the hpnv21g.b8c I'm using
<jhovold>
i don't think you can use the fw from windows, I'm not
<jhovold>
I see now that there has been two fw updates since I last tested bluetooth so it's possible that something has changes that prevents us from using the windows boardfile from an earlier build now
<jhovold>
the frame error is nothing to worry about, and the driver does download the fw twice on boot/start
<jhovold>
so nothing unexpected in that log
<jhovold>
if you revert the fw to the version from this spring you should have the same fw and bdf that I tested with
<jhovold>
steveej[m]: i just verifed that using the windows bdf works with the latest arch linux-firmware, range is much better (but possibly not quite as good as during my tests during spring)
<jhovold>
so that would be the second latest 639 build
<steveej[m]>
jhovold: i'm on the 2.1.0-00629 one now and still can't get better reception. is this potentially a HW issue? i compared this x13s with another one inside, and the other one had much more wiring from the wifi card, in addition to the wiring for the 5g module that the other one has and this one doesn't
<jhovold>
steveej[m]: seems unlikely, and I don't have a modem either
<jhovold>
I get about 2 meters of range with the bdf from linux-firmware, and 16-18 m (and around corners) with the windows bdf
<jhovold>
so quite a difference
<steveej[m]>
i can't even duck down to grab something 😆 the headset goes silent and reconnects
<steveej[m]>
i'm using the laptop on wifi with bluetooth listening to music and chatting here
<jhovold>
those errors seem to come from the jack microphone (swr2), which doesn't seem to make much sense if you're using bt
<jhovold>
have you seen that with 6.10 as well?
<jhovold>
may be worth giving 6.10 a try for both issues (they may be unrelated)
<jhovold>
and you could try disabling wifi to see if it makes any difference too
<steveej[m]>
i've got the microphone disabled in the UEFI setup. i would actually prefer to disable the entire internal soundcard. i just enabled it to see if the errors disappear
<steveej[m]>
i'll enable the mic to see if that helps
<steveej[m]>
jhovold: which permutations of fw/board/setup would be interesting for you to know? i'll at least try disabling the mic again as i'd prefer that.
srinik has joined #aarch64-laptops
Caterpillar has joined #aarch64-laptops
<steveej[m]>
disabling the mic brings back the errors. bluetooth is still great on the 2023-01 FW
<jhovold>
ok, good to hear the soundwire issue is sorted
<jhovold>
an it was unrealted to the bt issue then?
<jhovold>
I'd suggest you try the latest bt fw again, at least the second latest worked fine here, but otherwise I guess you can use that 2023-01 one until qcom gets there act together and releases that missing board file
<jhovold>
their*
srinik has quit [Ping timeout: 480 seconds]
<HdkR>
Looks like Oryon-1 still has the issue that WFE has spurious wakeup after 0-2 cycles. What a shame
<travmurav[m]>
ugh is wfe even allowed to be used in el0?
<HdkR>
Of course
<HdkR>
I think technically you can even use wfi
<travmurav[m]>
ugh so you somehow can make use of it for waiting on shared resources I guess?
<HdkR>
I use it for busy-loop based futexes, since exclusive-monitor clear counts as an event that wfe wakes up on
<travmurav[m]>
oh
<travmurav[m]>
yeah I see that makes sense I guess
<travmurav[m]>
tbh I somehow didn't think wfe has much use beyond having some spintables in early boot xD but I guess it makes sense to cut on loop waiting
<travmurav[m]>
(though still iirc architecturally wfe is allowed to be nop even)
<HdkR>
Yea, it's like one additional instruction in my busy-loop, so it's easy
<HdkR>
So even if it is a nop implementation, I'm fine with it being one-instruction cost more in that case :D
<travmurav[m]>
heh
<HdkR>
Ideally it saves a bit of power when contended though
<travmurav[m]>
yeah though I think my impression was that compared to wfi, wfe doesn't do much, perhaps still better than hitting cache all the time
<HdkR>
Yea, if it can get notified through the exclusive monitor interface rather than hammering a cacheline with atomic-load, it's a win
<travmurav[m]>
and ugh "still" is that cortex cores do the same?
<HdkR>
yea
<travmurav[m]>
fun
<HdkR>
Also Apple Silicon
<travmurav[m]>
does it reliably exit or still waits most of the time?
<travmurav[m]>
as in, maybe it's just something else creating events too frequently for it to work
<HdkR>
I've never gotten more than 2 cycles waiting on an otherwise idle system
<travmurav[m]>
right, sounds sad, would be interesting to see if it dies in bare metal maybe xD
<HdkR>
A bit harder for me to test that as I'm a userspace programmer :)
<HdkR>
Also Oryon-1 doesn't seem to support wfet, so I can't test that one
<travmurav[m]>
well I think on 7c when running single cpu fully bare wfe doesn't exit
<travmurav[m]>
just hacked sltest to add wfe to the green line drawing loop, the loop never advanced past wfe
<travmurav[m]>
or wait hm
<travmurav[m]>
it does exit wfe but veeery slowly, perhaps taking ~second in wfe, this kind of timeframe
<HdkR>
That would be significantly more reasonable timeframes
<travmurav[m]>
actually I think it draws two pixels so one hangs for ~second, other is fast but I'd not be surprized if it's something dumb like tz being scheduled and doing things inside, which ends up waking up the el2 too
<travmurav[m]>
if you want to try but you'd need tcblaunch.exe from the windows install and efi shell
<HdkR>
Could be wfe getting trapped by EL2/EL3 once Linux is booted I guess?
<travmurav[m]>
(run as wfetest.efi tcblaunch.exe in efi shell, then should see green pixels appear)
<travmurav[m]>
quite possible
<travmurav[m]>
especially by el2, but won't explain apple silicon which has no el3 and presumably no proprietary el2
<Jasper[m]>
What's wfe?
<travmurav[m]>
"wait for event" instruction
<Jasper[m]>
Ah, what is it for?
<travmurav[m]>
to halt the cpu until "something" happens
<HdkR>
It could be since I'm using Parallels instead of Asahi Linux that wfe isn't quite working correctly on that platform for me
<HdkR>
But that also doesn't explain why Orin also doesn't work :D
<travmurav[m]>
so i.e. if you have a busy loop that reads value and loops and repeats until it has been set, you can add wfe and then cpu "should" wait in wfe until whoever writes that value executes "sev" iirc
<HdkR>
or in my case, ldaxr+wfe and wait for exclusive monitor clear. Since the number of events that wfe wakes up on is...a lot
<HdkR>
Ideally ARM would introduce a new variant of wfe/wfet that takes an event mask, or only waits on exclusive monitor, but that's asking too much. I can eat spurious wake-ups if it is more than zero cycles :D
<jannau>
HdkR: wfe works on bare-metal apple silicon at least in EL2
<HdkR>
jannau: Fancy. I'll need to retest with asahi and see if the situation improves there
<HdkR>
When I tested like five different platforms and they all sucked I gave up hope to try harder on that one
<HdkR>
Just tested it under Asahi and I do get wfe sleeping with spurious wake-ups in the 2048 cycle range
<HdkR>
So that's nice
<HdkR>
85333 nanoseconds, so 0.085ms which is reasonable. Not quite as long as x86 monitor instructions, but considering the potential for spurious wake-up, it is quite a bit better than 0
<HdkR>
Didn't test if that behaviour carries through to krun since I don't have it setup
<jenneron[m]>
steev: nah, audio got broken again after that patch
<jenneron[m]>
don't remember which version, but the fix is to just copy-paste old soundwire driver to new tree
<HdkR>
I'm a derp! I had a typo!
kettenis has joined #aarch64-laptops
<kettenis>
HdkR: Linux sets up a ~10kHz timer event stream
<kettenis>
and your 0.085ms seems to be close enough to 0.1ms for that to be your wakeup
<HdkR>
Sounds reasonable from the numbers I'm getting elsewhere now
flokli has quit [Quit: WeeChat 4.3.5]
flokli has joined #aarch64-laptops
jhovold has quit [Quit: WeeChat 4.3.2]
louist103 has joined #aarch64-laptops
<JensGlathe[m]>
ooh interesting
<JensGlathe[m]>
those dtb loading mechanisms are a b*tch
<JensGlathe[m]>
no offense
<JensGlathe[m]>
manual image generation is for those with too much time on their hands
<JensGlathe[m]>
in chroot in the image, flash-kernel ofc does nothing (for whatever reason)
<JensGlathe[m]>
and I have to set up the dtb link I want manually
<JensGlathe[m]>
d'oh
<JensGlathe[m]>
and for multiple machine types I would need to do this anyway, because not yet integrated dtbloader
<JensGlathe[m]>
...aaand 6.11rc1-x1e is booting from type-c
<steev>
jenneron[m]: yeah, i just can't remember which kernel to grab the soundwire driver from.
<steev>
i want to say 6.7
<JensGlathe[m]>
so it was user error as always. 6.11 boots from type-c with the right drivers in the initramfs/modules, and it doesn't need the adsp/cdsp firmwares for this. Also it is enough to have the gpu firmware on the rootfs for the first boots as it appears.
<nirik>
Jens Glathe: x1e ? perhaps you could document what drivers? ;) I'm still stuck with it booting and then hard resetting after it's almost done booting up in userspace. ;(
louist103 has quit [Remote host closed the connection]
<JensGlathe[m]>
well that was my intent. I have a bootable image for Ubuntu 24.04 (now booting with x1e kernel) on my sc8280xp hardware. That was step 1. Will be reworked now for sc8280xp and x1e modules as described by jhovold [here]https://github.com/jglathe/linux_ms_dev_kit/commit/46b2f3748ee335bd8284659ae1fcab19d4c84793 and disable some automations which worked well for single machine. Then boot entries for... Yoga 7X and Vivobook I guess
<JensGlathe[m]>
(which I don't have here), and then its experimental time for everyone who likes to try it.
<steev>
i can give his patchset a swirl tonight or something
f_ is now known as funderscore
Lucanis has quit [Ping timeout: 480 seconds]
Lucanis has joined #aarch64-laptops
funderscore is now known as f_
<JensGlathe[m]>
wht is the device name of wlan on the x1e laptops - still wlP6p1s0 ?
<JosDehaes[m]>
I've seen P4 and P5 on the yoga
rlittl01 has joined #aarch64-laptops
louist103 has joined #aarch64-laptops
schaeffer has joined #aarch64-laptops
<schaeffer>
hello hello - I was taking a look at https://github.com/jhovold/linux/wiki/X13s and saw the TPM doesn't have mainline support yet. from some cursory digging, is there something special about the X13s TPM or is it compatible with the current TPM TIS I2C driver?
<schaeffer>
I'm not a hardware expert, but it looks like the relevant pieces might be there for TPM support, minus any DT changes needed for the X13s
<Jasper[m]>
I think that the issue is that the TPM setup on the x13s is accessed through trustzone calls which isn't fully figured out yet
<schaeffer>
got it, so it is more involved than just clicking things together
<louist103>
What does "/dev/root can't open block dev" followed by "VFS Cannot open root device "PARTUUID=[long uuid]"" mean? I installed everything per the handbook like before but never saw that error in the previous times I did this. The only difference this time is that I used a kernel from linux upstream without any gentoo specific additions.
schaeffer has quit [Remote host closed the connection]
<jiegec>
Currently, the device tree is copied from Qualcomm CRD, but I am unsure about whether most of it will still apply to Surface Laptop 7. It just works.
<jiegec>
Surface Aggregator Module support is kindly ported by Luz for Surface Pro X, so I just ported these out of tree patches to Surface Laptop 7, and they worked well. The internal keyboard, battery and ac are working.