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
enyalios_ has joined #aarch64-laptops
enyalios has quit [Ping timeout: 480 seconds]
shoragan has quit [Quit: quit]
shoragan has joined #aarch64-laptops
Erisa0 has joined #aarch64-laptops
Erisa has quit [Read error: Connection reset by peer]
<_merk>
bah
<_merk>
whats the / where is the mailing list?
<_merk>
and where is the for-next tree?
<_merk>
i see it on github
<_merk>
but not sure if i should build SpieringsAE's kernel or not
<_merk>
maybe there is a later and greater one?
<_merk>
i am downloading maud's sources
<_merk>
not sure if the config is already set and i just build or what
<TheBITLINK[m]>
SpieringsAE: ping me once you have those patches, USB-A and DP are literally the only things keeping me from daily driving Linux on my Asus 👀
krei-se has joined #aarch64-laptops
<_merk>
touchscreen would be nice
<_merk>
so would sound
<_merk>
but at least i'll have bluetooth after building this kernel
<TheBITLINK[m]>
huh
<TheBITLINK[m]>
wait, is there a touchscreen variant?
<TheBITLINK[m]>
mine doesn't have one
<_merk>
yeh
<_merk>
this one is touchscreen.
<TheBITLINK[m]>
dayum, you're lucky
<TheBITLINK[m]>
they don't sell it in my country, only non-touchscreen variants
<TheBITLINK[m]>
I have the 32GB one
<_merk>
yeah 32GB
krei-se- has quit [Ping timeout: 480 seconds]
<TheBITLINK[m]>
btw I have sound kinda working on mine, but it only comes through a single speaker and sounds distorted
<TheBITLINK[m]>
I saw a kernel patch the other day that mentions 2 speaker systems and supposedly addresses that specific problem, but I don't remember where
<_merk>
TheBITLINK[m]: oh great, if you find it let me know please
<TheBITLINK[m]>
You could also get a pair of cheap USB-C headphones or a USB-C -> 3.5mm adapter, they usually have their own DAC and work just fine
<TheBITLINK[m]>
That's why sound doesn't bother me too much, I use headphones most of the time anyways
<_merk>
yeah i'll have bluetooth shortly if this kernel works then i can use my bose headphones
<_merk>
brb testing kernel
chronicuser21[m] has joined #aarch64-laptops
hexa- has quit [Quit: WeeChat 4.4.3]
tobhe_ has joined #aarch64-laptops
hexa- has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
nothorseface has joined #aarch64-laptops
nothorseface has quit []
alfredo has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
nothorseface has joined #aarch64-laptops
<dunc4n>
<steev> "the files can be found in..." <- vivobook firmware .exe's are available on asus' website and can be extracted with 7zip
nothorseface has quit []
enyalios has joined #aarch64-laptops
enyalios_ has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
_merk: you can do `make johan_defconfig`
<SpieringsAE>
its a fork of johans fork, that one also has some extra out of tree patches that are necesary for bluetooth
<SpieringsAE>
that is a very barebones config, so some things might be missing, like UINPUT and CIFS/Network storage had to add that myself
<SpieringsAE>
the touchscreen is interesting, mine doesn't have one either so I cannot test that, I'm afraid you'll have to find out that one yourself
nothorseface has joined #aarch64-laptops
nothorseface has quit [Read error: Connection reset by peer]
nothorseface has joined #aarch64-laptops
nothorseface has quit [Read error: No route to host]
alfredo has joined #aarch64-laptops
chrisl has quit [Read error: No route to host]
chrisl has joined #aarch64-laptops
sskras has quit [Read error: Network is unreachable]
pundir has quit [Read error: Network is unreachable]
pundir has joined #aarch64-laptops
rfs613 has quit [Remote host closed the connection]
sskras has joined #aarch64-laptops
rfs613 has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
krzk has quit [Ping timeout: 480 seconds]
<_merk>
SpieringsAE: i tried that but it faults trying to find the root partition
<_merk>
but i'm using the dtb from the build on my other kernel and now bluetooth works
<_merk>
what about gpu gl rendering? is therre any patches for that?
martiert_work has quit [Ping timeout: 480 seconds]
<macc24>
gpu on x1e works in linux
<macc24>
you just need the device specific firmware
<_merk>
macc24: oh are you the mac guy from cadmium?
<macc24>
yes
<_merk>
nice
<macc24>
and more like a girl than a guy
<_merk>
your cadmium stuff helped me heaps
<_merk>
macc24: i am/a little/teapot
<_merk>
macc24: die to the lasck of the efivars support i had to copy the rootfs to the nvme, but it works... i used it on a usb until the firmwares wouldn't let the thing boot cos it would drop the dev node
<macc24>
they should be supported, not sure tho because x1e in cadmium is a lil bitrotten
<_merk>
i built it on a x86_64 arch laptop and had to sed edit pacman.conf to not check space cos it thought the pkg dir had no space
martiert_work has joined #aarch64-laptops
<_merk>
macc24: so i just run the yoink-firmware script?
<_merk>
i have other firmware from x1e-alarm/firmware
<_merk>
is that the same or different?
<macc24>
yes, and set DESTDIR to /
<_merk>
ok
<_merk>
macc24: do i need a windows partition to yoink it from?
<_merk>
SpieringsAE: so after i 'install' the kernel i need to run mkinitcpio with that conf?
<_merk>
SpieringsAE: i tried that firmware from anonymix007 but gpu rendering doesn't work
<_merk>
i only get software rendering
<SpieringsAE>
but did you already have the correct dtb at that point?
<SpieringsAE>
with gpu enabled
<_merk>
SpieringsAE: i'm not sure tbh
<_merk>
i'm using your dtb with 6.13-rc2
<_merk>
and glxgears -info says its doing software rendering
davidinux has joined #aarch64-laptops
<SpieringsAE>
and there is nothing in dmesg about gpu/firmware?
<_merk>
oh
<_merk>
ome stuff about adreno
<_merk>
some*
<_merk>
msm_dpu
<_merk>
vdd and vddcx not found using dummy regulator
<SpieringsAE>
wait I have my laptop with me today I'll check in a couple of minutes
<_merk>
are vdd and vddcx firmware related errors?
nothorseface has joined #aarch64-laptops
<SpieringsAE>
no just parts missing from dts, or incorrect dts bindings, not sure which
<dunc4n>
if there's no errors about firmware loading then it should be fine. I'd grab the latest .bins from the .exe anyway because those in the anonymix repo are 4 months old. lenovo had updated theirs few times at least
<_merk>
SpieringsAE: with mkinitcpio do i just specify that config file and the kernel version and run? or is there other flags i need too?
<SpieringsAE>
I have sudo mkinitcpio -p linux-test
<SpieringsAE>
name is just how I named it
<SpieringsAE>
it should find the conf based on the preset
<SpieringsAE>
should be a path in there
<_merk>
ok
<_merk>
SpieringsAE: it looks for vmlinuz-* but i dont have vmlinux-* in /boot
<_merk>
it should be ok to just rename them right?
<SpieringsAE>
-> replace "%KERNVER% with the patch to your test kernel
<SpieringsAE>
It can have any name you put in there
<_merk>
oh i thought it was just the version not the whole filename?
<SpieringsAE>
for me I have /boot/test/vmlinux
<SpieringsAE>
it will read the version from the Image and find the correct modules folder
<SpieringsAE>
asuming you did make modules_install
<_merk>
i have a file named Image in /boot but thats for the other kernel
<SpieringsAE>
aswell
<_merk>
yeah i did
pinskia has quit [Read error: Connection reset by peer]
<_merk>
==> WARNING: Possibly missing firmware for module: 'msm'
<_merk>
==> ERROR: file not found: '/lib/firmware/qcom/gen70500_gmu.bin'
<_merk>
==> ERROR: file not found: '/lib/firmware/qcom/gen70500_sqe.fw'
<SpieringsAE>
yeah you need to copy your new one somewhere in /boot, doesn't matter what name or place as long as you have a correct boot entry for it
<_merk>
ok cool
<_merk>
hopefully those firmware files are in that exe i just downloaded
<SpieringsAE>
those should be part of the general linux-firmware package
<SpieringsAE>
I think
<SpieringsAE>
ah no it is part of x1e-firmware
pinskia has joined #aarch64-laptops
<_merk>
its in linux-firmware-qcom from arch packages
<_merk>
and its in that path
<_merk>
but mkinitcpio says it can't find it
srinik has joined #aarch64-laptops
<_merk>
should i try booting it now anyway?
<SpieringsAE>
then there must be something different
<SpieringsAE>
I'm not quite sure what those firmwares do, I think it is best to tinker till those errors are fixed
<SpieringsAE>
path is 100% the same?
<_merk>
-rw-r--r-- 1 root root 80K Nov 13 08:01 gen70500_gmu.bin
<_merk>
yes
<SpieringsAE>
qmu or gmu
<Jasper[m]>
try sha256sum file instead
<SpieringsAE>
the line you just sent has qmu
<SpieringsAE>
but the mkinitcpio looks for gmu
<SpieringsAE>
or am i blind
<_merk>
no you are blind lol
<_merk>
they both say g
<SpieringsAE>
nope I am blind yep, anoying line covered the letter
<_merk>
uhm
<_merk>
i'm going to try booting it now if not i'll fall back on the other kernel
<_merk>
dunc4n: there are so many files in that .exez i dont know which ones i need
<_merk>
brb
<dunc4n>
check dts, but it's probably qccdsp8380.mbn and qcadsp8380.mbn
<_merk>
dunc4n: ok
<_merk>
kernel still doesn't boot
<dunc4n>
under "Driver/QualcommBSP/Subsystem/qcsubsys_ext_adsp8380_0822_SSID_7050_C90_0822_Signed" and "qcsubsys_ext_cdsp8380_0812_SSID_7100_0812_Signed/"
<_merk>
oops
<_merk>
sorry
<dunc4n>
you also need the .elf binaries from those folders
<_merk>
bah
<_merk>
i cant find those files
<dunc4n>
ahh hmm gen70500_gmu.bin is not included, you were looking for that
<_merk>
dunc4n: i already have that but mkinitcpio doesn't see it for some reason
<dunc4n>
not familiar with mkinitcpio sorry. those files are in the qcom directory under /lib/firmware?
<dunc4n>
I used dracut and had to manually add firmware paths for now
<_merk>
yeah they are
<_merk>
i think i overwrite the johan config with regular defconfig so i'm building again
nothorseface has quit [Read error: Network is unreachable]
nothorseface has joined #aarch64-laptops
wizzard has joined #aarch64-laptops
nothorseface has quit []
ke7cfn[m] has joined #aarch64-laptops
<ke7cfn[m]>
Created this bug report. Any suggested next steps to get the viviobook with x1p4200 working ?? Are any x1p4200 working ??
<konradybcio>
ke7cfn: not at the moment, but hang tight!
nothorseface has joined #aarch64-laptops
<wizzard>
Could using a thunderbolt 3 cable be the reason that my external monitors don't work with the lenovo thinkpad hub 3? All other acessories do work with the dock. I have tried checked for dmesg errors, but only get `usb 1-1.2: 3:1: cannot get freq at ep 0x84`
<wizzard>
Could someone please send me the missing file from this error message: `tplg firmware loading qcom/x1e80100/X1E80100-LENOVO-Thinkpad-T14s-tplg.bin` failed -2
nothorseface has quit [Read error: No route to host]
<wizzard>
That fixed the last issue. Now I am stuck with this:" MultiMedia1 Playback: ASoC: no backend DAIs enabled for MultiMedia1 Playback, possibly missing ALSA mixer-based routing or UCM profile". Is there a known fix?
davidinux has joined #aarch64-laptops
davidinux has quit [Quit: WeeChat 4.3.1]
davidinux has joined #aarch64-laptops
davidinux has quit [Quit: WeeChat 4.3.1]
davidinux has joined #aarch64-laptops
davidinux has quit [Quit: WeeChat 4.3.1]
davidinux has joined #aarch64-laptops
davidinux has quit [Quit: WeeChat 4.3.1]
davidinux has joined #aarch64-laptops
laine has quit [Remote host closed the connection]
laine has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
todi has quit []
whiskey9 has joined #aarch64-laptops
krzk has joined #aarch64-laptops
nothorseface has joined #aarch64-laptops
nothorseface has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
todi has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
SpieringsAE has quit [Quit: Leaving]
nothorseface has joined #aarch64-laptops
<jhovold>
Here's an updated wip branch for the T14s and X Elite:
<jhovold>
- fix usb superspeed hotplug on t14s and crd (6.13-rc1 regression)
<jhovold>
- fix suspend hard reset on t14s and crd (6.13-rc1 regression)
<jhovold>
- fix broken ucsi and dp altmode (6.13-rc1 regression)
<jhovold>
- fix usb qmp phy supplies
<jhovold>
Known issues:
<jhovold>
- t14s uefi bugs can still be triggered with event workaround
<tobhe_>
thx <3 I also noticed that the workaround sadly didn't fully solve the issue
<tobhe_>
still might have improved the situation a bit
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
todi has quit []
nothorseface has quit [Remote host closed the connection]
nothorseface has joined #aarch64-laptops
nothorseface has quit [Ping timeout: 480 seconds]
todi has joined #aarch64-laptops
nothorseface has joined #aarch64-laptops
<ppd[m]>
wizzard: kinda? there are ucm profiles out there that do make the speakers work but they're, eh, not great.
srinik has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
nothorseface has quit [Read error: Network is unreachable]
<steveej[m]>
thanks jhovold! will update ASAP
<ppd[m]>
oh and kuruczgy 6.13-rc2 rel
<kuruczgy[m]>
ppd: Yeah I did not update to rc1 because of the systemd logs not showing during boot for some reason. Hope it's fixed now, might just have been some kernel config issue in nixpkgs.
<ppd[m]>
ok
davidinux has quit [Read error: Connection reset by peer]
<ppd[m]>
i'll rebase the audio stuffs and just mark the thing as experimental
<ppd[m]>
there isn't really much I can do regarding that until I finish reading the xml reverse engineering
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
for the people with the asus vivobook, I have updated my fork of johan aswell, now with USB A enabled:
<SpieringsAE>
wicked, I got one of those riscv framework thingies, apparently it has a chromeos EC
<SpieringsAE>
It also came with an st-link debugger and I found an stm32f401 on the board, this thing is pretty wacky
<maz>
at least this is a known quantity, as opposed to the ITE ECs.
<robclark>
bamse, maz, konradybcio, (and/or anyone else who has opinion about dt vs el2), do you have any opinions about https://patchwork.freedesktop.org/patch/627815/?series=142279&rev=1 ... AFAIU the dtb should describe the hw+fw so the appropriate thing would be for zap node to not be there (or be disabled) if bootloader decides to boot us in el2 (which is what we have done so far on other devices)
<konradybcio>
ideally the dt should not be any different between el1 and el2.. but then gunyah alters the software interface very noticeably
<robclark>
well, I mean hyp in general changes the sw interfaces around other things too (like smmu, but that is at least probeable this days)
<konradybcio>
i'd love for this to go away, at least removing the variability within a single platform, but unfortunately I can not promise anything here
<robclark>
the existing soln seems nice and clean from driver perspective, trying to decide whether zap is there or not based on EL1 vs EL2 feels a bit hacky to me.. but maybe others have different opinions. But IMO the first thing is decide what we want this to look like from dtb standpoint, and then go from there
<maz>
Gunya actively repaints things (case in point, the GIC emulation and its relation with the SMMUv3), so your DT really changes significantly.
<konradybcio>
robclark fwiw i don't have concerns with Akhil's patch, but i'll wait for bamse's opinion too
<maz>
robclark: looking at this patch, I find it pretty odd. nVHE or VHE have the same addressing capabilities
<maz>
so why should they behave differently?
<maz>
in general, if you have to put is_kernel_in_hyp_mode() in driver code, you're doing something really odd.
<maz>
is any of the GPU stuff system-register based?
<maz>
that'd really be the only reason to use this primitive.
<robclark>
you mean scm stuff??
<robclark>
(but I guess an scm query would be better than hyp mode check)
<maz>
I have no idea what scm is, sorry...
SpieringsAE has quit [Ping timeout: 480 seconds]
SpieringsAE has joined #aarch64-laptops
<maz>
from what I can see, gpu_write() is just a writel, so it should be possible to write to it from EL1 or EL2 as long as we are booted from EL2. This would solve the VHE vs nVHE distinction.
<maz>
(it being the SECVID_TRUST_CNTL register.
<maz>
it is obviously not accessible from EL1 when running under Gunyah, but that's another story.
* maz
takes a DINER interrupt
chrisl has joined #aarch64-laptops
nothorseface has quit [Read error: No route to host]
nothorseface has joined #aarch64-laptops
<konradybcio>
maz the real check should be is_hyp_gunyah()
nothorseface has quit []
<konradybcio>
but we can't do that because the gunyah we're upstreaming has a different ABI to the one that's been shipped on millions of phones as that one wasn't welcomed during review
<konradybcio>
or hmm maybe we can check if qcom_scm_pas_auth_and_reset(GPU_PAS_ID) reports something different when it's unimpl vs when it gets a bad image
chrisl has quit [Ping timeout: 480 seconds]
SpieringsAE has quit [Quit: SpieringsAE]
<maz>
konradybcio: surely gunyah has its own SMCCC hypervisor ID that can be probed?
<JensGlathe[m]>
so the upstreamed gunyah version is sorta... incompatible with real-world devices?
<maz>
robclark: worse case, is_hyp_mode_available() is a more palatable approach. it unifies cases 2 and 3. case 4 is just case 2.
<konradybcio>
(that's the initial submission & the abi was adapted since, afaicu)
<maz>
well, I stand by every word I wrote at the time. this is a hypervisor, not a vertically integrated software stack that happens to invade multiple exception levels.
<maz>
the phone stuff probably matches this second definition. upstream can't deal with that.
<konradybcio>
i'm not trying to persuade you otherwise
<konradybcio>
just saying it's probably not feasible to check for it
<maz>
at least on the devkit, you can easily spot Gunyah by the GIC emulation it presents, which doesn't match what the actual HW.
<kuruczgy[m]>
ppd: Nope, systemd logs still broken with -rc2.
<kuruczgy[m]>
Anyone else having this issue with 6.13-rc{1,2} (Johan's branch) where during boot the messages normally shown by systemd are not shown? If only me, then I guess this must be something NixOS specific...
<konradybcio>
maz well, the ZAP shader is with us since ~2016.. much earlier than gunyah, there was a different (effectively similar but very much not the same) hypervisor in place back then
<konradybcio>
and the driver needs some sort of a catch-all
<JensGlathe[m]>
can't you just check on which EL we are?
todi has joined #aarch64-laptops
<maz>
konradybcio: I outlined how to do it for bare-metal Linux just above, irrespective of the broken distinctions between VHE/hVHE/nVHE/pKVM.
<maz>
JensGlathe[m]: the EL you are running at says nothing. you need to know how the kernel was *entered*.
<konradybcio>
maz could you reply on the thread?
<maz>
konradybcio: let me see if I have that email somewhere...
<kuruczgy[m]>
robclark: did my tcblaunch.exe work btw? (If yes then I guess I could include it in my NixOS image, questionable from a legal standpoint sure, but much easier than making everyone manually copy it from their Windows partition that they may or may not have already wiped.)
chrisl has quit [Ping timeout: 480 seconds]
<robclark>
kuruczgy[m]: I expect it will, but did not have a chance to test yet
<ppd[m]>
kuruczgy: Even `noquiet` didn't work?
nothorseface has quit []
<kuruczgy[m]>
ppd: Nope. I am not sure what even is supposed to interpret that flag, the kernel or systemd
nothorseface has joined #aarch64-laptops
<ke7cfn[m]>
konradybcio: looking forward to it. Curious about the process. Does qcom provide a reference devicetree for X1P42 and then test ??
<anonymix007[m]>
It's been a while, but I finally updated my alarm packages: