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
<kibiz0r[m]> Turns out I didn’t have pd-mapper running on my x13s for days on end. Is it bad for the battery if you let it go completely dead multiple times?
<steev> probably not great for it, but shouldn't be bad? depends
<steev> what kernel are you running that you need pd-mapper userland? in kernel has been a thing for a long time
<bamse> kibiz0r[m]: what distro are you running?
tobhe_ has joined #aarch64-laptops
AldairsilvaSilva[m] has joined #aarch64-laptops
<kibiz0r[m]> NixOS, stitched together from multiple Github repos. upower -d shows qcom-battmgr-bat, but state is unknown.
<kibiz0r[m]> Using jhovold’s defconfig on 6.14
tobhe has quit [Ping timeout: 480 seconds]
<kibiz0r[m]> I guess I probably don’t need it in userland, cuz /proc/config.gz shows qcom_pd_mapper configured as a module
<kibiz0r[m]> But why else would my battery status show up as 0% in all hyprland status bars, and in upower -d?
<freekurt[m]> Firmware?
<freekurt[m]> The same happens with [@noisycoil:matrix.org](https://matrix.to/#/@noisycoil:matrix.org)'s Tails OS on the x13s.
<freekurt[m]> The 0% battery thing, that is.
<kibiz0r[m]> UEFI firmware? N3HET91W (1.63)
<dgilmore> There is patches for "msdu_done bit in attention is not set" in 6.15-rc1 right?
<dgilmore> # dmesg |grep "msdu_done bit in attention is not set"|wc -l
<dgilmore> root@tomin:~# w
<dgilmore> 152
<dgilmore> 21:53:46 up 1:18, 4 users, load average: 1.11, 1.09, 1.13
<steev> dgilmore: no
<steev> i have a hack that just removes the print, but i'm not submitting that upstream
<kibiz0r[m]> It occurs to me that maybe that cenunix bundle wasn't the best idea.
<steev> no idea what that is :)
<dgilmore> steev: ahh okay
<steev> oh, the repo for the firmware - the firmware aside from venus is in the mainline linux-firmware repository
hexdump02 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<freekurt[m]> Link?
<kibiz0r[m]> Yeah, before I went off on this userland pd-mapper adventure I was only using linux-firmware, which gave the same result from upower -d (qcom-battmgr-bat shows up, but state is unknown and percent is always 0%)
<steev> what version of upower?
<steev> admittedly, i'm on 6.12.20 (debian based kernel), and i definitely see the info here in upower -d
<steev> i'm on 1.90.8
<kibiz0r[m]> 1.90.6
<kibiz0r[m]> I'm not sure if there's a lower-level way to inspect this -- presumably the hyprland status bars I've tried haven't been using upower under the hood to determine the battery %, and they also show 0% consistently
<kibiz0r[m]> Armbian did show the battery % though. I guess I could try Gnome and see if it finds it any better. Could be a long ways to go, just to check, cuz I had trouble with keyboard input the last time I tried Gnome (but that was very early in this whole thing).
hexdump01 has joined #aarch64-laptops
jglathe_angrybox has quit [Remote host closed the connection]
hexdump0815 has quit [Ping timeout: 480 seconds]
<steev> alas, i don't do nixos, but i know there are people here who do
svarbanov__ has quit [Remote host closed the connection]
svarbanov__ has joined #aarch64-laptops
svarbanov__ has quit [Remote host closed the connection]
svarbanov__ has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
Son_Goku has quit [Read error: Connection reset by peer]
eric_engestrom has quit [Read error: Connection reset by peer]
Son_Goku has joined #aarch64-laptops
eric_engestrom has joined #aarch64-laptops
rfs613 has quit [Ping timeout: 480 seconds]
rfs613 has joined #aarch64-laptops
ungeskriptet has quit [Remote host closed the connection]
ravikant_ has joined #aarch64-laptops
ravikant_ has quit [Ping timeout: 480 seconds]
ravikant_ has joined #aarch64-laptops
steveej[m] has joined #aarch64-laptops
<steveej[m]> kibiz0r: i'm on the x13s and use nixos with it. waybar displays the battery % correctly with the standard battery applet. i haven't had to take care of that specifically, so i don't know where it gets the info.
patrickm has left #aarch64-laptops [Textual IRC Client: www.textualapp.com]
<Jasper[m]> @kibiz0r what kernel tree do you use? Is the firmware compressed?
roy has joined #aarch64-laptops
<roy> I saw the discussion about 64g t14s potentially able to use all 64g ram in EL2 - it indeed seems to work. I used kuruczgy's config to enable el2 and then was able to fill a 32g file in tmpfs without any crashes
<roy> what is not working in el2? other than the battery driver
<JensGlathe[m]> sound, I guess
<JensGlathe[m]> perhaps DP altmode switching
jglathe_angrybox has joined #aarch64-laptops
srinik has joined #aarch64-laptops
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
agl has joined #aarch64-laptops
<anthony25> kibiz0r[m]: I'm pretty sure it's because of https://github.com/Alexays/Waybar/pull/3942
<anthony25> you can adapt it for hyprland status bar
agl has quit []
agl has joined #aarch64-laptops
<travmurav[m]> roy: nice, thanks for testing this
<roy> no problem. I was really surprise how well this 'hack' was packaged up, it took very little effort to get working
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
agl has joined #aarch64-laptops
<maz> roy: that would tend to confirm my long standing suspicion that the >32G issue is due to the SMMU driver in Gunyah...
<roy> interesting. Then qualcom maybe eventually will fix this? OTOH I'd rather have linux working in EL2
<maz> probably not. these machines are supposed to run Windows, which replaces the firmware EL2 code with HV, so the incentive for anyone to touch this is exactly zero.
<HdkR> Tuxedo computers doesn't want working 64GB configs? :D
* travmurav[m] has intrusive evil thoughts of how funny would it be if they rip out "windows bloat" like mssecapp.mbn from the firmware
roy has quit [Remote host closed the connection]
<Stardust> So anyway, regarding aarch64 laptops, do they run Linux well enough with powersaving features, all important hardware and such?
<maz> you have to make your own mind. what's important to you may not be important to someone else.
<Stardust> There is a password-locked aarch64 snapdragon laptop. Do you think it's possible to recover UEFI password at all?
<Stardust> Even on x86 laptops the password is often written in a separate I2C chip and you need a programmer and software to unlock it
ravikant_ has quit [Ping timeout: 480 seconds]
tobhe_ is now known as tobhe
ravikant_ has joined #aarch64-laptops
<kibiz0r[m]> anthony25: Thanks for the lead. I'm running 0.12.0, so I've already got that change and it still shows 0%, but reading that code a bit it looks like it depends on `/sys/class/power_supply/qcom-battmgr-bat/power_now`, and if I try to cat that I get "Resource temporarily unavailable"
<anthony25> hmm, that is weird
<kibiz0r[m]> steveej: Do you have a repo with your nix config somewhere so I can compare?
ungeskriptet has joined #aarch64-laptops
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #aarch64-laptops
<kibiz0r[m]> Noticed this in journalctl: wireplumber[1285]: default: Failed to get percentage from UPower: org.freedesktop.DBus.Error.NameHasNoOwner
<kibiz0r[m]> ...which brought me to realize the upower daemon wasn't running. And if I start it, I see this output in journalctl:... (full message at <https://matrix.org/oftc/media/v1/media/download/AYKmAt67BO1izk6VKADpVK6NSzD467aPnzzcsWuqn2QddFfxOv0avUCTOC6MBarUsdjd6SPvqCaGUxvuJLhIHgRCeWZ9jNQQAG1hdHJpeC5vcmcvZ3Jmck9lU09xUmpxUEJ2WlFodEN6QW5D>)
<kibiz0r[m]> Ah, I also see this... Does this mean I need to do something to enable the remote processor?... (full message at <https://matrix.org/oftc/media/v1/media/download/ARtYTahKeLKYpWeVZ3Qnrq0LOEb5nF-kyvJhbrPWc5CebtJcTk8fTBdmm6rshNyAhbhsJG9hjbPOr7PbMUz8qs9CeWZ-ZBKgAG1hdHJpeC5vcmcvVkdEWWpDVElxRktjbG9uR2JMdGtxTnF4>)
minecrell7 has joined #aarch64-laptops
abcdw_ has joined #aarch64-laptops
shoragan_ has joined #aarch64-laptops
misyl_ has joined #aarch64-laptops
ypwn_ has joined #aarch64-laptops
kuruczgy_ has joined #aarch64-laptops
tobhe_ has joined #aarch64-laptops
krzk_ has joined #aarch64-laptops
tobhe has quit [reticulum.oftc.net helix.oftc.net]
pbrobinson has quit [reticulum.oftc.net helix.oftc.net]
ypwn__ has quit [reticulum.oftc.net helix.oftc.net]
Caterpillar has quit [reticulum.oftc.net helix.oftc.net]
hexa- has quit [reticulum.oftc.net helix.oftc.net]
shoragan has quit [reticulum.oftc.net helix.oftc.net]
jannau has quit [reticulum.oftc.net helix.oftc.net]
kuruczgy has quit [reticulum.oftc.net helix.oftc.net]
ektor52 has quit [reticulum.oftc.net helix.oftc.net]
minecrell has quit [reticulum.oftc.net helix.oftc.net]
abcdw has quit [reticulum.oftc.net helix.oftc.net]
brand[m] has quit [reticulum.oftc.net helix.oftc.net]
hellfire7734club[m] has quit [reticulum.oftc.net helix.oftc.net]
june[m] has quit [reticulum.oftc.net helix.oftc.net]
agraf has quit [reticulum.oftc.net helix.oftc.net]
hfg477[m] has quit [reticulum.oftc.net helix.oftc.net]
exeat has quit [reticulum.oftc.net helix.oftc.net]
krzk has quit [reticulum.oftc.net helix.oftc.net]
apple-corps[m] has quit [reticulum.oftc.net helix.oftc.net]
JosDehaes[m] has quit [reticulum.oftc.net helix.oftc.net]
Dantheman825[m] has quit [reticulum.oftc.net helix.oftc.net]
sadness88267[m] has quit [reticulum.oftc.net helix.oftc.net]
LiangQi[m] has quit [reticulum.oftc.net helix.oftc.net]
albsen[m] has quit [reticulum.oftc.net helix.oftc.net]
kuruczgy[m] has quit [reticulum.oftc.net helix.oftc.net]
farchord has quit [reticulum.oftc.net helix.oftc.net]
sobek[m] has quit [reticulum.oftc.net helix.oftc.net]
dcavalca has quit [reticulum.oftc.net helix.oftc.net]
fossdd[m] has quit [reticulum.oftc.net helix.oftc.net]
konradybcio has quit [reticulum.oftc.net helix.oftc.net]
misyl has quit [reticulum.oftc.net helix.oftc.net]
abcdw_ is now known as abcdw
jannau has joined #aarch64-laptops
agraf has joined #aarch64-laptops
ektor5 has joined #aarch64-laptops
<kibiz0r[m]> Jasper: Kernel tree as in the kernel source code, or as in the device tree? I'm using jhovold's wip/sc8280xp-6.14 branch and sc8280xp-lenovo-thinkpad-x13s.dtb
<kibiz0r[m]> And the firmware is compressed
pbrobinson has joined #aarch64-laptops
hexa- has joined #aarch64-laptops
june[m] has joined #aarch64-laptops
hellfire7734club[m] has joined #aarch64-laptops
hfg477[m] has joined #aarch64-laptops
<Jasper[m]> <kibiz0r[m]> "And the firmware is compressed" <- Do check if the kernel config has the right compression methods enabled
LiangQi[m] has joined #aarch64-laptops
fossdd[m] has joined #aarch64-laptops
<kibiz0r[m]> CONFIG_FW_LOADER_COMPRESS_ZSTD=y
<kibiz0r[m]> And this does exist: /run/current-system/firmware/qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn.zst
brand[m] has joined #aarch64-laptops
<steveej[m]> kibiz0r: if you want i can send you a link to my x13s config. it uses a fork of the nixos-x13s repo. i'm not sure _all_ the firmware config is still required, however my laptop works okay right now (except pipewire issues with firefox, which may or may not be a kernel issue)
apple-corps[m] has joined #aarch64-laptops
<kibiz0r[m]> Yes please, that would be great
<steveej[m]> feel free to DM me with detailed questions
<kibiz0r[m]> I just checked the IRC logs and saw that erebion 🏳️‍🌈♾ 3421@EPVPN ran into a similar issue a few days ago. Battery readings and remoteproc failing to load.
sobek[m] has joined #aarch64-laptops
kuruczgy[m] has joined #aarch64-laptops
Dantheman825[m] has joined #aarch64-laptops
albsen[m] has joined #aarch64-laptops
sadness88267[m] has joined #aarch64-laptops
konradybcio has joined #aarch64-laptops
farchord has joined #aarch64-laptops
dcavalca has joined #aarch64-laptops
JosDehaes[m] has joined #aarch64-laptops
<erebion3421EPVPN[m]> And I solved it by adding an initramfs hook for the firmware, for some reason that seems to have gone missing in Debian, it used to work a few kernels ago.
<Jasper[m]> @kibiz0r another thing you can check is if you're loading the kernel driver in initramfs and if you have the firmware included in there (it will make it increase in size significantly)
<Jasper[m]> Hah^
<kibiz0r[m]> Ah. Yeah, lots of sc8280xp firmware in there, but not the adsp/cdsp ones
<robclark> if you don't want to mess with adsp/cdsp in initrd, you can do something like this:
<kibiz0r[m]> Haha, okay. Wild that you can just echo start to it. That did make the battery show up though.
<Jasper[m]> Hard to debug if you need to reboot the entire time :p
ravikant_ has quit [Ping timeout: 480 seconds]
<robclark> kibiz0r[m]: yeah, you just need to kick it, the driver probes and tries to find fw when you are still in initrd, and has no way to know later when the fw becomes avail unless you echo start
<noisycoil[m]> Hey there. What's the required kernel module?
<travmurav[m]> If you saw a "for parts" x1e laptop that was thrown out of the window by the prior owner, what chance would you give it having still working motherboard inside?
<JensGlathe[m]> 0
<travmurav[m]> Completely unrelated, here is a 50MiB jpeg of ASUS vivobook s15 mainboard: https://nyx.trvn.ru/misc/asus-s15-front.jpg
<Jasper[m]> @noisycoil what platform?
<noisycoil[m]> x13s, following the discussion above
<Jasper[m]> To get battery configuration to work? Or things like display and keyboard when filling in an encryption password (for example)?
<noisycoil[m]> Is it qcom_q6v5_pas?
<JensGlathe[m]> yeah this loads the firmware
<noisycoil[m]> Nope, just the battery indicator (and possibly configuration, yes)
<JensGlathe[m]> travmurav: That SoC looks dead
<noisycoil[m]> Yeah, so I had to disable that during initramfs because it made booting from USB crash
<travmurav[m]> Jens Glathe: it is cracked, yes
<JensGlathe[m]> Ad thats normal, too
<JensGlathe[m]> s/Ad/And/
<noisycoil[m]> Any idea how to avoid qcom_q6v5_pas crashing boot from usb?
<Jasper[m]> Are you installing to nvme?
<JensGlathe[m]> on x13s: put all fws in the initramfs, disable the file on rootfs
<Jasper[m]> Or is this for an external ssd?
<noisycoil[m]> No, it's a live distro (Tails), so it just runs from USB
<JensGlathe[m]> qcadsp8280.mbn is the culprit
<noisycoil[m]> It should be possible to probe it after boot has completed though, right?
<Jasper[m]> Tails runs in RAM right?
<JensGlathe[m]> nope
<noisycoil[m]> Everything should be loaded into ram at that point and the issue may never arise again
<noisycoil[m]> Yes, it does
<JensGlathe[m]> you need to load the adsp firmware before rootfs is mounted via USB
<JensGlathe[m]> or you need a self-powered hub
<noisycoil[m]> After won't work?
<Jasper[m]> Then you might? The issue is that loading the firmware will reset the usb controller and the UUID for the root partition will differ from the one that is passed to the kernel
<noisycoil[m]> Ah the "nope" was answering this question I think
<JensGlathe[m]> the problem is apparently that loading adsp firmware disrupts VPUS on type-c for a short time, invalidating all type-c device handles.
<Jasper[m]> JensGlathe[m]: If the environment is in RAM this technically won't matter I think
<JensGlathe[m]> s/VPUS/VBUS/
<Jasper[m]> Only if there's any persistence involved, you may run into issues
<noisycoil[m]> Jasper[m]: Not if I make it so the driver is probed before one can possibly access persistence
<noisycoil[m]> Jasper[m]: Tails has a way to detect if the USB is being disconnected: it triggers an emergency shutdown if it does. Depending on how this check is implemented (I have no idea) this may be relevant. Other than that yeah, it may work
<Jasper[m]> Try it I guess
<noisycoil[m]> Yeah
<Jasper[m]> iirc it looks to Linux like it physically disconnects
<noisycoil[m]> freekurt will try it, I don't actually have an x13s, I'm doing this blindly (with the help of Kurt of course)
<Jasper[m]> impostor!
<freekurt[m]> lol
<noisycoil[m]> :-P
<Jasper[m]> Well, LARP'er would be a better term hahahah
<noisycoil[m]> Lol
<noisycoil[m]> By the way, if any of you is interested in porting Tails to other arm64 platforms there's a base here: https://gitlab.tails.boum.org/NoisyCoil/tails/-/tree/wip/arm64
<noisycoil[m]> Currently works on arm64 VMs, apple silicon, raspberry pis (only tested on 5) and x13s
<noisycoil[m]> Unfortunately, it requires a different image for each (except for VMs which boot everything except for the raspberry image) due to kernel/userspace needs which you are well accustomed to
<travmurav[m]> back of the pcb and both sides of the subboard, I hope this is useful to someone
AldairsilvaSilva[m] has left #aarch64-laptops [User left]
srinik has quit [Ping timeout: 480 seconds]
ednouu034[m] has joined #aarch64-laptops
<robclark> does this extend to the signed fw?
<anthony25> I'll see, from what I understand, yes
<anthony25> so I might be able to use the signed fw of the CRD
<konradybcio> not sure if that's what you want esp. given the fw may contain device specific things.. but maybe the designs are similar enough
<robclark> gpu fw won't be device specific, just gpu specific... I guess that would also be the case with iris/venus
<anthony25> exactly
<anthony25> that's why windows users were waiting for this bios so they could use the updated qualcomm video drivers
<robclark> that said, it is unlikely that the zap fw actually changed.. but maybe however the driver package is installed would overwrite the zap fw?
<robclark> do we know what other laptops can use qc's driver drops?
<anthony25> it says: UGD should just work in all the models except Lenovo Yoga Slim
<robclark> I guess someone with something other than the 7x could try using the crd zap fw?
<Jasper[m]> That's... devkit, tuxedo (maybe) and Medion (with no Device Tree)?
<robclark> there are a bunch more laptops that are not 7x than that
<Jasper[m]> Ah wait I read over the context and was stuck at the 7x firmware upgrade. mb
<robclark> nw
jhovold has quit [Ping timeout: 480 seconds]
<konradybcio> I would assume ZAP not to be a problem
<sgerhold> I doubt any retail devices will accept the test-signed firmware from the CRD
<Jasper[m]> @sgerhold Medions were reportedly unfused
<sgerhold> the medion firmware is OEM signed even though
<sgerhold> or ODM I guess
<Jasper[m]> Aha then I may have been misinformed, I think there was some murmur around the coreboot assembly about it at CCC
<sgerhold> I guess they can use OEM-signed firmware on an unused device as well :p
<sgerhold> You can try the T14s GPU/CDSP(/Video) linux-firmware on other laptops, that one has a better chance of working than the CRD one. ADSP probably won't work, and is kind of device-specific for the charging stuff etc anyway
kdavid has joined #aarch64-laptops
davidk has joined #aarch64-laptops
kdavid has quit [Quit: Page closed]
<anthony25> I'll just take whatever is shipped with the qcom drivers for windows
<anthony25> oh I didn't see that!
<tobhe_> yeah, very cool. Hope other OEMs take notice and follow :)
<anthony25> for the live usb on ubuntu, do you explicitely remove it from the iso?
<anthony25> because if I remember correctly, loading the firmware creates a disconnection of the USB devices
<noisycoil[m]> IIRC they don't
<noisycoil[m]> Because I copied most of the x13s enablement code from Ubuntu and booting from USB failed
<noisycoil[m]> However it may be that they changed it afterwards
<anthony25> I'll see if it helps with the GPU lockups I have
<robclark> zap fw is only run once each time the gpu is powered up to take it out of secure mode, I wouldn't expect it to be related to crashes
<anthony25> I confirm, I just got one right now :p
<anthony25> I have some free time, I'll try to see what triggers it
<robclark> thx
Kelsar has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
luca020400 has joined #aarch64-laptops
Kelsar has joined #aarch64-laptops
exeat has joined #aarch64-laptops
luca020400 has quit [Quit: WeeChat 4.5.0]
luca020400 has joined #aarch64-laptops
mbuhl has quit [Remote host closed the connection]
mbuhl has joined #aarch64-laptops
svarbanov_ has joined #aarch64-laptops
svarbanov__ has quit [Read error: Connection reset by peer]
jglathe_angrybox has quit [Remote host closed the connection]
jglathe_angrybox has joined #aarch64-laptops