ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
<steev> i use firefox esr
<clover[m]> Finally got my little raspberry under control. Had to update the bootloader from early 2020 it was a whole thing...
<steev> heck yeah rpi (jk, i hate them)
<HdkR> How soon until we have a Pi with four Cortex-X3 cores in it?
<HdkR> I'd buy one
harvests[m] has joined #aarch64-laptops
<steev> 2026
<szclsya[m]> probably rpi 8
<clover[m]> it didn't help that vc4 was enabled by default in all of the OSes i was trying to flash, which borked my hdmi output somehow
<steev> though with the jacked up prices, i think the rpi foundation is discovering that people are actually willing to pay more than 35
<steev> clover[m]: ah, yeah that, module.blacklist=vc4
<steev> i have to do that on my one with dsi because when vc4 takes over, it disables the dsi screen and enables hdmi.... sigh
<HdkR> X3 in 2026 would still be quite a boon to Pi users trying to rock Cortex-A72/A53 today :P
<steev> i really can't see a pi user *needing* an X3
<HdkR> Wanting is a strong desire
<steev> i need something to control the lights in my 1br apartment, better throw a quad core x3 at it
<HdkR> no no no, You want a new Pi Zero with Cortex-A510 in it :P
<steev> well i "just had it lying around" :P
<HdkR> haha. Don't look at my pile of boards
<HdkR> But also hopefully with a higher performance zero SoC you would just have piles of those lying around
danielt has joined #aarch64-laptops
rfs613- is now known as rfs613
cmeerw[m] has joined #aarch64-laptops
<steev> bamse: is mdss gonna make it in to 6.0 (since i guess linus doesn't like counting > 20 )
<bamse> steev: no, i didn't get the patches in order in time...so v5.21 it is...or v6.1 i guess
<steev> kk
<bamse> got some pointers to the programming guide for DP as well...so hopefully that will resolve the link training part as well
<steev> nice
<clover[m]> Leo Shen: hmm, when i try to get `linux-x13s` it's still pulling down 5.19.0-rc8-1 instead of 5.19.0
<szclsya[m]> hmm true
<szclsya[m]> lemme check
<szclsya[m]> ah, pacman consider `5.19.0.rc8-1` to be newer than `5.19.0-0`
<szclsya[m]> my bad, I should write rc8 as `5.19.0rc8`
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<szclsya[m]> I'm getting tons of pcie errors on 5.19.0. doesn't seem to be there on previous patchsets
<szclsya[m]> [ 1.816575] pcieport 0006:00:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
<szclsya[m]> [ 1.816576] pcieport 0006:00:00.0: device [17cb:010e] error status/mask=00000001/0000e000
<szclsya[m]> [ 1.816579] pcieport 0006:00:00.0: [ 0] RxErr (First)
psydroid[m] has joined #aarch64-laptops
<steev> szclsya[m]: hm, you can try backing out d6a0dc9d6f28ce9829eaed1d7e17f8b6159fff59
<steev> it's a dtsi change, so you should be able to make dtbs, then point at the newly built dtb file instead of installing the full kernel to test it
<steev> but yeah, looks like thats the one
<steev> that wasn't actually supposed to go in, sorry about that :(
<steev> szclsya[m]: should be a new tag (sorry!)
<szclsya[m]> hmm I can't find this tag on github, but I saw you just redone 5.19.0 branch, so I guess it's good now?
<steev> it should be the same tag
<steev> just a different commit
<szclsya[m]> also no worries, I'd expect some small annoyance when using such bleeding edge branch :)
<steev> bleeding edge will be when -next stuff starts rolling in :D
<steev> i haven't wanted to deal with the pcie patches in it, so i'm still doing 20220722 here :(
<szclsya[m]> what's still missing in -next now? just the pcie patchset?
<steev> quite a bit
<steev> in actual next, the biggest thing missing is mdss
<szclsya[m]> ah...
<szclsya[m]> so we won't even get a framebuffer
<steev> we can patch it, and we have the patches, and they'll be applied, they just, haven't made it yet and won't make the merge window for 5.20, or 6.0, whatever linus decides to number it
<steev> https://github.com/steev/linux/commits/sc8280xp-next-20220722 this is the stuff, on top of 0722, as i said
<steev> but between 22 and 28, a bunch of pcie changes happened
<steev> and it's about to be release time so i'm gonna be busy the next couple weeks and don't wanna poke at it, but eventually a new -next branch will show p
<steev> i'm also gonna try and combine what i have for the c630, flex5g, and thinkpad together for the 5.19 branch
<steev> it's currently 150 patches for the thinkpad, and 199 for the c630/flex5g (and there's some... but probably not all the thinkpad stuff in there) so i just need to see what is what
<steev> i also wanna try to git annotate to point out where the patchsets come from
<steev> jstultz used to do that with his kernel tree, and i always found it helpful to know what i could dismiss and what i could try to play with
<szclsya[m]> nice, thanks for your work
<szclsya[m]> ah I see some GPU bring up in the next branch. does it work?
<steev> or if i knew how the cros tooling stuff worked, where it adds stuff like chromium: or fromlist: or whatever (or maybe whoever is doing it amends the commits)
<steev> no
<steev> you just end up with a black screen (it's booted) and a bunch of smmu faults currently
<steev> you can ssh in though
<steev> oh
<steev> you know what, i might have missed the gpu mem reserving
<szclsya[m]> that would explain the mmu errors!
<steev> the other option is that the firmware we're loading for the a690 isn't actually correct
<steev> which is entirely possible
<steev> suppose i can give it a whirl, and then spin it back to the a660 ones that are in linux-firmware just to see
<steev> robclark: 0x1ff is supposed to give me *all* drm messages no?
<steev> seems like passing drm.debug overrides module blacklisting?
<steev> actually, it seems like module blacklisting is just, ignored... sometimes
<steev> pushed, if anyone else wants to give it a whirl, likely culprit is that i've got the memory stuff wrongs, but idfk that maths
<steev> i just cannot get drm to give me more useful info and i'm likely missing something from my config or something
<HdkR> Interesting, no longer complaining about the smmu thing?
<steev> no it still does
<steev> just that those are the only messages i get from drm
<HdkR> hm
<steev> one last attempt before bed
<steev> maybe i should try reverting the reverts that qzed needed to do
<steev> hm, but i don't think thats it, because i don't have anything deferred
<steev> yeah, didn't help, didn't think it would, anyway, bedtime
<_kbingham> /msg chanserv unban ##iob
_kbingham has quit []
klardotsh has joined #aarch64-laptops
Erisa4 has quit [Quit: The Lounge - https://thelounge.chat]
Erisa4 has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
kbingham has joined #aarch64-laptops
arnd__ has quit []
arnd has joined #aarch64-laptops
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #aarch64-laptops
<robclark> steev: drm.debug=0x1ff should get you a lot of traces.. but might also need loglevel=10 or so?.. and fwiw there is a fromupstream.py script that does the UPSTREAM/FROMGIT/FROMLIST formatting
<steev> ah, i'll try increasing the log level
<steev> later
<steev> oh, i'm a derp
<steev> hm, or not, i do have debug stuff enabled, but maybe not enough
<steev> robclark: even with loglevel 10, it looks exactly like my previous paste
<robclark> not detecting a connected display, maybe?
klardotsh has quit [Ping timeout: 480 seconds]
<steev> definitely possible
<clover[m]> Leo Shen: I see other arch projects separating rc kernels and release kernels as two different packages, maybe due to the roadblock we encountered yesterday. Here is a PR to add rc kernel pkgbuild. You might have to remove existing kernel packages from your repo and re-build and add both. https://github.com/szclsya/x13s-alarm/pull/2
<szclsya[m]> eh the current kernel is only intended for dev works anyway... I don't see a point to separate a dev kernel
<clover[m]> In other news, Replacement x13s came in (left) and it's a bit faster on the benchmarks
klardotsh has joined #aarch64-laptops
Erisa46 has joined #aarch64-laptops
kbingham has quit [charon.oftc.net coulomb.oftc.net]
Erisa4 has quit [charon.oftc.net coulomb.oftc.net]
psydroid[m] has quit [charon.oftc.net coulomb.oftc.net]
harvests[m] has quit [charon.oftc.net coulomb.oftc.net]
javierm has quit [charon.oftc.net coulomb.oftc.net]
abelvesa has quit [charon.oftc.net coulomb.oftc.net]
Erisa46 is now known as Erisa4
_kbingham has joined #aarch64-laptops
HdkR has quit [Ping timeout: 481 seconds]
javierm has joined #aarch64-laptops
abelvesa has joined #aarch64-laptops
HdkR has joined #aarch64-laptops
psydroid[m] has joined #aarch64-laptops
abelvesa has quit [Remote host closed the connection]
abelvesa has joined #aarch64-laptops
harvests[m] has joined #aarch64-laptops