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
<robclark>
nirik: you can try https://drive.google.com/file/d/1_VSOJmk754E4gUQvu7YJ68f126jfubYo/view?usp=sharing .. that is same kernel I'm running but packages with `make binrpm-pkg` (which isn't how I install kernels, although I guess I can try that tomorrow).. the other thing is you probably want to use dtb=/x1e80100-lenovo-yoga-slim7x.dtb in your kernel cmdline (that is path into ESP ie /boot/efi so you want to copy the dtb to
<robclark>
for f40, I was getting a reboot mid-boot.. I had to delete (approx, from memory) /usr/lib/udev/rules.d/80-devices.rule
<robclark>
not entirely sure what the problem was there but those udev rules shouldn't be anything needed
<nirik>
Yeah, I did copy the dtb to /boot/efi and passed "dtb=/x1e80100-lenovo-yoga-slim7x.dtb onsole=tty0 clk_ignore_unused pd_ignore_unused arm64.nopauth efi=novamap"
<robclark>
turns out arm64.nopauth isn't needed.. ftr:
<nirik>
cool. I'll look more tomorrow... dinner calls. thanks...
<colemickens>
bummer. even with uas and every qcom module I've seen, my USB device is not available in my intrd
<colemickens>
yeah, I feel like I'm missing something, I get no journalctl logs at all from hotplugging this usb stick in my emergency console
<colemickens>
maybe if someone has a booted yoga7x with working usb they could give me lsmod output and I can eyeball and see if something obvious is missing
<colemickens>
My lsmod suspiciously has phy_qcom_qmp_pcie but nothing qcom/usb-ish sounding
iivanov has joined #aarch64-laptops
<robclark>
I can try usb boot tomorrow when I get to office (wouldn't hurt to remind me).. but probably a good strategy is to start with more =y than =m and then work backwards to make things modules again
* colemickens
groans in lazy + just using abelvesa's defconfig
<colemickens>
but okay, I get it, thanks for the advice
iivanov has quit [Ping timeout: 480 seconds]
<robclark>
try sed 's/=m/=y/g' or something along those lines? The disadvantage is that for some things that need fw might be unhappy if builtin instead of module, if the fw isn't in the initrd.. so like wifi and some things like that might not work.. but I think it would give you a starting point, you should at least be able to get to the point where you could recompile and install kernel on device
<robclark>
this is the bootstrap game ;-)
<colemickens>
oh I don't know, right now it's annoying because it's slow to pull back the image and I can't iterated on the initrd alone, but I've got like a 64core cloud builder versus a 4core hyperthread local builder
<colemickens>
I guess if I were building /on/ the x1e it would be better, that's certainly true.
<colemickens>
I suspect a little lsmod action from someone with it booted will help.
<colemickens>
and/or if there's a public image available, I can maybe investigate it myself. I haven't really followed what the easiest thing to boot is, or if the qcom dev image even boots
<robclark>
you can also dump a file /etc/modules-load.d/ to load a bunch of modules:
<robclark>
at least for me it is easier when I can get to the point of not having to cross compile kernel but that may be just down to what I'm more familiar with
<colemickens>
heh, I don't even know what HW this is, but 80core, 250GB of RAM, native aarch64.
<colemickens>
someone donates a box to the nixos community that I have access to
<HdkR>
Sounds like a fancy Ampere Altra
<steev>
yeah
iivanov has joined #aarch64-laptops
phire_ has joined #aarch64-laptops
phire is now known as Guest1618
phire_ is now known as phire
Guest1618 has quit [Ping timeout: 480 seconds]
iivanov has quit [Ping timeout: 480 seconds]
<colemickens>
dang, none of those helped :(
<colemickens>
I took out evdev though
<colemickens>
is any of the firmware needed for usb to come up? I do still see a number of them kind of whining, I think this one is model/wlan related though, probably from adding ath12k module.
<steev>
robclark: so, re: 16K pages on the X13s and zed not working, the issue was coming from blade ( https://github.com/kvark/blade ) - cloning that and trying to run an example, and i get TU: error: MSM_INFO_SET_IOVA failed! -28 (No space left on device) TU: error: ../src/freedreno/vulkan/tu_device.cc:2340: empty shaders (VK_ERROR_OUT_OF_HOST_MEMORY)
<steev>
this is on 24.1.3
<robclark>
yeah, I'm sure there are plenty of ways for mismatched CPU and GPU page sizes to go badly
<steev>
so it's definitely that the gpu on the x13s doesn't support 16K either?
<robclark>
it sounds like it.. I guess there are things that can be fixed
<robclark>
but it will take someone to, well, fix them
<steev>
on the c630, the error was verrrrrrrrrrrrrrrrrry different for not supporting 16K pages, in that there was all sorts of kernel spew
<steev>
this is such a niche thing, i doubt i should even bother filing a bug (and i have no idea where to even file one)
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
<steev>
i was really hoping i could get it to print out *what* it sees as the gpu info as part of VK_LOADER_DEBUG=all but alas
systwi_ has joined #aarch64-laptops
<jhovold>
Jasper[m]: yes, the thermal zone warning fix is tagged for stable backport
systwi has quit [Ping timeout: 480 seconds]
<jhovold>
sgerhold, lumag: I don't think thw fw misbehaves on x1e due to slight timing differences, but rather that the problem is that the driver can start interacting much sooner with the fw with the in-kernel pd-mapper
<jhovold>
so my guess is that this is a completly generic issue affecting all qualcomm board with in-kernel pd-mapper even if you may be lucky with timing (e.g. when having many drivers enabled)
<lumag>
jhovold, why? I mean, it's perfectly fine to start userspace pd-mapper before starting the remoteproc.
<lumag>
Can we please move the disccussion to the ML? This way bamse and Chris Lew can also participate in it.
<jhovold>
lumag: my point is that changes in timing is likely what exposed existing issues in drivers
<jhovold>
as I wrote in my report on the mailing list, which no one has yet replied to
<lumag>
jhovold, ML please
<jhovold>
feel free to reply on the mailing list and ignore the discussion here, up to you
<HdkR>
Has someone got a DT hacked together to get the Thunderbolt controllers visible on the bus? I see on the Yoga it is tied to PCI 0,1,2 but I'm too much of kernel pleb to poke at it
<jhovold>
no
<jhovold>
and it's going to take alot more work then just dt changes
<jhovold>
than*
<HdkR>
womp womp
<HdkR>
jhovold: Do you know what's blocking USB 20gbit?
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<jhovold>
HdkR: no, sorry, I'm not even sure what the hw is capable of
<HdkR>
Dang
iivanov has quit [Remote host closed the connection]
<FarchordSteveCossette[m]>
jhovold: yeah that's the config I got
<FarchordSteveCossette[m]>
That'S the config I used
<jhovold>
then you need: nvme tcsrcc_x1e80100 phy_qcom_qmp_pcie pcie_qcom
<jhovold>
to access the nvme from your initramfs
<FarchordSteveCossette[m]>
What if it's on USB-C?
<jhovold>
then you need a bunch of other modules
<FarchordSteveCossette[m]>
Because I installed the kernel using my orangepi, dracut should've got it installed outside of -H (Host mode), i.e. it built all drivers in the initramfs
<FarchordSteveCossette[m]>
Trying to see if there'S a kernel commandline arg to make sure it loads those drivers
<jhovold>
usb-c booting is also problematic as the fw triggers a disconnect when loading the adsp fw
<jhovold>
not including that fw may suffice, but getting this to work is a bit of a black art
<FarchordSteveCossette[m]>
ahhhh
<FarchordSteveCossette[m]>
So right now I might be stuck between a rock and a hard place and making my life difficult as a result.... I was really hoping not to have to remove the laptop's back panel.... mmmm
<JosDehaes[m]>
that was almost the first thing I did 😀
f_ has quit [Ping timeout: 480 seconds]
<jhovold>
FarchordSteveCossette[m]: it certainly possible to boot from usb, just hard to write conclusive instructions for every distro and config
<FarchordSteveCossette[m]>
yeah, I do have a backup nvme but it has a heatsink... maybe this'll go on hold until after my vacation lol
<FarchordSteveCossette[m]>
jhovold: Oh no I 100% get it
<colemickens>
robclark: hi just pinging as I think you indicated it might be good to nudge, but I'm curious if you come up with any observations from trying to usb boot and/or can get me a `lsmod` from a running system
<jhovold>
so don't give up just yet :)
f_ has joined #aarch64-laptops
<FarchordSteveCossette[m]>
yeah the fedora kernel boots, but SDDM isn't popping, better though!
<jhovold>
these are the modules I had in my initramfs when setting up my x1e crd:
<jhovold>
and remember to include "regulator_ignore_unused" on the kernel command line so you have display if things go wrong
<jhovold>
and usb-c will only work in one of the two directions...
<jhovold>
good luck!
<JosDehaes[m]>
jhovold: that regulator_ignore_unused seems useful! I didn't know this. I was trying to get the ubuntu installer to boot, but the screen goes back so fast I can't see any kernel messages
<nirik>
robclark: so, with your kernel I get further, but it can't find rootfs and panics and reboots (this is on usb). I'll just try with a nvme later today...
<robclark>
hmm, can you get to emergency shell somehow?
<nirik>
possibly (in a meeting too tho). ;) I got further with root=/dev/sda3 instead of the uuid for some reason... it actually gets to userspace, but then it reboots later (after zam setup?)
<nirik>
was that udev file you nuked that was causing reboots for you /usr/lib/udev/rules.d/80-drivers.rules ?
<steev>
yes
krei-se has quit [Remote host closed the connection]
krei-se has joined #aarch64-laptops
<nirik>
yep... removing that and it no longer reboots. ;)
<nirik>
ooh. I bet I know. i might have the old dtb from fedora kernel instead of the one from rob's rc1.
<robclark>
iirc I had some problems with UUID for root so switch to device path. I guess I never revisited that. But idk why that would be something x1e specific
<bamse>
me too, but it used to work fine...wonder if anything changed
<JosDehaes[m]>
UUID works fine for me
<JosDehaes[m]>
Maybe buggy grub?
<FarchordSteveCossette[m]>
<robclark> "hmm, can you get to emergency..." <- It takes ~5mins but yes I can get in a rescue shell. Do keep in mind, it works fine with an untouched fedora kernel. Do a dracut --regenerate-all -f though, and Poof, you're done! No longer boots.
<FarchordSteveCossette[m]>
I'm actually gonna do some tests on this, but it'll involve extracting the initramfs and rebuilding it manually XD fun!
<bamse>
JosDehaes[m]: i presumed that the bootloader was fully out of the picture once we're reaching the point to pick up the rootfs
<bamse>
JosDehaes[m]: but it might have been a user error...
<FarchordSteveCossette[m]>
I agree
<FarchordSteveCossette[m]>
Oh no, that can't be it....
<FarchordSteveCossette[m]>
lemme c something
<FarchordSteveCossette[m]>
I know it'll come as a surprise to most of you, but I did something dumb.... sigh
<steev>
what was it?
<steev>
don't feel bad, i do dumb stuff all the time :D
<FarchordSteveCossette[m]>
I didn't import the kernel config
<FarchordSteveCossette[m]>
I am pretty sure I did now. The tag is "dirty"
<FarchordSteveCossette[m]>
And the kernel build was MUCH shorter
<FarchordSteveCossette[m]>
Alright, installed, here goes quite litterally nothing XD
<FarchordSteveCossette[m]>
Still a no-go at mounting rootfs...
<FarchordSteveCossette[m]>
And there'S no firmware in the initrd so it loading firmware shouldn't be the issue right?
<steev>
maybe try the thing about not using uuid, but using device id?
<steev>
s/id/path/
<FarchordSteveCossette[m]>
changed UUID=(whatever) to /dev/sda3, still nope
<FarchordSteveCossette[m]>
lemme try to boot it into dracut recovery
<colemickens>
<robclark> "that is after usb boot" <- o_0 huh
<FarchordSteveCossette[m]>
Oh yeah.... keyboard isn'T working
<robclark>
re: kb if you can ssh in or something, maybe check if evdev is loaded? I had problems with kb/touchpad not working without `modprobe evdev`
<FarchordSteveCossette[m]>
robclark: I don't think you can ssh in from the initramfs, can you?
<robclark>
hmm, maybe not.. does usb keyboard work?
<FarchordSteveCossette[m]>
Yes
<FarchordSteveCossette[m]>
Well, using a USB-C hub
<FarchordSteveCossette[m]>
lemme go fetch it
<FarchordSteveCossette[m]>
Oh nope, usb-c isnt working at all, evne the keyboard isnt picked up
<robclark>
hmm, ok.. try making evdev builtin and see if that gets you further?
<robclark>
steev: hmm, I can't run 16k kernel on x1e
<robclark>
anyone know what the supported pg sizes are on x1?
<steev>
weird, i'd have assumed the cores were new enough
<robclark>
I think they are _too_ new, so maybe have to go up to higher page size?
<robclark>
maybe I have to go up to 64k (but at least that is something the gpu also supports)
iivanov has quit [Remote host closed the connection]
<FarchordSteveCossette[m]>
<robclark> "hmm, ok.. try making evdev..." <- I think evdev is already built in? I see an evdev udev rule in the initramfs
<FarchordSteveCossette[m]>
and there'S libevdev also
<robclark>
what is CONFIG_INPUT_EVDEV ? normally it is =m .. try =y
<FarchordSteveCossette[m]>
robclark: I checked your default config, it's already y
<robclark>
hmm, ok
<FarchordSteveCossette[m]>
hold on something'S odd, lemme find your github again
<FarchordSteveCossette[m]>
dangit... I knew it. This has been changed
* FarchordSteveCossette[m]
sighs heavily
<FarchordSteveCossette[m]>
Rebuilding again....
<robclark>
steev: 64k is supported.. but display seems to not come up..
<steev>
robclark: i'd check dmesg, it may be spewing a bunch of drm stuff, though on the c630 with 16K pages, the display still comes up
<robclark>
I think it is before gpu fw is avail so would be different than the smmu bug
<Painkiller995[m]>
jhovold:
<FarchordSteveCossette[m]>
Yeah still not booting. I'm not even 100% sure I'm properly loading the kernel config. I run amake menuconfig and import the config, and it builds a kernel with the tag -dirty
<FarchordSteveCossette[m]>
but it's still not booting
<steev>
-dirty means something isn't committed
<FarchordSteveCossette[m]>
ahhh
iivanov has joined #aarch64-laptops
iivanov has quit [Read error: No route to host]
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
<steev>
gwolf: i pushed out https://salsa.debian.org/steev/linux of the 6.10 kernel with thinkpad/c630 support - you should be able to follow https://www.linux.it/~ema/posts/enabling-kernel-settings-in-debian/ in order to build it; reminder that if you do wanna give it a try, you need to blacklist ipa otherwise you'll get rcu stalls. this is basically my 6.10 kernel tree + (some of) c630 patches on top, audio still no worky :(
<steev>
thanks for fixing it before i even got around to filing the bug
<colemickens>
<robclark> "https://www.irccloud.com/..."; <- is this using abelvesa's defconfig, if not, can you share yours/
<steev>
robclark: and nice to see that i was kinda on the right track-ish (despite misunderstanding exactly what was needed) - my changes were similar (minus the ram thing) i just hadn't edited tu_knl_drm.cc :D
<steev>
now i guess the last thing is get binutils fixed again
<steev>
since arnd mentioned on the #debian-arm channel that 32-bit chroots should be supported on 16K pagesize but it's currently not
<robclark>
colemickens: hmm, if it boots, `modprobe configs` to get the config.. or otherwise I'll paste my current config (but I can't tell from the matrix quoting which of the kernels I've posted you are referring to)
<arnd>
unfortunately the binutils developers disagreed about this being a bug. I did not have the energy to follow up
<robclark>
steev: I wouldn't even worry too much about 32b chroots.. newer cores don't even support aarch32
<robclark>
(and aarch32 support has always been optional)
<steev>
robclark: alas, i have to support aarch32 devices, so like arnd's bug report, i build 32bit images on my arm64 system (arm64 = 20 minutes, x86_64 = 180 minutes)
<JensGlathe[m]>
oof
<steev>
*shrug* pi-w is still very very popular
<robclark>
then maybe use 4k kernels for those system(s)
<arnd>
robclark: the crazy bit is that they managed to break it so hard that you can't even use qemu-user to run 32-bit arm binaries, even though qemu-user works for x86 binaries
<robclark>
heh, lol
<JensGlathe[m]>
more for the x86-64 part
<steev>
robclark: yeah, i can always reboot into 4k (although tbh, it was more of a "how does 16K pagesize perform on the thinkpad" than "i'm gonna move to 16K pagesize and you're gonna like it")
<steev>
JensGlathe[m]: that's been roughtly the timeframe, actually i suck at math, it's an hour and a half or so, so maybe closer to 90 minutes?
<steev>
90-120m depending
<steev>
robclark: while vulkaninfo works, i don't seem to get a window with zed :( https://zed.dev not sure if i'm not fully passing every environment variable needed or not
<robclark>
idk what zed is
<steev>
that's why i gave the url :P but it's like vs code, but without all the node
<JensGlathe[m]>
180m = 3hrs. That's bad. 90m sounds better but is still nerve wracking
<steev>
JensGlathe[m]: that's after figuring out i was passing QEMU_CPU in incorrectly, it was 6-7 hours when you pass the wrong one
<steev>
or let it choose default
<robclark>
steev: well vkcube works, so I guess this is more of a zed issue
<steev>
okay probably on blade's end. thanks
<JensGlathe[m]>
I remember that frustration
<steev>
robclark: yep, vkcube works here :)
<steev>
robclark: ah it looks like it had to be rebuilt :)
<steev>
jannau: yeah, i'm familiar with that bug :D i looked into it; one of the things i wanna do is figure out what we have in kali that is broken with 16K pages
<robclark>
hmm, why doesn't jemalloc just compile variants for all different page sizes and let linker magic do the rest
<steev>
4K should be good enough for anybody, seems to be their mantra
<HdkR>
jemalloc's stance on supporting runtime selection of pagesize is odd. I understand that they bake the page size in to some structures, but maybe...they just shouldn't do that
<abby>
not everything has ifunc
<abby>
if you tell jemalloc to support large pages it does work on both normal and large from the same .so
<abby>
(went through this with raspberry pi 5)
iivanov has joined #aarch64-laptops
<steev>
abby: heh, that's actually what first caught my eye about it, the pi5's default kernel is 16k pages, though i do rebuild for 4k because lack of time to go through everything we have, but now that i have the thinkpad....
<robclark>
ifunc at least is the normal way to plug in a more optimized platform specific thing
<abby>
and only glibc supports it
<steev>
though, asahi says that blender is broken and a bug was filed and closed, but it seems to run here on my thinkpad
<steev>
good of them on getting a ton of stuff fixed though!
<steev>
oh, right, fedora does that thing where after each release they close every bug and then users re-open if it's still an issue with current version
<robclark>
abby: then do a less efficient runtime dispatch for other libc's
<robclark>
(ie fxn ptr call or similar)
<robclark>
(or different LD_LIBRARY_PATH or ...)
iivanov has quit [Ping timeout: 480 seconds]
<jannau>
the blender issue wasn't page size but missing OpenGL features / too low version