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
<steev>
in case you don't have the firmware, the file is there (just be sure to download the raw and not try to wget that url)
<vk6[m]>
thanks, but i find it somewhat strange that it's still looking inside the initramfs even after it's already switched to the actual debian rootfs
<colemickens>
well, I was not able to remove the udev file the way I'd hoped
<colemickens>
so I might hold off in the hopes someone else can figure out which one causes the reboot so I can block it
<steev>
at 1.5 seconds?
<steev>
i doubt you're out of the initramfs at 1.5 seconds
<colemickens>
oh maybe so
<colemickens>
the screen goes black and then resets
<colemickens>
I thought that was the udev rule anyway
<steev>
sorry, my responses were for vk6[m] :)
<steev>
oh man, they finally added back the X to get rid of downloads in chrome. thank god that shitty experiement is over
<colemickens>
maybe I could ask on lkml and see if someone knows the module to blacklist
<colemickens>
or if someone has a working fedora image, I can re-add it and try the debug method suggested above.
<colemickens>
I don't know the latest on actual working images 😅
<robclark>
vk6[m], steev: not finding gpu fw should not be fatal.. drm/msm will keep trying again and again each time the device file is opened by userspace (specifically to avoid having to get zap fw into initrd)
<robclark>
so typical sequence is plymouth opens the device file from initrd and finding fw fails but when x11 or gdm-wayland (or whatever) tries again later after rootfs is mounted, it would succeed (assuming you actually have the fw.. zap need to be copied from windows partition currently)
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
<steev>
robclark: isnt it in l-f? the file that vk6[m] shows as in there for me
<colemickens>
I think it's still the udev rule but that's what mine is doing
<FarchordSteveCossette[m]>
colemickens: Yes that looks VERY similar to what I got originally with that udev rule
bluerise has joined #aarch64-laptops
bluerise_ has quit [Ping timeout: 480 seconds]
<robclark>
steev: gmu and sqe is.. zap is signed by OEM so we can't use the "generic" one (the path to the one we need is in the per-laptop dts)
<steev>
it's so dumb
<robclark>
well, it's the same situation with all the other signed fw.. I've suggested some changes that would make it easier for linux folks who don't care about protected content, so we'll see how that goes, it might eventually get easier
<HdkR>
Ampere finally announced prices for AmpereOne parts. That 96 core part looks very enticing, if someone actually makes a workstation with it :D
<robclark>
so, greater portland area includes plenty of intel chip designers... but ampere has an office in downtown not far from where I work.. usually some of them show up at the local pdx kernel dev meetup
<robclark>
I guess they are mostly interested in continuing to populate data center with arm, but feel free to show up and make your case ;-)
<HdkR>
Fancy, Portland might be a bit of a drive for me :P
<HdkR>
Only a few miles away from their Santa Clara headquarters, I could go knock on the door
<steev>
do it
<steev>
i don't think we have a local kernel dev meetup :(
<HdkR>
Get the cops called on you in one easy step
<robclark>
kernel dev's are no weirder than anyone else up here so no worries about that ;-)
<vk6[m]>
also, using the 6.11-rc1 kernel seems to have gotten rid of all those temperature error messages that were spamming the console
hexdump01 has joined #aarch64-laptops
<vk6[m]>
maybe i need to compile the latest mesa?
hexdump0815 has quit [Ping timeout: 480 seconds]
<HdkR>
vk6[m]: Probably need the latest mesa since X1E GPU support is very fresh
<HdkR>
`Segmentation fault at address 0x0` jumping to a nullptr is quite fun though
<steev>
what version of debian are you on?
<vk6[m]>
i'm using the latest debian sid
<steev>
not that xorg gets updates often
<frozen_cheese[m]>
been offline for a few days... still trying to make me Yoga 7x work right. What's the best kernel to use right now?
<frozen_cheese[m]>
I have it booting with a abel vesa kernel, but a recent pull from the repo seems to have messed up the device tree, it won't boot unless I use an old .dtb
<steev>
johan's 6.11-rc1 tree
<frozen_cheese[m]>
is there a trick to getting that setup? I just compiled that and it won't boot at all for me.
<steev>
use his defconfig?
<frozen_cheese[m]>
yeah
<steev>
what are your kernel command line arguments
<frozen_cheese[m]>
just using boot=/dev/nvme0n1p5 init=/sbin/init
<frozen_cheese[m]>
using grub so devicetree is specified on another line
<steev>
i think you need "efi=novamap clk_ignore_unused pd_ignore_unused regulator_ignore_unused" too
<frozen_cheese[m]>
I'll give those a try real quick
<frozen_cheese[m]>
well, progress.. that helped it keep going, but now it can't find my boot partition. I can probably fix that.
<frozen_cheese[m]>
Thanks though! I didn't know about the boot options
<steev>
boot partition or root partition?
<steev>
also, which distro?
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
agl has joined #aarch64-laptops
ektor52 has joined #aarch64-laptops
ektor5 has quit [Remote host closed the connection]
ektor52 has quit []
ektor5 has joined #aarch64-laptops
dubiousness has quit [Remote host closed the connection]
abcdw has quit [Remote host closed the connection]
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
dubiousness has joined #aarch64-laptops
abcdw has joined #aarch64-laptops
srinik has joined #aarch64-laptops
<robclark>
fwiw on yoga 7x I'm not needing regulator_ignore_unused (but you might need it depending on your devices dts to keep the panel enabled or something like that.. doesn't hurt to keep it until things are working and then try removing it)
<colemickens>
anyone getting any hints on the offending kernel module that udev is trying to modprobe? 🤞
<robclark>
steev suggested something like `ENV{MODALIAS}=="?*", RUN+="/usr/bin/udevadm info -q env -p $devpath >> /var/log/udev.log" #RUN{builtin}+="kmod load"`
<FarchordSteveCossette[m]>
robclark steev can we agree on a communal place where we can submit what is needed to get the X1E laptops going? To save us all from repeating the same stuff over and over again? Now that I got a bootable system, I do want to document what is needed (In my experience) to get stuff running and allow other people to make PRs on it
<FarchordSteveCossette[m]>
We can also update it as things change/get easier
<robclark>
maybe send PR to https://github.com/aarch64-laptops/build or convince lumag to enable the wiki? Idk what would be best, but (hopefully) it should be fairly transient (ie. the goal is to get everything upstream so distro installers just work)
<FarchordSteveCossette[m]>
<robclark> "maybe send PR to https://github..." <- Oh fair enough but I'm guessing that that's months away at the very least :) (Though, things have been moving pretty quickly)
<robclark>
I assume we need at least some of the patches in jhovold's branch which didn't make it into v6.11 (est release late Sept).. and est release for v6.12 is beginning of Dec.. so yeah, unless distro's pull some extra patches into their kernel, I guess EoY
<FarchordSteveCossette[m]>
robclark: Huh, thought it would take more time.... what about the firmware bits we're currently ripping from Windows?
<FarchordSteveCossette[m]>
yeah enabling the wiki is one thing, but we'd need to dump some files in there too
<robclark>
I guess it would be nice if installer image could somehow automate slurping up fw from windows partition before overwriting it
<JensGlathe[m]>
Main reason: you have device specific signed portions of the fw because of... (who cares) but they are there. to get all these into linux-firmware could take a while
<robclark>
AFAIU it would have to be the vendor who sends the fw to l-f .. so reasonable odds for lenovo and perhaps dell.. but I'm not sure how much we can count on the others
<FarchordSteveCossette[m]>
yeah most of the modprobey-custom kerneley-thing will disappear by the release of 6.12 (mostly) but the firmware might take longer
<robclark>
yeah, that might be worth documenting on aarch64-laptops
<robclark>
or, maybe someone could write some "prepare-for-linux.exe" type tool, that installs DtbLoader.efi and latest dtb files, copies fw, etc
<robclark>
(and then ideally after that, fwupd would learn how to install dtb updates to the ESP
<robclark>
)
<colemickens>
My image/config will be more or less self documenting :)
<colemickens>
DtbLoader.efi 👀 is there movement on automatic DTB selection!?
<JensGlathe[m]>
yes
<clee>
robclark: something that I can run from Linux to grab files from the stock Windows partition would be great, but something I have to run in Windows… ugh
<clee>
(it may be dumb but a personal goal of mine with this Yoga Slim 7X has been to never boot Windows on it)
<colemickens>
Farchord (Steve Cossette): do you have a working image now, then? Would you be maybe willing to upload it later if I can't figure out a workaround for my udev rules? I'm just not sure it's feasible for me to patch the udev rules to remove/debug the 80-drivers.rules.
<colemickens>
Farchord (Steve Cossette): but if I have your image, I can try the debug steps mentioned and see if I can get udev to snitch on the offending module.
<robclark>
the drawback of running from linux is you can't really do that after you've overwritten the windows partition ;-)
<robclark>
also, you need to be able to boot your installer first
<clee>
yeah, I removed the original SSD from the machine before I ever booted it. I still have it here, in a little USB/NVME thing. so I can access it if I need to
<robclark>
maybe it could be something that runs entirely from efi, but I think that would still require booting windows to disable bitlocker
<FarchordSteveCossette[m]>
colemickens: Kindof. GPU ain't working, sound ain't working, but I do boot into KDE! Oh, and Wifi aint working
<FarchordSteveCossette[m]>
I get an image, but it uses llvm
<FarchordSteveCossette[m]>
which leads me to think the gpu aint working
<colemickens>
Farchord (Steve Cossette): that's close enough tbh, as long as you make it past the udev reboot.
<robclark>
have you rebuilt mesa from Tot / main branch?
<colemickens>
Farchord (Steve Cossette): are you willing to magic-wormhole it to me?
<robclark>
the fedora mesa rpm won't be new enough
<FarchordSteveCossette[m]>
robclark: nope not yet. I only got the sucker booting yesterday XD
<FarchordSteveCossette[m]>
robclark: so if I build mesa from git, I'm good to go?
<FarchordSteveCossette[m]>
colemickens: How big of files do they accept? Because this is a 2TB SSD lol
<FarchordSteveCossette[m]>
I got fiber, I don't care, but that's big XD
<FarchordSteveCossette[m]>
bbiab, dinner
Caterpillar has joined #aarch64-laptops
<robclark>
yeah, build mesa from git... `meson --prefix=/usr --buildtype=release -Dvulkan-drivers -Dgallium-drivers=freedreno && ninja -C build && sudo ninja -C install` should do it
<robclark>
or something approx like that
<robclark>
might need to `dnf builddep mesa-libGL`
<robclark>
steev: btw, I tried your udev rule hack (but changed the path to /var/log/udev.log).. but not seeing that file created.. OTOH I can at least confirm that commenting out that rule in the file does prevent reboot
<robclark>
srinik: btw, any idea what is missing for external dp on yoga 7x? I _guess_ it is just dts, but it seems not to be wired up the same way as the CRD
<HdkR>
I would also like external DP on yoga so I can do game capture :)
<colemickens>
In another channel, this was suggested udev.log-priority=debug to maybe see what the offending module is.
<colemickens>
That one is easy enough I can try later.
srinik has quit [Ping timeout: 480 seconds]
<steev>
robclark: might need to fix the actual path to udevadm or even the commands :)
<robclark>
I checked the path to udevadm... at least that part was ok
<robclark>
_maybe_? If it is an async external abort it could be something that happened before that, I guess. Or maybe something that happened just after that?
<robclark>
I guess after lunch I can check if disabling zram swap "fixes" it.. but that would be ... strange (considering zram swap was getting mounted later in boot without that rule)
<FarchordSteveCossette[m]>
robclark: I can tell you: It doesn't I tried lol
<steev>
i don't think it's swap
* FarchordSteveCossette[m]
has to figure out why wifi fails to work, this is getting annoying
<FarchordSteveCossette[m]>
Unless I'm missing something in the modprobe file
* FarchordSteveCossette[m]
is debating whether to bring his arm laptop in his vacation or not. In addition to his normal x86 laptop that is.
<colemickens>
I don't have any swap partitions or zram setup in my image fwiw
<FarchordSteveCossette[m]>
Now that I disabled zram, me neither XD but my laptop has 32gb of ram so I should be fine
<colemickens>
I wonder if you boot, then re-enable the bad udev rule, (magically make udev wait between each rule trigger), then trigger udev, while watching the sys log? could you catch it that way?
<FarchordSteveCossette[m]>
Now lets reboot and see what caused it to pop. Or in what order anyway
<steev>
colemickens: that's what i was thinking too... add a sleep to the loop of the "RUN" portion. obviously it would ccause a massive increase in boot time, but you'd at least figure out which device its choking on maybe
<FarchordSteveCossette[m]>
robclark: i noticed the kernel has a x1e80100 snd driver, is it functional? And which module would make it so that the clock doesnt always reset to midnight? 😂
<HdkR>
Interesting, looks like the FN-lock on the Yoga 7x turns off if you fully power cycle the thing. Very wacky
<frozen_cheese[m]>
<FarchordSteveCossette[m]> "robclark: i noticed the kernel..." <- As far as I was able to tell, the sound driver works on the CRDs. My Yoga 7x loads the driver modules... but I don't get any actual device. Wondering if there is something different in the device tree
<FarchordSteveCossette[m]>
frozen_cheese[m]: Mmmm… ill compile that module and see!
<FarchordSteveCossette[m]>
Right now im trying to see if i can get battery levels going
<FarchordSteveCossette[m]>
And it remembering the time
<robclark>
frozen_cheese[m]: I'm pretty sure that we are at least missing alsa ucm bits.. but I'm not really the one to ask about audio stuff
<frozen_cheese[m]>
gotcha. I was just reading through source and patches from qcom. Which made it seem like they had sound working
<robclark>
FarchordSteveCossette[m]: re: correct time, I guess once network is up, ntp fixes things
<robclark>
I could believe they do on CRD
<robclark>
but idk if other laptops use same codecs and whatever else
<FarchordSteveCossette[m]>
Oh well yeah but cant we get it from the bios?
<robclark>
I'm not really sure how the UCM stuff works, I stay away from audio
<robclark>
srinik might know
<nirik>
Still not able to get a boot to userspace here. ;( It boots and can't find rootfs... I'm not sure why. Here's the checklist I have made of what I have been trying: https://paste.centos.org/view/f4a5a757
<FarchordSteveCossette[m]>
I have the feeling the sc8280 should be replaced by the x1e80100 variants. But it wouldnt help your current problem
* nirik
goes to do real work(tm) for a while. ;)
jgowdy has quit [Remote host closed the connection]
jgowdy has joined #aarch64-laptops
<colemickens>
nirik: wait what are you booting from?
<nirik>
usb...
<colemickens>
oh, I can tell you what list of modules works for me specifically
<colemickens>
and I think some of the last three are critical
<colemickens>
but that gets me into my rootfs
<nirik>
sure, but I have been using Farchord (Steve Cossette)'s kernel in recent attempts.
<colemickens>
and their initrd?
<nirik>
cool. Can look more when I get home/back to the laptop.
<nirik>
no, a locally made one (in a qemu aarch64 vm on my x86_64 laptop)
<colemickens>
right
<colemickens>
you need some of the modules from my list
<colemickens>
I don't see some of them listed in your dracut commands, good luck :)
<nirik>
will check later. ;) I did add a bunch to force_modules... but might have missed some
<colemickens>
<robclark> "steev suggested something like..." <- wouldn't one want to structure it so that you get to print the module name? I presume it's passed as an arg to `kmod load` or via an env var per udev norms?
<steev>
you could do that too, yeah
<steev>
knowing the device and module name would be good
<colemickens>
is it confirmed that adsp breaks usb boot?