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
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
agl has joined #aarch64-laptops
erebion has left #aarch64-laptops [#aarch64-laptops]
erebion has joined #aarch64-laptops
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
agl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
davidinux has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
tobhe has joined #aarch64-laptops
tobhe_ has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump02 has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hexdump02 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
lksdfgjdlsdvk has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
lksdfgjdlsdvk has quit [Quit: Quits]
ravikant_ has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
Caterpillar has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #aarch64-laptops
icecream95 has joined #aarch64-laptops
pbrobinson_ has joined #aarch64-laptops
svarbanov_ has quit [Remote host closed the connection]
svarbanov_ has joined #aarch64-laptops
pbrobinson_ has quit [Ping timeout: 480 seconds]
svarbanov_ has quit [Read error: Connection reset by peer]
<icecream95>
alexVinarskis[m]: For the Asus Vivobook S15, I wrote a HID-BPF program for getting the function keys working properly: https://github.com/icecream95/udev-hid-bpf
<icecream95>
I'm interested in whether that works on the Zenbook A14, or if it uses different keycodes
svarbanov has joined #aarch64-laptops
<icecream95>
From pictures of the zenbook, it seems to have a function for F11, which the vivobook doesn't (which I consider that a feature since F11 for fullscreen is useful), so at least that would have a new keycode
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #aarch64-laptops
<icecream95>
(hid-recorder can be used to look at the raw HID reports)
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #aarch64-laptops
ravikant_ has quit [Ping timeout: 480 seconds]
<icecream95>
It's also possible that the magic numbers required to enable setting other features (set_init_unk_[12] in my .bpf program) are different. (I found them by attaching to AsusOptimization.exe with windbg and setting a breakpoint on ntdll!NtDeviceIoControlFile.)
ravikant_ has joined #aarch64-laptops
erebion has left #aarch64-laptops [Disconnected: Hibernating too long]
<maxboone>
i'm trying to get audio working on the Surface Pro X (sc8180x) which from teardown photos appears to have a WCD9340 which according to the windows drivers goes over SLIMBus and is pretty well defined in the DSDT
<maxboone>
I have no previous experience working with slimbus devices, and according to the DSDT the codec itself also works over SPI (instead of GPIO on the current sdm845 driver?)
krei-se has joined #aarch64-laptops
<maxboone>
Anyways - I can get the system to boot and configure the SLIM bus, but once I try to add the actual codec to the bus it won't boot
<alexVinarskis[m]>
_oftc_icecream95: interesting, that explains what the HIDRAW device with PID 0x4543 is, as the actual keyboard is on 0x0220. Ill try it today/tmr and report back
<maxboone>
Do y'all know any devices where that I can take inspiration from for DTS configuring this, or is there any userspace tooling for slimbus (or docs) available so I can try to work on getting the codec wired without constant reboots
<maxboone>
tl;dr - can't get the wcd934x driver to work on sc8180x and it appears to use SPI instead of GPIO - is there some reference I can work off as a kernel newb?
<JosDehaes[m]>
<JensGlathe[m]> "@Yoga Slim 7X users would..." <- how do I do that? Not familiar with upstreaming process
ravikant_ has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
Answer on the list with Tested-by: jouremail <journame>
<JensGlathe[m]>
Best case is with a short quote from my text, and a short description how you tested (wich port, adapter, display resolution)
jglathe_angrybox has quit [Ping timeout: 480 seconds]
<konradybcio>
yes
<konradybcio>
you must reply with plaintext, or else the list will bounce you email
srinik has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
srinik has joined #aarch64-laptops
<anthony25>
thanks a lot JensGlathe[m]!
<robclark>
JensGlathe[m]: has the patch changed at all recently? I've been using a (possibly older) version of it for a couple months now
<Jasper[m]>
Slight nitpick, but might it be worth it to merge both sc8280xp-microsoft upstream DT's? Both are mostly the same hw (except for some obvious things that make one a tablet and the other a mini pc)
<anthony25>
robclark: it's a trimmed version of the older one, without the audio and bluetooth parts
<robclark>
ok.. I guess I trimmed those parts out of the original patch as well.. I'll have to compare them to verify we ended up in the same place
<alexVinarskis[m]>
Maybe [@_oftc_robclark:matrix.org](https://matrix.to/#/@_oftc_robclark:matrix.org) could confirm the behavior?
<alexVinarskis[m]>
I can drop topology file and retry
<alexVinarskis[m]>
Worth mentioning that USB3 devices work in all cases in all ports in all orientations
<JensGlathe[m]>
I have a dev kit, and dp altmode works on all three type-c ports. I could try all three consecutively, though... brb
<JensGlathe[m]>
huh. all three work with 2k@75 when plugged consecutively
<JensGlathe[m]>
aaand... same definition I guess, but no topology file loaded
<alexVinarskis[m]>
Tried without audioreach topology, no change, same error on whichever is last
<robclark>
fwiw, if I boot with right side connected, the display is detected, but doesn't light up
<alexVinarskis[m]>
And if you boot without anything connected, then plug right side after login?
<robclark>
same
pabs has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
<JensGlathe[m]>
I just checked the devkit dts I use against the slim7x dts in the patch, and there is no difference in the additional definitions for retimers and dp, except for ps8830,boot-on; on the retimers. Not sure if this is actually recognized and used in the driver (I looked a few weeks back, found nothing)
<robclark>
it could just be unhappy about the displays I have.. one usb-c and one dp.. don't have an hdmi display handy to test.. (but would be curious what sort of display(s) have been seen to work on the right side, ie. hdmi vs dp
ravikant_ has quit []
<jhovold>
alexVinarskis[m]: matrix features don't render well on irc (e.g. when you're referrng to someone in your replies)
<alexVinarskis[m]>
Ah didn't realize, sorry. Will tag instead, thanks.
chrisl has quit [Ping timeout: 480 seconds]
todi1 has joined #aarch64-laptops
<jhovold>
alsa-ucm-conf-1.2.14 released this week with configs for t14s and yoga
<jhovold>
and topology files in the linux-firmware april release
<robclark>
nice
<jhovold>
looks like you got x14s and thinkbook 16 in the ucm release as well, JensGlathe[m]
<jhovold>
are there any public topology files for those yet?
<JensGlathe[m]>
and the ThinkBook 16 dts is not even upstreamed yet
srinik has quit [Remote host closed the connection]
<jhovold>
and alexVinarskis[m] got zenbook a14 in there too
<JensGlathe[m]>
yes, both are in audioreach-topology, too
<travmurav[m]>
fwiw on the vivobook s15 I made photos of the subboard only has usb3 A ports and so relevant redrivers, the actual DP/type-c and hdmi is on the mainboard
<robclark>
interesting, the SoC on your device has x1e labeling, earlier teardown pics I've seen still had sc8380xp labeling
<travmurav[m]>
I think sc labeling is old (i.e. first batches or preprod?)
<travmurav[m]>
saw some early photos of sc and late ones are x1
<JensGlathe[m]>
yes looked a bit like it, also the sc8370xp that was on one pic
<travmurav[m]>
also I just noticed that the sd reader chip is not the realtek sd-express one but.... some chinese usb reader, despite the platform having multiple sd controllers in the soc -_-
<JensGlathe[m]>
The amount of confusion this naming scheme gives...
<JensGlathe[m]>
sd readers is sort of "whatever works first" IMO. On the vivobook its an USB chip (uas device?) un usb_2, on the Thinkbook and on the DevKit it is the builtin sdc2 controller. Guess which one works better.
<JensGlathe[m]>
There's still some debug/RE work to do to get the sdc2 compatible with all cards. sad, really
<JensGlathe[m]>
The Windows driver works, although... there is an out of tree driver when I looked, but its trying the msm-sdcard which... does strange things.
* travmurav[m]
is so confused why did they put a huge ass thermal pad on the microsd slot if it's not even sd-express
<JensGlathe[m]>
it is
<JensGlathe[m]>
SDR-104 iirc
<JensGlathe[m]>
and I rememember a tale from @spieringsae where this sd card reader got thermal damage
pabs has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<roy[m]>
I've been having a lot of crashes due to hitting some thermal shutdown limit (that's on t14s with jhovold kernel). The current "fix" is to set cpufreq scaling_max_freq (2-2.5GHz) before running a large job, but hoping there is a better way. Is this something others run into as well? Looks like there is some support (?) for thermal throttling but it was rolled back in
<robclark>
roy[m]: I haven't (slim 7x, so x1e78 vs x1e80).. what does the tail of `journalctl -b -1` say? That should tell us if linux or the fw is triggering shutdown
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<roy[m]>
<robclark> "roy: I haven't (slim 7x, so x1e7..." <- I'm going to check now, but i'm pretty sure it is the firmware as it often has to fsck disks
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
* travmurav[m]
wonders what the funny APL6012 ADC chip on the vivobook does
<travmurav[m]>
the i2c5 -> 0x76 I guess
chrisl has joined #aarch64-laptops
<travmurav[m]>
or at least that's in the range datasheet for it says
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<roy[m]>
<robclark> "roy: I haven't (slim 7x, so x1e7..." <- yeah nothing in the linux log, must be the firmware
<robclark>
yeah, sounds like it
chrisl has joined #aarch64-laptops
<roy[m]>
any idea what exactly triggers it? I have the cpu0_btm temperature in the status bar and it typically hovers around 95 degrees, sometimes for quite a while, then crashes seemingly out of nowhere. I remember seeing (in the DTB) mentions of 115C threshold in the firmware, which feels far enough from 95 not to be an issue
<robclark>
I guess the fw on your device configures a lower limit?
<steev>
are the fans not running at all?
<roy[m]>
could be. Actually is it the firmware that throttles CPUs at 95C? The only mentions of 95C in the DTB are for GPUs
chrisl has quit [Ping timeout: 480 seconds]
<roy[m]>
steev: oh the fans are running, although I'm not sure how to tell whether it runs at full speed or not, but it does sound like it is having a hard time :)
<JensGlathe[m]>
My HP X14 will switch off when airflow is too low, otherwise it will run full tilt on all cores
<roy[m]>
"too low" as in blocked by whatever the laptop sits on or you have some way to control the fan speed?
<JensGlathe[m]>
And the devkit will not switch off, although when on Windows, the fan will sound much angrier
<JensGlathe[m]>
Dev Kit is not going over ~70, though (the airflow is quite warm
<roy[m]>
JensGlathe[m]: hmm I haven't really tried the fans on windows. I do notice that upon crashing the fans will speed up for half a second, then turn off, so I had a suspicion that perhaps they are not running at full speed
<JensGlathe[m]>
I have seen full tilt only on windows
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<kuruczgy[m]>
Does the T14s still not boot upstream GRUB? roy did I understand correctly that with the NixOS ISO you didn't even get to the GRUB menu?
<steev>
depends on how much ram you have :)
<steev>
a 64gb model, no it does not
<kuruczgy[m]>
And how difficult is the hack to boot it on the 64GB version? Is it documented somewhere?
<steev>
tobhe sent the patch that ubuntu uses upstream, but it was pointed out that it's not quite right to be generic enough across devices, so i'm not sure the status, but if you only care about your x1e, https://lists.gnu.org/archive/html/grub-devel/2025-04/msg00072.html
<roy[m]>
kuruczgy[m]: I tried it with the 4gb grub patch applied locally and it still crashed before the grub menu. Haven't debugged it further
<kuruczgy[m]>
Oh... well I guess just applying that above patch would have been too easy.
<kuruczgy[m]>
But you said that the Ubuntu installer worked for you, right? I assume they are using this patch too?
<roy[m]>
Yup, ubuntu installer works and yes it has the patch applied
<roy[m]>
idk, perhaps I messed up the patch application. But I could boot systemd off USB-A (but not -C) on the t14
<roy[m]>
I did not feel like debugging this any more, plenty of other broken things :-/
jhovold has quit [Ping timeout: 480 seconds]
<kuruczgy[m]>
Did you build grub manually or apply the patch using Nix? I guess there is more space to mess things up if done manually.
<kuruczgy[m]>
Anyway I will probably make a PR to my repo applying that patch to grub, and maybe upload the built ISO for easier testing.
<kuruczgy[m]>
Also, the above patch does not mess with other X1E devices, right? So the GRUB with that patch will still work on my slim7x fine.
<steev>
i think you're meant to use only usb-a on the t14s (i have not tested usb-c) and i only tested running ubuntu as a live image for the moment
<steev>
it would limit grub to 4GB on all arm64 devices
<kuruczgy[m]>
only grub or also linux?
<steev>
as far as i know, since it works fine for other devices, if its listed as supported by ubuntu, it shouldn't be an issue
<steev>
that's only grub
<steev>
i think for linux itself, you still need to limit to 32gb or theres instability, but i don't know as i haven't gotten that far yet, i was fighting with fakemachine and only just now tracked down what the hell was going on with it
<kuruczgy[m]>
I don't want to know if there is a scenario where grub would want to use more than 4GB of RAM...
<steev>
s/want/need :D
<roy[m]>
kuruczgy[m]: I applied patch using nix
<kuruczgy[m]>
Yeah that's fine, applying kernel cmdline options conditionally is much easier than grub patches
<steev>
that is, afaik, a grub option you have to run
<roy[m]>
steev: Does Ubuntu do anything apart from the 4GB patch to boot grub?
<steev>
something about cutmem (again, i haven't looked into it, but i would assume ubuntu's grub.cfg would have it in there)
<steev>
actually probably in the x1e wiki that jhovold has
<kuruczgy[m]>
Hm I only saw mem=31G for the kernel cmdline, is that not enough?
<steev>
if that's what ubuntu is setting, you could try it :)
<roy[m]>
but that's assuming grub booted, in my attempt to get @kuruczgy:matrix.org's nix iso to boot, I did not get that far :)
<JensGlathe[m]>
my attempted workaround was to use sd-boot instead. Not sure if this helps with the 64GB T14s
<roy[m]>
that's what i did too, sd boot off usb-a works. No need to limit sd boot memory
<kuruczgy[m]>
Hm I think the NixOS install ISO is pretty hardcoded around GRUB, switching to sd-boot would be non-trivial, if ubuntu has a working GRUB I kinda want to find out why.
<JensGlathe[m]>
for USB-C you would need to blacklist q6v5_pas, but it also inhibits adsp firmware load (which is the reason there are issues with USB-C)
<kuruczgy[m]>
I think USB-C booting on the T14s is very low priority, if USB-A works fine.
<kuruczgy[m]>
But I kinda want to get the NixOS ISO booting, having to install NixOS using the Ubuntu installer is quite unintuitive.
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<tobhe>
kuruczgy[m]: happy to help you with grub but I haven't found a perfect solution yet
<tobhe>
I also set cutmem 0x8800000000 0x8fffffffff in the grub config to work around a kernel crash
chrisl has joined #aarch64-laptops
<kuruczgy[m]>
tobhe: Thanks. From what I understood roy said that they did not even get to the grub menu with that patch applied (so kernel not in the picture yet)
<kuruczgy[m]>
roy do you perhaps have the nix expression that you used?
<JosDehaes[m]>
Qualcomm Technologies is proud to collaborate with Canonical and is fully committed to enabling a seamless Ubuntu experience on devices powered by Snapdragon®. Ubuntu’s new ARM64 ISO paves the way for future Snapdragon enablement, enabling us to drive AI innovation and adoption together.
<JosDehaes[m]>
Leendert van Doorn, SVP, Engineering at Qualcomm Technologies, Inc.
<JosDehaes[m]>
*
<JosDehaes[m]>
Qualcomm Technologies is proud to collaborate with Canonical and is fully committed to enabling a seamless Ubuntu experience on devices powered by Snapdragon®. Ubuntu’s new ARM64 ISO paves the way for future Snapdragon enablement, enabling us to drive AI innovation and adoption together.
<JosDehaes[m]>
Leendert van Doorn, SVP, Engineering at Qualcomm Technologies, Inc. ```
<roy[m]>
<kuruczgy[m]> "tobhe: Thanks. From what I..." <- looks like I do have it, let me push it
<JosDehaes[m]>
s///, s///
<HdkR>
Oh no, AI innovation.
<kuruczgy[m]>
Putting up with some AI buzzwords in exchange for getting better Linux support from QC is a trade I am willing to take.
<JosDehaes[m]>
what's the difference between this new arm64 ISO and ubuntu concept?
<HdkR>
I would assume officially supported versus experimental?
<roy[m]>
<kuruczgy[m]> "tobhe: Thanks. From what I..." <- here you go: https://bpa.st/GKBQ please let me know if something is obviously wrong, still learning this language
<kuruczgy[m]>
Looks fine to me.
<kuruczgy[m]>
At this point I am kinda suspicious of the 73 security patches, that's a lot of code. What if you did `patches = [ ./grub.patch ]`, just removing all the original patches from nixpkgs?
<kuruczgy[m]>
Waaaait that patch is not the grub patch, that's the patch adding the grub patch to the ubuntu repo.
<kuruczgy[m]>
On one row I see three +s, so that's a patch adding a patch adding a patch.
<tobhe>
patchception
<roy[m]>
good, let me try it again with one less layer (and perhaps without the other patches)
<roy[m]>
@_oftc_tobhe:matrix.org do you remember if grub without 4gb patch goes blue screen or not? (it was not for me, just a quick reboot)
mbuhl has quit [Remote host closed the connection]