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)
<qzed>
ah, I should start using b4 for reviews probably... not that I really have to collect tags and all that stuff (luckily for me the surface stuff is still collected by hans de goede via pdx86)
<qzed>
and lei seems pretty neat
<qzed>
knew about b4 but not that
<steev>
sadly, it came out too late for debian stable
<steev>
but it's in sid or testing, at least
<steev>
i don't remember which, because i usually just ask that we include stuff from debian sid/whatever, if i use it myself, and it hasn't made its way to testing just yet
<steev>
qzed: in all your time messing around with rmtfs, did you ever get "failed to get rprocfd" ?
<steev>
nevermind, i see the issue, just not sure how to get around it
AlexMarty[m] has joined #aarch64-laptops
<clover[m]>
Welcome Alex
<AlexMarty[m]>
Hey all been trying to get arch arm installed on thinkpad x13s. I used a ISO that I found that booted and compiled the kernel from source. But when I try to setup any boot loader it is failing and says that efivars aren’t supported on my platform. I have tried a bunch of stuff like mounting the sys partition and making sure I was booted in UEFI mode. Still says it’s not supported.
<clover[m]>
You used my iso right?
<AlexMarty[m]>
Correct
<clover[m]>
Check /sys/firmware/efi/efivars
<AlexMarty[m]>
There is nothing there in in chroot and not in chroot
<AlexMarty[m]>
I also tried to mount that directory. “Mount -t efivarfs efivarfs /sys/firmware/efi/efivars” and I get an error saying operation not supported.
<clover[m]>
You shouldn't have to mount anything. Just boot and CD to that directory. I guess I'm confused what you are trying to do with efivars? Are you trying to use grub or something
harvests[m] has joined #aarch64-laptops
<clover[m]>
Welcome harvests
<AlexMarty[m]>
I want to boot from an EFI stub. And I need efivars to do that. Efibootmgr says that efivars aren’t supported and grub uses efibootmgr and only has an efi option for arm64 so I would still need efivars for grub as well
<clover[m]>
I think steev: is using grub with x13s. He might be able to help
<AlexMarty[m]>
I’m compiling his kernel
<clover[m]>
He just added efivars support to his kernel tree
<AlexMarty[m]>
I used the default config from the iso “/proc/config.gz”
<clover[m]>
Check this commit for the relevant kernel configuration
<AlexMarty[m]>
Ok I will look at that
<harvests[m]>
Hi everyone, I'm playing around testing linux on my thinkpad x13s. Today I just downloaded ironrobin's arch iso and messed around in the chroot environment today (going to do more tomorrow at the library with faster internet speeds lol)
<harvests[m]>
Wifi worked well for me
<clover[m]>
I would say the installer is not fully ready yet because i still need to self host a pacman repo for x13s. Be sure you have your steev kernel and device tree in the right spots
<harvests[m]>
my plan was to download git in the chroot environment and then see what I can do after that but yeah not used to setting those sorts of things up manually
<clover[m]>
Yeah more support coming but nothing stopping you from having fun with it ;)
<harvests[m]>
any tips on the install in terms of deviating from the install guide?
<harvests[m]>
I guess it would deviate when installing the kernel like you said: can't just pactrap linux /mnt lol
<clover[m]>
Nope you are on your own. It's the wild west right now
<clover[m]>
I would say don't Uninstall windows
<clover[m]>
Because the computer doesn't charge without certain files you can get from windows
<clover[m]>
So you partition your drive in windows, make some space. Then you can mount it and pacstrap etc
<harvests[m]>
yeah I partitioned a 250gig spot for the install
<harvests[m]>
I might just end up throwing in a different ssd though to be extra safe
<clover[m]>
And you need an efi partition too I think
<clover[m]>
And that's where you have systemd-boot
<clover[m]>
And you tell it your root partition kernel dtb
<clover[m]>
Dtb= is kernel parameter actually
<clover[m]>
dtb=
<clover[m]>
Look at the partition on my iso
<harvests[m]>
I'll refer back here tomorrow when I'm hacking on it lol
<clover[m]>
You can use grub instead of systemd-boot if you are more familiar with it
<harvests[m]>
I'd be pretty happy to be able to get through an install and even moreso if I can get xmonad working lol
<clover[m]>
What's that
<harvests[m]>
yeah I've pretty have only used grub but I have time to read on systemd-boot
<harvests[m]>
it's a tiling window manager in haskell
<AlexMarty[m]>
Do you all know if I use the “/proc/config.gz” file that wouod be sufficient for compiling the steev kernel or should I use the PKGBUILD from iron robin.
<AlexMarty[m]>
steev: I am retrying it I think I messed up on my end will update
<steev>
i use the laptop_defconfig in my repo
<steev>
but iirc, arch wants some stuff that isn't enabled in it
<steev>
i was given some defconfigs to diff but i haven't had a chance
<steev>
the laptop_defconfig is based-ish on a debian config
<steev>
but i also haven't added anything recently (3 days ago)
<AlexMarty[m]>
I will try default and see what happens 🙃 maybe I’ll get lucky
<AlexMarty[m]>
If not I’ll pull some condoms down or configure it myself.
<steev>
if you wanna go really bleeding edge... i just pushed the -next branch i've been using (it's jhovold's work, mostly)
<steev>
it's closer to what will end up in mainline, versus, "this is something working"
<steev>
HdkR: if you wanna poke at the dtsi and dts to add the gpu stuff, i did pull in qzed's a690 work
<steev>
it was... pretty simple
<HdkR>
steev: Oh, did it work? :D
<HdkR>
I got distracted by helping a user so I didn't try
<steev>
no, i mean, the driver has it, but the dtsi and dts still need changes
<steev>
but i went out for a smoke, and then the neighbor came out with their puppy, and puppy > computers
<HdkR>
Ah, DTS I'm completely terrible at
<HdkR>
I barely wrap my head around it :P
<steev>
tbh
<steev>
i just look at what the others do
<steev>
so i was looking at the sc8180x's dtsi for the gpu changes there, and those should... roughly work, with addresses corrected
<steev>
opps might be off
<steev>
aaaaaaactually, i can't quite go to bed yet
<steev>
then compile, and fix up things as it complains they're missing/wrong
<steev>
the second one going into sc8280xp.dtsi
<clover[m]>
Software is the key to the future
<HdkR>
steev: I'm looking forward to the changes :)
<AlexMarty[m]>
I’m looking forward to getting this booted. I’m getting close to it. I have it boot looping at loading the EFISTUB so that’s a start. What did you all do to fix that? I know there were other install media that would do that as well
<qzed>
steev: re rmtfs: yeah, I've seen that yesterday with the defconfig...
<qzed>
things work with my normal config IIRC, but I have no idea what options to enable
<qzed>
haven't really looked into it yet
<qzed>
Alex Marty: do you have efi=novamap set?
matthias_bgg has joined #aarch64-laptops
<steev>
qzed: hm, interesting, i figured the remote procs weren't coming up because no wwan here, and no audio yet either
<steev>
but it could be a missing config option
<qzed>
I'll give it a try in a bit... I thought I had remoteprocs with one config I used, but I'm not so sure any more... let me know if you figure more stuff out, if it's a config thing that should definitely be in my fragment config
<qzed>
(i.e. it should go in there but apparently isn't right now)
<steev>
right
<AlexMarty[m]>
<qzed> "Alex Marty: do you have efi=..." <- Considering I don’t know what that is and I don’t know how to set that I would say no lol
<qzed>
kernel command line parameter, you want that and clk_ignore_unused
<qzed>
maybe others
<qzed>
setting that depends on your bootloader
<AlexMarty[m]>
Ok I’ll look into that thank you
<steev>
we also use pd_ignore_unused
<steev>
so you'd want to make sure whatever you're using that sets cmdline args has "efi=novamap pd_ignore_unused clk_ignore_unused" in it - and if you're using !grub, you want to pass "dtb=/path/to/the.dtb"
<steev>
look at clover[m]'s cmdline setup on his iso
<steev>
as well as wherever he puts the dtb
<leezu>
re deep suspend regression in 5.18 on lazor: It's fixed in the later stable 5.18.x. I think it's "cpufreq: qcom-hw: Don't do lmh things without a throttle interrupt" from 5.18.10 that fixed the issue and also provides hopes for fixing a hanging issue I observed occasionally
<steev>
leezu: that's possible - thanks for mentioning it, i'll check on my c630 if battery life seems to last longer (again)
<qzed>
so the 0x71 was also already in the 8180 driver
<qzed>
with the 0x57
<qzed>
this driver seems to support more GPUs
<qzed>
but my guess would be that the firmware from the 8180 driver associated with id 0x71 should work on the 8280
SallyAhaj has joined #aarch64-laptops
<qzed>
hmm, bit early to tell but it might also only have two blobs, one for 0x71 and one for 0x57
<steev>
clover[m]: if you want to give it a try, and because i'm fucking terrible at tagging, i have no idea if this works... lenovo-x13s-5.19-rc7-battery - you'll need to either enable or make module (i've only tested =y) QCOM_PMIC_GLINK and QCOM_PMIC_GLINK_POWER and that should give you something AKIN to a battery, but it's not its final form
<steev>
i also added the commits in the wrong order but meh
<steev>
gnome doesn't show me the battery info, but upower definitely sees something
<steev>
oh, hm, no, everything is empty
<steev>
that explains why it doesn't show the battery infos
<qzed>
gmu firmware is different
<qzed>
sqe I still need to check
<qzed>
but gmu firmware is longer in the newer driver
<qzed>
at least the one for 0x71
<clover[m]>
<steev> "oh, hm, no, everything is empty" <- So not ready yet I assume?
<steev>
yeah, not quite
<steev>
ideally, we would get Qcom legal sign off and release the battery stuff that works properly, but still need that (disclaimer, i say we, but really i mean the dev working on it)
<clover[m]>
Kinda limited on what I can do today. Dealing with a family issue
<clover[m]>
So no rush
<steev>
no worries, trying to figure out why remote procs are broken in -next
<qzed>
so the sqe firmware is also longer
<qzed>
for the a690 at least
<qzed>
I'll extract them and send them to you
<steev>
appreciate
Lucanis0 has quit [Read error: Connection reset by peer]
<clover[m]>
a690 == x13s gpu?
<steev>
yes, Adreno A690
<steev>
or maybe it's just Adreno 690
<clover[m]>
OpenGL 3.3 support, nice
<clover[m]>
Or do we need a driver for that
<steev>
we need the kernel support, and then mesa support as well
<steev>
that's actually what i was wanting it for... lol
<steev>
was making a fork, for thinkpad, but maybe should just submit them as PR, but idk?
<steev>
that's also why i was asking about wwan, wondering if they have more firmware than the non-wwan do
<steev>
because i don't have the modem*.jsn files at all on my system
<qzed>
would be nice to have everything in one place... but there are some "hacks" (aka symlinks) for the bluetooth stuff in there, not sure if that's compatible with the x13
<steev>
the x13s uses entirely different firmware
<steev>
give me a sec, i'm gonna push my thing so you can see... ignore the "f" commit, that's my internal "fixup" commit name
<steev>
well, fixup commit message
<qzed>
ah right, intel bluetooth or something if I remember correctly?
<steev>
not sure
<steev>
it's all plastered with qcom, as per usual
<steev>
none of the intel firmware seem to follow that naming scheme
<robclark>
qzed: if a690 sqe fw is approx 2x bigger (or maybe 1.5x bigger) that seems like it is probably a660 generation (ie. a6xx_gen4).. the gen4 stuff has basically two sqe fw's, one stripped down one for LPAC ring
<robclark>
I guess a660 gen would make sense.. since that is what sc7280 is
<steev>
AlexMarty[m]: you're probably either missing the firmware, or missing the firmware symlink
<steev>
AlexMarty[m]: go into /lib/firmware/ath11k/WCN6855
<steev>
if you only have a "hw2.0" directory, create a symlink from hw2.0 to hw2.1
<steev>
if you don't have any of that... then yeah, you don't have the wifi firmware
<qzed>
robclark: yeah, back when I looked at the drivers in more detail there are some memory block things that are clearly distinct between a640-like and a660-like models, the 680 looks like 640 and the 690 like 660
<steev>
there is a HUGE caveat to the wifi currently, that we are not using the correct firmware, but one that loads and works but with various issues
<steev>
i've been trying to see if i could rig something up, but my board-2.bin file is just... not becoming a board-2.bin file
<robclark>
yeah, that fits with what I was expecting.. and a680 is defn in the same generation as a640.. it is basically like a doubled-up a640
<steev>
according to the downstream stuff that bamse pointed to the other day, it definitely is 660 derived
<robclark>
I expect a690 is a660 but w/ 4 sp's instead or 3
<steev>
sp is... shader profiler?
<robclark>
got link to downstream, btw?
<robclark>
shader processor.. basically a "shader core"
<qzed>
steev: so things look compatible
<qzed>
send a pr if you want
<steev>
https://git.codelinaro.org/clo/la/kernel/msm-5.4.git - bamse said LA.AU.1.4.2.r1-01100-gen3meta.0 but i never found that in there, so i looked at LA.AU.1.4.2.r1-02500-gen3meta.0 which seems to have it
<robclark>
thx
<steev>
qzed: well, need to make some dts changes here - we're dumping the thinkpad's firmware into qcom/sc8280xp
<steev>
and we should either do qcom/LENOVO/2XXXXXXXXXX like we do with the c630, or do qcom/sc8280xp/lenovo/thinkpad-x13s/ like you do with the spx
<steev>
not sure if bamse decided which was betterer
<qzed>
right, let me know once you have decided that and I'll try to figure out that id thing on the spx if I can
<qzed>
or is that something lenovo specific?
<steev>
it's part of the "product name" of dmidecode
<steev>
but
<steev>
the c630s were all the same
<steev>
i have Product Name: 21BX0015US for my x13s, but others have Product Name: 21BX0016US
<steev>
and i'm not sure we want to do firmware for each sku
<steev>
so it would probably make more sense to do qcom/sc8280xp/lenovo/thinkpad-x13s/
<steev>
though i suppose we could do 21BX001XUS
Obsdark has joined #aarch64-laptops
<steev>
i suppose, could push as is, and then later on git mv them?
<qzed>
ah, on the spx the product name is just "Surface Pro X"... regardless of SQ1 or SQ2 (and I think the firmware works on both)
<qzed>
sure
Obsdark has quit []
<qzed>
so I should probably change that to remove the sq2 part...
<qzed>
there are also a bunch of other things I need to touch-up before upstreaming the dts
<leezu>
The touchpad on my lazor is sometimes creating inputs by itsel (evtest log at https://pastebin.com/ZPSuvMFk), which causes it to open random applications like LibreOffice or Firefox or copy-pasting stuff around. Around the time of occurrence, I see "elan_i2c 7-0015: invalid report id data (0) This is the same lazor that previously got into the faulty EC state where the tablet
<leezu>
mode sensor was stuck at 1 (disabling the touchpad) until EC reboot.
<leezu>
I suspect there's a hardware issue with this device. Or is this a known bug? dmesg also logs "loop0: detected capacity change from 0 to 8" every 10 minutes, which I'm not sure why
<leezu>
(For the evtest log above, the laptop lid was closed and an external screen connected)
SallyAhaj has left #aarch64-laptops [Good Bye]
<AlexMarty[m]>
Still no WiFi but I’m booted up. Now I just need to see if I can get Ethernet to work.
<steev>
AlexMarty[m]: can you show your dmesg output?
<AlexMarty[m]>
Yeah let me boot back into it
<steev>
ideally, just dmesg | grep ath
<steev>
also, the output of ls /lib/firmware/ath11k/WCN6855 and ls /lib/firmware/ath11k/WCN6855/hw2.0/
<steev>
okay, then just rsync the entirety of the firmware folder in there
<steev>
you'll get extra stuff
<AlexMarty[m]>
Sounds good
<steev>
but that doesn't matter
<steev>
and you definitely want that because without the cdsp (i think it is) firmware, the battery doesn't charge
<AlexMarty[m]>
steev: Yeah I noticed it not charging
<steev>
:)
<steev>
i didn't lol
<steev>
i thought i'd killed mine
<steev>
"it was plugged in all this time, and i just unplugged it and it died..."
<harvests[m]>
oh, good to hear charging is working with that firmware :p
<steev>
yeah :)
<steev>
as soon as the dev gets approval we'll have proper battery driver as well
<steev>
AlexMarty[m]: did that work for you?
<steev>
while the bleutooth firmwares are in there, it's not yet wired up. i need to look into that too
<AlexMarty[m]>
Yeah WiFi is up I just forgot to install dhcpcd 🙃 so back to the ISO for that lol
<steev>
heh
<steev>
as a former gentoo dev... it's embarrassing how many times i've done that as well
<steev>
ayy, rc8 is out
<AlexMarty[m]>
You know your stuff better than I do. I’ve only installed gentoo and even then it was hacked together. I would love to do that and linux from scratch one day and do it well
<steev>
i keep a gentoo box around just to play with arm64 big endian userland
<steev>
mostly because of some of the wireless tools we have in kali are sometimes run by people with uhhh, machines that cost more than i've ever made, and we need a way to check things