00:37 <steev> HdkR: well, that... sucks

01:05 <HdkR> steev: Sign up for their in-stock notification I guess? Seems like they underestimated how many Deck users wanted a 2TB drive

03:50 <HdkR> steev: Good news, you're not missing much. There's some weird behaviour with the drive but otherwise IOPs are similar. https://docs.google.com/spreadsheets/d/1SIxqR8bJpMg7ESaAlR_6lN7A4tIEdn9FI6FQBSCap3I/edit#gid=344325347

03:51 <HdkR> WD drive is probably the better choice even concerning perf from these numbers

06:46 <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

06:49 <steev> none

06:50 <steev> they're all in linux-firmware

06:50 <HdkR> Oh, even the GPU one now?

06:50 <steev> mmm, the a690 gmu one probably comes from linux-surface/aarch64-firmware or something

06:50 <steev> the bluetooth firmware (but not nvm patch) are even in linux-firmware

06:51 <HdkR> It also needs zap right?

06:51 <steev> all the mbn files are in linux-firmware

06:52 <HdkR> Neat

06:52 <steev> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/qcom/sc8280xp/LENOVO/21BX

06:52 <steev> we'll probably need a device specific venus though

06:52 <steev> whenever that comes around

06:53 <steev> which reminds me, i was gonna do that for the c603

06:53 <HdkR> venus?

06:53 <steev> v{enc,dec}

06:53 <HdkR> Oh right

06:53 <HdkR> The name conflicting with virtgpu always throws me off

06:54 <steev> https://github.com/linux-surface/aarch64-firmware/tree/main/firmware/qcom - that's the a690_gmu file

06:54 <HdkR> Alright, will add those to my local guide instructions

06:55 <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

06:55 <steev> it's pulled out of the windows driver, not the mbn

06:56 <HdkR> I look forward to the day-0 Snapdragon blobs direct from Qualcomm

06:59 <HdkR> Maybe for the next 8cx SoC :P

08:22 <HdkR> steev: Is there a location where the boot partition lives in the Debian ISO? Other than just installing it?

08:23 <steev> not sure what you mean

08:23 <HdkR> The dtbloader partition that ends up getting installed

08:23 <steev> it's not a partition that gets installed, dtbloader is a package

08:24 <HdkR> ah, so it'll mount the newly generated ESP partition and install the required files in to it?

08:24 <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

08:25 <HdkR> Interesting

08:25 <HdkR> Trying to make my installation instructions better than *Rip the ESP partition from the Debian install*

08:25 <HdkR> Because that's what I did :D

08:26 <steev> https://github.com/Mani-Sadhasivam/debian-cdimage/commit/1f3384824bf755c945abd199cf887c81a0174960

08:27 <HdkR> Where does Persisted_Capsules.bin and grubaa64.efi come from?

08:28 <HdkR> Actually does grubaa64.efi even get used in this, doesn't it pull from the other partition?

08:30 <HdkR> context, I have zero clue how it manages to boot from the ESP partition in to the grub configuration on the root partition

08:42 <HdkR> Oh, does it never actually load the grub from the root?

09:37 <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

09:37 <danielt> known working backup DT).

09:37 <danielt> If your distro is super modern and is grubless then DtbLoader might still be useful but otherwise...

09:38 <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

09:40 <HdkR> As long as I can get the couple of people up and running then never touch it again I'm happy :P

09:41 <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!

09:42 <HdkR> Indeed

09:42 <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 ;-) )

09:49 <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

09:49 <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.

09:50 <HdkR> I've noticed that something gets crashy in wayland but as long as I auto-login to i3 I haven't hit it

09:51 <HdkR> Might just bee a userspace thing since it isn't quite stable

10:37 <HdkR> I still need to disable sleep pn my X13s so I can clamshell it and keep it docked forever

10:38 <HdkR> But also hopefully disabling internal display gets more stable soon

11:06 <juergh> what is remoteproc and why is it causing a USB disconnect when it loads?

11:06 <juergh> on the x13s that is. that's kind of bad when you try to boot from a USB disk :-)

11:07 <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

11:07 <danielt> abstracting the hardware differences".

11:08 <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.

11:08 <danielt> (remote processors means any of the small programmable co-processors that modern SoCs have scatttered everywhere)

11:09 <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.

11:10 <juergh> oh. which means I need to shove FW into the initrd as well :-(

11:11 <danielt> 'fraid so

11:27 <Dylanger> Does anyone know how often Collabera's commits make it into mainline? I'd like to start using mainline for my Cherry Chromebook

14:37 <bamse> juergh: remoteproc loads firmware onto the "adsp", which among other things implements the usb type-c firmware

14:38 <bamse> juergh: so, iiuc we're momentarily loosing vbus when this happens...and that's why usb is disconnected

14:40 <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.

14:54 <bamse> juergh: the worry there is that the adsp is pretty big...and device-specific

15:07 <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?

15:08 <juergh> that might be sufficient for a USB installer image

16:30 <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

16:30 <steev> with the script that's installed, but have not seen dtbloader->grub chain break here... ever

16:32 <bamse> juergh: battery management, hot-plug events from your external display and audio

16:33 <bamse> juergh: so unless i'm forgetting something critical, that seems like a decent tradeoff for the installer...

16:43 <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 install-dtbs.py script

16:45 <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)

16:46 <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.

16:56 <steev> weird

18:59 <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

19:01 <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 :-(

19:01 <steev> robclark: i don't see any certs in the a690_gmu.bin

19:02 <robclark> yeah, gmu fw is not signed

19:02 <steev> oh, sorry, misread :)

19:03 <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)

19:03 <steev> maybe we could ask qualcomm very nicely for an a690_gmu?

19:12 <robclark> yeah, I guess it would have to come from them

19:35 <steev> maybe someone we know could reach out and ask...

20:34 <robclark> like bamse ;-)

21:17 <bamse> robclark: noted

21:56 <clover[m]> What is zap?

22:05 <robclark> it is what happens when you touch a doorknob after walking across carpet :-P

22:06 <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)

22:07 <robclark> but for devices that boot in EL1 it is needed when gpu is powered to take gpu out of secure mode

22:53 <bamse> robclark: so would that be invoked every time one transitions out of a secure use case?

22:54 <robclark> yup.. although the only times we transition out of secure is when we resume the gpu ;-)

22:54 <robclark> but if we did have secure content support, there would be additional transitions from secure -> normal

22:56 <qzed> secure as in drm decoding stuff or what does that mean?

22:56 <bamse> that kind of secure, yes, but not necessarily limited to that use case

23:55 <HdkR> robclark: I don't even remember which device I have. Does that mean I can or can't tinker with it?

23:59 <robclark> strongbad == detachable (tablet), trogdor == clamshell