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
mbuhl has quit [Remote host closed the connection]
<agl>
steev: Do you patched kernel 6.13 but have not pushed iton your Web site?
chrisl has quit [Ping timeout: 480 seconds]
landwork has quit [Ping timeout: 480 seconds]
<steev>
correct agl
<steev>
HdkR: how do you programmatically check for arm32 support on armv8+?
<steev>
its in one of the registers right?
Core2165_ has joined #aarch64-laptops
tobhe_ has joined #aarch64-laptops
<HdkR>
steev: uuuuuuuh, Is it in an exposed ID register in EL0? I'd have to check
tobhe has quit [Ping timeout: 480 seconds]
<HdkR>
steev: ID_AA64PFR0_EL1 I guess?
<HdkR>
I don't know if that's the "ground truth" or if the kernel reads some place else. Not even sure if it sanitizes that when aarch32 is disabled in the kernel config
<dgilmore>
lscpu has some code to detect if the processor supports 32-bit instructions
<steev>
yeah, i think we're gonna go with lscpu - the new arm64 runners from gitlab don't differentiate between runners that can/will run arm32 and those that won't/can't
<HdkR>
Ah, lscpu uses the personality flag
<HdkR>
Which is reasonable
<HdkR>
Since that will also tell if the kernel is wired for 32-bit support
<HdkR>
steev: That's a pain. Especially if you have CI jobs that need to run on both
<HdkR>
At least github self-hosted you can put tags on whatever
<steev>
well, that's fucky-er
<steev>
yeah, our self hosted are fine, we want to use theirs :P
<steev>
but, it gets weirder, running a ci which runs arch-test, lscpu always reports only 64-bit op-mode support but some runs succeed for armhf/armel
chrisl has quit [Ping timeout: 480 seconds]
<HdkR>
That sounds odd
<HdkR>
Hold on while we hot-migrate your VM to another server that supports arm32 on SIGILL
Core2165_ has quit [Read error: Connection reset by peer]
Core2165 has joined #aarch64-laptops
Core2165_ has joined #aarch64-laptops
Core2165 has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<steev>
robclark: do you see corruption "after a while" on sc8280xp? mesa version is 24.2.8
<robclark>
I haven't been using the xps13 so much lately.. but not something I'm familiar with (although I think 24.2 is already more or less eol or at least not having any more planned releases)
<robclark>
err, x13s
<steev>
i have only seen it a couple of times, usually after a suspend
<robclark>
standard disclaimer, check if it repros w/ ToT mesa.. check if you are seeing any gpu hang msgs in dmesg, and if so send devcoredump
<robclark>
I do use gnome shell (basically a vanilla fedora setup) for my daily driver... although on yoga 7x most of the time these days.. but 24.2 is old and I don't think there is much a6xx related there recently (although there are certainly a7xx issues that are fixed in newer mesa)
<HdkR>
steev: quirky quirky
<steev>
i am kind of surprised mesa has fallen off, but maybe to do with trixie stable dates being announced
<steev>
tobhe_ could possibly answer it, but could check the Linux git repo and see if it’s in the config
<chenxuecong[m]>
Unfortunately, I have a Huawei Matebook E Go and simplefb must be loaded during the init phase
<chenxuecong[m]>
Otherwise it will be gray screen
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<icecream95>
chenxuecong[m]: Yes the config has CONFIG_SYSFB_SIMPLEFB=y.
Core2165_ has quit [Read error: Connection reset by peer]
Core2165 has joined #aarch64-laptops
Core2165_ has joined #aarch64-laptops
Core2165 has quit [Read error: Connection reset by peer]
Core2165_ has quit [Read error: Connection reset by peer]
Core2165 has joined #aarch64-laptops
Core2165_ has joined #aarch64-laptops
Core2165 has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
<Treibholz>
I recently got an X13s (refurbished, but according to smartctl, the nvme had only 80 power on hours). I'm surprised how well it runs under Ubuntu. Besides some minor stuff and "acceptable instabilites", the only really missing thing for me is KVM.
<Treibholz>
But something strange about charging the battery: it only charges up to 100% when the device is shut down. Whily running Ubuntu, it only charges up to 82% - on Windows up to 73%. Now I wonder if this is a bug or a (undocumented) battery-saving feature?
<travmurav[m]>
Just swap being able to see battery state for kvm support and the problem is gone when you can't see it /s
<Treibholz>
travmurav[m]: the missing KVM-support is a problem I understood much better (EL1 vs. EL2). The battery-thing is much more mysterious. And I still don't know if it might be a hardware-problem of my device.
<travmurav[m]>
Well my joke was that you /can/ boot at el2, just at the cost of adsp not booting and thus having no battery monitoring :p
<albsen[m]>
Treibholz: absolutely hardware, I had 2 `x13s` and none had this
<albsen[m]>
actually on x13s typing this now
<albsen[m]>
also, make sure u use a max 20w usbc charger
<Treibholz>
albsen[m]: max. 20W? The original charger is 65W
<albsen[m]>
exactly
<albsen[m]>
actually, just checked, my new charger is 35w "VOLTME 35W GaN3 USB-C Fast Charger" but the one that it comes with will crash ur device
<Treibholz>
travmurav[m]: Oh, I can boot Windows, use Hyper-V with EL2 and still have the battery-problem... But... no.
<albsen[m]>
I use a VM in the cloud (tm) to run my virtual machine needs - alternatively - qemu software emulation does work.
<albsen[m]>
also, check which kernel ur running. no clue what ubuntu does, I usually compile my own from a repo from some of the nice people in this chat room :)
<Treibholz>
the KVM-issue is sad, but not critical. I also guess it will be solved, given enough time. (it works on rk3588 and even Apple Silicon, somebody clever will fix it on Snapdragons aswell...)
<travmurav[m]>
> it will be solved
* travmurav[m]
is not sure if him saying "you can boot in el2" was understood or if something different like "works perfectly" is implied
<travmurav[m]>
But meh, "at a cost of adsp and thus audio and battery monitoring broken, you can boot linux in el2 on pretty much all woa platforms using https://github.com/TravMurav/slbounce"
<Treibholz>
albsen[m]: OK, I will try to charge with a 20W phone charger, to see if it charges higher. But I still don't understand, why the original charger should "crash my device".
<Treibholz>
travmurav[m]: ahh, now I understand. The battery-monitoring-issue with EL2 has nothing to do with my current battery mystery.
<icecream95>
Hmm this gives me an idea... is it possible to boot Linux at EL2 and then have a Windows VM with enough hardware access to show the battery status?
<travmurav[m]>
Probably easier to figure out how to boot adsp in el2
<travmurav[m]>
(To remind, the problem is that for us the qcoms hyp boots it, and obviously in el2 it's gone)
<icecream95>
Does Windows start it before installing its own hypervisor, or afterwards?
<travmurav[m]>
After
<travmurav[m]>
Taking over el2 is the first thing it does
<travmurav[m]>
So I guess some windows driver implements adsp boot
<icecream95>
Incidentally I found that if (in QEMU with TCG) you install an ExitBootServices hook to switch from EL2 to EL1, then Windows seems to try to use tcblaunch to switch back to EL2, but it doesn't do that if you switch to EL1 before starting the boot manager
hogliux has joined #aarch64-laptops
<travmurav[m]>
I guess it tries the "sane" way of using tz for it? Or you spoofed stuff to make it think it's qcom?
<icecream95>
I don't actually know what it was doing before that, but I found it at an hvc instruction and clearly expecting to be in EL2 afterwards
<travmurav[m]>
Ah fun
<travmurav[m]>
Perhaps it checks currentel before and gets confused when it changes suddenly xD
<icecream95>
But I hope it doesn't get confused about it changing in the other direction, since that would make it annoying to replace Hyper-V with another hypervisor
<icecream95>
x
chrisl has joined #aarch64-laptops
<icecream95>
It could be that both "Running on qcom" and "Start boot in EL2" set the "can use hypervisor" flag, and then after ExitBootServices, if it sees "can use hypervisor" && "in EL1" it tries to switch
janrinze has quit [Remote host closed the connection]
<Treibholz>
albsen[m]: ok, with my phone-charger (18W), it did charge fully. I'm still irritated, why the original charger behaves "wrong". (or any other more powerfull charger I tried)
d0pefish5 has joined #aarch64-laptops
d0pefish has quit [Ping timeout: 480 seconds]
d0pefish5 is now known as d0pefish
janrinze has joined #aarch64-laptops
<anonymix007[m]>
travmurav: would it be feasible to write our own hypervisor that would "emulate" EL2 for qcom's hyp?
<travmurav[m]>
No idea honestly, considering it works directly with hardware in places
<travmurav[m]>
I guess there is NV on x1e
<travmurav[m]>
But I kinda think qhee is not worth the time
<travmurav[m]>
theyv'e copied half of qhee into gunyah and """""open source"""" part is only the core
<travmurav[m]>
i.e. securelaunch stuff is copied as is with all the same bugs, rproc loading too I think
<maz>
I think they have added their own bugs though! :)
<travmurav[m]>
it's also so open source they even say you shouldn't bother contributing to it unless they allow you /s
<travmurav[m]>
(bugs == doubled memory unmap resulting in hyp crash on error handler path at least)
<exeat>
Huh, I've always charged the x13s with the original 65W Lenovo charger without any problems. I'd make sure the BIOS isn't too out of date, just in case.
<travmurav[m]>
(god this bug gave me so much headache)
Kelsar has joined #aarch64-laptops
<maz>
anyway, on the basis that one hypervisor is enough for a lifetime, I'm not touching this thing.
<sgerhold>
exeat: BIOS version shouldn't matter much for charging on Linux, since the charging functionality is implemented in the ADSP firmware that is part of linux-firmware
<sgerhold>
so whatever the BIOS is using will be replaced when Linux boots
<sgerhold>
In my tests the X13s can charge with up to 45W (15V@3A). The original charger can do more, but it doesn't use that
Core2165 has joined #aarch64-laptops
<anonymix007[m]>
travmurav: is DSP bringup sequence the only thing that's missing? Looks like it's done in one of the drivers, but surely something else is also needed
<anonymix007[m]>
That is, QcSkExt8380.exe has i.e. the `lpass_bring_up` string
<travmurav[m]>
I'd expect mostly the dsp cpu boot + mapping the iommu for it
<anonymix007[m]>
Oh, the same driver has a `pil_lpass_mem_assign` string. Sounds like something related to ^
Core2165_ has quit [Ping timeout: 480 seconds]
<anonymix007[m]>
Okay, I really think this is the driver we're looking for. If only someone actually worked at Qualcomm/Linaro/etc and could look into this so that we won't have to reverse-engineer the driver...
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
alfredo has quit [Read error: Connection reset by peer]
alfredo has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
Core2165 has quit [Read error: Connection reset by peer]
bjin[m] has left #aarch64-laptops [#aarch64-laptops]
lucanis has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<steev>
albsen[m]: ancedotal other way, i've only ever used the charger that came with my x13s and 0 issues with it
<steev>
admittedly he went to exeter but pretty dang cool for a high school senior
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<exeat>
sgerhold: you're right of course; I admit that my brain resists remembering that the adsp does this
lucanis has joined #aarch64-laptops
hogliux_ has quit [Quit: Leaving]
flokli has quit [Quit: WeeChat 4.4.3]
<dgilmore>
steev: are there any bootargs needed on the c630?
flokli has joined #aarch64-laptops
Rayyan has quit [Remote host closed the connection]
Rayyan has joined #aarch64-laptops
<steev>
the same ones as x13s, the clk_ignore_unused and pd_ignore_unused
<steev>
i let my battery die, so its charging right now and i can double check
flokli has quit [Quit: WeeChat 4.5.1]
flokli has joined #aarch64-laptops
flokli has quit []
flokli has joined #aarch64-laptops
<freekurt[m]>
I randomly get a metallic type of sound on my x13s which is running Ubuntu. It happens on both [@juergh:matrix.org](https://matrix.to/#/@juergh:matrix.org)'s 6.11 kernel and [@jglathe:matrix.org](https://matrix.to/#/@jglathe:matrix.org)'s 6.13 kernel. Do any other OSes have this same problem? Or is it just an Ubuntu thing?
weirdtreething has quit [Read error: Connection reset by peer]
chrisl has joined #aarch64-laptops
weirdtreething has joined #aarch64-laptops
flokli has quit [Quit: WeeChat 4.5.1]
flokli has joined #aarch64-laptops
<steev>
dgilmore: actually here i am using clk_ignore_unused arm64.nopauth initcall_blacklist=msm (i assume the initcall blacklist can be dropped and was for some kinda mesa issue i was having once upon a time)
<steev>
i do not use pd_ignore_unused
<steev>
on the c630
<steev>
this is a 6.12.7 kernel
jhovold has quit [Ping timeout: 480 seconds]
Rayyan has quit [Remote host closed the connection]
Rayyan has joined #aarch64-laptops
weSt has joined #aarch64-laptops
Rayyan has quit [Remote host closed the connection]
Rayyan has joined #aarch64-laptops
Rayyan has quit [Remote host closed the connection]
Rayyan has joined #aarch64-laptops
pabs has quit [Ping timeout: 480 seconds]
<dgilmore>
Thanks. I'm going to put Fedora on it's internal storage