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
<steev>
this is typically for arm64 laptops, there are arch users here but you might want #archlinux on liberachat
* abby
curses whoever decided aarch64 would be the name for 64bit arm
<BlueCrayon>
ok
<BlueCrayon>
Is Arch easy to install?
<BlueCrayon>
Lenovo laptops, generally?
<abby>
probably a question for #archlinux on libera
<BlueCrayon>
Really?
<BlueCrayon>
Libera doesn't work when I try to join it 50% of the time.
<BlueCrayon>
abby: Are you a user of all distros?
<abby>
no, just one
<steev>
i've never had any particular issues following the arch documentation. i usually check the wiki (or just use a search engine for any possible gotchas with specific hardware)
<agl>
long time test: After 4 days i upgrade Debian (234 packages) and reboot. In this 4 days all works. After upgrade all works.
<agl>
Begin of next long time test: 10. August 2024 3:00, kernel 6.10.2-steev
<steev>
did i not push 6.10.3?
<agl>
moment I see ...
<steev>
i may not have
<agl>
Oh yes, since 3 days you have generated 6.10.3
<steev>
yeah, i just pushed it
<steev>
the only difference is v3 of bryanodonoghue
<agl>
I will compile and install it ....
<steev>
's rgb sensor for the webcam but i'm not entirely sure it works with 6.10, i just pulled it in for completeness in the dts
<agl>
ok
<agl>
steev: Is it necessary to use the new johan_defconfig. I have a .config from 6.10.2.
<steev>
no, you can drop your 6.10.2 config into the directory as .config
<agl>
Begin of next long time test: 10. August 2024 3:29 CEST, kernel: 6.10.3-steev, Distribution: Debian/testing
<agl>
Good night
shadow2 has joined #aarch64-laptops
shadow2 has left #aarch64-laptops [#aarch64-laptops]
<BlueCrayon>
ool
<BlueCrayon>
lol
louist103 has joined #aarch64-laptops
<louist103>
Alright. Firefox is up and running. That leaves only two more things until I think this is good to daily drive... Audio, which seems to be in progress, and the wifi. I noticed its a bit unstable when there is a lot of data being transferred.
<louist103>
Things like this seem fine. But I noticed some instability when emerge was downloading firefox and when I tested youtube
louist103 has quit [Remote host closed the connection]
<steev>
wifi seems fine on my c630, though crashes on shutdown :D but they're gone
<travmurav[m]>
Jens Glathe: "bsod" as in kernel oops/panic or as in "purely blue" picture on the whole screen?
<travmurav[m]>
(idk if modern things still fallback to blue in hardware when mdp underflow happens)
hexdump01 has quit [Read error: Connection reset by peer]
hexdump01 has joined #aarch64-laptops
<bamse>
travmurav[m]: to my knowledge that's still the mdp underflow color...
BlueCrayon has quit [Ping timeout: 480 seconds]
<travmurav[m]>
I recently saw someone with very modern sm8??? thing having a failure condition of "repeated pink to white gradient" after touching incorrect memory or something like that, so wasn't sure if something has changed :D
<bamse>
fancy
<bamse>
i try my best to not summon the blue pixels...so i might be wrong, but gradients or other artifact are generally caused by other badness
<louist103[m]>
<steev> "wifi seems fine on my c630..." <- Its weird because I had the exact same issue the last time I did this and I did a lot of things different. The only thing that may be the same is the `firmware-5` file.
<louist103[m]>
And I don't think its a hardware issue cause this is a different machine. Unless its a hardware bug.
<travmurav[m]>
tbh I think ath10k crashes on shutdown for me too, and did it since forever
<travmurav[m]>
on 7c that is
<louist103[m]>
Now that I am looking closer, I am trying to shut it down and it is giving "ufshcd-qcom 1d84000.ufsch: ufschd_wait_for_doorbell_clr: timedout waiting for doorbell to clear" over and over
<louist103[m]>
I may have typed that wrong since I can't copy and paste from a shutting down system.
<steev>
nah, you're right
<steev>
i get that like every few shutdowns as well, no idea what causes it
systwi has joined #aarch64-laptops
<JensGlathe[m]>
<travmurav[m]> "Jens Glathe: "bsod" as in kernel..." <- 😆 completely blue, practically unrecoverable. Need to reboot then.
<JensGlathe[m]>
what is mdp underflow
<travmurav[m]>
yeah then I guess something horribly dies and as a side effect, mdp hits underflow and shows blue error condition
<travmurav[m]>
nothing sends the image data to the display engine to output
<JensGlathe[m]>
sounds like a case for drm.debug=0x1ff, proveke it, clean shutdown, have a look
<travmurav[m]>
well my guess would be that if it's "unrecoverable" then everything might as well be dead, not just the display
<travmurav[m]>
but still worth a try I'd guess
<JensGlathe[m]>
oh with bsod I can remote in and do stuff, it's a bit slower, but works. And you can shotdown or reboot
<travmurav[m]>
oh interesting
<travmurav[m]>
could try enablling drm debugging at runtime after it exploded
<travmurav[m]>
or maybe there is some hung-dead cores if you say it's slower?
<JensGlathe[m]>
how would I see this
<travmurav[m]>
linux would complain about rcu stalls in dmesg and you will see i.e. in htop that one of the cores gets exactly zero utilization
<JensGlathe[m]>
will do a test after breakfast
<travmurav[m]>
but you say it explodes in normal operation but if you run in el2 it's fine? xD
DeepGaurav[m] has joined #aarch64-laptops
srinik has joined #aarch64-laptops
<JensGlathe[m]>
yes that's the odd part
<JensGlathe[m]>
on EL2 I don't have ZAP firmware loaded, and then it doesn't seem to happen
<travmurav[m]>
zap shouldn't matter
<travmurav[m]>
My loose guess would be that i.e. qcoms hyp dies and iommu emulation breaks => mdp can't read memory to get image data anymore
<JensGlathe[m]>
whatever else is in this firmware. I have normal operation on 2,5k@60 in EL1 and EL2
<JensGlathe[m]>
hmm but it doesn't on Windows
<JensGlathe[m]>
its working there
<travmurav[m]>
Well windows also "runs in el2" xD
<JensGlathe[m]>
fair point
<JensGlathe[m]>
There were versions of the kernel (up to ~6.6) where this worket though
<JensGlathe[m]>
ok display is suspended in 4k, dmesg is still running like mad
<JensGlathe[m]>
bsod is on
<JensGlathe[m]>
only drm_debug messages
<JensGlathe[m]>
htop looks normal (all cores have sth to do)
<bryanodonoghue>
steev just run "qcam" assuming you have libcamera > 0.3.0
<bryanodonoghue>
should just work
<Molyuu[m]>
After I switch to pmOS'
<Molyuu[m]>
* to pmOS's kernel, my device's keybord work now, but still won't boot if I enable ADSP.
<Molyuu[m]>
I supposed that might be caused by incorrect reserved memory for adsp. I'm trying to know how Windows set it up, I only found ADSP's length and align in registry (SubsystemLoad), is there any way to know where the region of ADSP and other subsystem is?
<Molyuu[m]>
s/supposed/suppose/
<travmurav[m]>
the remoteproc binaries should be relocatable as long as the load address is aligned, don't believe there are any non-relocatable firmware on qcom nowdays...
<Molyuu[m]>
That means I can put it anywhere in PIL Region? Just make sure the address is aligned, right?
<travmurav[m]>
probably anywhere outsize pil region too but probably want to make sure it's in whatever uefi already reserves (if it does) so you don't waste more ram
<travmurav[m]>
but more importantly, what's the device your'e working on, again?
<Molyuu[m]>
Xiaomi Book S 12.4 (SC8180XP)
<travmurav[m]>
right, and I guess you're using the firmware blobs from it's windows install?
<Molyuu[m]>
Yes
<travmurav[m]>
and "doesn't boot" == crash early in boot I guess?
<travmurav[m]>
I wonder if it just resets the usb power like all other modern qcom laptops which have adsp control usb stuff
<travmurav[m]>
but I guess this would imply you boot from usb
<travmurav[m]>
(do you? :D)
<travmurav[m]>
if you do, may want to place the firmware into initramfs to make sure adsp resets before you start mounting the fs
<Molyuu[m]>
Yes I'm booting from usb. As what I can know is it boots into init process, and system halted later, neither systemd nor openrc init records any logs.
<Molyuu[m]>
s/./ in /var/logs/
<travmurav[m]>
what if you remove firmware blob, boot, place it back and write sysfs entry to start the adsp manually?
<travmurav[m]>
but if it's modern qcom + adsp + usb I'd guess it's the usb reset problem and your boot disk just disappears when adsp loads because of that
<Molyuu[m]>
Is is normal that screen display nothing when I disable adsp? (using simple-framebuffer)
<Molyuu[m]>
I'm sure it boots as I can connect to device thorugh SSH (UNDIS USB network).
<travmurav[m]>
jdb: Amazing, thanks! What should I put as name/email to credit you?
<jdb>
Jérôme de Bretagne <jerome.debretagne@gmail.com>
<robclark>
JensGlathe[m]: underflow should trigger a display devcoredump.. I use this script to collect gpu devcore dumps but should work for display as well...
<robclark>
(the display devcore won't mean much to me but I think abhinav__ or perhaps bamse or lumag would have a way to decode it)
<robclark>
JensGlathe[m], travmurav[m]: I guess one diff btwn el1 and el2 is two vs one stage of smmu translation.. idk if it is possible that makes enough of a diff in bandwidth to cause underflow at higher resolutions?
<jdb>
I have made quite some progress on the Surface Pro 9 5G devicetree, the previous ARM-based Surface generation running on the sc8280xp (Snapdragon 8cx Gen 3), I wonder how far I am from proposing it upstream
<travmurav[m]>
jdb: hm, somehow I'm failing to find where is the kernel tree with the dts, would you mind sharing a link (or letting me know the dts name that you are using)?
<jdb>
If anyone curious, I would be happy to get some comments / early reviews, here is the main devicetree I've used to boot the MS SP9 5G:
<jdb>
konradybcio: ^ it would be great to have your input too, as you've worked on the Surface Laptop 7 devicetrees recently
<travmurav[m]>
jdb: pushed, thanks!
<jdb>
travmurav[m]: you're welcome!
<jdb>
I'm really eager to see the Linux ARM ecosystem move to a better approach to load the correct devicetree
<travmurav[m]>
jdb: fwiw I think one of the best ways to get reviews would be to just send the patch upstream :D, especially since i.e. Konrad is one of the upstream reviewers for qcom
<jdb>
konradybcio: for instance, should I rename the devicetree to microsoft-arcata, as you've named yours microsoft-romulus?
<jdb>
Yes, that was one of my thoughts :-) but I was wondering if there were some obvious changes to include earlier on based on a first look
<jdb>
I've hit some limitations based on my limited reversed engineering currently, I can enable the
<travmurav[m]>
jdb: but if you want, you can create a PR within your fork and I can give you few comments using the GH review ui
<travmurav[m]>
(so to not spam chats or leave comments on commits which are hard to track)
<jdb>
GPU to get external display working (only on the bottom USB Type-C port) but I can't get the built-in display to work then...
<jdb>
Otherwise, I pass module_blacklist=msm to get the built-in display working but then I can't plug-in an external monitors
<jdb>
this is the kind of investigations I would like to progress on before sending a first patch upstream
<travmurav[m]>
jdb: aactually I think there is only one obvious nit I see
<jdb>
travmurav[m]: thanks for your PR proposal, should I create the PR into one of my own projects?
<travmurav[m]>
pinctrl-names like any *-names should go last after *-0 *-1
<travmurav[m]>
so if you fix that, I don't see anything else obvious that would've been brought up upstream
<jdb>
thanks, interesting feedback, it must have changed in the recent months as it was in the same order in the sc8280xp-crd.dts at the time I started working on this (based on Linux v6.7)
<travmurav[m]>
yeah it was a somewhat recent rule to mandate putting all -names last (it was customary for everything else with names but not pinctrl-names before)
<travmurav[m]>
ah also after name/compatible you can put chassis-type
<travmurav[m]>
s/name/model/
<travmurav[m]>
otherwise I think that dts looks pretty clean, good job!
<jdb>
Great :) Your points are easy to fix. Thanks a lot travmurav[m] for your review !
<travmurav[m]>
np, looking forward seeing this on the lists and later upstream :)
<travmurav[m]>
jdb: hm do I remember correctly that ms devkit is just surface pro 9 mainboard in a funny box, or that was a different surface mainboard?
<jdb>
the 2 devices are based on a very similar hardware indeed, but the external ports are not the sames ones at all
<travmurav[m]>
I somehow recall it was the same mainboard but MS made adapters for the ports as a separate boards connected to it
<travmurav[m]>
but I'm askign because Jens Glathe has a tree for that devkit
<jdb>
I'm aware, I've taken inspirations / hints from all the sc8280xp devicetree files available
<travmurav[m]>
it would've been ideal if two devices could be commonized together via a dtsi for upstream but original devkit contributor didn't leave signed-off-by and went MIA afaiu, so those commits are stuck a bit :(
<jdb>
I've read that in the chats previously; in fact I should have joined much earlier as I'm enjoying the discusions and the great mindset around these projects for a while now
<jdb>
travmurav[m]: the original MS devkit contributor was Merck Hung (merckhung), if I remember correctly, right?
<travmurav[m]>
robclark: wrt iommu bw, I doubt 1 vs 2 stage would make a difference since I'd hope iommu would just read TLB with "complete" translation data most of the time in both cases
<travmurav[m]>
jdb: I thinks so, yeah
<travmurav[m]>
(iommu) ... that is, I think it only matters when it needs to do a page walk to save into tlb
<travmurav[m]>
robclark: Jens Glathe on the other hand, when you use slbounce, you will have mdss set to bypass iommu completely which I'd guess is not the case in el1
<travmurav[m]>
dunno if then it would be some funny physical vs virtual memory space issue
<robclark>
maybe something about icc is different? underflow does seem to imply a bandwidth issue
<travmurav[m]>
(if it's even related to buffers managed by os)
<travmurav[m]>
perhaps but I'd hope hyp doesn't manage that lol
<jdb>
it's surprising that he wouldn't agree to put a signed-off-by, especially as devicetree sections are mainly hardware descriptions
<travmurav[m]>
... but I'd hope hyper-v in windows properly sets iommu for mdss so that won't explain why it works in el2, windows but not in el1
<jdb>
on my end, coming back to the Surface Pro 9 5G, I would still like to investigate why I can't get the builtin display to work. I've tried reusing the edp entries from the CRD and from the Lenovo ThinkPad X13s devicetrees, but without success so far, I always get a black screen
<travmurav[m]>
any chance it's mipi not edp?
<travmurav[m]>
but I guess devkit uses 4 lane edp for it's primary output
<travmurav[m]>
does linux detect that the screen is there via dp aux?
<jdb>
about mipi vs. edp, I don't have any schematics so it's just pure guess work (and it's getting annoying and old very quickly...)
<travmurav[m]>
I think there should be an xml file in dsdt that describes the display
<jdb>
I can see that the Surface Laptop 7 are using edp so I'm hopeful that they were using the same approach on the previous Surface Pro 9 5G
<jdb>
in the dsdt, there are 2 references to following panel : AUO 1080p eDP Video Mode Panel(1920x1080 24bpp) / B133HAN05.3
<jdb>
it's confusing to me though as the SP9 5G has a 2880x1920 resolution
<travmurav[m]>
might be wrong ^C^V
<travmurav[m]>
(or acpi is a total mess on those devices and windows has to override even this in the driver lol)
<jdb>
I remember that when I kept the eDP entries in the devicetree, I didn't see any error / warning messages in dmesg so I didn't know how / where to investigate further
<jdb>
I should certainly give it another try though, it's a few months old already
weirdtreething has joined #aarch64-laptops
<travmurav[m]>
but to me the xml feels similar to what x13s would have
<travmurav[m]>
(funnily the name of the xml is the same as well)
<travmurav[m]>
so perhaps they just copied it as is from some reference design because who cares and timings are read from edid anway
<JensGlathe[m]>
they are eerily similar
<JensGlathe[m]>
even by hw id of WLAN
<travmurav[m]>
jdb: so I'd guess setting up the panel and pmic based backlight like on x13s "should" work, if I've read the xml correctly and the power regulators are enabled by the bootloader
<jdb>
robclark: should I see / look for some specific error messages when the builtin display switches off after boot, when I enable the x13s entries in my SP9 5G devicetree?
<jdb>
or is there a way to read / query the edid even if the display is not working / supported upstream yet?
<travmurav[m]>
edp should autodetect the screen when generic edp panel driver is used, as long as the panel talks to the soc
<travmurav[m]>
unless that panel is //special// and need some custom driver I guess
<travmurav[m]>
like on those funny new x elite laptops with oled screens
<travmurav[m]>
(but even in that case generic driver half-works afaiu)
<robclark>
if the panel is powered up you should be able to read EDID.. if it is an OLED panel, have a look at samsung,atna33xc20, the samsung panels seem to have a different power sequence
<jdb>
nope, it's not OLED on this previous Surface Pro tablet
<travmurav[m]>
jdb: I wonder if it's just backlight missing
<travmurav[m]>
but I assume you've copied that too? (as well as enabling lpg/pwm stuff in the pmic)
<robclark>
hmm, ok.. if not OLED I'd expect panel-edp to work.. but yeah, maybe it is working but backlight is not
<travmurav[m]>
inb4 shines a flashlight into the panel and can see the image
<jdb>
:)
<jdb>
it was a long time ago, I will give in another try in the coming days / weeks
<jdb>
thanks all! I plan also to switch to a more recent Linux version anyway as I did all my devicetree guess work on Linux v6.7, many changes have landed since
<jdb>
if anyone at Linaro / Qualcomm has some pointers to help me improve my SP9 5G devicetree, I'll happily take any suggestions
<JensGlathe[m]>
steev: you asked re "Framebuffer is not in virtual address space." Interesting.
<JensGlathe[m]>
It is commit b3e8813773c568fd2d65e9752abfda27442e502e fbdev: Warn on incorrect framebuffer access
<steev>
weird... somehow at some point i'd masked user@108... which, user 108 was Debian-gdm which is what gdm runs as, and that seems to have been the cause of my issues
noferrets[m] has joined #aarch64-laptops
BlueCrayon has joined #aarch64-laptops
<steev>
there is one down side to the non-working audio on c630, and that is it seems to block suspend from working :/