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 :-(