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
<eac>
travmurav[m]: hwids are here: https://gist.github.com/eaceaser/abddaf199a686ad254edbf5d0900ca8b - Ed Ceaser <ceasere@gmail.com> is my contact. As far as the deferred devices are concerned, besides some multimedia codec stuff there is `6e80000.pinctrlqcom-sm8550-lpass-lpi-pinctrl: Failed to get clk 'core'` which seems suspicious... but i'm not
<eac>
sure if that would interfere with seeing any nvme devices
paddymahoney has quit [Ping timeout: 480 seconds]
<HdkR>
Turns out the Yoga only consumes 60w over USB-C when plugged in, but under full system load it pulls more than 60w. So watch out if you're doing high-load tasks for a long time while plugged in.
<HdkR>
Have a chance of draining the battery out
<steev>
dang, so power hungry
<HdkR>
Oh, it was actually respecting my cable reporting it only supported 60w. Let's see if it pulls more when I replace that one
<HdkR>
77w in grub
<HdkR>
80-ish watts whew
<Nios34[m]>
ah, it can pull so much power? My 7cx even charges under 5V2A
<HdkR>
Big soc is hungry
<HdkR>
Idles closer to 10-13w under Linux
<bamse>
then we have quite a bit of work to do...
<HdkR>
Sometimes it drops to 8w if you're lucky :P
<bamse>
that's about twice compared to sc8280xp iirc
<HdkR>
Ouch
<bamse>
well, let's see if we can land a functional baseline in time for v6.12...then we can polish it up ;)
<FarchordSteveCossette[m]>
bamse: That's by what, 6 months or so? Not bad
<bamse>
and on sc8280x when you idle, the two cpu-rails are turned off...
<bamse>
FarchordSteveCossette[m]: 4-5 weeks
<FarchordSteveCossette[m]>
bamse: Hah, okay
<bamse>
FarchordSteveCossette[m]: i mean, v6.12-rc1...
<HdkR>
From what I see, it looks like currently power isn't disabled on the clusters being unused on x1e. Purely from looking at the power usage
<HdkR>
They just throttle down to 900mhz or so
<bamse>
yeah, not a lot of bits set in the arm,psci-suspend-param properties...
<bamse>
haven't checked the psci documentation on this one though...
<HdkR>
Main thing I was testing here was to see if WFE with its 100us sleep capability would actually show a tangible power consumption reduction compared to an atomic spin-loop. Nothing I could notice with all 12 cores loaded at least
<bamse>
hehe, yeah that's not going to be affected by the idle parameters
<HdkR>
Seems like when the CPU core is entirely stuck within a cacheline that is in L1 that it doesn't consume a ton of power, since L2/SLC/DRAM would end up being the majority factor off-die there
<HdkR>
Only ~27w with all cores loaded spinning on a single cacheline
<HdkR>
So at least spinlocks aren't that much worse compared to a baseline :P
<HdkR>
Maybe I'll try creating a cpuburn test next to see what the load is when all the ALUs and memory are pegged
Lucanis has quit [Ping timeout: 480 seconds]
Lucanis has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
Caterpillar has quit [Quit: Konversation terminated!]
<travmurav[m]>
eac: Thanks, pushed. I think for pcie you could also look into dmesg to see if the bus is registered at all
<travmurav[m]>
that is, I'd assume if half of the stuff was missing, it'd complain from the other half deferring but perhaps there is i.e. no pice drivers enabled at all in the config
<steev>
assuming johan's stuff, pcie *should* be (assuming johan's with the thinkpad's dts patchset on top)
<gabertron>
btw for audio -- does anybody have a tplg file for the yoga slim?
<gabertron>
i do see that the alsa-ucm-conf package has: alsa-ucm-conf: /usr/share/alsa/ucm2/conf.d/x1e80100/X1E80100-CRD.conf
<eac>
pretty confident I have pcie enabled in my kernel at least. That being said the kernel config is my own attempt thru make menuconfig, building off of this branch: https://github.com/SoMainline/linux/tree/topic/t14s - so its very possible that I did something wrong. lspci is showing the host bridges but no devices attached. I just looked a bit
<gabertron>
eac: is the issue that you can't see /dev/nvme0n1pxx and can't find the rootfs? or what was the issue again?
<eac>
i don’t see any nvme devices in /dev. I’m booting into a rootfs off of a usb drive, and usb seems to be working fine in general, was trying to get a partition going on the ssd
<eac>
i saw a qualcomm blog post saying that they merged nvme over pcie support at some point so I’m assuming that this shokld
<gabertron>
ok will try to do a build here of that branch and see what happens
<eac>
*should be able to work
<gabertron>
yea it works I have a t14s and use nvme
<eac>
nice - if theres a branch you’re using lmk and I can try it tomorrow
<gabertron>
that's what i'm using for my defconfig -- bunch of random extra things turned on, but you can diff against yours to find the key differences
<gabertron>
-- not sure if I actually need the efi=novamap and arm64.nopauth
<eac>
kk i’ll report back after trying this. likely i’m doing something dumb. I’m booting the efistub from an efi shell and i compiled everything I selected into the kernel vs. modules to avoid having to update an initramfs while experimenting but maybe that’s causing problems?
<gabertron>
the initrd even when you compile everything =y , you still usually have some firmware in there -- but i would imagine nvme would come up even with no firmware
<steev>
it should, as long as the right modules/builtins are there
iivanov has joined #aarch64-laptops
sgerhold has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
<akaWolf>
steev: there is in 6.10.5 still a problem with reboot when I do poweroff
clee has quit [Read error: No route to host]
clee has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov has quit [Read error: Connection reset by peer]
iivanov has joined #aarch64-laptops
<kuruczgy[m]>
Does anyone where the Wi-Fi firmware files come from on the Yoga on Windows?
<kuruczgy[m]>
So far AFAICT the mapping is wlanfw20.mbn -> amss.bin, phy_ucode20.elf -> m3.bin, regdb.bin -> regdb.bin
<kuruczgy[m]>
But I cannot find board-2.bin, does anyone know where it is on Windows?
<kuruczgy[m]>
* Does anyone know where the
<sgerhold>
kuruczgy[m]: board-2.bin is a combination of multiple boards, it doesn't exist as-is on Windows. It has separate board files (board.bin) instead with the bdwlan* files
<sgerhold>
for WiFi the recommendation usually is to use the linux-firmware files instead of the Windows ones, if possible
<kuruczgy[m]>
Ah is everything for the Wi-Fi already upstream in linux-firmware?
<kuruczgy[m]>
The hashes for amss.bin and m3.bin don't match with what I found on windows, but I guess that's just a version difference and should be fine.
<kuruczgy[m]>
How do I check if my board is supported by board-2.bin? To me it looks like an opaque binary file.
<sgerhold>
kuruczgy[m]: the easiest way would be to install it and see if it complains :p
<kuruczgy[m]>
Okay I will try.
<kuruczgy[m]>
regdb.bin is not in linux-firmware though, so I guess I still have to copy that?
<sgerhold>
no, it is also part of board-2.bin
<kuruczgy[m]>
I see. Thank you for the help, I will try and see if the Wi-Fi works with just these upstream firmwares.
ellyq has quit []
ellyq has joined #aarch64-laptops
minecrell7544 has quit []
minecrell7544 has joined #aarch64-laptops
<steev>
akaWolf: i can't reproduce here. 6.10.5 poweroff power's off
<kuruczgy[m]>
Can confirm that the linux-firmware commit linked by sgerhold adds support for the yoga 7x. After updating to this commit, my wifi now works.
<kuruczgy[m]>
<anonymix007[m]> "kuruczgy @kuruczgy:matrix.org..." <- Thanks. Fortunately then I don't need the tool.
Segfault[m] has joined #aarch64-laptops
<Segfault[m]>
so i got around to giving the ec stuff another go
<Segfault[m]>
tlmm 46 works, i've got ec events showing up in my kernel log
<Segfault[m]>
but now suspending the device causes the i2c controller to start timing out all its operations so i can't talk to the ec anymore lol
<Segfault[m]>
not even reprobing the i2c controller fixes that
<Segfault[m]>
maybe i need to use pd_ignore_unused again
<Segfault[m]>
oh and hey the freedreno blit fix made it into mesa 24.2! finally i can stop overlaying custom mesa builds :P
<FarchordSteveCossette[m]>
And we thought the firmware files would be the ones taking the longest to land
<steev>
depends on which firmware :D
<steev>
venus firmware still hasn't dropped for the x13s :(
<Segfault[m]>
has there been any news on the venus firmware lately? i haven't been following that super closely
<Segfault[m]>
dammit pd_ignore_unused didn't fix the i2c controller dying
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<steev>
we're waiting on qualcomm/lenovo afaik
lollaritits[m] has joined #aarch64-laptops
<lollaritits[m]>
<steev> "venus firmware still hasn't..." <- whats venus firmware?
<Segfault[m]>
qcvss8280.mbn or whatever it's called
iivanov has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
alfredo has quit []
alfredo has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
alfredo has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
alfredo has quit [Ping timeout: 480 seconds]
<colemickens>
<kuruczgy[m]> "colemickens: Here is my ISO..." <- do you think you'll see this through to nixos-hardware as this stuff lands upstream?
<colemickens>
I mostly just want to make sure your or my work "lives on" so other folks can get in on the fun.
<colemickens>
It may well be that in a month though, there's nothing needed extra last-mile config for specifying the DTB.
<kuruczgy[m]>
<colemickens> "do you think you'll see this..." <- No, unfortunately I don't have plans for driving this upstream in the near future.
<kuruczgy[m]>
What's missing is DTB support for grub, to me it seemed like it would be non-trivial to make the install iso support systemd-boot.
<kuruczgy[m]>
After all the new stuff lands (new linux, new linux-firmware, new mesa) the only custom things will be the initrd kernel modules, the two blacklisted modules, and the two *_ignore_unused kernel params.
<kuruczgy[m]>
If you want to upstream these to nixos-hardware/nixpkgs though feel free to tag me, I would be happy to do code review and/or testing if I have the time.
flokli has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
<colemickens>
> , to me it seemed like it would be non-trivial to make the install iso support systemd-boot
<colemickens>
hoof, I dunno
<colemickens>
my strategy has been to just generate a disk image. systemd-boot in nixos-unstable now supports devicetree passing into the systemd-boot config. So you don't really have to do anything special. Make the image, burn it, voila. Can use it as install media of course.
<colemickens>
Which means it's mostly just... the special mesa build, which won't matter when 24.2.1 is out, the kernel, which might not matter by 6.13 or sooner. So /shrug maybe nothing to worry about other than a list of the kernel modules for usbboot for nixos-hardware or something.
<colemickens>
Still, I'm happy to hear someone got nixos a bit further on the x1e :D
<kuruczgy[m]>
> my strategy has been to just generate a disk image
<kuruczgy[m]>
How large is it? I kinda like the squashfs idea that `installation-cd-minimal.nix` does. Though it's still over 1 GiB, I wonder how far it could be reduced.
<kuruczgy[m]>
Though you are completely right that there is zero point in generating a iso9660 image and supporting actual CDs nowadays
<anonymix007[m]>
Are all firmware blobs in `C:\Windows\System32\DriverStore\FileRepository` or are there other directories?
<kuruczgy[m]>
> Still, I'm happy to hear someone got nixos a bit further on the x1e :D
<kuruczgy[m]>
🙂 I do want to get it to a point where I can attempt to daily-drive it (actually successfully daily driving it is different question though), so I still have my work cut out for me.
<steev>
they should all be in there, but if there is a driver installed into program files for some reason (as an example) then it might be there, but i doubt thats the case
<anonymix007[m]>
I bought T14s (it arrived just a few hours ago), so I will have to extract it on my own, but thanks! File names are basically the same
<FarchordSteveCossette[m]>
anonymix007[m]: You might be able to save yourself some headaches and get a fellow T14s user to send you their fw
<FarchordSteveCossette[m]>
playing with the qca swissknife tool thingy is a bit annoying
iivanov has quit [Ping timeout: 480 seconds]
<anonymix007[m]>
I know, since I already played with it on my previous x86_64 laptop
<konradybcio>
Segfault: the ec had special pre/post suspend commands..
<konradybcio>
in dsdt
iivanov has joined #aarch64-laptops
hexdump0815 has quit [Quit: WeeChat 3.8]
hexdump0815 has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
<robclark>
konradybcio: is EC involved in kb backlight? I didn't run windows enough to check the behavior there, but it seems like kb backlight should be disabled when the laptop suspends (but doesn't currently)
<konradybcio>
yes it is and it even drives the keyboard
iivanov has quit [Remote host closed the connection]
<robclark>
so I guess I can hope for a day when kb backlight turns off when suspended?
<kuruczgy[m]>
My screen-going-black issue was solved by adding a bunch of random kernel modules to the initrd, but I did not root-cause it yet. Though my error messages looked different from yours. Regardless, adding modules is a cheap solution to try, before trying more precise debugging.... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/TnFwEurFjDsBGTPWTBMftPrP>)
<kuruczgy[m]>
* My screen-going-black issue was solved by adding a bunch of random kernel modules to the initrd, but I did not root-cause it yet. Though my error messages looked different from yours. Regardless, adding modules is a cheap solution to try, before trying more precise debugging.... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/bJtJEmFJUYfvPQEYIErJoyVv>)
<anonymix007[m]>
Nope, unfortunately still the same black screen
<kuruczgy[m]>
Then you have to do it the hard way and actually try to debug the issue. What I did while debugging was to insert bash -i somewhere early in the init script (before the screen dies) so it pauses, then I can poke around, and then continue booting after.
<steev>
what does your kernel command line look like
<kuruczgy[m]>
Ah yeah anonymix007 `module_blacklist=qcom_edac,qcom_q6v5_pas pd_ignore_unused clk_ignore_unused` is my command line sorry didn't even suggest the more obvious thing first.
<steev>
the dtb is in the same place as the kernel and initramfs?
<anonymix007[m]>
Yes
<steev>
you could try also passing dtb=<dtbfile>
iivanov has joined #aarch64-laptops
iivanov has quit [Read error: No route to host]
iivanov has joined #aarch64-laptops
<anonymix007[m]>
Okay, I'm totally lost and have no idea what to actually put there. dtb=x1e78100-lenovo-thinkpad-t14s.dtb doesn't seem to work, full path (/boot/*.dtb) doesn't as well. Though I'm quite sure that grub already passes the correct dtb
<kuruczgy[m]>
You could do ls /sys/firmware/devicetree/base to see if the kernel sees the devicetree nodes