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
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
arhue has joined #aarch64-laptops
<arhue>
Hello everyone,
<arhue>
I just got a Snapdragon X1 Elite based laptop - Lenovo Yoga Slim 7x and I'm running Ubuntu. Most things work fine, but I'm bugged about lack of support for KVM and lack of properly supported sleep
<arhue>
I'm wondering if the path forward for KVM/hypervisor support is Gunyah with QEMU or is it support for booting w/ EL2 w/ something like slbounce
<arhue>
Afaik lots of things don't work if you try to boot Linux w/ SL2 like ADSP/CDSP. Any idea if there is work going into fixing these?
tobhe_ has joined #aarch64-laptops
hexdump02 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
tobhe has quit [Ping timeout: 480 seconds]
<valpackett>
arhue: I think someone already found a way to run a "simple" aDSP (IIRC meaning keep using the FW loaded into it in the boot process) and it would already enable battery monitoring at least
<arhue>
Interesting
<valpackett>
Windows runs in EL2, so full functionality should be possible with a bit more research
<arhue>
Yes, I think running in EL2 is the best path forward. Hopefully it's not too far away
<arhue>
I wonder what the priority is to get KVM working. There are some vendors that have started shipping these in mini PC variants and I imagine KVM support would be high up in the list for buyers of these
<valpackett>
well, if buying these for server usage, you generally wouldn't even care much about the stuff provided by xDSP :D
Grabunhold_ has quit [Remote host closed the connection]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
Grabunhold has joined #aarch64-laptops
<konradybcio>
valpackett: these functions are rather auxilliary.. the DSPs provide quite some compute power
<konradybcio>
it's not something that is very commonly taken advantage of at the moment by software, but the silicon's there
<valpackett>
konradybcio: how much code signing enforcement is on them?
<valpackett>
i guess cDSP runs user NPU code but the rest?
<valpackett>
would definitely be nice to run NPU stuff on linux..
<konradybcio>
lumag: would know more, but I think you can run code on all DSPs through FastRPC
zdykstra has quit [Ping timeout: 480 seconds]
<anonymix007[m]>
Only on cdsp, actually
<valpackett>
mm, from what i can find, there are unprivileged unsigned applets but apparently the proper NPU stuff is only accessible through SDKs and not as bare instructions? https://news.ycombinator.com/item?id=37775025
<anonymix007[m]>
I tried a couple of demos on my T14s, but got nowhere trying to do something more than that. Some things are just broken, one notable example is adspmsgd logs
<valpackett>
huh, there is some sort of UAPI in mainline already i guess, I do see /dev/fastrpc-cdsp (and cdsp-secure and adsp)
<valpackett>
are there docs?
<anonymix007[m]>
valpackett: I believe NPU is actually CDSP and one can run custom code on it
<valpackett>
is it possible to run QNN on linux? the onnxruntime docs only say android and windows
<konradybcio>
I don't knwo
zdykstra has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
ravikant_ has quit [Ping timeout: 480 seconds]
ravikant_ has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<kcxt>
im having random freezes followed by a reboot on slim 7x with latest next (cc jhovold abelvesa ) any ideas?
<robclark>
kcxt: anything manage to get flushed to journal, ie. does `journalctl -b -1` give any hint?
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<kcxt>
robclark: nothing stands out...
<robclark>
hmm, ok
<robclark>
icecream95: this first commit from me here might be helpful for your firefox issue.. it at least fixes the root issue.. I still eventually can make it crash but no idea if that is in mesa or in ffox itself
jglathe_angrybox has quit [Remote host closed the connection]
<icecream95>
robclark: That should fix one of the issues involved, but not the problem of another context having its current batch flushed. I think in the Firefox case one of the threads uses a lot more batches than the other, so LRU (or more accurately least recently created) means that the current batch of the other thread will eventually be picked
<robclark>
hmm, maybe that is what is going on.. I didn't manage to figure out how to gdb firefox in a short amount of time so moved on
Erisa has quit [Read error: Connection reset by peer]
cyrinux94907 has quit [Ping timeout: 480 seconds]
zetam has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
agraf has quit [Ping timeout: 480 seconds]
agraf has joined #aarch64-laptops
ahf_ has joined #aarch64-laptops
ahf has quit [Read error: Connection reset by peer]
sudeepholla has quit [Ping timeout: 480 seconds]
sudeepholla has joined #aarch64-laptops
<icecream95>
I've also noticed some problems with the Valgrind annotations; for example, fd_bo_map_for_upload calls VG_BO_MAPPED even if the BO is already mapped
<robclark>
I've not used valgrind in ages.. tend to use asan since it isn't painfully slow
ahf_ has quit []
ahf has joined #aarch64-laptops
<HdkR>
It would be nice if I could use valgrind, but it falls apart if an application uses large virtual memory allocations.
zetam has quit [Quit: going out!]
ravikant_ has quit []
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
kalebris_ has joined #aarch64-laptops
kalebris has quit [Ping timeout: 480 seconds]
kalebris_ is now known as kalebris
chrisl has joined #aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
icecream95 has quit [Quit: rcirc on GNU Emacs 29.1]
<valpackett>
robclark: oh huh actually looking at journal like that (also did have a freeze last boot here) i see '[drm:dpu_crtc_frame_event_cb [msm]] *ERROR* crtc106 event 1 overflow' a few times in a row
<robclark>
next time it freezes, see if you can vt switch?
<robclark>
maybe it hasn't really frozen?
<valpackett>
i always try that
<valpackett>
but it's definitely really frozen since the watchdog reboots it in a minute or so
<valpackett>
i guess i should try alt-sysrq-R too
<valpackett>
before trying to vt switch
<robclark>
I think if watchdog resets it, then the crtc event overflow should probably be unrelated
<valpackett>
ahh maybe yeah
<valpackett>
the occasional freeze seemed veeery loosely correlated with bluetooth audio but then i got a freeze once without it so idk what even
matthias_bgg has quit [Ping timeout: 480 seconds]
ksco has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
matthias_bgg has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<ksco>
Hi, I'm sorry if this bothers you guys. I brought an x13s laptop for AArch64 Linux related development. So I tried to install Linux on this machine.
<ksco>
I followed the steps in https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s, I used `clk_ignore_unused pd_ignore_unused arm64.nopauth` parameters, and I tried other available images as well, but the behaviour was always the same:
<ksco>
After the GRUB selection and a few EFI and kernel logs, the screen flashed 3 times and goes into black.
<ksco>
While trying Armbian, I plugged an external monitor via USB-C, and I can get into the Desktop without hardware accelaration on this monitor while the builtin screen remains black.
<ksco>
I know little about these things, please forgive me if this is silly, but any way I can solve this? Thanks in advance.
<valpackett>
ksco: from what i've heard recently with someone else who was also looking at debian's instructions, those completely miss the dtb thing
<ksco>
valpackett: hi you mean copy the dtb to the internal fat32 drive right? yeah I did that.
<valpackett>
adding `devicetree (hd0,gpt1)/sc8280xp-lenovo-thinkpad-x13s.dtb` to the grub config i mean
<steev>
you don't need to do that if it exists on the efi partition as /sc8280xp-lenovo-thinkpad-x13s.dtb
<steev>
*and* linux option is enabled in bios
<valpackett>
ohh uh lenovo's "linux option" is like a built-in dtbloader?
<steev>
i wouldn't call it that good
<steev>
but it passes the dtb at least
<valpackett>
oh interesting! i see now that the debian instructions do mention it (but without explaining wtf it does)
<ksco>
btw mine machine has a non-touchscreen, not sure if that matters, probably not
<steev>
i followed the debian steps to do my install (most recently), and they definitely worked at that point in time
<steev>
nah that part doesn't (but lucky you!)
<steev>
i'd double check that you copied in the kernel that is installed's dtb
<steev>
armbian sounds like might just be missing firmare
<steev>
firmware*
<ksco>
so it's expected that the screen goes completely black without firmwares installed?
<steev>
it's expected if something is missing that it doesn't work properly
<valpackett>
someone else who messaged me on fedi who was also trying that combo (x13s+debian) ended up adding the devicetree line to grub, just told them about the lenovo option
<steev>
i'm guessing based on no logs
<valpackett>
sometimes(?) it's possible that your configuration doesn't want to use the efi framebuffer and passing console=tty0 etc. can help with early display output
<valpackett>
or earlycon even
<steev>
could pass video=efifb
<steev>
but without logs, really hard to guess what might be going wrong
<steev>
the vblank timeout is an issue but the issue will be further back in the logs - could you pastebin your dmesg output?
<steev>
most recently though, from what i've seen of people with issues on x13s, its that their dtb isn't matching their kernel
<ksco>
yeah I should really provide the logs, but external monitor only worked on Armbian for me and I have Ubuntu now... I need to switch the bootable USB
<steev>
understandable :) its frustrating i know
<steev>
i was thinking of going through the instructions again once i switch to my T14s, and update with any info that seems a bit tricky because you're not the first person to have an issue when following the debian wiki (plus some things have changed since then)
<ksco>
thanks for your work!
<steev>
oh no, i'm a kali dev not debian, but i'm willing to try to figure out what is tripping people up
akaWolf has quit []
<steev>
if you were to do a debian install again, IF you didn't encrypt the rootfs, you could also do the devicetree trick in grub and point to where the dtb is on the filesystem (e.g. devicetree /usr/lib/linux-image-6.12.25-arm64/qcom/sc8280xp-lenovo-thinkpad-x13s.dtb)
ellyq_ has quit []
ellyq has joined #aarch64-laptops
<ksco>
thanks, I'll try Armbian again before sleep
ksco has quit [Remote host closed the connection]
ema has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
melody has joined #aarch64-laptops
melody has quit []
melody has joined #aarch64-laptops
ksco has joined #aarch64-laptops
melody has quit [Remote host closed the connection]
<ksco>
(so here is the dmesg log on Armbian with an external monitor plugged: https://ksco.cool/etbS)
MelodyOwO has joined #aarch64-laptops
<steev>
[ 12.815097] panel-simple-dp-aux aux-aea0000.displayport-controller: Couldn't power on panel to ID it; using conservative timings: -110
<steev>
do you actually have an edid on there?
<ksco>
what is an edid :^)
<steev>
it tells us info about your screen (what it reports)
<steev>
every monitor has one (though some (most?) lie )
<ksco>
so there is something unexpected in my machine?
<steev>
well, it's not able to power it on for some reason
<steev>
that could be why it stays black
<steev>
errno 110 is timed out
<ksco>
strange, WoA does work without any issue
<steev>
windows is not linux
<ksco>
yeah
<steev>
that lets us know the hardware itself does work, which is good
<ksco>
this is empty: /sys/devices/platform/soc@0/ae00000.display-subsystem/ae01000.display-controller/drm/card0/card0-DP-1/edid
<steev>
any others?
<steev>
cardX or DP-X
<JensGlathe[m]>
try all available DPs, could be that DP-3 is eDP
<JensGlathe[m]>
card1-eDP-1
chrisl has quit [Ping timeout: 480 seconds]
<ksco>
there is only card0, DP-1 and eDP-1 is empty, here is the decoded content of DP-2: https://ksco.cool/naHm
<JensGlathe[m]>
ok 4k display
<ksco>
it's1920x1200 showed in windows
<ksco>
maybe this is the external display?
<JensGlathe[m]>
That's the EDID of an external monitor
<ksco>
yeah, this is the external display, I unplugged it and it becomes empty
<JensGlathe[m]>
So this is an x13s, and your internal screen stays black. 🤔 you said you have an Ubuntu install... tried my [6.15.0-jg-5](https://drive.google.com/drive/folders/1Lps5o3FXroAJFDiKj18vutJbC1uld49s) kernel package? It is Ubuntu X1e, tested on X13s internal screen and external display on usb0 (the one nearer to the touchpad)
<hogliux>
valpackett: kcxt: I've tried everything to get a log message on what's going on. The annoying thing is that it is super rare and random. I use my slim 7x fulltime, sometimes I go weeks without it happening and sometimes it happens 2-3x a day.
<hogliux>
valpackett: kcxt: So you can never be really sure that you've fixed it. It also doesn't seem to be affecting all the slim 7x users here. I'm starting to suspect that it may be a hardware issue only affecting some batches and only affecting linux.
<hogliux>
valpackett: kcxt: Did any of you exchange your SSD by any chance? That might be a common thing that people who have this issue have done.
<hogliux>
valpackett: kcxt: It does to seem to happen slightly more often when something audio related is running (either bluetooth or USB). But in rare occasions it also happens without audio running. Once or twice I had the same thing happening but audio
<hogliux>
valpackett: kcxt: continued to play even though the laptop was otherwise not responding. It continued to stream and play audio from the web until the laptop's watchdog timer reset the laptop. Nothing in the logs after the reboot though. So super super strange bug.
chrisl has quit [Ping timeout: 480 seconds]
hogliux has quit [Quit: Leaving]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<JosDehaes[m]>
I had a period where my 7x would random reboot. When I swapped the SSD back to windows and then back to linux, it went away. Maybe the SSD wasn't well seated? No idea, but it would sometimes hang, but more often just reboot out of the blue
kalebris_ has joined #aarch64-laptops
kalebris has quit [Ping timeout: 480 seconds]
kalebris_ is now known as kalebris
kuruczgy[m] has quit [Ping timeout: 480 seconds]
travmurav[m] has quit [Ping timeout: 480 seconds]
konradybcio has quit [Ping timeout: 480 seconds]
JosDehaes[m] has quit [Ping timeout: 480 seconds]
tobhe[m] has quit [Ping timeout: 480 seconds]
JensGlathe[m] has quit [Ping timeout: 480 seconds]
bumble[m] has quit [Ping timeout: 480 seconds]
ahoneybun[m] has quit [Ping timeout: 480 seconds]
amstan has quit [Ping timeout: 480 seconds]
nirik has quit [Ping timeout: 480 seconds]
noisycoil[m] has quit [Ping timeout: 480 seconds]
shadowarrior[m] has quit [Ping timeout: 480 seconds]
M9names[m] has quit [Ping timeout: 480 seconds]
Timmy[m] has quit [Ping timeout: 480 seconds]
freekurt[m] has quit [Ping timeout: 480 seconds]
n0nfl3x[m] has quit [Ping timeout: 480 seconds]
logan2611 has quit [Ping timeout: 480 seconds]
WeetHet[m] has quit [Ping timeout: 480 seconds]
apple-corps[m] has quit [Ping timeout: 480 seconds]
smoorgborg[m] has quit [Ping timeout: 480 seconds]
mehdidjait[m] has quit [Ping timeout: 480 seconds]
Jasper[m] has quit [Ping timeout: 480 seconds]
TangTang[m] has quit [Ping timeout: 480 seconds]
clover[m] has quit [Ping timeout: 480 seconds]
chapstikk[m] has quit [Ping timeout: 480 seconds]
anonymix007[m] has quit [Ping timeout: 480 seconds]
macc24 has quit [Ping timeout: 480 seconds]
GurneyBuchanan[m] has quit [Ping timeout: 480 seconds]
Tammieyem[m] has quit [Ping timeout: 480 seconds]
Eighth_Doctor has quit [Ping timeout: 480 seconds]
KieranBingham[m] has quit [Ping timeout: 480 seconds]
sadan[m] has quit [Ping timeout: 480 seconds]
alexVinarskis[m] has quit [Ping timeout: 480 seconds]