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
<clover[m]>
rooms have been upgrading on matrix to version 12 lately so just curious. we might need to do that here too, not sure who the matrix admins are for this room
eluks has quit [Remote host closed the connection]
eluks has joined #aarch64-laptops
jglathe_volterra has joined #aarch64-laptops
<steev>
same, sure, some spam comes in from matrix, but it's the price we pay so the kiddos can have their fancy emojis in their comments
<amstan>
<clover[m]> "i think security reasons, here's..." <- I don't even think i can actually, since oftc bot is the only admin here
<amstan>
also, that attack vector is really not applicable here, not like we have multiple admins
<strongtz[m]>
Val Packett: The pcie2a controller in sc8280xp needs to have a MMIO64 window, and in fact, it does. Just add this line to the pcie2a node in sc8280xp, then it will work.
<mmediouni[m]>
<strongtz[m]> "arch/arm64/boot/dts/qcom/sa8540p..." <- Note that Makena automotive is B0 while Makena sc8280xp is a0. But it's just different steppings of the same chip
<strongtz[m]>
Yeah I doubt that the MMIO64 window is specific to that sa8540p board
<HdkR>
Would have been nice for the Snapdragon Dev Kit's PCIe slot to have been available to do the same :D
<valpackett>
<strongtz[m]> "Val Packett: The pcie2a controll..." <- that's all? so mapping pcie bars as normal memory (ioremap_wc) just works on qcom? so many SoC vendors have screwed that up in various ways
<strongtz[m]>
Yeah, no kernel patches :)
<valpackett>
let's goooo this is literally the year of the qualcomm desktop (or at least of me becoming a qcom fangirl)
<HdkR>
I would love a platform to replace my current ARM+Radeon dGPU setup :)
<valpackett>
I'd love to just run a thunderbolt eGPU dock for gaming.. the Adreno is okay for not-so-intensive titles but I wanna play a couple AAAs sometimes too :)
<valpackett>
just to confirm @strongtz:matrix.org you have checked graphical workloads too, not just compute, right?
<strongtz[m]>
Val Packett: haven't check, let me take a look
<\[m]>
clover amstan I think public rooms admins were kindly waiting for the self-hosters to catch up but eg. my distro (yunohost) has done the necessary like more than a month back ++
<\[m]>
might be ok now, afaict you run 1 command with OP +
<\[m]>
strongtz that's connected how? neato
<\[m]>
steev
<\[m]>
> same, sure, some spam comes in from matrix, but it's the price we pay so the kiddos can have their fancy emojis in their comments
<\[m]>
funnily I have to put up matrix bridges to at least 3 other messaging services to talk to people that swear by stickers and gifs 🙂
<strongtz[m]>
connected to the m.2 slot of an unreleased product :)
<\[m]>
mysterious, kudos nonetheless !! that's the modem m2 connector then?! since disk is not pcie? or is it??
<steev>
I was just joking, I really don’t care what people are using to chat as long as collaboration is happening and people aren’t all off in silos
<\[m]>
(should ve read more oops)
<\[m]>
last time i used irc was when you could download from bots there tbh
<\[m]>
I hope you can make a write up of what you described in a blog or so? I want magic too 🙂
<\[m]>
ooooh new oryon soc?
<JensGlathe[m]>
Look at the time
mosasaur has joined #aarch64-laptops
Grabunhold_ has joined #aarch64-laptops
Grabunhold has quit [Read error: Connection reset by peer]
tobhe has joined #aarch64-laptops
tobhe_ has quit [Ping timeout: 480 seconds]
Gnappo85 has joined #aarch64-laptops
pbrobinson has quit [Ping timeout: 480 seconds]
<steveej[m]>
are there any fanless aarch64 laptops that support virtualization on linux?
<travmurav[m]>
all of fanless qcom, if you don't mind it being a mess? :P
<tobhe[m]>
My m2 air does
<steveej[m]>
travmurav: meaning i can have fast VMs on the thinkpad x13s today if i get the right software set up?
<steveej[m]>
my use-case is running nixos integration tests locally which by default use qemu.
<travmurav[m]>
for now the only limitation is missing remoteprocs (so no fuel gauge) but hopefully that will be fixed too in a reasonable amount of time
jkaczman has joined #aarch64-laptops
Gnappo85 has quit []
Gnappo85 has joined #aarch64-laptops
Gnappo85 has quit []
mosasaur has quit [Quit: Leaving]
ravikant_ has quit [Ping timeout: 480 seconds]
jkaczman has quit [Read error: Connection reset by peer]
jkaczman has joined #aarch64-laptops
icecream95 has joined #aarch64-laptops
<abelvesa>
anyone having issues with any of the combo PHYs timing out in init, on x1e devices ?
<abelvesa>
s/out in init/out on init/
<angeloverlain[m]>
wonder why less of y'all don't try alpine linux. unlike arch linux, it supports aarch64 (and hf,v7) and it's package build format (APKBUILD) is very similar to arch's (PKGBUILD)
pbrobinson has joined #aarch64-laptops
<deathmist>
angeloverlain[m]: probably because they want/need systemd or like the convenience of a typical GNU/Linux (glibc) without workarounds? people have preferences lol there's no point in asking "why isn't everyone using X". I boot Chimera Linux on my X1E Vivobook and it's the same kinda deal but it strays even further by replacing libstdc++/libgcc as well etc
<tobhe[m]>
also there are plenty of postmarketos users here which is based on alpine
ravikant_ has joined #aarch64-laptops
<anthony25>
Also, for a desktop usage, I don't find Alpine being great (it misses quite some things)
<steveej[m]>
travmurav: what do i lose without remoteproc in practical terms? e.g., bluetooth, wifi, displayport support via usb-c, etc.?
<travmurav[m]>
steveej: battery monitoring, stuff related to type-c alt modes
<travmurav[m]>
sound of course
<travmurav[m]>
since all of that is due to adsp not being booted anymore
<steveej[m]>
i see. well i do need the type-c alt modes as i'm using the device as a daily driver with an external display. so unfortunately slbounce is not an option
<deathmist>
couldn't you re-use adsplite boot fw like on X1E?
<deathmist>
still not perfect must mostly gets you there, maybe it'd also work on X13s
<travmurav[m]>
the adsplite works differently on 8c3 so it's not as easy, but this problem will be solved eventually
zdykstra has quit [Ping timeout: 480 seconds]
pbrobinson has quit [Remote host closed the connection]
pabs has quit [Read error: No route to host]
pabs has joined #aarch64-laptops
Gnappo85 has joined #aarch64-laptops
zdykstra has joined #aarch64-laptops
hightower2 has joined #aarch64-laptops
hightower3 has quit [Ping timeout: 480 seconds]
Gnappo85 has quit []
Gnappo85 has joined #aarch64-laptops
Gnappo85 has left #aarch64-laptops [#aarch64-laptops]
<anthony25>
I mean yeah, the move to 6.17 in the concept PPA, but a lot of patches were already backported to 6.14
<robclark>
firmware update?
<bamse>
perhaps they had the 100% cpu-usage from wifi-driver enabled back then?
<robclark>
heh, or that
<abby>
anyone seen issues with 6.16.1 or later and gpu on x13s? latest linux-firmware, mesa 25.1.9 works fine (uses freedreno) on 6.16.0 but uses llvmpipe on 6.16.1 or later
<robclark>
there was that mdt_loader bug.. which was backported to v6.16.4 but I don't think earlier?
<abby>
i've seen this on .5, zdykstra has seen it as early as .3
<robclark>
the error looks similar to that mdt_loader issue.. not sure if distros/etc had also cherry-picked the problematic patch earlier or something?
<bamse>
sounds quite likely
<abby>
void doesn't cherrypick stuff, we use kernel.org tarballs
<bamse>
i did get the notice from greg that the fix is being pulled into stable, don't know if that's out yet...
<bamse>
-rc5 has the fix
<abby>
the fix being that linked patch?
<bamse>
yeah
SpieringsAE has quit [Quit: SpieringsAE]
<robclark>
I guess if you don't need that fix, then you'll know because the patch doesn't apply cleanly
pbrobinson has quit [Ping timeout: 480 seconds]
jkaczman has quit [Remote host closed the connection]
icecream95 has quit [Ping timeout: 480 seconds]
ravikant_ has quit []
sally has quit []
sally has joined #aarch64-laptops
<abby>
robclark: that was it, thanks
<robclark>
np
<nirik>
Has anyone investigated/bisected the qcom-battmgr breakage in recent kernels yet?
<minecrell>
steveej[m]: I’ve been working on a tool to start the remoteprocs from uefi even on X13s (similar to the lite firmware on X1E). Not entirely done yet but it should solve those issues
<steveej[m]>
minecrell: that is awesome, thank you! where can i follow your work?
<minecrell>
steveej[m]: I can try to ping you here once I have something ready to share, might be a few more weeks but should be done at least for the x13s soon
<zdykstra>
I'm not familiar enough with remoteprocs - what is the goal behind that work?
<zdykstra>
easier startup, easier debugging, ??
<JensGlathe[m]>
Full functionality on EL2
<travmurav[m]>
on modern qcom the adsp remoteproc runs firmware needed for sound,charging,type-c; if you boot in EL2, remoteprocs like adsp need to be booted differently, so without a way to boot it, you don't have audio/battery etc if you want to use hardware virtualisation (or even full ram on some devices)
<zdykstra>
oh wow
<zdykstra>
I didn't know EL2 had those limitations. That's really exciting news, then.
<mmediouni[m]>
<minecrell> "steveej: I’ve been working on..." <- The proper thing to do is to have the driver to start the remoteprocs from Linux (see sc7180/7280) but that's SoC specific code
<mmediouni[m]>
(relevant especially as you can reset the coprocessors)
<travmurav[m]>
well not really a limitation, just that "normally", the boot code for the remoteprocs is located in the qcom's hyp, which gets displaced
<travmurav[m]>
Mohamed Mediouni: never got adsp to boot with existing code on 7c1 fwiw
<mmediouni[m]>
Have been playing with cDSP and the number of times I had to reset it has been non-zero so far
<travmurav[m]>
fsm claimed it started but it never fetched any instructions
<travmurav[m]>
and on more modern things noone will share the docs eitehr
<travmurav[m]>
to know which clocks/pds/etc need to be kicked for it to even start booting
<mmediouni[m]>
travmurav[m]: See the IOMMU series from QCOM (for Makena auto)
<mmediouni[m]>
You need to configure the iommu or it's not gonna read any code
<mmediouni[m]>
The HV does it for you if you use the PIL interface
<travmurav[m]>
I know, it's supposed to fault the iommu. It didn't fault the iommu
<travmurav[m]>
well, nor did it fault the xPUs when I tried to make it so, since IOMMU was bypassed with sids inherited from qhee
<travmurav[m]>
suffice to say, it didn't work
<travmurav[m]>
qcom can make it work, they have docs of course
<mmediouni[m]>
That code works fine on chromebooks using the same SoC :/ so interesting...
<travmurav[m]>
don't know of any chromebook that uses adsp in prod
<travmurav[m]>
but I have 7c woa so idk if having different firmware helps them somehow
<mmediouni[m]>
will have to look into this further on 8280 and see if I get somewhere now...
<mmediouni[m]>
Has been a long time since I last touched this
<mmediouni[m]>
(haven't been at QCOM for... 3 years)
<travmurav[m]>
I guess the fact that makena auto actually needs el2+adsp is nice to see, that would probably help booting adsp on 8c3 "properly" but that doesn't help other socs as much without someone sharing all the clocks/pds/etc to make it boot, reverse engineering qhee rproc boot code is annoying af in the absence of any resources about the hw
<minecrell>
mmediouni[m]: I‘d be happy to throw away my code if you can figure out how to start them without going through PIL. It was more an experiment to help test my series for the lite ADSP on X1E anyway :p
<mmediouni[m]>
travmurav[m]: Makena auto uses a completely different firmware path unfortunately (where EL3 actually bothers bringing the copros)
<travmurav[m]>
ah great
<minecrell>
(reusing the lite ADSP firmware isn’t intended for EL2, it allows basic battery/typec functionality even without copying the adsp firmware from Windows)
<travmurav[m]>
can't allow user to boot software they want to boot I guess, must be signed /s
<travmurav[m]>
except if the user is microsoft of course /s
<mmediouni[m]>
travmurav[m]: Well the thing is that MS had none of QCOM's Gunyah thing - and insisted on their own HV. It was built ad hoc for MS - lockdown wasn't a goal.
<travmurav[m]>
of course everything is a huge hack, yet a hack that happens to vendor lock devices to microsoft
<mmediouni[m]>
travmurav[m]: My internship project at QCOM (back in 2022) was Linux at EL2 on 8280/8380 - wasn't in the best state at the time but at the end got somewhere - unfortunately QCOM worked with freezing firmware code bases soon after launch so there was no path towards retrofitting it for existing devices
<mmediouni[m]>
tbh there isn't a will to explicitly lock down things to MS, just a high amount of insane decisions and a pile of hacks
<travmurav[m]>
yeah I'd /hope/ so xD
<travmurav[m]>
but I guess none of that funny stuff we saw in x1e crd about "el2 mode" ended up in retail, nor did it work in the first place allegedly...
<mmediouni[m]>
travmurav[m]: Internship project unfortunately - although I hear that it was reimplemented after I left
<mmediouni[m]>
The Secure Launch threat model is cursed: basically it's for DRM because not gonna waste memory on a DRM memory aperture - so have EL2 own that part of security isolation for protected media - with a tamper fuse SMC for demotion
<travmurav[m]>
I guess that's how it works on android and for windows they just tacked a backdoor on top to not spend time rewriting anything, at least that's what was my impression
<mmediouni[m]>
travmurav[m]: The whole secure launch needed for EL2 thing was to be able to reuse the existing sec model yeah...
<travmurav[m]>
I hate how pcie iommu is in PT under qhee though
<mmediouni[m]>
I mean you're supposed to handle it in stage-1
<mmediouni[m]>
And behave as if qhee wasn't there (well, apart from that only single translation stage bit)
<travmurav[m]>
yet linux is not allowed to touch that iommu in el1 and pcie "just works" :^)
<travmurav[m]>
at least it's easy to find the iommu definitoins in acpi since windows can actually use it
<mmediouni[m]>
Windows on 8cx Gen 3 is supposed to run at EL2 ~100% of the time, and for X Elite there's an explicit block so that's actually enforced now
<travmurav[m]>
yeah i mean windows is fine, linux is not
<travmurav[m]>
not sure about uefi
<travmurav[m]>
and I guess mobile platforms so far dont' have untrusted pcie
<minecrell>
travmurav[m]: on mobile PCIe is SMMUv2, only compute platforms have SMMUv3
<travmurav[m]>
ah right
<mmediouni[m]>
btw QCOM provided a Gunyah update to OEMs to fix 64GB of RAM devices - but of course this even was an issue in shipped devices only because QCOM didn't really care :/
<mmediouni[m]>
(and as windows always uses secure launch, didn't show up there)
<travmurav[m]>
and phones don't have as much ram, yeah...
<minecrell>
mmediouni[m]: so did this change land for any production laptop?
<mmediouni[m]>
Dunno if it did - quite some OEMs have a habit of only taking security updates...
<steev>
mmediouni[m]: it would be nice if the OEMs would put out that fixed firmware then because on Linux with 64G devices, you end up with a random blue screen
<minecrell>
mmediouni[m]: Both Lenovo T14s and Dell XPS still had „BSP level updates“ every now and then, so if it was added to the BSP they should get it eventually
<mmediouni[m]>
minecrell: Can Acar from QCOM said: > apparently there is a Gunyah fix that Lenovo (and others) can take that addresses the 32G problem. I did hear there may be other issues, though. I will keep asking. It seems complaining to Lenovo may help.
<mmediouni[m]>
So sounds like it's in a BSP update...
<travmurav[m]>
inb4 it's like the nopauth fix for 8c3 where "it broke windows"
<travmurav[m]>
(pauth seems to work in el2 too though, funnily)
<minecrell>
mmediouni[m]: if it ends up in the main Windows branch it should end up in some of the laptops at least. If it’s an optional (extra) patch it will probably have limited chances, we’ve had that before with the X13s where you still need arm64.nopauth even though patches supposedly existed
<weirdtreething>
travmurav[m]: > don't know of any chromebook that uses adsp in prod
<weirdtreething>
dont they all?
<travmurav[m]>
7c1 chromebooks bypass adsp and use lpass hw from linux
<travmurav[m]>
7c3 never got finished afaiu
<weirdtreething>
ah
<weirdtreething>
yeah it looks like google canceled the 7c3 project
<travmurav[m]>
afaiu the original adsp boot code was added for 7c3, perhaps it worked there at some point
<mmediouni[m]>
<travmurav[m]> "(pauth seems to work in el2..." <- Not only it works, but it's enabled by default on Windows :D (when booting at el2)
<travmurav[m]>
lol
jhovold has quit [Quit: WeeChat 4.5.2]
witcher01 has quit [Remote host closed the connection]
witcher01 has joined #aarch64-laptops
jglathe_t14s has joined #aarch64-laptops
anonymix007[m] has joined #aarch64-laptops
<anonymix007[m]>
minecrell: is your tool using the EFI PIL protocol?
Ariadne has quit [Ping timeout: 480 seconds]
Ariadne has joined #aarch64-laptops
<minecrell>
anonymix007[m]: no
<minecrell>
Perhaps it should, but I don’t know how to use it
<minecrell>
I’ve also seen the weirdest crashes if you do it too early, so my tool does it very late shortly before booting Linux
<minecrell>
I think the uefi drivers can’t handle the remoteprocs being (re)started
jglathe_t14s has quit [Ping timeout: 480 seconds]
<anonymix007[m]>
It appears to be used internally by the XBL to load the ADSP Lite firmware, so maybe it'll work for loading the full one as well. I have some relevant info and can send it to you privately if you're interested. Maybe it'll be useful
<minecrell>
anonymix007[m]: Private info doesn’t help me since I would like to publish it when done :-)
<minecrell>
But I don’t think it’s feasible in any case, I had to move most of the loading to late exit boot services because the UEFI seems to crash if the ADSP is restarted inbetween. With my custom implementation I have control what to do when, but I’d assume the protocol is „all in one“ and won’t be functional anymore at that point
<minecrell>
I finished the ELF loading part, I think the biggest blocker right now are the rpmh proxy votes which are needed to guarantee reliable startup of the remoteprocs
<minecrell>
I need to implement a rpmh driver or do this via the UEFI drivers somehow