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
nothorseface has joined #aarch64-laptops
derzahl has quit [Ping timeout: 480 seconds]
nothorseface has quit []
<_merk>
macc24: ausis vivobook
<_merk>
all my diff's i did to your Cadmium is stuck on my x86 vivobook that wont take charge atm
<_merk>
and i have messed with /boot that much yesterday that i'm stuck with the kernel/init trying to find the rootfs
<_merk>
i was trying to use the alarm linux-aarch64(-rc) kernel(s)
<_merk>
i think it's because the pcie module is setup wrong somehow
<_merk>
i haven't had a chance to look at the kernel package's .config..
<_merk>
the hospital "lost" my charger and the universal replacement one wont work at all anymore
<_merk>
i have to check the battery termials and connections
<_merk>
re the x86
<_merk>
i also wonder if there is an easy way to take the keys off the snapdragon asus to change the layout to dvorak
<_merk>
cos it confuses my subconsious
<_merk>
:s/sub/un/g
<_merk>
i need to focus on an aarch64 archiso imho
<_merk>
but i can only do that on the snapdragon so i guess i better fix the /boot
<_merk>
i can still boot off my cadium usb but it's got an old dtbs
nothorseface has joined #aarch64-laptops
nothorseface has quit []
echanude has quit [Ping timeout: 480 seconds]
nothorseface has joined #aarch64-laptops
nothorseface has quit []
xroumegue has quit [Ping timeout: 480 seconds]
derzahl has joined #aarch64-laptops
nothorseface has joined #aarch64-laptops
derzahl has quit [Ping timeout: 480 seconds]
nothorseface has quit []
derzahl has joined #aarch64-laptops
derzahl has quit [Ping timeout: 480 seconds]
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
joarc has quit [Ping timeout: 480 seconds]
x44a has joined #aarch64-laptops
x44a has quit []
hexdump0815 has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
alfredo1 has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
alfredo1 has quit [Ping timeout: 480 seconds]
nothorseface has joined #aarch64-laptops
nothorseface has quit []
svarbanov__ has joined #aarch64-laptops
svarbanov_ has quit [Ping timeout: 480 seconds]
nothorseface has joined #aarch64-laptops
nothorseface has quit [Remote host closed the connection]
nothorseface has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
xroumegue has joined #aarch64-laptops
nothorseface has quit [Read error: Connection reset by peer]
srinik has joined #aarch64-laptops
hogliux has joined #aarch64-laptops
<hogliux>
anthony25: thank you for your work on lid-switch. Along with macc24 and kuruczgy, I also tried to find the correct gpio but failed. Your patch works great on my slim 7x.
<hogliux>
kuruczgy: does sleep work for you when your laptop is connected to AC power? It will always wake up after less than a minute but it shows the same behavior in Windows. So I guess suspend is just not expected to work with AC connected? Or my 7x is faulty?
hogliux has quit [Remote host closed the connection]
<kuruczgy>
hogliux: Just tested, 10 minutes and it's still sleeping. But I never leave it plugged in for prolonged periods of time, being kept at 100% charge is not good for lithium batteries. (And we don't have charge limiting... yet?)
<kuruczgy>
Though plugging in/unplugging the charger definitely does wake it up.
<kuruczgy>
Not sure how to fix that, probably just the specific wake event has to be disabled somehow.
nothorseface has joined #aarch64-laptops
<kuruczgy>
Ah, it just randomly woke up, after 17 minutes at 87% charge
hogliux has joined #aarch64-laptops
baozich has quit [Ping timeout: 480 seconds]
<hogliux>
kuruczgy; thanks, for me it definitely always wakes up after a minute or less on AC.
<hogliux>
Along with the random complete system freezes (exactly the same type of freeze that happens when running qemu without `id_aa64mmfr0.ecv=1`), I think my mainboard must be faulty. I get the same freezes in Windows just much more often.
<hogliux>
The only difference between our two machines that I can think of is that I replaced my SSD with a larger capacity SSD. Maybe it's drawing too much power or something. I'm going to try to put back the original SSD and see if it makes any difference before I try to get it replaced via my warranty.
<kuruczgy[m]>
<hogliux> "Along with the random complete..." <- Could also be gpu, check dmesg over ssh when it freezes
<hogliux>
kuruczgy: I can't: same as with the qemu freeze, the watchdog timer seem to reboot the machine before I have a chance to debug
<hogliux>
kuruczgy: I have maybe 10 seconds of time before it reboots and as it happens so rarely... I don't always have a second machine setup to ssh into. Also, it also freezes the same in Windows, so....
nothorseface has quit []
baozich has joined #aarch64-laptops
<kuruczgy>
Ah ok, then probably not gpu
<maz>
hogliux: if the symptom is the same as when running KVM without the cmdline hack, then it suggests that your FW is catching fire for a reason or another.
<hogliux>
maz: hmmm anyway to debug this?
<maz>
nothing easy. you need to narrow down the exact trigger. having a serial console may help, just in case the FW logs something interesting.
<hogliux>
max: I think the 7x has some kind of serial UART on the mainboard, but I'd rather just return it on warranty before I start messing around with that. I'm going to re-install the original SSD, then use lenovo's system restore tool and see if it still locks up in Windows. If yes, it's going back.
<maz>
in the KVM case, it was easy, as I could bisect the VM entry path until I hit the exact instruction that was getting trapped. but if you don't have an easy trigger, things are much harder.
<maz>
fair enough.
<hogliux>
maz: ok got it. Thanks. Also just wondering: I use linux vms a lot with qemu on this laptop. Just for fun I tried booting a Windows 11 setup iso. But it freezes shortly after the windows boot progress spinny thing is shown. Have you ever tried booting Windows in qemu on the snapdragon x elite?
<maz>
hogliux: yes, I have a win11 VM running.
<hogliux>
Ahh cool. Do I need to be on a special qemu branch for that? Or some kernel patches I need?
<maz>
no, I use whatever comes with Debian bookworm.
<maz>
for the kernel, I use whatever is in my work branch of the day, so that may or may not have an influence.
<hogliux>
ok
<maz>
from what I remember, win was picky about the display. but once I figured that out, it started working.
<hogliux>
ok interesting. not something i really need - i was just curious
<anthony25>
hogliux: I switched to s2idle and it fixed the issue for me
<anthony25>
The power drain is bad for both deep and s2idle anyway
<anthony25>
and on "deep", mine also wakes up on AC, even on battery with nothing plugged it randomly wakes up
alfredo has joined #aarch64-laptops
hogliux has quit [Remote host closed the connection]
<macc24>
konradybcio: what do i write in the commit message when adding ec to a laptop? it's an ec and how it is everyone can see
<konradybcio>
macc24 it's a bit like writing official letters.. when you have nothing to say, you gotta say that the grass is green, water is wet,
<konradybcio>
"Configure the onboard IT1234-based embedded controller. It seems to be a variant of a common design used across ABCDclassofdevices"
<konradybcio>
yeah that is a good example ^
alfredo has quit [Ping timeout: 480 seconds]
hogliux has joined #aarch64-laptops
<hogliux>
Thanks @anthony25 that totally worked. Now I just need to write some script that sets `/sys/power/mem_sleep` to `s2idle` on ac and `deep` on battery.
<hogliux>
anthony25: my slim 7x also randomly wakes-up for me on battery but it's much rarer than on AC (maybe once every 20-30 min or so). Ubuntu's lock screen seems to put the laptop right back to sleep when there is no password input for 30 sec or so.
nothorseface has joined #aarch64-laptops
<hogliux>
anthony25: so all in all, on battery, the laptop is deep sleeping "most of the time". I had kind of hoped that if the lid switch is on, that ubuntu would simply put the laptop straight back to sleep when it wakes up, but it doesn't.
<hogliux>
kuruczgy: there seem to be different revisions of the slim 7x that behave slightly differently. Your slim sleeps fine on AC and anthony25/mine seem to have problems with this. Strange...
<kuruczgy[m]>
we should compare fw versions too I guess. I can post mine when I get home
<anthony25>
on my side, I didn't find much difference in power consumption between deep and s2idle
<anthony25>
so I leave it on s2idle all the time
<anthony25>
I shutdown the laptop when it would be suspended for a long time, anyway
<anthony25>
so if it's to be suspended for a short time, I prefer having something that won't trigger a wakeup of the laptop in my bag for whatever reason
<konradybcio>
you generally want "deep", but as you've noticed, there's currently some things missing to make it really power conserving
<anthony25>
I'll try to understand why s2idle stays suspended when deep doesn't, maybe s2idle will allow me to catch the wakeup events
<anthony25>
konradybcio: is it something qualcom specific? s2idle has been preferred on x86-64 in the last years
<anthony25>
I mean, I don't know if it was some corpo speech from intel due to microsoft pushing for s2idle
<konradybcio>
I suppose that's platform specifics
<anthony25>
ok
<travmurav[m]>
konradybcio: what does it actually do in "deep" mode on x1e even?
<travmurav[m]>
is there something more to it on x1e than dropping all resource votes and releasing cores with psci to let firmware handle the rest?
alfredo1 has joined #aarch64-laptops
<konradybcio>
nothing new
<travmurav[m]>
well ugh so is it any different than s2idle then? xD
<konradybcio>
there's a lengthy thread on linux-arm-kernel relating to the psci driver
<travmurav[m]>
do you have some keywords/msg-id? can't find it immediately somehow
shoragan has quit [Read error: Connection reset by peer]
<travmurav[m]>
konradybcio: Thanks! Didn't read beyond first few lines but I guess it's like "in s2idle we're lucky linux asks us for deepest cpuidle that happens to suspend properly, but now we will explicitly let linux implement suspend via the same thing"?
<hogliux>
TheBITLINK: you also seemed to have the random system freezes problem. Did you manage to find a fix for it? Did you replace your SSD?
hogliux has quit [Quit: Page closed]
echanude has joined #aarch64-laptops
SpieringsAE has joined #aarch64-laptops
<kuruczgy[m]>
Ah yeah I remember some talk a while ago about a maybe a replaced SSD causing issues... I have stock SSD. Yeah, maybe you should try reinstalling stock to see if the issue persists
<SpieringsAE>
does anyone have like a little table to convert dts panel-timings into panel-simple.c drm_display_mode, trying to convert a screen to the actual driver but I can't seem to get the alignment correct
<SpieringsAE>
would've been pretty cool if the names of those had some kind of connection to each other
<SpieringsAE>
already went through an adventure to convert "vesa-24" to MEDIA_BUS_FMT_RGB888_1X7X4_SPWG, but I can't find this one
<SpieringsAE>
nvm I think I got something
<macc24>
@hogliux: you have old "bios" firmware version, try updating it
<anthony25>
it's something I talked about in https://bugs.launchpad.net/ubuntu-concept/+bug/2084191 (comment #145 to #150), I don't understand why I could get an updated version of the bios through windows update when other people don't
<anthony25>
they're stuck with v1.36
<anthony25>
I don't know if it's a region thing
alfredo1 has joined #aarch64-laptops
<anthony25>
I really hope that the bios updates will end up being in LVFS at some point, or even just listed on lenovo's website…
alfredo has quit [Ping timeout: 480 seconds]
<macc24>
you can update it manually
<macc24>
i've shared instructions here some time ago
<travmurav[m]>
konradybcio: Yeah I guess I see what's going on, thanks for clarifying this! (though somehow I thought s2idle flag is enough for drivers to start packing up but I guess you want to keep slow stuff on for shallow idle and only kill for deepest states, which makes sense to me)
<konradybcio>
if pulling power from the CPUs would mean pulling power from the system, like it was historically more or less the case, that would be a fair assumption.. but not in the 21st century..
alfredo1 has quit [Ping timeout: 480 seconds]
<travmurav[m]>
well I thought more like "most drivers should properly runtime-pm anyway and not waste power even more aggressively than the cpuidle" but I guess if you have your ssd or whatnot dying/waking up all the time that would be sad, I guess the main problem is that pcie PM doesnt play nicely with that?
<konradybcio>
well the bottom line is, linux currently has no clue when we're pulling the plug
<konradybcio>
and when we pull the plug from the system, pcie goes away with it
<konradybcio>
the nvme is understandably unhappy about that
<travmurav[m]>
yeah, I just somehow I thought when we ask for s2idle linux uses the same facilities to pull the plug properly, but I see that a) if the entry/exit latencies are badly calculated (too good I guess lol) then it would try to runtime s2r xD and b) I guess drivers actually care about "s2idle" mode and "deep" mode?
<konradybcio>
we can't pull the plug from the entire system when the cpus are idle
<konradybcio>
other things may be doing work if all the hardware isn't shut down
<konradybcio>
and then, some hw can't really be runtime-PMd
<travmurav[m]>
by "s2idle" I meant "s2idle suspend mode" not oops accident runtime idle into s2r but I see
<anthony25>
macc24: I looked into the backlog of this channel but I can't find anything, do you remember vaguely how to do that so I can narrow down my search?
<anthony25>
I can share it in the ubuntu bug, at least, so it makes it easier to find
<travmurav[m]>
konradybcio: tho I'd actually find it amusing on non-pcie platforms to do runtime idle s2r xD
* travmurav[m]
'd love see his laptop's power led blink that way
<travmurav[m]>
but sadly the entry/exit latencies are just too bad for it to make sense xD
<travmurav[m]>
(or it's just forbidden somehow, didn't look into it)
<macc24>
anthony25: fwupdmgr install-blob and point it at uefi firmware device-id and alaxbios .cap file
<macc24>
do the same for ec firmware
<anthony25>
oh nice!
<anthony25>
so they could push it to LVFS, that's good news
<anthony25>
the downside is… the .cap are not available anywhere, aren't they?
<macc24>
look around in FileRepository in windows
<macc24>
directory name with "alaxbios"
<macc24>
and do updates from oldest to newest
<anthony25>
I mean for people who didn't receive the update from windows update
<anthony25>
which seems to be the issue here
<macc24>
well
<macc24>
my dms are open
derzahl has joined #aarch64-laptops
<macc24>
also
<macc24>
windows still downloads the alaxbios update
<macc24>
it's just failing to install it
<anthony25>
oh, ok!
<kuruczgy[m]>
(Mine is NHCN44WW and EC is NHEC53WW @hogliux, so yeah, you should probably try to update somehow)
<anthony25>
mine is NHCN53WW too
SpieringsAE has quit [Quit: Leaving]
hogliux has joined #aarch64-laptops
<macc24>
how long should i wait before sending out v3 of the ec driver?
<hogliux>
anthony25: that's spot on. I'm not getting any bios updates via Windows updates. I've definitely gotten 'Lenovo Platform Update' via Windows update. Always assumed that was for BIOS.
<konradybcio>
macc24 i'd wait for reviews on dt-bindings and some commetns from the platform/arm64 maintainer on the driver itself
<anthony25>
hogliux: I don't know if you can force to install the .cap file, otherwise if you want to try using fwupdmgr like macc24 described, you can do so
<anthony25>
I don't know how risky it is
<hogliux>
anthony25: sorry if I'm being slow but where can I find the .cap file?
f_ has quit [Read error: Connection reset by peer]
f_ has joined #aarch64-laptops
hogliux has quit [Remote host closed the connection]
<macc24>
konradybcio: rob's bot found a yaml error in my bindings, after i specifically made sure to bindings_check with yamllint on my end :/
<travmurav[m]>
I'd say if it's just that, can still wait a day or two for people to have a chance to find more :P
f_ has quit [Remote host closed the connection]
f_ has joined #aarch64-laptops
hogliux has joined #aarch64-laptops
<hogliux>
anthony25: I'd assume the installer puts a firmware update file somewhere on a system partition and that the firmware does the actual updating, right?
<hogliux>
I would hope that the firmware checks if the firmware file can be applied for my model
<konradybcio>
for the you want something like make [...] dt_bindings_check DT_SCHEMA_FILES="Documentation/devicetree/bindings/path/to/some.yaml"
<konradybcio>
unless you want to validate all bindings, which yknow you're free to do, but that'll take some time
<konradybcio>
you also need a newer release of some python packages than what certain distros ship, so you may want to install those from pipx or through a venv
<travmurav[m]>
I think at this point some packages should be /older/ than in distros xD
hogliux has quit [Remote host closed the connection]
<travmurav[m]>
or is the jsonschema thing fixed now?
<konradybcio>
idk i have a venv that i made once and update when either Rob or the checker complains
<travmurav[m]>
yeah I guess, I think latest jsonschema breaks dtschema which depends on older version of the api, at least that was the case semi recently
<travmurav[m]>
hm perhaps it was fixed long ago or I'm thinking of something else
<travmurav[m]>
still think I saw people complaining about it quite recently
tobhe has joined #aarch64-laptops
tobhe_ has quit [Ping timeout: 480 seconds]
<ardb>
is there any documentation for the ipa wwan stuff?
<ardb>
bamse: ^^^
<ardb>
trying to get it working again on my c630 but I'm off into the weeds figuring out which modules and packages i need
flokli has quit [Ping timeout: 480 seconds]
akaWolf has quit [Ping timeout: 480 seconds]
flokli has joined #aarch64-laptops
akaWolf has joined #aarch64-laptops
akaWolf has quit [Ping timeout: 480 seconds]
akaWolf has joined #aarch64-laptops
<bamse>
ardb: been too long, so i don't entirely remember... but i think ipa + rmnet would be the ones, as libqmi would speak qrtr directly...
<ardb>
bamse: is rmnet a kernel module?
<bamse>
CONFIG_RMNET
<bamse>
last i tried, the trick was that libqmi (or modemmanager?) needs to be compiled with --with-soc (or something like that)
<ardb>
my user space used to work, and it is stock debian
<ardb>
so it's probably something in my kernel
<bamse>
i should find mine and make sure it works out of the box with arch as well...
patrickm has quit [Ping timeout: 480 seconds]
<macc24>
oh my god, i've just built jhovold's branch with lid switch patch and my ec patch and got genuinely surprised when i shut the lid of my slim7x and it went to sleep and then i opened it and it resumed no problems
<konradybcio>
macc24 which ver are you testing? 6.13-rc3?
<steev>
ardb: you might need to do fcc unlock thingie
<steev>
unless you aren't even getting the device, but my experience with the debian kernel on c630 is that it has rcu stalls when ipa is probed. i believe lumag saw the same issue, but i don't know if you'er using debian's kernel too
srinik has quit [Ping timeout: 480 seconds]
<konradybcio>
unfortunately the ipa maintainer has moved on to a new project :(
<steev>
i get the device here, but no idea if it actually works or not
<steev>
at least with a !debian kernel
<steev>
oh wait, i do have the sim card in here
<steev>
when i connect, i end up with another device, qmapmux0.0@rmnet_ipa0
<bamse>
i believe that's the name of the de-muxed qmap interface on the ipa0 hw interface...
<bamse>
"qmap interface" == rmnet
patrickm has joined #aarch64-laptops
<ardb>
bamse: steev modemmanager tells me
<ardb>
ModemManager[4274]: <wrn> [1734720282.724948] [base-manager] couldn't create modem for device 'qcom-soc': Failed to find a net port in the QMI modem
<steev>
my knowledge of it is more of a "hot dog/not hot dog" except "it works/it doesn't work"
<HdkR>
Sandwich or not a sandwich. Hot Dog: Not a Sandwich. Hot dog in a bun: A sandwich. Hamburger: Beef sandwich.
<bamse>
steev: c630 should be quite capable to run the hotdog detector...
<steev>
this is true
<steev>
i still haven't figured all that stuff out, and that's why i haven't submitted the slpi patch i wrote like 4 years ago
<steev>
which does nothing but load the slpi firmware
<steev>
it does show that it loads it, so i know that part works, i just don't know if it works works
<bamse>
i think srini is the only one who has ;)
<bamse>
should try to improve on that though
<bamse>
there was a repo with some wip code to talk to the slpi and present some iio drivers... but i don't know where i stashed the bookmark
<steev>
the problem i had was... not knowing how to tell the slpi what it has
<steev>
and i couldn't quite follow the docs that existed
<steev>
but it was like "copy it from android" and i was like uhhh, what if you don't have androit
<konradybcio>
for your convenience, windows used to hold a directory structure that would 1:1 replicate the one of android's for some thing like this..
<macc24>
has anyone dumped acpi tables from crd?
<macc24>
* tables from x1e80100 crd?
hogliux has joined #aarch64-laptops
<JensGlathe[m]>
have you looked at aarch64-laptops/build?
<macc24>
yes
<hogliux>
macc24: what is the uefi firmware device-id for fwupdmgr? when I do `fwupdmgr get-devices` it only lists my ssd?
<macc24>
hogliux: you have acpi missing, enable it
<macc24>
in kernel config
<hogliux>
ahh ok thanks
hogliux has quit []
<macc24>
is there any progress on linux on honor magicbook art 14?
<steev>
konradybcio: oh, i do happen to still have windows on the c630, maybe i'll take a look
<steev>
i just figured it was somewhere on one of the /dev/sdeX devicecs