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
rlittl01 has joined #aarch64-laptops
rlittl01 has quit [Read error: Network is unreachable]
rlittl01 has joined #aarch64-laptops
rlittl01 is now known as Guest2278
rlittl01 has joined #aarch64-laptops
Guest2278 has quit [Ping timeout: 480 seconds]
rlittl01 is now known as Guest2281
Guest2281 has quit [Read error: No route to host]
rlittl01 has joined #aarch64-laptops
rlittl01 has quit [Read error: Connection reset by peer]
rlittl01 has joined #aarch64-laptops
rlittl01 has quit [Read error: No route to host]
rlittl01 has joined #aarch64-laptops
rlittl01 is now known as Guest2283
Guest2283 has quit [Read error: Connection reset by peer]
rlittl01 has joined #aarch64-laptops
rlittl01 is now known as Guest2285
Guest2285 has quit [Read error: Connection reset by peer]
rlittl01 has joined #aarch64-laptops
rlittl01 has quit [Read error: Connection reset by peer]
rlittl01 has joined #aarch64-laptops
rlittl01 is now known as Guest2287
rlittl01 has joined #aarch64-laptops
Guest2287 has quit [Read error: Network is unreachable]
rlittl01 has quit [Read error: Connection reset by peer]
rlittl01 has joined #aarch64-laptops
rlittl01 has quit [Read error: Connection reset by peer]
rlittl01 has joined #aarch64-laptops
phire_ has joined #aarch64-laptops
phire is now known as Guest2293
phire_ is now known as phire
<robclark> travmurav[m]: random though.. if linux could learn to load fw from multiple locations, then a .exe thing that installs DtbLoader could also copy signed fw to a location in ESP that kernel could use as fallback location to look for fw? I guess that might avoid the need to disable bitlocker to copy fw from linux installer?
Guest2293 has quit [Ping timeout: 480 seconds]
rlittl01 has quit [Remote host closed the connection]
rlittl01 has joined #aarch64-laptops
rlittl01 has quit [Read error: Connection reset by peer]
rlittl01 has joined #aarch64-laptops
rlittl01 has quit [Read error: Connection reset by peer]
rlittl01 has joined #aarch64-laptops
<bamse> robclark: check fw_path[] in drivers/base/firmware_loader/main.c... i.e. it does support that already
<bamse> robclark: that said, it's still a matter of jumping through hoops, so i don't think it's better
<robclark> oh, ok, I knew of that but didn't realize it already supported multiple paths
<bamse> steev: hmm, i don't see any gmu spam on my flex 5g...perhaps i "need" to update my linux-firmware?
<bamse> robclark: hmm, how does the module_param work? would that be firmware_class.path=/abc on the commandline then?
<bamse> well, i guess my actual question is "what's the module name of that thing?"
<robclark> I think we'd just need to add some entries to fw_path, ie /boot/efi/firmware/
<bamse> yeah, but what i'm saying is that you can do that dynamically, using the module parameter
<bamse> and i thought you where not supposed to keep the esp mounted, as it's a fat file system...
<robclark> hmm, slight preference to not require kernel cmdline more than needed, since that would be per-distro thing
<robclark> most distros (AFAICT) keep ESP mounted at /boot/efi
<bamse> maybe it's just me failing to read the instructions of arch then...
<robclark> also, my vague ideas of using fwuipd to distribute dtb to DtbLoader involve fwupd downloading latest and greatest dtb and dumping them in the ESP
<bamse> that's true
Mathew has joined #aarch64-laptops
mcbridematt has quit [Read error: Connection reset by peer]
mcbridematt has joined #aarch64-laptops
Mathew has quit [Read error: Connection reset by peer]
<steev> bamse: it's a patchset that's in flight that is needed? somehow (and a640_gmu isn't in linux-firmware still :( )
<bamse> steev: ohh, i thought we got that settled, so it was only the signed firmware files we where lacking...
<steev> on 6.11-rc1 if i don't have https://patchwork.freedesktop.org/series/135645/ with a tiny fixup to set ubwc_config.macrotile_mode to 1 for a680 (a640? not on my flex atm), then i have corrupt graphics with the gpu (there's a v3 coming that should have that fixup)
<bamse> will that fix the total ubwc corruption when i launch wayland?
<steev> yes
<bamse> wonderful
<steev> i didn't even think to check xorg
<bamse> steev: so it's only the gmu? we have the sqe? or it's both of them?
<steev> seems like it uses a630_sqe but tries to load a640_gmu (and symlinking a630_gmu to a640 doesn't work, only that RE'd a680_gmu seems to work)
<robclark> newer gmu might sometimes work (with the caveat that it probably isn't a combo that qc tests and it might break assumptions in kernel drm/msm/adreno code about version of gmu it is talking to)
<steev> bamse: the patchset mentioned above and this fixup https://paste.debian.net/hidden/cdd830b2/ allow it to work
<steev> robclark: i tried a650, a660, a630 and none of them worked, sadly
<bamse> and if i just wait a little bit it will magically solve "itself"?
<steev> whenever cwabbot gets v3 in, it should
<steev> just not sure if that should count as a fix for 6.11 or not? the pre sc8280xp devices are all iffy with their firmware since lenovo never shoved em to l-f
<steev> or i suppose qualcomm :P
<steev> i dunno who is responsible for gmu firmware
<steev> [ 24.300825] msm_dpu ae01000.mdp: [drm:adreno_request_fw [msm]] loaded qcom/a640_gmu.bin from new location
<steev> so it definitely tries to load the a640 even though it's a680, and idk why (as long as it works *shrug*)
<robclark> it should probably not be -fixes uness it comes with the new uabi parts since new-mesa-on-old-kernel would have to make some assumptions
<bamse> steev: that's because a680 seems to be an a640 with more juice...
<steev> sadly, i don't know when it broke, because 6.7.0-rc7 was the last kernel i tested (sorry)
<robclark> yeah, it is 640 with more shader cores (SPs)
<steev> oddly enough, the sc8180x performance feels terrible with llvmpipe
<bamse> steev: but you don't need to go that far, you can just disable ubwc and have a good experience(?)
<steev> i wanted to do as little kernel hacking on it as possible :D
<steev> the easiest thing was yanking the gmu out
<steev> gmu symlink*
<bamse> i'm running pure upstream, just setting the FD_MESA_DEBUG=noubwc (or whatever it is) and it seems to work fine
<steev> oh!
<steev> i think maybe at some point i was doing that?
<bamse> there's still an issue that it doesn't always boot...which is caused by mmcx dropping to 1 momentarily during boot and screwing everything up...
<steev> but rather be annoyed with it and make obnoxious noises til someone smarter than me fixes it (which someone already had)
<bamse> but other than that, it seems to be in pretty decent shape
<steev> is that whhat that is?
<bamse> the power-rail for display etc
<steev> i'd noticed sometimes it doesnt' boot and i thought it was me messing around with the gpu firmware
<bamse> nah, unfortunatley it's not you
<steev> i'd taken to powering off instead of rebooting
<bamse> i can see it in kernelci quite clearly :/
<steev> oh
<bamse> but we should give that thing a bit more love, because when it boots it seems to be in quite decent state
<bamse> and when i let it idle in sway, it reports that i have 28 hours left on my battery... (so if nothing else, i should verify that ;))
<steev> battery isn't quite as good as c630, but better than the x13s yeah
<bamse> i've lost my c630 :(
<bamse> not bad
<steev> i still use mine daily
<bamse> but it should be here somewhere, or upstairs...
<steev> there's still the missing dp stuff? i think
<bamse> i believe lumag made some progress there
<bamse> he rejected my solution, and was working on a proper solution
hexdump0815 has joined #aarch64-laptops
<travmurav[m]> robclark: there is a sysfs prop for extra firmware dir, yes, so if we wanted to, we could indeed make some .ps1 extractor running in windows, though I also don't think there is much overlap with dtbloader so it could as well be separate helper :D
hexdump01 has quit [Ping timeout: 480 seconds]
<travmurav[m]> fwiw could as well do it "android way" by manually adding a "modem" partitoin with those blobs xD
<travmurav[m]> but that's more manual actions than reusing esp
<travmurav[m]> that is, to create a new partition
<travmurav[m]> so as a first step it'd indeed not be that hard to experiment with that by writing like echo /boot/firmware > /sys/module/firmware_class/parameters/path on boot as a distro side thing
<travmurav[m]> (though if your distro already uses that feature, there is only one override path sadly)
rlittl01 is now known as Guest2302
rlittl01 has joined #aarch64-laptops
rlittl01 is now known as Guest2303
Guest2302 has quit [Read error: Connection reset by peer]
rlittl01 has joined #aarch64-laptops
Guest2303 has quit [Read error: No route to host]
rlittl01 has quit [Read error: Connection reset by peer]
rlittl01 has joined #aarch64-laptops
rlittl01 has quit [Quit: -a- IRC for Android 2.1.60]
<Painkiller995[m]> Jens Glathe: I tried the image on a Vivobook and encountered the same issue. It boots but reboots before reaching the desktop.
<Painkiller995[m]> Jens Glathe: Here's a photo from before the reboot.
aradhya7 has joined #aarch64-laptops
martiert has quit [Quit: WeeChat 4.3.3]
martiert has joined #aarch64-laptops
alpernebbi has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
alpernebbi has joined #aarch64-laptops
martiert has quit [Quit: WeeChat 4.3.3]
<JensGlathe[m]> I have a suspicion. The A750(?) firmware in /usr/lib/firmware/updates/qcom also contains a zap file. I would disable this, and also remove from /etc/initramfs-tools/hooks/x1e-firmwares. Afterwards update-initramfs -u -k all.
<JensGlathe[m]> Easiest on the USB disk (a bit more cumbersome in the image)
martiert has joined #aarch64-laptops
<JensGlathe[m]> Image is compressing, Ubuntu_Desktop_24.04_x1e_6.11rc_nozap.img.xz
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
bryanodonoghue has quit []
lumag has quit [Quit: ZNC 1.8.1 - https://znc.in]
vkoul has quit [Quit: ZNC 1.8.1 - https://znc.in]
apalos has quit [Quit: ZNC 1.8.1 - https://znc.in]
shawnguo has quit [Quit: The Lounge - https://thelounge.chat]
sgerhold has quit [Quit: :/]
bryanodonoghue has joined #aarch64-laptops
lumag has joined #aarch64-laptops
apalos has joined #aarch64-laptops
vkoul has joined #aarch64-laptops
mani_s has joined #aarch64-laptops
sgerhold has joined #aarch64-laptops
iivanov_ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
aradhya7 has quit [Quit: Connection closed for inactivity]
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<Painkiller995[m]> Jens Glathe: It did not boot at all this time. I think something went wrong with the creation of the image. I got an error message when I did validation after flashing the image.
flokli has quit [Ping timeout: 480 seconds]
<robclark> JensGlathe[m]: a750 fw is wrong gpu.. and the zap fw is specific to the laptop (or at least OEM)
<JensGlathe[m]> the fw files are named gen70500_., took them from the working arch image
<JensGlathe[m]> Have no means to test it here, though
<JensGlathe[m]> but then it is right not to have the zap fw at first (if its the wrong one)
<robclark> gen70500 is the right one for sqe/gmu.. the name/path for the zap fw comes from dts (ie. "qcom/x1e80100/LENOVO/83ED/qcdxkmsuc8380.mbn" for yoga 7x) and the file needs to be copied from windows partition at this point
<robclark> travmurav[m]: fw partition is a bad idea.. the goal is to make things look "normal" to distro installer.. and yeah, it is an orthogonal function to DtbLoader but it is part of the same goal, ie. to prepare a laptop so distro can be installed without further hacks
<travmurav[m]> well I'm definitely not opposed to us figuring out an automatic way to dump the firmware
<travmurav[m]> and yeah fw partition was just a random thought from the sysfs thing for firmware dir, since we use that sysfs to use the fw partition on pmOS
<travmurav[m]> I guess also would be interesting to check what's the usual size for esp and firmware blobs
<FarchordSteveCossette[m]> <travmurav[m]> "well I'm definitely not opposed..." <- I'd have to see... I might be able to make a .NET app that rips the appropriate files... Or I guess someone could simply make a batch, is the qualcomm swiss knife app thing available for win326
<FarchordSteveCossette[m]> ?
<robclark> fwiw, fedora esp is ~630MB.. not sure about other distros.. all of /lib/firmware/qcom (xz compressed files) is 66MB
<travmurav[m]> well if you're extracting from windows, I guess you want it to fit to the pre-partitioned esp? xD
<travmurav[m]> seems like on my aspire1 the original esp was 260M but I guess if firmware compresses <100 then it's fine
<robclark> hmm, so I guess the question is what _was_ the ESP size before I nuke'd windows
<kettenis> my vivobook came with a 260MB ESP
<JensGlathe[m]> Painkiller995: I went and burned the -nozap image to disk, booted (on X13s ) and it behaved normally. I can re-upload it to exclude some error with the version on Google Drive.
flokli has joined #aarch64-laptops
<JensGlathe[m]> which udev rule needs to be disabled?
<JensGlathe[m]> I thing the zap file in initramfs might be of no effect, so let's see what udev rule that is. Unfortunately (?) I can't test, it boots regardless on SC8280XP
<robclark> yeah, I think zap in initramfs or not is not the issue
<Painkiller995[m]> Jens Glathe: I left my laptop at the office, so I'll text you back tomorrow. By the way, I used Balena Etcher on Windows to flash both images since I didn't have access to a Linux device. I'll try using my daily driver laptop and test it using dd. There might be an issue because I got a notification that there was a problem during flashing the second image.
louist103[m] has joined #aarch64-laptops
flokli has quit [Ping timeout: 480 seconds]
flokli has joined #aarch64-laptops
f_ is now known as F_
F_ is now known as FunDerScore
FunDerScore is now known as funderscore
funderscore is now known as f_
<louist103[m]> steev: any idea which modules I am likely missing? Or should a stock upstream kernel not be used? Or 3rd option, is there a c630 defconfig anywhere for 6.11?
<JensGlathe[m]> Painkiller995: rufus is also pretty okay. If in doubt incompress the image first.
<steev> louist103[m]: i haven't tried c630 6.11-rc1/2, i can't say which modules you might be missing
<louist103[m]> Ok. I'll also try using genkernel with the latest gentoo supports with your patches on top. It may be a dracut issue. Not sure
<louist103[m]> Though I did just use your config but maybe something got missed between 6.10 and 6.11RC1
<steev> i hope to try 6.11 rcs on it soon
<steev> but this week is blackhat/defcon so no promises about getting to it
<louist103[m]> Thats fine don't feel pressured to.
<louist103[m]> I just hate trying a bunch of different things cause chrooting is annoying lol
<steev> if you're chrooting in from x86_64, make sure you set QEMU_CPU=cortex-a72
<steev> otherwise it's slow as shit
<louist103[m]> I didn't even know that was an option. Though thats not the annoying part. I hate having to setup SSH, and mount all those directories manually each time. I have never been able to clone the arm image onto a drive and have that drive be readable on an x86 machine.
<steev> you can clone it to a file, and mount the partitions that way, nerdboy (not here, but he's in #gentoo-arm over on libera, but i keep trying to convince him to show up here) might have some script to do that
<louist103[m]> Oh thats nice. I compressed the linux image but that would have been nice when trying to mount the Windows image. I didn't know mounting a disk image was possible.
<steev> i do something like (for just / and /boot ) https://www.irccloud.com/pastebin/ETP3AQ9d/
<steev> and then i can just mount $rootp /mnt ; mount $bootp /mnt/boot; and then i don't chroot, but i use systemd-nspawn because we're a systemd distro here, alas. and i just systemd-nspawn -E QEMU_CPU=cortex-a72 -D /mnt
<steev> the magic really comes from the losetup --show -fP
<steev> which gives you the offsets to use
<JensGlathe[m]> Painkiller995: new v3 image in test, disabled udev rule, lets see if we get somewhere
<agl> steev: Hello, I was for some days not online.
<JensGlathe[m]> Hmm. I disabled all rules (but not the infrastructure) of /usr/lib/udev/rules.d/80-drivers.rules, and it still boots. So... I guess this will be v3 of this image then. The rules inside are all odd technology storage devices that we don't have, so maybe a compromise to get further on x1e laptops
<agl> steev: All the days I wasn't on the x13s, it was running. Today when I was back on it, the IRC client stopped working properly and wifi shut down when I turned it on. It's been about 6 days that the x13s has been running. I had to reboot to get everything working again. Not a good sign. So if Linux on the x13s just stopped working properly after 6 days and the x13s only had the IRC client and an internet browser on and no work was done with the
<agl> machine, I think that's a little short to call it stable.
<agl> steev: I now have the 6.10.2 kernel from you on the x13s and I will now see how long everything works. I'll keep starting and stopping the Internet browser and using the IRC client and whatever else comes up. Let's see how stable the x13s runs.
<agl> Translated with DeepL.com (free version)
<steev> You’d need to look at the logs to find out what was going wrong
<robclark> battery stopped charging?
<agl> ok i will look
<agl> robclark: No it's full.
<steev> More likely it’s the thing where the Wi-Fi device errors out. I’ve definitely left mine up for >6 days before
<steev> But, I’m just a user like you are, I’m not sure why you keep pinging me
<JensGlathe[m]> Painkiller995 Jos Dehaes : Ubuntu_Desktop_24.04_x1e_6.11rc_v3.img.xz on google drive, should be up in 10 mins
<agl> steev: Well, you build your kernel and I thought you cared!?
<agl> And also all the others.
<steev> i do build my kernel, but there isn't much i can do aside from say yes i see that too
<agl> OK, then if the x13s stops working properly after x days, I'll post that here in general.
<steev> what do you mean by "stops working properly" though. and i'm also not sure what you mean by wifi shut down when i turned it on. but still, the logs will have the info anyone would need to begin to look into whatever you ran into
<agl> steev: When I wrote in the IRC client, it took 0.5 to 0.75 seconds for the characters to appear. I wrote and then the characters were delayed. In principle, the IRC client worked, but somehow it was disconcerting. When I pressed Switch on WLAN in the tray, the on/off button disappeared and it was indicated that there was no corresponding hardware.
<agl> when I reboot the x13s all works.
<louist103[m]> Update... I built the gentoo-6.10.3 kernel and I was able to boot into a shell. Networking (with the help of networkmanager) and USB at the very least seem to work
<steev> yeah, that sounds like the wifi module dropped, you definitely should check the logs
<steev> louist103[m]: you need the userland bits, but 6.10 doesn't have the EC module for the c630
<steev> there should be tftpqserv, rmtfs, qrtr and pd-mapper (not sure their equivalent names in gentoo)