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
<Jasper[m]>
You can use cabextract on these and fetch the firmware you need from there.
feketetukor_ has joined #aarch64-laptops
<LiangQi[m]>
which arm64 laptop is easier solution for now? Thanks in advance for the suggestions.
<JensGlathe[m]>
wdym with easy
<JensGlathe[m]>
Most users appear to prefer the T14s
chrisl has joined #aarch64-laptops
bryanodonoghue has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
svarbanov has quit [Read error: Connection reset by peer]
svarbanov has joined #aarch64-laptops
landwork has quit [Quit: Leaving.]
landwork has joined #aarch64-laptops
landwork has quit []
landwork has joined #aarch64-laptops
janrinze has quit [Remote host closed the connection]
Kelsar has quit [Ping timeout: 480 seconds]
janrinze has joined #aarch64-laptops
landwork1 has joined #aarch64-laptops
landwork has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<anthony25>
T14s firmware is in linux-firmware, so you don't need to import it from windows, and overall the support seems to be a bit better than other laptops due to more devs having it
<anthony25>
Just I don't recommend the 64gb of RAM version, there's a bug in the firmware
<d0pefish>
Jasper[m]: thank you, great suggestion, I didn’t know about this useful repo! Will adjust the build script to fetch things from there :)
<Jasper[m]>
@d0pefish I'm not sure how packaging that stuff would work legally speaking, but I'd try to figure out which ones you need exactly and direct download from there.
<d0pefish>
@Jasper[m]: Yeah, I'm not sure either, I would hope that this kind of scenario is some form of fair use, especially if the WOA-Project repo has existed this long. What I'm trying to do is just reduce the amount of friction in getting a usable Linux env. on the SP11 so that people who might be able to help fix the non-working stuff can just jump in,
<d0pefish>
so if I can somehow avoid the chicken-and-egg problem where you need network to download firmware to get Wi-Fi working, that would be less annoying :)
<d0pefish>
BTW, I'm not sure if Arch Linux ARM is the best choice these days - I just picked it because I'm very familiar with Arch, but I noticed the mirrors can be unreliable and the current root tarball is quite old - what are people using here?
<anthony25>
I don't think it ever was the best choice, with non official support from Arch
feketetukor_ has quit [Ping timeout: 480 seconds]
<Treibholz[m]>
ALARM is a PITA - Arch is amd64-only. I'm still on Ubuntu here, but I guess, I will switch to Debian Trixie, as soon as it is in soft-freeze (and I have the time for it...)
<kuruczgy[m]>
d0pefish: Most people seem to be using Ubuntu/Debian. I think there are also some Fedora users. Me and a couple others are running NixOS on the yoga slim 7x. (NixOS being quite a high learning curve distro, so I would not recommend it to everyone.)
<d0pefish>
NixOS is on my list of things that I feel I should learn; my job uses the package manager part to set up a working dev env for our project
<kuruczgy[m]>
(In theory compared to the slim 7x just the devicetree and the firmware should need to change.)
<jhovold>
d0pefish: been running arch all along for x13s and x1e work, but any distro works since we've worked hard to make sure everything's upstream
<jhovold>
even if you may need to build your own kernel, or install the odd fw file manually
<jhovold>
x13s should be supported by the arch kernel (config) now too, though
<d0pefish>
jhovold: with your kernel, I was 80% there - thanks for your hard work on this
<Jasper[m]>
@d0pefish fyi the files in that repo come straight from Windows Update so the legality part is not a woa-project thing, but more from qcom/ms
chrisl has joined #aarch64-laptops
* Treibholz[m]
really likes this channel, because it is so distro-agnostic. (I just need to take care, not to start a stupid flamewar myself...)
<Jasper[m]>
@Treibholz I do not like $YOUR_DISTRO_PREF so you should probably step on a lego brick
<Treibholz[m]>
Jasper: sometimes the firmware-blobs in the windows-update are even older than in linux-firmware.
<d0pefish>
Jasper[m]: Yeah, I understand that part :) My point was that qcom/ms haven't come for the WOA-Project repo
<Treibholz[m]>
Jasper[m]: I stepped on lego bricks, before linux was invented!
<Jasper[m]>
@Treibholz ms is fairly poignant with these, but it's good to have available for board specific stuff like wifi
<d0pefish>
kuruczgy[m]: Bookmarked - thanks :) I'll take a look
<Jasper[m]>
(if you're able to get it to work, iirc it's also somewhat windows specific)
<exeat>
I just realised the universal applicability of lego bricks with "debian/rules" etched on the side :)
chrisl has quit [Ping timeout: 480 seconds]
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
d0pefish: I tend to use pacstrap directly to make my own arch linux arm images, but jeah the repos sometimes take a nap like they are doing right now
<SpieringsAE>
I wonder how long this nap will take, the last nap was pretty much a full month
<SpieringsAE>
glibc update this time so I think it will be a very long nap
Kelsar has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
Kelsar has quit []
chrisl has quit [Ping timeout: 480 seconds]
Kelsar has joined #aarch64-laptops
<d0pefish>
SpieringsAE: Ahh, I hadn't thought of using pacstrap, I wonder how difficult it would be to use from a non-Arch distro...
landwork has quit [Quit: Leaving.]
landwork has joined #aarch64-laptops
<TheBITLINK[m]>
I hope official Arch ARM becomes a thing soon now that valve's supporting them
<Treibholz[m]>
TheBITLINK: That sounds like a "Steamdeck on ARM"?
<TheBITLINK[m]>
rumors say it's for their upcoming standalone VR headset
<TheBITLINK[m]>
and there's been hints here and there of valve testing out stuff with FEX and waydroid
SpieringsAE has quit [Quit: SpieringsAE]
<Treibholz[m]>
When I set up my X13s, I wanted to disprove, that you can't run games on Arm... So I didn't just run Doom, but also a modern game like "Doom 3". Then I realized: damn, Doom3 is also over 20 years old...
SpieringsAE has joined #aarch64-laptops
<TheBITLINK[m]>
Well, the folks at Asahi successfully ran a few modern AAA games and they run relatively well
<SpieringsAE>
d0pefish: from a non arch distro probably will require distrobox to at least have some kind of arch
<SpieringsAE>
never tried it though
<SpieringsAE>
Also used it for arch riscv for my deepcomputing framework thingy
<SpieringsAE>
I'm happy that I no longer have to mess around with binfmt/qemu-user static now that I have an arm64 system that can actually do something lol
<Treibholz[m]>
TheBITLINK: with fex or native?
<SpieringsAE>
fex is my guess, don't think any AAA game has a native arm version
<Treibholz[m]>
I mean: are there any AAA-games with linux-arm-binaries?
<SpieringsAE>
they barely support linux as is
<TheBITLINK[m]>
fex on top of a microVM they wrote to run 4K pagesize programs on a 16K pagesize kernel
<TheBITLINK[m]>
add to that the fact they basically wrote the GPU drivers from scratch as well lol
<jhovold>
- fix mhi modem suspend and shutdown deadlock
<jhovold>
- enable audio on the t14s
<jhovold>
- enable watchdog
<jhovold>
Known issues:
<jhovold>
- no speaker protection in place for the t14s (use at own risk)
<jhovold>
- 200+ new devicelink cycle messages due to coresight nodes
<Jasper[m]>
Oi that's a big one
<Jasper[m]>
Thanks!
<anthony25>
thanks jhovold!
<ektor5>
jhovold Kudos!
<tobhe_>
jhovold: thanks, I really appreciate your thorough changelogs :)
<albsen[m]>
Jens Glathe: I've been trying out both 6.13 (the version that do boot) and 6.14-rc for a bit now and concluded that both are not stable enough as daily driver. I'm getting random kernel freezes especially when an external screen is attached via usbc
<JensGlathe[m]>
wow thats a lot. Thank you, jhovold !
<JensGlathe[m]>
albsen: hmm rc2 will be out soon-ish. I've had some strange issues, too, but not especially with usb-c.
landwork has quit [Quit: Leaving.]
landwork has joined #aarch64-laptops
ungeskriptet_ has joined #aarch64-laptops
ungeskriptet__ has joined #aarch64-laptops
<SpieringsAE>
nice time to update my asus tree, thanks jhovold!
<SpieringsAE>
asus enjoyers, you can expect it in a couple of hours, still at work rn
chrisl has joined #aarch64-laptops
ungeskriptet has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #aarch64-laptops
ungeskriptet_ has quit [Ping timeout: 480 seconds]
ungeskriptet__ has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hightower2 has quit [Remote host closed the connection]
hightower2 has joined #aarch64-laptops
Kelsar has quit [Remote host closed the connection]
<JensGlathe[m]>
For Thinkbook 16 and the Vivobook S15 x1p4* there are bootable images on google drive, too.
pbsds has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
SpieringsAE has joined #aarch64-laptops
SpieringsAE has quit [Remote host closed the connection]
chrisl has quit [Ping timeout: 480 seconds]
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
my tree for the x elite version of the asus vivobook is updated to 6.14-rc2 as well new features:
<SpieringsAE>
dp alt mode on the usb c ports
<SpieringsAE>
I did also commit my current work for the hdmi port but as far as I can tell it does not work yet
<steev>
dang, it arrived
<d0pefish>
Just tested 6.14-rc2 on SP11, ath12k is not happy ("failed to receive wmi unified ready event: -110" / "failed to start core: -110" / "failed to send QMI message") and I've lost USB ("deferred probe pending: qcom-snps-eusb2-hsphy: failed to get repeater")
<\[m]>
steev: good timing !
<\[m]>
at this rate MAYBE I will get one with release of 6.14 🙂
<steev>
d0pefish: is that with jhovold's kernel?
pbsds has joined #aarch64-laptops
<d0pefish>
Yeah, with the same few hacks I needed to get 6.13 working. I guess it's time to start bisecting and trying different ath12k firmwares again :)
<enyalios>
im having a weird problem on my x13s after switching from a vanilla kernel to steevs tree with johan_config
<enyalios>
i mount a remote cifs filesystem from my samba server, and suddenly unicode characters in filenames get all weird
<enyalios>
they dont match between the client and the server anymore, which was never a problem previously
<enyalios>
on the client when i touch 'file1☺' it shows up on disk on the server as 'file1â?º', and when i touch 'file2☺' on the server the client sees 'file2?' in listing and cant read it at all
<maz>
CONFIG_NLS_UTF8?
<enyalios>
i tried making all the cifs kernel params identical between the old vanilla config and the new kernel which is based on johan_config, but im still having this weird issue, anyone have any ideas?
<enyalios>
maz: ill try that
<clover[m]>
Are any of the x elite laptops fanless?
<SpieringsAE>
not that I know of, but the fans on the asus barely spin when running linux so it almost seems fanelss lol
<d0pefish>
Ok, ath12k was easy :) Reverted m3.bin / amss.bin to the versions from linux-firmware (instead of from Windows) and extracted a board that seemed like a close match from board-2.bin with qca-swiss-army-knife and moved it to board.bin
<d0pefish>
This is good, because it's 3 less files from Windows and I can get network purely from the stuff in linux-firmware \o/
<enyalios>
maz: that doesnt seem to have made any difference
SpieringsAE has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
jelly has quit [Read error: Connection reset by peer]
<JensGlathe[m]>
x13s users, do you have this with 6.14 builds?
<JensGlathe[m]>
constantly spamming dmesg, box is working regardless
jelly has joined #aarch64-laptops
jelly has quit [Read error: Connection reset by peer]
chrisl has joined #aarch64-laptops
jelly has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<steev>
have not moved to 6.14 yet
<robclark>
JensGlathe[m]: I guess you'll see that every time the gpu is powered up due to `280807dd4692 drm/msm/a6xx: Print GMU core firmware version at boot` .. konradybcio maybe we only want to print that the first time?
<JensGlathe[m]>
thanks, I was steeling myself to do a bisect already
<JensGlathe[m]>
6.14-rc2 fixes sound on my x13s
<konradybcio>
robclark yeah guess so
<konradybcio>
or we can cache the fw ver and print if it changes
<konradybcio>
or i suppose we only request it once
<konradybcio>
do we have to memcpy it each time?
<robclark>
I'm assuming that the memory we copy it to isn't retained if gmu power collapses
<robclark>
but I guess a question for akhilpo
<robclark>
I guess the fw version shouldn't change unless we request_firmware() again, so printing it once should be ok
<JensGlathe[m]>
dp works but usb doesn’t in this case
<d0pefish>
Looks like suspend/resume is working with the typecover too, before I would resume to a corrupted desktop if I had a graphical environment running
<Jasper[m]>
<d0pefish> "This is good, because it's 3..." <- What do you have left from Windows?
<d0pefish>
Down to 5 files now, ADSP/CDSP/GPU firmware
Triebholz has quit [Remote host closed the connection]
Triebholz has joined #aarch64-laptops
<Jasper[m]>
Isn't basically everything for x1e upstream these days? Except for maybe iris?
<Jasper[m]>
hw video acceleration I mean
<Jasper[m]>
(and the wlan boardfile you already found)
<d0pefish>
I'm not really sure, I should shasum these files and see if I can avoid any more
<Jasper[m]>
I'm pretty sure you can
<d0pefish>
I'll have a look, you've made me wonder now :)
icecream95 has joined #aarch64-laptops
<d0pefish>
I implemented your cabextract idea either way, so now absolute worst case scenario is that user has working wifi out of the box, and just runs a script once connected to download the fw
<Jasper[m]>
If I'm correct the only things you need to fetch using cabextract are the wlan boardfile and the hw video acceleration firmware (once the driver for it lands somewhere)
<Jasper[m]>
The rest should be in linux-firmware
<Jasper[m]>
But others probably know more about that. I only have 8cx gen 3 stuff for now
<d0pefish>
So I was testing 6.13-rc2 with my cabextract'd wlan boardfile and it didn't work with the other wlan firmwares (from upstream), but I noticed that one of the boards inside board-2.bin was a very close match to the hardware ID ath12k was looking for, so if I just pull out that one and name it board.bin, ath12k picks that up and it works
<d0pefish>
s/6.13/6.14
<d0pefish>
I also noticed that the working board file is included in board-2.bin twice with different hardware IDs; same shasum
srinik has quit [Ping timeout: 480 seconds]
<anonymix007[m]>
Jasper: no, not everything. For example, some DSP blobs aren't. And without them the CDSP is completely useless, more so than ADSP, which can i.e. do battery stuff.
<anonymix007[m]>
Actually, these blobs aren't upstream even for 8cx Gen 3
<d0pefish>
Just looking now: adsp_dtbs.elf and cdsp_dtbs.elf from upstream are sha1 matches for what I've been cabextracting, so I can eliminate those two
<d0pefish>
But qcadsp8380.mbn and qccdsp8380.mbn don't seem to be upstream
landwork has quit [Quit: Leaving.]
landwork has joined #aarch64-laptops
landwork has quit []
<anonymix007[m]>
These all are signed per-device at it seems, so you're probably looking at the wrong blobs
landwork has joined #aarch64-laptops
landwork has quit []
landwork has joined #aarch64-laptops
landwork has quit []
landwork has joined #aarch64-laptops
landwork has quit []
landwork has joined #aarch64-laptops
<Jasper[m]>
<anonymix007[m]> "Jasper: no, not everything..." <- > <@anonymix007:matrix.org> Jasper: no, not everything. For example, some DSP blobs aren't. And without them the CDSP is completely useless, more so than ADSP, which can i.e. do battery stuff.
<Jasper[m]>
> Actually, these blobs aren't upstream even for 8cx Gen 3
<Jasper[m]>
Interesting, I never knew that
landwork has quit []
landwork has joined #aarch64-laptops
<Jasper[m]>
I thought most of that stuff already worked? Or is that because Lenovo was trying with the x13s?
<d0pefish>
anonymix007[m]: you're probably right, I have all sorts of things copied all over the place and my head is starting to hurt :)
landwork has quit [Read error: Connection reset by peer]
landwork has joined #aarch64-laptops
landwork has quit []
landwork has joined #aarch64-laptops
landwork has quit []
landwork has joined #aarch64-laptops
landwork has quit []
landwork has joined #aarch64-laptops
landwork has quit []
landwork has joined #aarch64-laptops
<anonymix007[m]>
Jasper: open-source fastrpc library was released just in May and no one, apparently, cares about DSPs anyway
<robclark>
anonymix007[m]: for some devices, the dsp fw is upstream:
<robclark>
umm, it is the same fw that windows uses?
<robclark>
or are you talking about the thing that is executed via fastrpc?
<robclark>
(ie. so we can have AI or whatever on cdsp)
<anonymix007[m]>
It's actually both. These are used by Windows and also executed via fastrpc (on the DSPs that is). I guess I should try that tomorrow, would be interesting to see if it actually works.
pstef_ has joined #aarch64-laptops
pstef has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<icecream95>
robclark: VLC works quite badly on x1e when software decoding... seems that the codec is operating directly on a write-combine buffer
<icecream95>
VLC decodes to a MAP_PERSISTENT PBO, but Freedreno will only use FD_BO_CACHED_COHERENT if MAP_COHERENT is also set.
<icecream95>
I guess (for GPUs that support it) a cached coherent BO should be used for MAP_PERSISTENT as well?
<icecream95>
But there's also a ternary scoping bug in realloc_bo, so VLC would get write-combine even if it set MAP_COHERENT
chrisl has quit [Ping timeout: 480 seconds]
mbuhl has quit [Remote host closed the connection]