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> HdkR: well, that... sucks
<HdkR> steev: Sign up for their in-stock notification I guess? Seems like they underestimated how many Deck users wanted a 2TB drive
hightower2 has joined #aarch64-laptops
derzahl has quit [Ping timeout: 480 seconds]
derzahl has joined #aarch64-laptops
kettenis has quit [Ping timeout: 480 seconds]
kettenis has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<HdkR> steev: Good news, you're not missing much. There's some weird behaviour with the drive but otherwise IOPs are similar.
<HdkR> WD drive is probably the better choice even concerning perf from these numbers
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
<HdkR> What was all the blobs I had to rip from Windows for the X13s again? Creating a guide for someone and I don't remember them all
<steev> none
<steev> they're all in linux-firmware
<HdkR> Oh, even the GPU one now?
<steev> mmm, the a690 gmu one probably comes from linux-surface/aarch64-firmware or something
<steev> the bluetooth firmware (but not nvm patch) are even in linux-firmware
<HdkR> It also needs zap right?
<steev> all the mbn files are in linux-firmware
<HdkR> Neat
<steev> we'll probably need a device specific venus though
<steev> whenever that comes around
<steev> which reminds me, i was gonna do that for the c603
<HdkR> venus?
<steev> v{enc,dec}
<HdkR> Oh right
<HdkR> The name conflicting with virtgpu always throws me off
<HdkR> Alright, will add those to my local guide instructions
<steev> i dunno how we convince peeps to get that into linux... i *think* that would need to come from qualcomm? since i'm assuming qualcomm build the windows driver and lenovo just sign their copy
<steev> it's pulled out of the windows driver, not the mbn
<HdkR> I look forward to the day-0 Snapdragon blobs direct from Qualcomm
<HdkR> Maybe for the next 8cx SoC :P
<HdkR> steev: Is there a location where the boot partition lives in the Debian ISO? Other than just installing it?
<steev> not sure what you mean
<HdkR> The dtbloader partition that ends up getting installed
<steev> it's not a partition that gets installed, dtbloader is a package
<HdkR> ah, so it'll mount the newly generated ESP partition and install the required files in to it?
<steev> at that point, the new esp partition is already mounted (that's handled by the disk partitioner of the debian installer), it's just a package like any other in debian, that writes its files there, yeah
<HdkR> Interesting
<HdkR> Trying to make my installation instructions better than *Rip the ESP partition from the Debian install*
<HdkR> Because that's what I did :D
<HdkR> Where does Persisted_Capsules.bin and grubaa64.efi come from?
<HdkR> Actually does grubaa64.efi even get used in this, doesn't it pull from the other partition?
<HdkR> context, I have zero clue how it manages to boot from the ESP partition in to the grub configuration on the root partition
<HdkR> Oh, does it never actually load the grub from the root?
<danielt> steev: HdkR : I recently gave up on the chainloaded DtbLoader completely because I was fed up with `apt update` making my X13s unbootable whenever a new version of grub came out. When DtbLoader is chainloaded (rather than being implemented as a driver) then AFAICT it doesn't do anything we can't already do better using the devicetree command in grub (for example, once we put devicetree into grub we can have a menu entry to roll back to
<danielt> known working backup DT).
<danielt> If your distro is super modern and is grubless then DtbLoader might still be useful but otherwise...
<HdkR> danielt: I'm actually using both atm. dtbloader which loads grub, which then uses its own DT. Because I don't know wtf I'm doing with bootloaders
<HdkR> As long as I can get the couple of people up and running then never touch it again I'm happy :P
<danielt> HdkR: If you are setting up the DT in grub anyway then you'll probably never even notice when/if a grub update removes DtbLoader from the chain!
<HdkR> Indeed
<danielt> HdkR: Oddly, having the X13s "unload" the DtbLoader is a sign of progress (e.g. the OS has enough influence over the EFI boot vars the break things; on older Arm laptops the OS is refused access entirely ;-) )
<danielt> I also have a "is this already well known" question. I have an X13s which is almost always hooked up to a dock and an external monitor. It's always felt a bit fragile but inspired by working GPU I have been poking about a bit more closely to try and better figure out what "fragile" actually means. I realized that before we connect an external monitor the Gnome display manager defaults to Wayland (I only noticed this after rebooting
<danielt> without the DP hooked up)... after I connect an external monitor (which prompts the wayland session to crash and restart) then wayland becomes unavailable and I can only have X11 graphics from that point onwards.
<HdkR> I've noticed that something gets crashy in wayland but as long as I auto-login to i3 I haven't hit it
<HdkR> Might just bee a userspace thing since it isn't quite stable
Lucanis has quit [Ping timeout: 480 seconds]
<HdkR> I still need to disable sleep pn my X13s so I can clamshell it and keep it docked forever
<HdkR> But also hopefully disabling internal display gets more stable soon
<juergh> what is remoteproc and why is it causing a USB disconnect when it loads?
<juergh> on the x13s that is. that's kind of bad when you try to boot from a USB disk :-)
<danielt> The docs express it more clearly than I could: "The remoteproc framework allows different platforms/architectures to control (power on, load firmware, power off) those remote processors while
<danielt> abstracting the hardware differences".
<danielt> Arguably it shouldn't cause a USB disconnect but maybe it shows why there would be a gitch if we reboot the processor that helps run the USB-C ports.
<danielt> (remote processors means any of the small programmable co-processors that modern SoCs have scatttered everywhere)
<juergh> ok. thanks for the elaboration. I guess I need to load all that in the initrd to not loose the root disk later on.
<juergh> oh. which means I need to shove FW into the initrd as well :-(
<danielt> 'fraid so
<Dylanger> Does anyone know how often Collabera's commits make it into mainline? I'd like to start using mainline for my Cherry Chromebook
arnd has quit []
arnd has joined #aarch64-laptops
hightower2 has quit [Ping timeout: 480 seconds]
<bamse> juergh: remoteproc loads firmware onto the "adsp", which among other things implements the usb type-c firmware
<bamse> juergh: so, iiuc we're momentarily loosing vbus when this happens...and that's why usb is disconnected
<juergh> bamse: ok. I can add that to the initrd, no prob. but fw is not listed in modinfo so won't get added automatically. I guess the path is constructed at runtime based on the HW.
svarbanov_ has joined #aarch64-laptops
svarbanov has quit [Ping timeout: 480 seconds]
<bamse> juergh: the worry there is that the adsp is pretty big...and device-specific
<juergh> bamse: better to have a big initrd than loosing the OS disk...what functionality am I loosing if the whole remoteproc stuff is blacklisted?
<juergh> that might be sufficient for a USB installer image
miracolix has joined #aarch64-laptops
<steev> danielt: i don't know the full details but my understanding is that the flex5g has issues loading dtbloader as a driver, which is why the efi app was the chosen route; i've had zero issues updating grub and i've had linux installed since i first got the x13s here, and have only used debian stable and debian testing(kali) on it. i do use the devicetree command when i'm testing a new kernel, rather than blindly copy in the newest one
<steev> with the script that's installed, but have not seen dtbloader->grub chain break here... ever
<bamse> juergh: battery management, hot-plug events from your external display and audio
<bamse> juergh: so unless i'm forgetting something critical, that seems like a decent tradeoff for the installer...
<steev> if you mean the chain breaks because incompatible dtb file gets passed because it's forgotten... you can always add postint kernel hook to run the script
<danielt> steev: The chain breaks for me because when grub updates the EFI variables that should point at DtbLoader.efi end up updated and point at grubaa64.efi instead (hence my kernel is launched with only ACPI tables)
Lucanis has joined #aarch64-laptops
<danielt> Specifically Boot0000 (which used to contain DtbLoader.efi) ends up as: Boot0000* debian HD(1,GPT,841cafa2-3392-42a7-bfa9-9a8d6033504a,0x9c000,0x82000)/File(\EFI\debian\grubaa64.efi) instead.
<steev> weird
hightower2 has joined #aarch64-laptops
miracolix has quit [Read error: Connection reset by peer]
miracolix has joined #aarch64-laptops
miracolix has quit [Read error: Connection reset by peer]
miracolix has joined #aarch64-laptops
miracolix has quit [Read error: Connection reset by peer]
miracolix has joined #aarch64-laptops
miracolix has quit [Read error: Connection reset by peer]
<robclark> HdkR, steev: oh, I just realized that for x13s, we have zap (thanks to lenovo) but not unsigned gmu fw.. that is kinda a funny situation
miracolix has joined #aarch64-laptops
<robclark> HdkR: speaking of virtgpu, 64b userspace (and therefore 64b crosvm) is on stable channel for trogdor now.. but held up due to camera blobs for strongbad :-(
<steev> robclark: i don't see any certs in the a690_gmu.bin
<robclark> yeah, gmu fw is not signed
<steev> oh, sorry, misread :)
<steev> that's because the firmware is ripped out of the windows driver (same for the a680 that the linux surface uses for sc8180x afaik)
<steev> maybe we could ask qualcomm very nicely for an a690_gmu?
shoragan has quit [Ping timeout: 480 seconds]
<robclark> yeah, I guess it would have to come from them
shoragan has joined #aarch64-laptops
miracolix has quit []
miracolix has joined #aarch64-laptops
<steev> maybe someone we know could reach out and ask...
hightower2 has quit [Remote host closed the connection]
miracolix has quit []
miracolix has joined #aarch64-laptops
miracolix has quit []
miracolix has joined #aarch64-laptops
miracolix has quit []
miracolix has joined #aarch64-laptops
miracolix has quit []
miracolix has joined #aarch64-laptops
miracolix has quit []
miracolix has joined #aarch64-laptops
<robclark> like bamse ;-)
derzahl has quit [Ping timeout: 480 seconds]
miracolix has quit []
hightower2 has joined #aarch64-laptops
derzahl has joined #aarch64-laptops
miracolix has joined #aarch64-laptops
<bamse> robclark: noted
<clover[m]> What is zap?
<robclark> it is what happens when you touch a doorknob after walking across carpet :-P
<robclark> (actually is basically sqe code with some embedded cmdstream and shader to erase, aka zap, gpu state, so when transitioning from secure to normal mode there isn't possibility to leak data from secure to insecure)
<robclark> but for devices that boot in EL1 it is needed when gpu is powered to take gpu out of secure mode
miracolix has quit [Remote host closed the connection]
iivanov has quit [Ping timeout: 480 seconds]
<bamse> robclark: so would that be invoked every time one transitions out of a secure use case?
<robclark> yup.. although the only times we transition out of secure is when we resume the gpu ;-)
<robclark> but if we did have secure content support, there would be additional transitions from secure -> normal
<qzed> secure as in drm decoding stuff or what does that mean?
<bamse> that kind of secure, yes, but not necessarily limited to that use case
<HdkR> robclark: I don't even remember which device I have. Does that mean I can or can't tinker with it?
<robclark> strongbad == detachable (tablet), trogdor == clamshell