ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
<steev>
give me a few days, i'll poke at qzed's usb patches and see if i can get that stuff working on the thinkpad as well
<clover[m]>
Bootloader entry key `devicetree` Unsupported. is that what you are referencing qzed?
<qzed>
support for more USB ports, I think
<qzed>
is what steev is referring to
<steev>
qzed is talking about accessing efibootvars, something previous to todays thinkpad issues
<clover[m]>
now when i am booting, and its listing partitions, all i see is nvme when i should expect to see sda/sdb or something which would be where my root partition is on my USB drive
<steev>
right
<qzed>
you could maybe try plugging in some other USB device, maybe a keyboard or so... I guess that should show up in the kernel log?
* clover[m]
wonders if i still own a wired keyboard
<steev>
are you plugging the device directly in, or is it via a hub or some such?
<clover[m]>
i have a logitech usb thing emmitter thing i can stick in there
<clover[m]>
im set with my double-bladed lightsaber ;)
<clover[m]>
so am i stuck with my archiso work until the kernel supports usb root drives?
<qzed>
I think that should already work... if usb works I don't see why it shouldn't work for storage devices
<qzed>
what's a bit confusing to me is that the usb root ports do seem to show up properly
<qzed>
did you try anything before creating your iso?
<qzed>
I initially used buildroot to get started on the spx, so that could maybe help looking into the usb stuff
<qzed>
oh, and since it's usb-c stuff: did you try to flip the connector?
<clover[m]>
kk i will try flipping
<clover[m]>
No panic when I flip
<clover[m]>
Panic when flipped and in power port
<clover[m]>
No panic when flipped and in non-power port
<clover[m]>
Good tip qzed! Sadly doesn't solve my systemd-boot woes
<szclsya[m]>
steev: I tried devicetree option of GRUB2, still the same thing
<szclsya[m]>
efistub says `Using DTB from configuration table`, so it should be working
<steev>
the only difference, aside from some things being built in, is that i'm using gcc to build not clang, like you are, but i know clover[m] is also using gcc
<szclsya[m]>
Lemme try to switch to gcc
<szclsya[m]>
Well, that's the problem...
<szclsya[m]>
I can now see scsi in my kernel log
<szclsya[m]>
it now panicked at `pcie_3a_gdsc status stuck at off`
<szclsya[m]>
shit, never been so happy seeing a kernel panic message...
<steev>
that one is a bit above my paygrade - and you're using pd_ignore_unused and clk_ignore_unused ?
<steev>
and efi=novamap ?
<szclsya[m]>
yup, all of them
<szclsya[m]>
Guess it's (finally?) a devicetree problem now. I can see the definition for these in 8280xp's dtb
<steev>
bamse: any ideas about ^^ the gdsc stuff at off thing?
<qzed>
i guess you could comment out the pcie stuff and see how far you get without it
<steev>
szclsya[m]: what does your mkinitramfs.conf look like?
<szclsya[m]>
steev: still using kernel image by itself (I don't have a proper archlinux arm environment now, so I can't use its infrastructure to build one
<szclsya[m]>
qzed: good idea, I will have a try
<steev>
you can always use qemu to chroot in, but okay
<steev>
would definitely rather get the issue sorted, commenting out pci will mean no wifis or nvme
<qzed>
yeah, was meant more as a temporary thing to see if other issues creep up
<qzed>
I usually tend to go at this iteratively, preferably start cutting things away until it's working, then re-enable + fix them one by one
<steev>
makes sense
<steev>
and that message comes from drivers/clk/qcom/gdsc.c
<steev>
PCIe3A 4-lane
<szclsya[m]>
Right, it's part of the driver instead of dt
<steev>
there's a pcie3a in the dt, you should be able to comment it out (hopefully)
<steev>
or just change 'status = "okay";' to 'status = "disabled";'
<steev>
i'd do it in both pcie3a and pcie3a_phy
<steev>
and you can just make ARCH=arm64 CROSS_COMPILE=blah dtbs to just rebuild the dtb
<szclsya[m]>
I believe it's not just pcie3a, there are several error sections that I failed to capture and the last one is pcie3a
<steev>
do you have the version with a touchpad?
<steev>
er
<steev>
touch screen
<szclsya[m]>
yup
<steev>
instead of pcie stuff, try making qup0_i2c4 to be status = "disabled"
<steev>
i don't believe jhovold has had a chance to verify if that stuff is correct
<szclsya[m]>
it's already disabled in the tree
<steev>
no it isn't?
<steev>
are you looking at the sc8280xp-thinkpad.dts ?
<szclsya[m]>
oh you mean the thinkpad dts, I was looking at sc8280xp.dtsi
<steev>
you need pdmapper, qrtr, rmtfs and tqftpserv
<steev>
and then somewhere on your windows partition, you'll find some jsn files, and some .mbn files (C:\Windows\System32\DriverStore\FileRepository\) grab those and shove them into /lib/firmware/qcom/sc8280xp/
<steev>
actually, i dunno about rmtfs, it keeps crashing here on mine
<steev>
but ideally it'll be running and used
<szclsya[m]>
lemme check if arch's firmware package contains ath11k firmware
<szclsya[m]>
if so I can save some trouble
<szclsya[m]>
yes it odes
<szclsya[m]>
*does
<clover[m]>
dang, torn if i should make a pkgbuild for touchscreen or not
<szclsya[m]>
just wondering, why we still need a devicetree when all of the WoA laptops have ACPI?
<szclsya[m]>
dealing with device quirks maybe?
<steev>
Acpi boot isn’t really supported or arm64, with Linux, is my understanding
<steev>
for*
<szclsya[m]>
so we will have to add a devicetree for each laptop? sounds like a lot of work
<steev>
If the firmware doesn’t load, you may have to make a symlink in directory that is 2.0 to 2.1
<steev>
Maybe once a lot more arm64 machines ship with acpi… but right now, a lot of them… don’t
<clover[m]>
hmm, we could have two dts, then copy them both over, and have one entry to boot touchscreen and one entry to boot non-touchscreen
<steev>
i'm gonna go grab some celebratory tacos i think
<szclsya[m]>
yeah...
<steev>
clover[m]: the way we get around that in the debian side of things is to use dtbloader to do the heavy lifting like that, but that'll be up to bamse and the other maintainers
<steev>
on the debian image, we load dtbloader, which gives us the correct dtb, and then we don't bother with a devicetree line
<steev>
uefi->dtbloader->grub (or in your case, systemd-boot)
<szclsya[m]>
steev: can you elaborate on the symlink part? should I create a folder inside /lib/firmware/qcom/sc8280xp called 2.1 (which contains all the mbn) and create a link called 2.0 pointing to it?
<steev>
No
<steev>
It would be in the ath11k
<steev>
The path I showed you above, I have a symlink in there that has 2.0 pointing to 2.1
<szclsya[m]>
ah, that one
<steev>
Also, he’s not in here at the moment
<steev>
But jhovold (I believe is the nick, might be jhovald) is the one doing the majority of the mainlining work, so we may want to discuss with him as well
<steev>
szclsya[m]: can you pastebin your dmesg output somewhere as well?
<steev>
There will likely be errors and such
hexdump0815 has joined #aarch64-laptops
<steev>
But I wanna look through it
<steev>
When I get home anyway
<steev>
Not while in the taco line
<szclsya[m]>
sure, I'm building the wlan packages with qemu. will post it after I start the machine again
hexdump01 has quit [Ping timeout: 480 seconds]
<steev>
If you have WSL installed you could build them there, then disable bitlocker and mount the partition inside arch and copy across
<clover[m]>
steev: if you get time, can you see if my iso takes you all the way to command line? i want to see if im missing anything else before changing my pkgbuild around
<steev>
since i'm just testing, i don't have to say "i use arch btw" right?
<clover[m]>
Lol
<steev>
hmm
<steev>
i'm stuck, it gets about 6 seconds in and just sits, lemme look at the entries (i just chose the default)
<steev>
unfortunately, it just gets to about 6 seconds in, where i'm assuming it's supposed to switchroot and not
<szclsya[m]>
steev: the log seems to be truncated after boot. I'm only seeing log from 24 seconds
<szclsya[m]>
s/log/dmesg
<steev>
szclsya[m]: are you still passing earlycon? if so you can drop it now that you're booting
<steev>
the journal *might* still have it
<steev>
just that it probably rotated
<szclsya[m]>
ah I know what's happening, something is spamming the log
<clover[m]>
<steev> "i'm stuck, it gets about 6..." <- Default is as far as I got. 🫠
<steev>
clover[m]: if you want, maybe try the rc6 branch i pushed earlier, i doubt something in there fixed whatever, but it sems to be working for szclsya[m]
<steev>
szclsya[m]: ah, that's possible
<szclsya[m]>
yeah I just left USB mass storage debug on and it spits out tons of messages
<clover[m]>
steev: Would you tag rc6?
<steev>
oh right
<steev>
sorry
<steev>
done
<steev>
actually it's rc7 because rc7 came in a little earlier but nothing touched on arm stuff
<clover[m]>
Ok thanks. Will work on that tomorrow. Night guys
<steev>
sleep well, i need to do that soon myself, the 8am work meetings come early :(
<szclsya[m]>
clover: good night!
<steev>
okay so
<steev>
the DMI id for y'alls touchpad version, i'm guessing, looks to be 21BX0016US whereas mine is 21BX0015US
<steev>
touch screen*
<szclsya[m]>
yup, that's the model number displayed on lenovo website
<szclsya[m]>
note that it's pretty messy now, as I was turning things on or off to see what sticks
jhovold has joined #aarch64-laptops
flowriser has quit [Read error: Connection reset by peer]
iivanov has joined #aarch64-laptops
iivanov__ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov_ has joined #aarch64-laptops
iivanov__ has quit [Ping timeout: 480 seconds]
iivanov has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
<qzed>
re acpi support: Qualcomm uses PEPs (platform extension protocols) which hook into acpi power functions
<qzed>
the first problem is that windows doesn't support this
<qzed>
*linux doesnt support this
<qzed>
the second is that the PEP drivers and many other drivers still contain a ton of hard-coded stuff (mmio addresses, etc.)
<qzed>
so for acpi support, we still have to more or less write a device tree, just in software
<qzed>
and since we do already have some drivers that support DT/OF and not ACPI (usually from chrome-os and android stuff) it's easier to just use that
<qzed>
at some point we can hopefully support PEPs, but then we'd still have to hard-code a bunch of stuff in the drivers on a per-device or hopefully per-generation basis...
derzahl has quit [Ping timeout: 480 seconds]
derzahl has joined #aarch64-laptops
klardotsh has quit [Ping timeout: 480 seconds]
falk689 has quit [Remote host closed the connection]
<szclsya[m]>
backlight interface works through /sys/class/backlight
<clover[m]>
Huzzah!
<broonie>
steev: Further on the ACPI stuff - ACPI *is* well supported on Linux and is widely used for server type systems, it's just that the laptops people are working with really don't map well onto ACPI and the ACPI tables Windows uses aren't really a full system description largely as a result.
<szclsya[m]>
wlan do need the symlink
<broonie>
Unfortunately the idiomatic thing for ACPI systems that don't map well onto how ACPI wants them to work is essentially board files.
<steev>
clover[m]: what did you change, just using szclsya[m]'s defconfig?
<clover[m]>
yeah and your latest tag
<steev>
but it says rc1? my latest tag *should* be rc7?
<steev>
or is that just an arch thing
<clover[m]>
no i think that's just labelled wrong, trying to fix now
<steev>
clover[m]: would you mind going into your kernel tree with that config and running "savedefconfig" as the target and posting the resulting defconfig file somewhere?
<clover[m]>
its for sure rc7
<clover[m]>
idk why it is saying rc1, weird
<szclsya[m]>
steev: here's a defconfig generated by the config I posted yesterday https://fars.ee/Rc2W
<szclsya[m]>
oh a correction, the pcie3 problem I had yesterday was not a kernel panic. it can still boot with this error
<clover[m]>
<steev> "clover: would you mind going..." <- I mean the config i used is a part of the pkgbuild
<steev>
thanks szclsya[m], i'll take a look when i can
<clover[m]>
shows what i know. so i just go to the root the kernel where `arch/` is?
<steev>
clover[m]: no, it would be the kernel sources, where you copy the config in, then you savedefconfig which creates an updated "defconfig" file, and you can compare it to what is there, kind of thing
<qzed>
it's probably easier if you create a full install on a usb first though and then try to get wifi working there
<szclsya[m]>
yup, I'm currently doing a install before attempting that
<szclsya[m]>
fortunately NVMe still works after the pcie errors
<steev>
szclsya[m]: did adding the 2.1 symlink not make it just work? i don't believe the remoteprocs are required for wifi on the thinkpad, thankfully
<szclsya[m]>
mhi mhi0: loading /lib/firmware/ath11k/WCN6855/hw2.1/amss.bin failed with error -5
<szclsya[m]>
weird it can't use my WPA3 access point, have to resort to a WPA2 only one
<steev>
not that weird - there is a lot at play, and we're not using the actual firmware the device needs/uses typically, we've a hack in place to a firmware that gives us (mostly) working wifi
<steev>
the alternative is no wifi at all, currently, at least, not the onboard
<steev>
there is also no GPU
<szclsya[m]>
that sends it right to the level of the 3DS lol, I create the WPA2 only access point for the sole purpose of using my 3DS
<szclsya[m]>
still, it's much better than a usb solution
<steev>
it's still in the "bring up" stages of linux support, so things are expected to be wonky/broken
<szclsya[m]>
yeah, not complaining. had a usb wifi stick before, much more headache than this
<szclsya[m]>
at least ath11k is in mainline
<steev>
yeah, but it doesn't have support for the firmware we need yet :)
<szclsya[m]>
hmm if it's (partially) working, do we still need the packages you mentioned before? (like pd-manager and such
<qzed>
it looks like the thinkpad is different, so I guess not?
<steev>
you need those to start up the remoteprocs so that the laptop charges when you plug it in
<szclsya[m]>
we need a deamon for charging? oh well
<szclsya[m]>
btw the wifi seems very slow, I'm getting double digit kb/s
<steev>
see the previous statement about not using the actual wifi
<clover[m]>
could the squashfs decompression issue stem from an incorrectly configured mkinitcpio?
<clover[m]>
i think im going to record my bootup again and see if i can find anything
<steev>
bamse: there you go, 300MHz, and the long-ago requested removal of turbo-mode :)
<bamse>
steev: fancy
<steev>
assuming i set up the email right, anyway
<steev>
clover[m]: do you have dtc available on your arch setup?
gwolf has quit [Ping timeout: 480 seconds]
<clover[m]>
I don't have a set up really. Just trying to get this iso working but I can probably build an uso with device tree compiler package
<clover[m]>
s/uso/iso/
<steev>
right, that's what i meant -if you had it on there. you don't and that's okay - can you look in /proc/device-tree/cpu0-opp-tables and see if you have a folder that is opp-300000000
<steev>
should be the only opp- folder that is 3000...
<steev>
and it's cpu0-opp-table not tables :(
<clover[m]>
I'm getting sammich but yes when I get home