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
hexdump01 has joined #aarch64-laptops
<apple-corps[m]>
Out of curiousity, are the thinkpads the best supported aarch64 laptops regarding linux aside from perhaps the reverse engineered MBPs ??
hexdump02 has quit [Ping timeout: 480 seconds]
<robclark>
hmm, I don't have a thinkpad (I have yoga 7x).. but I think overall x1e stuff is ahead of MBP (not sure what the situation is for hw video decode or camera on MBP) but there aren't that many patches on top of linux-next... the flip side is there are more different devices and some thing depend on per-device dtb
<robclark>
actually having qc+linaro support for linux rather than being 100% r/e certainly helps.. but the per-device dtb situation and the fact that there are a lot more devices can make things harder in a way
<apple-corps[m]>
robclark: I think the asahi team wrote a reverse engineered graphics driver in rust
<robclark>
they did.. I wrote one in C (but a long time before rust existed).. rust is interesting but long path to getting all the dependencies needed to upstream the driver upstream
<robclark>
so in terms of having upstream support, that isn't really an advantage (not to say that I'm not interested in rust.. and happy that they and others are pushing forward with upstream rust support)
<robclark>
but in terms of upstream kernel support, it isn't an advantage yet
<apple-corps[m]>
Yeah it's IMO pretty amazing what they did. But at the same time I feel that Apple should be supporting the Asahi dev work. And then otherwise it makes sense to perhaps use these arm devices that have support from Qualcomm. But I am happy that Asahi exists. I had the opportunity to give it a spin a couple times and it was fun using the platform.
<robclark>
for sure, props to the asahi team.. and what apple has done has been at least interesting.. semi infuriating from the PoV of making system design decisions that only make sense for their closed ecosystem like the 16k page situation, but interesting at the same time because they found a way to optimize for their particular os+hw situation
<robclark>
but qc is closer to becoming boring/normal/just-works
chrisl has quit [Ping timeout: 480 seconds]
<robclark>
and as a kernel+mesa dev that has worked at OS vendors, I like boring/normal/just-works ;-)
<apple-corps[m]>
IMO my device feels like Asahi when I started. Perhaps even less so. I thankfully have some support from Jens Glathe regarding an installation. There is no public installer that works for my device. I don't believe there is a mesa driver for my x1p-4200 available. I perhaps foolishly thought that would be in the pipes and now worry that perhaps a driver won't be provided by qcom or quickly. The sound doesn't work and there are
<apple-corps[m]>
other curiosities what "just works". That is the reason for the inquiry. In the case that I buy a 2nd arm linux laptop. I might try to buy one that is more fully supported.
<robclark>
yeah, purwa (x1/x1p-4x) is missing.. although should be trivial to add support, we just need some help from qc (since there aren't devices w/ android that we can use to scrape the handful of magic regs)
<robclark>
I guess assahi has the advantage of only having like two SoCs to support and small # of devices, so special distro can paper over the end user friction in a way that is harder when you have way more devices
<robclark>
tuxedo has been posting revisions of dts so I guess they will follow thru w/ shipping an x1e laptop without of the box linux support
<apple-corps[m]>
I am happy that Asahi is there for MBP device support. I think apple should support them but that might make it a more compelling product and justify paying the premium for Apple hardware
<apple-corps[m]>
I feel similarly that it would be nice where any arm laptop platform vendor would give linux support as part of their product development and support you engineers whose effort is to make these devices work.
<apple-corps[m]>
I hope that perhaps we see a modern linux phone handset now as qcom has been embracing linux. Perhaps seeing postmarketOS work on something built with a modern process
<robclark>
in terms of volumes to justify NRE I don't hold much hope for modern linux phone handset.. the best we had was n900.. but the improving situation upstream will make it easier for PMOS and users that can unlock their device... and meanwhile as qc/arm expands into the laptop market users won't be getting left behind (compared to the alternate timeline where qc wasn't supporting upstream)
<robclark>
even if device ships with android, if users can put something else on it and live with it, the freedom is preserved
davidinux has quit [Read error: Connection reset by peer]
sibis92 has quit [Remote host closed the connection]
<travmurav[m]>
smoorgborg: thanks! I guess now we need someone else to compare with a different display
eluks has quit [Remote host closed the connection]
eluks has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
jgowdy_ has quit [Remote host closed the connection]
jgowdy has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
davidinux has joined #aarch64-laptops
hexdump02 has quit []
hexdump0815 has joined #aarch64-laptops
davidinux has quit [Read error: Connection reset by peer]
jhovold has joined #aarch64-laptops
Kelsar_ has joined #aarch64-laptops
Kelsar has quit [Read error: Connection reset by peer]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
robclark: I've been eyeing a fairphone 5, it has the display output over usb-c which has been accepted in mainline now I believe, so far they seem at least somewhat upstream it
<SpieringsAE>
I am trying to get one second hand now to try and put linux on
<Jasper[m]>
Z3ntu has been doing well :D
<Jasper[m]>
There's one for sale in Belgium on Tweakers I think, it's 475€ (8/256)
<Jasper[m]>
Been eyeing it aswell, but my current phone works okay still and is better in some ways.
<Jasper[m]>
iirc z3ntu is doing this in his own time with support from fp (which he works for last time I checked). Super impressive
srinik has joined #aarch64-laptops
shawnguo has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
<z3ntu>
Jasper: thanks for the compliments! Keep your phone until it breaks, then you can get one ;)
<z3ntu>
Jasper: and basically all FP4 & FP5 work is done on company time, I can spend 1 day per week on these things
<Jasper[m]>
I could've sworn you were around here, should've checked the government name :D
<Jasper[m]>
Good of them to see the value in upstreaming.
chrisl has quit [Ping timeout: 480 seconds]
<Jasper[m]>
Even if it isn't an fp5, your tree would theoretically help out with getting my book2go (sc7280) to boot so that's nice
<Jasper[m]>
Just need to find the time to work on it
<z3ntu>
I think SoC-wise basically everything from regular functionality is supported upstream nowadays, camss also went upstream recently by Qualcomm themselves
<z3ntu>
that was part of the original chromebook effort
<Jasper[m]>
Ahh right, firmware too? Or is that at Fairphone's, and by extend qcom's, decision?
<smoorgborg[m]>
<travmurav[m]> "smoorgborg: thanks! I guess..." <- It does seem suspicious that it returns all zeroes?
<SpieringsAE>
Jasper: that is the one I am trying to get yeah haha, no response yet from them
<SpieringsAE>
z3ntu: thanks for your efforts! Really admire it, working on more mainline linux support at my company too
<SpieringsAE>
Jasper: my current phone is an oppo a73 5g which has been left in the dust at android 10, would love to get something with more permanent support, which mainline linux support is key too in my opinion
<z3ntu>
Jasper: I think some semi-generic venus firmware should be in linux-firmware but for FP5 the firmware is signed with Fairphone's keys due to secure-boot-on, and we haven't been able to get any reply to requests to Qualcomm to attach any sort of explicit redistributable license to the binaries we build
<Jasper[m]>
At least you can point to Lenovo as far as precedent goes
<SpieringsAE>
gpu firmware is also signed? couldn't find that one in linux-firmware either. I guess those are kind off in the same boat
<travmurav[m]>
smoorgborg: it is but zero is a valid number in the code, so can't just say it's broken...
<travmurav[m]>
There is also a lot of space for me misinterpreting the decompiled aml code I guess
<travmurav[m]>
But I have an impression that at least the structure address should be stable between the t14s-es
Italiana22 has joined #aarch64-laptops
Italiana22 has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
alexeymin has quit [Ping timeout: 480 seconds]
alexeymin_ has joined #aarch64-laptops
<z3ntu>
SpieringsAE: zap firmware mbn is signed, but e.g. *_gmu.bin & *_sqe.fw used by some GPUs is not signed
SpieringsAE has quit [Remote host closed the connection]
<smoorgborg[m]>
travmurav: if you want me to dump another location with a known non zero value to validate the offsets lmk
<travmurav[m]>
hmmmm
<travmurav[m]>
smoorgborg: do you have a touchscreen option?
<travmurav[m]>
travmurav: "dmem d6cf6374 78" would dump few fields below the display one and should include VID/PID of hid-over-i2c devices such as touchscreen
<travmurav[m]>
but also uhm
<travmurav[m]>
it's possible I /did/ misinterpret everything...
<travmurav[m]>
so one moment
<smoorgborg[m]>
no touchscreen, unfortunately not offered with oled
f_[m]|OLD has left #aarch64-laptops [User left]
<smoorgborg[m]>
also no wwan because i'm a cheapskate
f_ has left #aarch64-laptops [#aarch64-laptops]
<travmurav[m]>
smoorgborg: would you be able to do `dmem d6cf5f2c 96`
craftyguy is now known as Guest11730
craftyguy has joined #aarch64-laptops
<travmurav[m]>
I misunderstood the struct layout and calculated byte offset where they should've been bits so last check we did was wrong, but this would include the panel thing and all the vid/pid things too
Guest11730 has quit [Ping timeout: 480 seconds]
<travmurav[m]>
hopefully one of those is touchpad
<smoorgborg[m]>
I'll do that in 3 hours when I get back to the machine
<travmurav[m]>
cool
<smoorgborg[m]>
thanks for helping :-)
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
bibikski has quit [Remote host closed the connection]
<travmurav[m]>
unless they use the same value for the other thing xD
chrisl has quit [Ping timeout: 480 seconds]
<travmurav[m]>
yeah I think all other xml define backlight type 1 so pmic pwm
<travmurav[m]>
and I guess this is whatever edp aux control
ungeskriptet has quit [Remote host closed the connection]
<travmurav[m]>
but cool, assuming the struct base address and layout is stable (i.e. assuming lenovo would be too lazy to change it), we most likely have a heuristic for both picking oled vs ips /and/ for picking correct touchpad/touchscreen if the thing needs it
ungeskriptet has joined #aarch64-laptops
<craftyguy>
jhovold: FYI I haven't seen any errors the last few days w/ your patch on rc6, I'll try your rc7 now. sorry for the delay, I've been a bit distracted :P
tudorel has quit [Quit: WeeChat 4.3.1]
<jhovold>
craftyguy: np, thanks for testing, just keep an eye out for ath11k unexpected length messages with rc7
<jhovold>
I'm thinking it's completely fixed, but want to be sure
<craftyguy>
ok will do :)
<steev>
now we just need to figure out the mdsu_bit not set in attention or whatever (i patched it out of my kernel because i was tired of the spam)
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<craftyguy>
yeah... I should patch that out too. it's quite annoying :P
<steev>
i'd dig into it, if the warning message made any sense to me, but i have no idea what it is even trying to say, aside from a bit isn't set
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
sally_ has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
sally has quit [Ping timeout: 480 seconds]
jhovold has quit [Ping timeout: 480 seconds]
hogliux has joined #aarch64-laptops
<hogliux>
@anthony25: I've had the same issue with the GPU freeze that you're having. For me it happens randomly (about 1-2 a week) in VS code when VS code attempts to open a code completion popup.
<hogliux>
@anthony25: It's been driving me insane. I'm on tobhe's Ubuntu 6.14.0-20-qcom-x1e kernel. But it's happened on all other kernels (jhovold's etc.).
<anthony25>
Without ACD?
sally_ is now known as sally
<anthony25>
Is it GPU lockups too, or is it because of wifi freezes?
<hogliux>
@anthony25: if you search my name on IRC you'll find me complaining about this every now and then. It's only GPU lockups. I mostly have WiFi disabled (i have an ethernet dongle).
<hogliux>
The whole machine freezes and will force reboot after 20-30 seconds
<hogliux>
The only workaround I've found so far is to open VS code under Xnest
<robclark>
hogliux: got dmesg?
<hogliux>
I can't get to the dmesg because the whole machine is frozen
<robclark>
fwiw I use vscode pretty regularly (both on internal and external display)
<robclark>
can you ssh to it? Or `journalctl -b -1` after reboot
<hogliux>
Nope. I even tried streaming dmesg'es to a remote computer.
<hogliux>
Nothing shows up. It's a complete lockup. I can get it to happen more often if I stress switch between virtual consoles and then switch back to vscode and start typing.
<hogliux>
Then often the next code completion will lock everything up. @anthony25 do you get dmesg'es when your GPU locks up? Does your laptop also force reboot after about 30 seconds?
<hogliux>
For me it's the same type of lockup I get if I run qemu without the kernel cmdline argument `id_aa64mmfr0.ecv=1`. maz mentioned that this indicates it's a firmware crash.
srinik has quit [Ping timeout: 480 seconds]
<robclark>
shouldn't really be too much fw related.. I'm wondering a bit about https://gitlab.freedesktop.org/drm/msm/-/issues/33 which has been a problem with electron things in the past.. maybe if dpu devcoredump tries to snapshot some registers which fw blocks it could trigger a reset
<hogliux>
@anthony25: this is not the type of crash you are seeing?
<hogliux>
@robclark: hmmm i think i've hit that issue separately i think on wayland with chrome. But it didn't lockup the whole machine. Just super sluggish. Is there a way to manyally trigger dpu devcoredump to confirm that this is the type of crash I'm seeing?
<hogliux>
@robclark: and dpu devcoredump would not write something to dmesg first? I'm seeing nothing in dmesg.
<hogliux>
@robclark: I don't have an external display so not sure if it's an issue you there.
hogliux has quit [Quit: Leaving]
<robclark>
you should see something in dmesg, but possible it doesn't get flushed to disk in time
<anthony25>
hmm so that might be different
<anthony25>
I don't get a full freeze, for me it's only the GPU, I can ssh the laptop and everything else is working fine
<robclark>
yeah, anything that triggers insta-reboot sounds like something different
hogliux has joined #aarch64-laptops
<hogliux>
Thanks. Yeah not really insta. More like after 30 seconds. It's exactly the same kind of freeze and reboot when f
<hogliux>
firmware crashes with qemu
<hogliux>
Yeah but anthony25's bug definitely looks different
<hogliux>
I'll need to figure out a way to more reliably reproduce this
hogliux has quit [Remote host closed the connection]
<anthony25>
hogliux: no, in my case the laptop can stay this way indefinitely, just the video output is frozen
<robclark>
I'm not sure how it could be related to reboot, but https://patchwork.freedesktop.org/series/143686/ helps recovery from gpu faults, prior to that you could get in a situation where the gpu was wedged until you reboot.. which was more problematic with older mesa versions, but I wouldn't expect you to hit that with v24.3.x and newer