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
<agl>
steev: Your 6.14.1 kernel works with all what I need. Also USB-Thethering with the RNDIS_HOST MOdule.
<steev>
good to know :) bamse ^ usb tethering works with flattened usb too
<agl>
steev: I'am have at this time only the x13s.
<steev>
it's still my daily driver
<agl>
I found the x13s very nice. I's needs about 10 hours until the Akku is down.
<agl>
I take it always into the "Löwenhof" a lokation for eating and tinking.
<agl>
trinking
<agl>
steev: Are you lucky about your ThinkPad T14s?
<steev>
i haven't really started using it just yet
<robclark>
steev: build kernel on x13s and then t14s and report back ;-)
<steev>
robclark: oh i have in wsl
<steev>
it takes like 7 minutes or something silly
<robclark>
ok, I assume wsl perf is good too but I haven't tried it
<steev>
it's quite good, i can actually build the kali arm images in wsl2 on w11 (at least the arm64 ones)
<robclark>
but my 7x is a nice step up when it comes to compile times from x13s
<robclark>
for full CrOS image builds, I still appreciate my threadripper but most of the time I only need to rebuild kernel and/or mesa.. for any dev I'd do on a laptop x1e is great
<robclark>
(and, well, I guess some ampere setup would be as good or better than the threadripper.. but I'm pretty happy with x1e for things that are reasonable to do on a laptop)
<bamse>
steev: nice, thanks for confirming
<steev>
that's v6 (i think), i haven't tested or pushed v7 since you say you rebased on usb-next
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
agl has joined #aarch64-laptops
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
phire_ has joined #aarch64-laptops
phire is now known as Guest13752
phire_ is now known as phire
Guest13752 has quit [Ping timeout: 480 seconds]
hexdump02 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<agl>
steev: Have you some infos about the KVM implementation for x13s?
<steev>
i do not, because we cannot access it without el2
<agl>
steev: Are some people working on that tha el2 works also on the x13s?
<agl>
tha=that
<steev>
there is an implementation but you lose access to the remote procs (so no battery)
<agl>
steev: does it work with power supply on th USBC-Port?
<steev>
i assume yes, you can still power the device, you just can't charge it
<agl>
Du you know where I can get the el2 implementation for x13s?
<agl>
I mean I have a lot to learn to set it up, or?
<agl>
Have you testet it?
<agl>
steev: ?
<steev>
i have not
<agl>
steev: Bevore some months someone say hier it needs 1 or 2 years until KVM would work for x13s. I don't know the nick of the.
<agl>
te=them
<steev>
i don't know either sorry, you could try checking the logs
<agl>
ok
<agl>
Do you know wher the KVM implementation ist. github.com or other web-sites?
<agl>
steev: ?
<travmurav[m]>
https://github.com/TravMurav/slbounce <- Either applying el2 dtbo for 8c3 or modifying dts is necessary; adsp will not boot loosing charging, audio and maybe some type-c related stuff like display output
<travmurav[m]>
Overlays can be applied using "fdtoverlay" tool from dtc package
hexdump01 has joined #aarch64-laptops
<agl>
travmurav[m]: Tank you .. i will look to it.
hexdump0815 has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
Kobold[m] has joined #aarch64-laptops
martiert_work has joined #aarch64-laptops
martiert_ has quit [Ping timeout: 480 seconds]
<Kobold[m]>
Hi everyone !
<maz>
agl: KVM does work on x13s. it has for a long time. you lose access to some devices, as explained.
sgerhold2 has quit []
sgerhold has joined #aarch64-laptops
<Kobold[m]>
Based on your experience, which distribution currently runs best on a x13s? Any recommendations?
ravikant_ has joined #aarch64-laptops
<JensGlathe[m]>
Running Ubuntu Concept X1E on it, works well
ravikant_ has quit [Ping timeout: 480 seconds]
<agl>
maz: I have read that the KVM implementation for the x13s does not handle the Battery. I need the x13s as a "Road Worrior" with Wireguard-VPN and that is very importand for me. When the implementation does not support these devices so it's not something vor me.
todi has quit [Remote host closed the connection]
<agl>
maz: It's not so necessary for me to have KVM.
<JensGlathe[m]>
Well but that's the fact. EL2 works, but you better have a constant PSU and don't need DP Altmode or sound
<JosDehaes[m]>
Jens Glathe: could you add the camera patches for the yoga 7x that hogliux posted above to your tree pretty please? 🙏 With your tree almost everything works (sound still distorted though)
<JosDehaes[m]>
(oh and also the EC patch is missing from the 6.15rc branch?)
<JensGlathe[m]>
EC should be there
<JosDehaes[m]>
maybe I had the wrong branch then? I had to add it manually, the option wasn't there in the menuconfig
<JensGlathe[m]>
oh ok. can you give me the config option? I'm using unchanged ubuntu X1e config
<JosDehaes[m]>
well not only the config is missing, also the actual code 😅
<JosDehaes[m]>
don't have the yoga with me right now, sorry
hogliux has joined #aarch64-laptops
<hogliux>
JosDehaes[m]: JensGlathe[m]: My camera patches do **not** work. It's actually using the completely wrong chipset. I don't think anyone has camera working on slim 7x yet, but anthony25 with Bryan's help is very close I think.
<JensGlathe[m]>
watching the situation and waiting for a go
<JensGlathe[m]>
we could also try to upstream the missing parts, but sb has to do it.
<JensGlathe[m]>
If no objections, I could do this for retimers / HBR3
<JensGlathe[m]>
but I don't have a slim7x to test
<JosDehaes[m]>
hogliux: Oh, ok
pabs has quit [Read error: No route to host]
pabs has joined #aarch64-laptops
srinik has joined #aarch64-laptops
hogliux has quit [Remote host closed the connection]
<anthony25>
JensGlathe[m]: I can test for you
<anthony25>
I'm already using your patch for the retimers (that also covers bluetooth)
hogliux has joined #aarch64-laptops
<bryanodonoghue>
hogliux alexVinarskis[m] have you pulled the clock fixes in my tree ?
<anthony25>
bryanodonoghue: you're talking about a fix you pushed after konradybcio and I did our testing, or was it already there?
<anthony25>
(just to know if you would like me to test anything on the slim 7x)
reng has quit [Ping timeout: 480 seconds]
reng has joined #aarch64-laptops
<anthony25>
Sorry I meant kuruczgy[m]
<alexVinarskis[m]>
[@_oftc_bryanodonoghue:matrix.org](https://matrix.to/#/@_oftc_bryanodonoghue:matrix.org) i dont think so, synced last week. Which branch? Will try rn
<anthony25>
I tell you in case it would mess up with your patch series
<anthony25>
I can try later without the video acceleration patch, if you want to be sure
<alexVinarskis[m]>
bryanodonoghuerebased on latest `origin/linaro/arm-laptop/wip/x1e80100-6.15-rc1-dell-inspiron14-camss-ov02c10-ov02e10-audio-iris`+ my patch to fix wrong supply names. still same errors https://bpa.st/WZJQ
<bryanodonoghue>
[ 81.454682] ------------[ cut here ]------------
<bryanodonoghue>
[ 81.454683] cam_cc_pll8 failed to enable!
<bryanodonoghue>
what's that ? not what i have on Insprion14
<bryanodonoghue>
meh
ravikant_ has joined #aarch64-laptops
<alexVinarskis[m]>
hmmm, just checked, had same cam_cc_ppl8 failed to enable! on 6.14 branch of yours. digged a bit yesterday, clocks that are failing for me are vfe_lite and cpas_vfe_lite, all others start just fine, including csiphy4_timer.
<bryanodonoghue>
makes me suspicious that cam_cc anything fails
<bryanodonoghue>
that clock controller is required to clock the CCI / i2c bus to the sensor
<alexVinarskis[m]>
FYI bryanodonoghue i found yesterday this awesome tool [1] to decompile various .bin. Converted all the files for Zenbook, uploaded it here [2]. I didn't manage to make anything useful out of it, most VREGs described don't even start on Zenbook. Random toggling of listed non-clock-related TLMMs also didn't do much. But perhaps its more useful to you.
<alexVinarskis[m]>
bryanodonoghue: i think i2c bus is working just fine, if i switch to different bus im getting i2c read errors. In current state there are none. Starting `qcam` also finds the sensor (at least the first few times), so it seems sensor got probed. Just no video running, and fps show 0.0fps.
<bryanodonoghue>
I'm getting confused here anthony25 has slim7x you have XPS ?
<alexVinarskis[m]>
I have both XPS and Zenbook. XPS works with your branch already. Logs & links above are for Zenbook with ov02c10, which seems to fail similarly to slim7x.
<alexVinarskis[m]>
when starting, qcam does see the sensor, and atttemps to stream something. inapproproiate ioctl errors for qcam seems to be normal, getting them on XPS too even when camera works.
<roy[m]>
<sgerhold> "On X1E you can try https://git...." <- really nice, thanks for mentioning it! It indeed makes battery indicator works on my t14s in EL2 (i didn't test dp)
<alexVinarskis[m]>
Bryan does ov02c10 need 1v2, 1v8, 2v8 supplies, or these may be somehow different from platform to platform?
<alexVinarskis[m]>
i experimentally found that on Asus Zenbook A14 without `l7b_2p8` and `l3m_1p8` sensor won't probe. Wondering which 3rd one I am missing, since `l2m_1p2` won't probe in my case.
<roy[m]>
hmm looks like one difference of that "lite" firwmware is that it will slowly discharge the battery when temperature is high, despite being connected to power :(
<sgerhold>
On T14s we've heard of that problem even with the full firmware though 😅
<roy[m]>
yeah, my workaround has been plugging it via a usb-c dongle, which magically works. But not on the "lite" fw
<sgerhold>
might be a different version
<sgerhold>
possibly even newer, if you updated BIOS but they didn't push new version to linux-firmware
<sgerhold>
On my X13s I have weird charging problems with some power supplies on Windows/UEFI nowadays
<bryanodonoghue>
alexVinarskis[m] did you pick up the changes for the clock ?
<sgerhold>
but in Linux, with the old version from linux-firmware, everything is fine 🤔
<konradybcio>
sgerhold: 10W C-C powerbank by chance? ;)
<roy[m]>
weird :( i did install the latest bios a couple of weeks ago, and windows keeps complaining about slow charge, no matter what i plug in
<sgerhold>
konradybcio: no, it's some fairly standard 65W supply (still random China quality of course)
<sgerhold>
the behavior on Windows is totally broken now, it selects 9V and then drives current so high that it exceeds the specifications on the power brick :/
<sgerhold>
while the old/Linux adsp firmware picks 15V and looks sane
<Jasper[m]>
Sounds like botched pps?
<Jasper[m]>
Also, @sgerhold does that el2 patch not work on sc8280xp or just the x13s specifically?
Stardust has quit [Read error: Connection reset by peer]
Stardust has joined #aarch64-laptops
<sgerhold>
Jasper[m]: I'm assuming sc8280xp, unlike X1E it doesn't have the "lite_pas_id" that I'm using in the patch
<alexVinarskis[m]>
bryanodonoghueyes, im on top of 575a8d5df0adbcc87a22b80fe1451eb1cf4e067b (origin/linaro/arm-laptop/wip/x1e80100-6.15-rc1-dell-inspiron14-camss-ov02c10-ov02e10-audio-iris) which does include e0b3fe6128020698a6588af1c46bc51d8d7faf0e
srinik has quit [Read error: Connection reset by peer]
<Kobold[m]>
Is there anything specific I need to care for when installing Linux on an x13s in terms of bootloader? Grub fails to install, systemd-bootd does not create the necessary EFI entries and efistub installs fine, creates EFI entry and then the systems fails to boot
<Kobold[m]>
Currently working with archinstall from ironrobin
clover[m] has joined #aarch64-laptops
<clover[m]>
Since everything was upstreamed i don't think you need the ironrobin repo anymore
<clover[m]>
You can probably just use the standard aarch64-linux package that alarm has
<Kobold[m]>
hmm intersting
<Kobold[m]>
aka just drop the aarch64 image onto a usb drive and install from there
<clover[m]>
Its weird that you are having bootloader issues
<Kobold[m]>
oh yes....
<clover[m]>
Well idk about the archiso. You might still need my version for that
<Kobold[m]>
but the system should be all updated
<Kobold[m]>
your version ?
<Kobold[m]>
Sorry, I just started this endevour today... no pun intended
<Kobold[m]>
Duuh, OK, I did not notice this beging your repo. Thank you!
jhugo4 is now known as jhugo
<anthony25>
what is your experience of EndeavourOS on ARM?
<anthony25>
they officially support several boards, but I didn't try because of the lack of a build for generic arm64 support
<anthony25>
is it better maintained than alarm?
hogliux has quit [Remote host closed the connection]
ravikant_ has quit []
chrisl has joined #aarch64-laptops
<clover[m]>
Its basically the same as alarm. I enjoy the more tight knit community of desktop Linux users it has thought.
pbrobinson_ has joined #aarch64-laptops
<clover[m]>
s/thought/though/
<Kobold[m]>
archinstall keeps failing when trying to install grub. Next stop, install bootd, chroot into archinstall folder and manually install grub over bootd
<clover[m]>
What does it say?
<Kobold[m]>
some file ít expects cant be found, I am already reinstalling, so my log is gone. sorry
<Kobold[m]>
Is there some merit in updateing the archinstall script to the latest version ? The version here is still 2.x, while it complains about 3.x availability
pbrobinson_ has quit [Ping timeout: 480 seconds]
<clover[m]>
Oh interesting. I'll have to take a look at that later
<Kobold[m]>
If you put up some documentation on how to update the iso, I could try myself
<Kobold[m]>
<Kobold[m]> "archinstall keeps failing when..." <- Grub starts, loads initramfs, then exists Boot process and laptop resets. Something still broken
<Kobold[m]>
OK, all of the luks cryptsetup stuff is missing in grub
<craftyguy>
has anyone tried running GTK4 apps under flatpak on Adreno GPUs lately? in pmOS, there's some weird failure that I can workaround with "MESA_VK_WSI_DEBUG=sw,nosyncobj" (flatpak GTK4 runtime seems to default to using vulkan)
<craftyguy>
seems specific to adreno/freedreno/turnip, I don't see this on e.g. AMD gpus
<robclark>
craftyguy: how ancient is the mesa in the flatpack.. recently the kernel exposed support for SYNCOBJ_TIMELINE, it was previously only disabled because of a userspace bug that was fixed >1yr ago
<craftyguy>
It seems to be using Mesa 25.0.3
<craftyguy>
I just noticed it also works if I "MESA_VK_WSI_DEBUG=sw". Another way to work around it is setting "GDK_VULKAN_DISABLE=dmabuf".
<craftyguy>
the "nosyncobj" might be a red herring, but I don't really understand what all these parts are :P
<robclark>
probably all of those things disable wayland use of syncobjs
<robclark>
either directly or indirectly
<craftyguy>
ok ya I was starting to suspect they all kinda did the same thing
<robclark>
does it happen outside of flatpack? Does it happen w/ x11 session?
<robclark>
f31 seems to have gtk4.. idk what apps are using gtk4 vs gtk3
<jannau>
which gtk4 version is in the flatpak?. the vulkan backend had a few bugs up to gtk-4.18 / gtk 4.16.13
<craftyguy>
I've not been able to reproduce it outside of flatpak. I tried GDK_BACKEND=x11 in flatpak to force x11 and it still fails. This used to work, it's a regression, and I'm still trying to narrow it down.
<jannau>
both released mid march
* craftyguy
checks gtk version
<craftyguy>
I _believe_ it's 4.18
alpernebbi has quit [Ping timeout: 480 seconds]
<robclark>
if you want to rule out something syncobj related, you can boot an older kernel... or comment out DRIVER_SYNCOBJ_TIMELINE in msm_drv.c
<robclark>
but I guess if it doesn't happen outside of flatpack then the question is what is different inside vs outside
<craftyguy>
yeah, I'm trying to figure that out, there are a lot of possible differences. Is there way I can get Mesa to tell me if it's missing something that might break this sync stuff? (like, to rule out flatpak not setting up stuff correctly for mesa/turnip)
<robclark>
vulkaninfo output should list supported extensions, which would change when kernel supports timeline syncobj
alpernebbi has joined #aarch64-laptops
<craftyguy>
debugging this stuff in flatpak kinda sucks... I'm curious if anyone using other distros that have adreno gpus can reproduce this when doing e.g. "flatpak install org.gnome.Calendar && flatpak run org.gnome.Calendar"
<robclark>
what does "weird failure" mean more specifically? Just hangs?
<craftyguy>
one sec
jhovold has quit [Ping timeout: 480 seconds]
<craftyguy>
here's the output with everything I could think of enabled for debug: https://bpa.st/raw/LDQA
<craftyguy>
thanks for the help so far btw. this issue is hurting a lot of folks using flatpak apps in pmOS on qcom phones/laptops :(
<robclark>
it does appear to be using timeline syncobj... although not really sure if that is related to the error or not
<robclark>
or what flatpak has to do with this
<craftyguy>
I'm kind of wondering if flatpak isn't setting something up correctly, that then causes mesa(?)/wayland(?)/gdk(?) to fail like that. The app running in flatpak appears to have permission/access to /dev/dri/*. I've been out of ideas for like 4 days now lol
<craftyguy>
that's why I'm curious if it can be repro'd on another distro, it might be an OS/flatpak config problem. I guess it's time to find some other distro I can boot from USB on my x13s
<robclark>
not sure if it is possible, but any way to see if same thing happens on other aarch64 device? I'm guessing flatpak uses something like seccomp for sandboxing... and the seccomp rules would be arch specific
<craftyguy>
I think all the aarch64 devices I have are qcom/adreno things :/
<robclark>
I can try on fedora a bit later.. in middle of other debug atm
<craftyguy>
np. is fedora super easy to flash to a usb/boot? I haven't installed/booted it in... decades lol
<robclark>
for x13s, I think it should be.. in theory.. I guess you somehow need to get a dtb somewhere where it can be loaded
<robclark>
I always end up installing before everything is upstream and supported in fedora so I end up having to do things the hard way ;-)
<craftyguy>
haha, yeah... I get it
<craftyguy>
I'll try following the fedora wiki (it mentions the bit about dtb, and other stuff)
<robclark>
iirc there is a live iso image/installer... you just need to copy dtb to windows ESP and then type things in at grub prompt
<robclark>
ok, maybe it is documented
<craftyguy>
I have another distro on my x13s's ssd that I don't want to replace/mess with, so I'm going to try the 'live` image on usb
<jannau>
org.gnome.Calendar from flathub works on asahilinux/fedora but that's kind of cheating since it doesn't use mesa from the flatpak but flatpak extension with the exact same mesa as the system one
<craftyguy>
yeah and also not an adreno gpu, right?
<jannau>
no, agx, apple's gpu
<craftyguy>
k. I'm pretty sure this only affects adreno things, at least that's all I/others have seen it on.
<robclark>
fedora has two sources for org.gnome.Calendar... fedora and flathub.. but both appear to work
<robclark>
(on x1e / f41)
<craftyguy>
oh, thank you. I've had no success booting fedora on this thing 😅
<craftyguy>
could I get the output from "flatpak info org.freedesktop.Platform.GL.default" on your x1e/fedora install?
<craftyguy>
thanks! so I guess it's either: 1) a difference in the compositor you're using vs others? or 2) some config for flatpak or ?? in the distro that's causing this to break for me but not for you
<craftyguy>
(and break in a very GPU-specific way... lol)
<robclark>
fwiw, gnome-shell is the compositor
<robclark>
looks like v47.5?
<craftyguy>
ahh ok, so it's probably not that then. some of our users have reported this problem on gnome 47 (and gnome 48, and COSMIC, and plasma/kde)
* craftyguy
wonders if fedora ships some flatpak config that might avoid/fix this issue
<robclark>
maybe some syscall is blocked that is used in the syncobj path but not the implicit sync path?
<Jasper[m]>
What's up with Fedora? Been running it on my x13s for a while
<craftyguy>
can you run gtk4 apps in flatpak?
<Jasper[m]>
Ah well I'm using KDE so I tend to avoid those
<Jasper[m]>
But if you have an example I'm willing to try
<craftyguy>
I've spent days debugging an issue on pmOS where gtk4 apps in flatpak all fail with some syncobj vulkan error on Adreno GPUs
<craftyguy>
"flatpak install org.gnome.Calendar && G_MESSAGES_DEBUG=all flatpak run org.gnome.Calendar"
<craftyguy>
I guess we should confirm that it's using vulkan, maybe fedora configures GDK to use ngl and not vulkan renderer...
<craftyguy>
(you should see "Vulkan:" messages in the output from that flatpak run cmd)
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
agl has joined #aarch64-laptops
<craftyguy>
Jasper[m] I was trying to get fedora on a usb to test it on my x13s ( I don't want to install to nvme). Following the fedora wiki, I can't get to a point where it lets me edit the grub config at boot to add the devicetree and kernel cmdline changes required. I tried putting them into "BOOT/loader/entries/<uuid thing>.conf", but boot fails because root on usb is unavailable or something (systemd can't start anything).. So I'm guessing...
<craftyguy>
... my changes to the bootloader config were ignored?
<craftyguy>
there's a grub.cfg but it's missing any config for booting the kernel. tbh I'm not quite sure what fedora is doing with both sd-boot and grub installed at the same time 😅
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
agl has joined #aarch64-laptops
agl has quit []
agl has joined #aarch64-laptops
agl has quit []
agl has joined #aarch64-laptops
agl has quit [Ping timeout: 480 seconds]
<craftyguy>
Ok got fedors booting, had to blacklist some module, the wiki page mentioned having to do it on older fedora versions but I guess it's still needed for 42
agl has joined #aarch64-laptops
<craftyguy>
*fedora
<Jasper[m]>
@craftyguy hi sorry was gone for a little bit
<Jasper[m]>
Yes the module blacklisting is standard for booting off usb because loading it resets the usb controller
<Jasper[m]>
Depending on the iso you download it may not show the grub prompt, but I might be wrong
<Jasper[m]>
It doesn't by default on already installed installs
<craftyguy>
ya we don't have to do that in pmOS, maybe because we load that module in the initramfs before the rootfs on usb is mounted
<Jasper[m]>
Likely yes
agl has quit []
<craftyguy>
hmmmm I can't get gtk4 in flatpak on fedora to actually use vulkan, it uses gl even when I set GSK_RENDERER=vulkan. The plot thickens
<craftyguy>
robclark: I'm curious if you see any vulkan-related msgs when running that app (by setting G_MESSAGES_DEBUG=all)... because it seems like maybe this isn't a problem on fedora because it's not using the vulkan renderer (on fedora 42 on my x13s at least)
<robclark>
I can try that later.. x13s/a6xx is vk1.3 x1e/a7xx is vk1.4.. which might make a difference
<robclark>
if it works outside of flatpack, I guess it is probably something related to the sandboxing