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>
craftyguy: i do here, sometimes it is a little slow to come back, but never gone forever
<craftyguy>
Like how slow?
<craftyguy>
It seems "forever" (until I hard reboot it), I've waited several minutes in the past for it to come back
<steev>
definitely not forever, sometimes i do have to close and re-open, i'd say maybe a minute
<craftyguy>
Hmmmm ok. what's the longest you've let it go to s2idle before resuming? like, > a few hours?
<steev>
yeah, on thursdays i tend to put it in my bag at ~5pm and then not get it out til 10 or 11pm
<_mike>
hi
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #aarch64-laptops
<craftyguy>
Weird, I can't get the fw update utility to flash the latest x13s fw, it just reboots when I hit "y" to start the update. I prepared a usb drive according to this, which has totally worked for me in the past: https://gitlab.com/TheOneWithTheBraid/x13s-firmware-update
<_mike>
so should bluetooth work in 6.13.0-rc6?
<_mike>
i'm recompiling mainline now with gcc to see what happens
hipboi has joined #aarch64-laptops
<_mike>
seems like the answer is no
<_mike>
has anyone played with the npu?
<_mike>
i've used the one on the rk3588 a bit ...
<craftyguy>
Bluetooth on what?
<_mike>
asus
<_mike>
vivobook s15
<_mike>
that's ok i've reverted back to maud's kernel and that works
rmsilva- has joined #aarch64-laptops
<icecream95>
_mike: Note that Qualcomm's NPU is quite different to the RK3588 one; the latter is more fixed function, compared to Hexagon which is a DSP with really wide vectors and a tensor coprocessor
<icecream95>
(And on the topic of hypervisors, has anyone managed to run QEMU on the Vivobook? I get a system hang even with `id_aa64mmfr0.ecv=1` on the kernel cmdline)
<_mike>
icecream95: yeah i'm using qemu to emulate x86 on arch
<_mike>
with a chroot
<_mike>
i'm going to try the windows arm 11 iso in a minute
<_mike>
i'll let you know how i go
<_mike>
can't do uefi
<_mike>
need to install firmware
<dgilmore>
Hrrm so I think my issue is because cutmem is not working correctly. The laptop is showing 64GiB ram when booted. My USB stick shows 32GiB
<dgilmore>
craftyguy: I had the same issue with the latest bios for the x13s
<icecream95>
_mike: Well obviously tcg is going to work, I mean booting in EL2 and using kvm
tobhe has joined #aarch64-laptops
<icecream95>
Hmm the NPU is just the cDSP, right? So there's already /dev/fastrpc-cdsp, I guess that can be used for loading programs
tobhe_ has quit [Ping timeout: 480 seconds]
<_mike>
icecream95: ooh maybe.. i dont know tbh
<robclark>
icecream95: yeah, I think it is cdsp.. although haven't looked at how to do anything interesting with it yet (but that would for sure be an interesting toy to enable)
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
hipboi has quit [Quit: hipboi]
<bamse>
icecream95: correct, there was 1-2 platforms that exposed the NPU directly, but then it was merged into CDSP
<craftyguy>
dgilmore: ohhh really? anyone else unable to flash the latest fw on the x13s?
<_mike>
anyone know how i can access the drm msm driver from within a chroot?
<robclark>
bind mount?
<_mike>
robclark: hah you read my mind
<_mike>
should that not just be /dev/dri/* tho?
<robclark>
depends a bit on what you are trying to accomplish and protect.. the easy thing is bind mount all of /dev /sys /proc into chroot.. if you want to lock things down you need to be more targeted
<_mike>
i just used arch-chroot into a debootstrap'd env
<_mike>
maybe i need a mesa package?
<robclark>
some libdrm and maybe other things will poke into other areas in /sys so if you aren't trying to sandbox just bind mounting all the special fs' into the chroot is easiest
<_mike>
oh ok
<_mike>
MESA: error: Failed to attach to x11 shm
<_mike>
thats where i'm stuck now
<robclark>
strace it and find what it is complaining about and then bind mount that into chroot?
<_mike>
robclark: within a qemu x86_64 emulated environment?
<robclark>
umm, that isn't a chroot.. I'd assume you'd need virtgpu (potentially drm native ctx, etc)
<_mike>
yeah it's qemu static
<robclark>
yeah, idk how that works or even if what you are trying to do can... but strace is a useful thing
<_mike>
robclark: i'm trying to run steam
<icecream95>
_mike: Mesa does work through other emulators (e.g. FEX), so qemu-user will probably work as well, as long as Mesa is compiled with the freedreno driver enabled
<_mike>
according to the mesa PKGBUILD it has freedreno
<_mike>
yay fex
<_mike>
ooops
<_mike>
wrong window
<icecream95>
Are you sure that you are looking at the right PKGBUILD? Arch Linux x86_64 doesn't have it.
<_mike>
icecream95: yeah the archlinuxarm one
<_mike>
icecream95: oh you mean mesa within the chroot!?
<icecream95>
qemu-user will use the one inside the chroot, though other emulators might use a host library
<_mike>
i see
<_mike>
thanks for the clarification
hipboi has joined #aarch64-laptops
<_mike>
great i made a PKGBUILD for mesa x86_64 with freedreno and it's about to build now
<icecream95>
Uh oh it seems qemu has a list of supported ioctls, so you'll have to patch it as well... if I run qemu with -d unimp I see "Unsupported ioctl: cmd=0xffffffffc0106442"
<hogliux>
The firmware file `qcom/vpu/vpu30_p4.mbn` is there on my system so I don't think it's an issue of a missing firmware file
hogliux has quit []
martiert has quit [Quit: WeeChat 4.4.4]
<Jasper[m]>
Ohhhh lenovo ideacentre mini x and thinkcentre neo 50q
<Jasper[m]>
very interesting
martiert has joined #aarch64-laptops
<macc24>
@hogliux: where did you get that firmware from?
<anthony25>
it's in linux-firmware
<dgilmore>
jhovold: I got to go home to Australia so it was nice and relaxing without touching a computer
<dgilmore>
I have a modem in mine also. I wonder if I should remove it as a test
<dgilmore>
now to figure out why cutmem is not working
hipboi has quit [Quit: hipboi]
<jhovold>
dgilmore: ah, you're from oz, whereabouts?
<jhovold>
I spent a year in Sydney once, only been back once since unfortunately
<dgilmore>
I claim the Gold Coast, but I lived in a few different places
<jhovold>
are you also seeing suspend issues (possible mhi hang) with your t14s?
<dgilmore>
the couple of times it has accidently suspended it has crashed
<dgilmore>
I have spent very little time in Sydney
<robclark>
hogliux, (if you see this), the vpu fw is signed, so dts would need to setup a firmware-path similar to gpu zap shader (ie. /lib/firmware/qcom/x1e80100/LENOVO/83ED/$something) and the fw file copied from windows
<jhovold>
my t14s (wo modem) has been suspending reliably until recently, but I did hit two resets on suspend yesterday
<anthony25>
hmm, so what is the difference with the same file already in linux-firmware?
SpieringsAE has quit [Quit: Leaving]
<robclark>
anthony25: the fw files under qcom/x1e80100/$vendor/$id are signed by OEM key. The stuff under qcom/vpu (for example) are just signed with a test key. They would work on CRD and possibly devkit, but not a "production" device
<anthony25>
ha, I see
<robclark>
(it's mostly related to protected content, ie. netfix type stuff)
kirill_ has joined #aarch64-laptops
kirill_ is now known as Guest5344
<Guest5344>
Hi folks, I'm here to ask does anyone is working on FDT for Magicbook Art 14 Snapdragon?
<Jasper[m]>
What brand is that? I haven't seen it pass by in this chat
<Guest5344>
Honor, sorry.
<Jasper[m]>
Ahhh, I haven't seen it
<Jasper[m]>
Do you happen to own one?
<Guest5344>
Yes, I do. I can't boot any Linux on it (but I haven't try hard frankly), but I had "fixed" OpenBSD.
<Guest5344>
Fedora 41 and Debian Sid goes to reboot after "selecting kernel", for example
<dgilmore>
Guest5344: I assume that's because without a fdt it is using ACPI which does not work. you can probably work on basing a fdt on a similiar laptop, having the specs/docs would help. someone may be able to help decode what the ACPI tables say
<dgilmore>
HdkR: but at $3000 its a steep ask
<maz>
not massively different from an Ampere box price wise, to be fair.
<HdkR>
dgilmore: Not too far off from an M4 Pro Mac Mini
<dgilmore>
maz: true, I use an ampere box as my daily machine and spent more than that
<Guest5344>
dgilmore, may you guess based on specs which laptop is similar to this one? Here not so many laptops
<Guest5344>
dgilmore or you mean try available FDT and discover which one works better?
<dgilmore>
Guest5344: well I would start with one closest and work on what changes are needed for known differences. but its not clear what actual CPU is in it. I would not be comfortable guessinga s to where to start
<robclark>
you might want to start by dumping acpi tables and uploading to https://github.com/aarch64-laptops/build .. and then find someone who is good at reading acpi tables ;-)
<robclark>
also, hw.ncpufound=12 ... would be one of the x1e variants (hamoa)
<craftyguy>
jhovold: ya my x13s has a modem, I haven't used it in months though
<steev>
craftyguy: ah, mine does not
<craftyguy>
maybe that's it, but I'm not sure how to "confirm" when display is nonfunctional (plugging in an external display doesn't work either, and almost always I'm on some wifi network that makes ssh to it difficult/impossible)
<steev>
i hate those wifi networks
<craftyguy>
yeah, 'client isolation' or something
<craftyguy>
steev: different topic: have you tried upgrading the fw on your x13s lately?
<steev>
i've had 1.63 on it since november
<steev>
but i do the upgrades from windows, not my own
<craftyguy>
did you try to do the upgrade w/o windows first?
<jhovold>
craftyguy: if you are hitting the mhi deadlock during resume you would not be able to ssh in
<steev>
i dropped the msdu print one because that one doesn't seem to actually affect things, however i do see the htc rtx message occasionally taking down the wifi itself, so haven't gotten rid of that print
<jhovold>
mani_s posted a fix today if you want to give it a try (have not had time to test it myself):
<kuruczgy>
SpieringsAE: Would this be an alternative to dtbloader? How does u-boot detect which devicetree to use?
<SpieringsAE>
kuruzgy: U-boot doesn't detect anything on its own, it still has to be configured, so I don't really see the advantage yet
<craftyguy>
jhovold: how were you able to collect kernel log info when it happened for you? connected over ethernet?
<SpieringsAE>
except that you can build the dtb into uboot
<jhovold>
the crd has a serial console, otherwise I would not have been able to track the hang down to the mhi recovery code
<craftyguy>
ahh ok. that's useful :P
<craftyguy>
I'm not sure if I'm hitting this issue or not, but I can try the patch and see if resuming is "better" somehow
<jhovold>
it doesn't hurt, I'll include it from next rc as well
<jhovold>
and if that is the issue, we should now be able to tell from the logs
<jhovold>
still need to figure out what is causing the modem to fail to resume since 6.13-rc1
<craftyguy>
just that single one-line patch?
<craftyguy>
(I see it's 1 of 2)
<steev>
assuming youre on linux and have a git repo of the kernel, you can apply the patchset with b4 like so `b4 am -t -l -o - 20250108-mhi_recovery_fix-v1-1-a0a00a17da46@linaro.org | git am`
<jhovold>
yes, just that single line should avoid the deadlock if you hit that path during shutdown or suspend
<craftyguy>
steev: ya, I just wanted to know if I should use the whole series or just that one patch, but if both are going to be included in jhovold's next RC then I guess I can just pick both 🤷
<craftyguy>
thanks for the refresher on using b4 though, I don't use that nearly enough :P
<steev>
:D
SpieringsAE has quit [Remote host closed the connection]
<agl>
steev: Do you forgot to push your patched kernel 6.12.8 to you web site at github?
<agl>
(for the x13s)
alpernebbi has joined #aarch64-laptops
<steev>
i have not, see above where i mention hitting the htc rx issue *a lot*
<steev>
i'm hitting it multiple times a day
pbsds is now known as Guest5350
<macc24>
@SpieringsAE: i've seen u-boot on arm64 load a dtb automatically like dtbloader
pbsds has joined #aarch64-laptops
Guest5344 has quit [Quit: Page closed]
Guest5350 has quit [Ping timeout: 480 seconds]
alfredo has quit [Remote host closed the connection]
<SpieringsAE>
added sd-card reader, my config is not enough to get it properly working, I'm hoping someone else with an asus vivobook can also take a look to see what I am missing
<SpieringsAE>
it does register a /dev/sda, but no partitions
<agl>
steev: OK, then I know.
pbsds is now known as Guest5353
pbsds has joined #aarch64-laptops
Guest5353 has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
SpieringsAE: same here on the dev kit (directly attached to the integrated sdhc controller @8804000) So I guess something is amiss
rmsilva has joined #aarch64-laptops
hogliux has joined #aarch64-laptops
srinik has quit [Ping timeout: 480 seconds]
<hogliux>
robclark: thank you for the clarification on iris firmware. Unfortunately, I see no fw file named vpu30_p4.mbn on my Windows partition and the iris module is specifically looking for that file :-(
<JensGlathe[m]>
I'm writing an image onto it for fun, and its not fast (35MB/s) but without errors
<JensGlathe[m]>
so... maybe incompatible for whatever reason?
<hogliux>
robclark: anthony25: Thank you! I know have working hardware accelerated h264 video decoding working. With ffplay it reduces top cpu usage from 26% to ~ 12%.
<anthony25>
yeah I'll base it on the last patch series that was sent, but cherry pick the x1e specific commits from this one
<anthony25>
thanks a lot!
<hogliux>
kurzugy: you should add those commits to your nix recipes. I'm still "manually" ;-) following your nix recipes when building my own ubuntu images. So thank you for your work!
<anthony25>
what is the limitation for the support of other codecs? (like vp9 or av1)?
<anthony25>
with av1 being in a separate fw file, I guess there would be a thing of supporting multiple firmwares for av1, but for vp9?
<SpieringsAE>
JensGlathe: very interesting, well, thats more functionality than I've gotten lol, I've tested with a sandisk V30 HC and sandisk V30 XC card
<SpieringsAE>
neither worked :(
* JensGlathe[m]
was surprised, too
<JensGlathe[m]>
v60 at least it is, it gets recognized as UHS-I
hogliux has quit [Quit: Leaving]
SpieringsAE has quit [Remote host closed the connection]
<JensGlathe[m]>
oh wow they're expensive now, UHS-II starts at 45€ like the PNY i bought for testing with the ThinkBook 16
<JensGlathe[m]>
I bought 3 of them when I aqcuired some Jetson Nanos, they were cheap compared to now
jglathe_volterra has joined #aarch64-laptops
<anthony25>
yaaaay, I see h264 supported \o/
<craftyguy>
steev: I see a bunch of those "HTC Rx: insufficient length" errors even on the older fw, I think it might have to do with 6.13, wifi has been dropping out for me a LOT more frequently since I've been using the 6.13 RCs...
<JensGlathe[m]>
hmm interesting
<JensGlathe[m]>
haven't seen an change with 6.13 rcs on x13s
<steev>
craftyguy: it has happened since ~6.8 but really kicked into gear in 6.12 and 6.13
<craftyguy>
it has been real bad for me recently. frequently have to reload ath11k to get wifi back
<craftyguy>
ya for sure, I've seen these messages for ages, but ^^
<steev>
yeah, johan has the theory that it's because we're using GIC ITS and not the internal implementation (~6.10 it went in)
<JensGlathe[m]>
we could deactivate this with a dt change
<JensGlathe[m]>
?
<steev>
would have to find the commit that enabled gic and revert it to test, yeah
<JensGlathe[m]>
I have "debugged" these htc rx errors into the interrupt handler, they are callbacks from the firmware with invalid skb data
<JensGlathe[m]>
craftyguy: interrupt controller, with its being the msi(-x) variant of pcie interrupts
<craftyguy>
fw gone mad, aka "nothing we can do about it but sit around and hope qcom fixes it" :/
<craftyguy>
JensGlathe[m]: thanks :)
<JensGlathe[m]>
I played with the idea of detecting and then actually re-booting the firmware in a context hook handler
<JensGlathe[m]>
from the code it looked that there is either a valid skb or garbage data, so if you get garbage once, it is a case of fw going mad -> kill it with fire
<steev>
hm
<steev>
i think i saw something on the ml the other day about ath12k and checking skb data is valid
<craftyguy>
hmmm maybe I'll revert that commit and see if things improve
<JensGlathe[m]>
Actually you could also just disable msi-map for pcie4, should have the same effect (needs to use the physical interrupt line then)
<JensGlathe[m]>
Do we have gic-its on x1e already?
<sally>
I have a generic question: We saw yesterdays new Snapdragon laptops from Asus, how is the Linux supportive from Qualcomm and other vendors?
<craftyguy>
JensGlathe[m]: I have no clue how to do that, reverting the commit is easier (at least for testing to see if it helps on my x13s)
<steev>
craftyguy: it would be deleting the line msi-map on pcie4
<craftyguy>
ya, uhh, looking at that patch you linked, which one is 'pcie4' ? :P
<craftyguy>
_domain 4_?
<steev>
line 1767 in sc8280xp.dtis
<steev>
dtsi*
<craftyguy>
ahh, 'domain 6'
<steev>
hm
<steev>
it should just be the line that starts with msi-map....
<craftyguy>
sure, I was just trying to find the right thing in the dts
<steev>
sorry, i just don't follow the domain 4/6 thing
<craftyguy>
in the patch you linked, a few lines above where the msi this was added, it mentions domains
<craftyguy>
anywys, I think I got it, building kernel now with only that one line reverted under the pcie4 thing in the dts
<steev>
ahhh, that's not related :)
<craftyguy>
haha no, not related, except useful for finding context
<JensGlathe[m]>
<sally> "I have a generic question: We..." <- Qualcomm: quite good. Newer chips (x1p-42-100) not yet, x1-26-100 no idea. Other vendors: like the laptop vendors? No active resistance .. tacit cooperation, I'd say.
anthony25 has quit [Quit: Quit]
anthony25 has joined #aarch64-laptops
<sally>
JensGlathe[m]: Thank you.
<steev>
agl: pushed the latest 6.12, there's some experimental stuff in there (bore scheduler), as well, attempting the bits we mentioned above to move pcie4 back to the internal interrupts instead of using gic; I've not seen the issue since doing so whereas I normally would by now, but we shall see.
<kuruczgy>
hogliux: sure, can you create an issue with links to the commits + dts patches + path and sha256 hash of the firmware file? not sure when I will have time for it, just don't want the info to get lost to the chat history.
<kuruczgy>
(also fyi you are getting my nick wrong and not actually pinging me, you should just copy-paste it, it's probably pretty difficult to get it right by hand...)
icecream95 has joined #aarch64-laptops
<_mike>
icecream95: good morning
<_mike>
i checked and i have msm_dri.so in /usr/lib.. still doesn't work lol
<HdkR>
_mike: Why are you trying to get GPU acceleration inside of a qemu VM anyway, instead of using something like Box/FEX?
<_mike>
can someone package up a new asus x1e firmware? i can't yoink it as i dont have windows
<icecream95>
_mike: Are you compiling Mesa as a package or directly?
<_mike>
HdkR: FEX wont load the steam browser
<_mike>
icecream95: using makepkg
<HdkR>
_mike: It should do, it does here.
<_mike>
HdkR: orly? maybe i should try again.
<HdkR>
As long as you have FEX-2501 anyway, since Steam updated and broke things again in 2412.
<_mike>
HdkR: yeah i built and installed it yesterday after removing qemu and yeah, couldn't get it to the login/broiswer etc..
<icecream95>
_mike: Output from `strace glxgears` might help then
<icecream95>
HdkR: I got Steam working through FEX, but I still had to compile Mesa for the chroot to get it to use the GPU.
<HdkR>
icecream95: Rebuilding mesa on top of FEX's provided images, or something custom?
<icecream95>
HdkR: Building Mesa for the Arch image