01:52 <qzed> alright, we now have a repo with pre-built kernel and firmware packages for the spx on Arch Linux, and a script-thingie to build a bootable disk image

01:53 <qzed> the latter works surprisingly well on x86 via binfmt_misc and qemu-user-static

01:53 <bamse> qzed: you're not running the script thingie on the device itself? ;)

01:53 <qzed> nope, built it so people are able to run it on pretty much any machine

01:54 <qzed> https://github.com/linux-surface/aarch64-arch-mkimg

01:55 <qzed> not sure whether that works in wsl... essentially the two options for me were either to make sure it runs on most devices or it runs on the spx in wsl

01:55 <bamse> qzed: so am i reading that correct that you start off with the generic arch linux arm tar?

01:56 <qzed> yeah, essentially extract that, chroot into it, do some stuff, copy it to an image

01:56 <qzed> should be fairly easy to adapt for the flex

01:56 <bamse> okay, yeah i used to do that...these days i chroot into that tar-ball, install arch-install-scripts and then use that to build my new system

01:57 <bamse> but for a bootable disk system, this should work just fine

01:57 <bamse> yeah, the flex should be quite straight forward...

01:58 <qzed> yeah, the intentions were to create something to get started

01:59 <qzed> also: since I didn't figure out how to do squashfs properly, the "default" profile is just creating one big initramfs... that could also help for debugging suspend stuff since the nvme seems to break

01:59 <bamse> ahh nice

01:59 <bamse> do you have any logs showing the nvme breakage?

02:00 <qzed> only https://gist.github.com/qzed/2288c651a017fcc016b524d3bac5a43e#file-dmesg-log-L887

02:01 <bamse> mani_s: ^^ does this nvme/suspend issue look familiar to you?

02:01 <qzed> that seems to be the first indication, below there's more stuff with BTRFS errors and things like that

02:01 <qzed> also this one: https://gist.github.com/qzed/2288c651a017fcc016b524d3bac5a43e#file-dmesg-log-L1030

02:01 <qzed> kinda looks like the pci device isn't coming back up

02:12 <steev> qzed: it won't work in wsl because wsl hates binfmt-misc, or it did the last time i tried to

02:13 <qzed> right, but you wouldn't need that when running on the spx/flex in wsl...

02:13 <steev> oh, right

02:13 <steev> yeah it should work fine there

02:13 <qzed> but I'm not sure how well wsl works with loop devices and things like that

02:13 <steev> i was thinking not on device

02:14 <qzed> right, I mean my two options were: run it on the device but in wsl, or run it off the device (preferably not in wsl)

02:15 <steev> loop devices should work fine in wsl2

02:15 <qzed> oh neat

02:15 <steev> steev@DESKTOP-UL9N8HT:~/git/c630/torvalds$ sudo mount /tmp/test /mnt/

02:15 <steev> steev@DESKTOP-UL9N8HT:~/git/c630/torvalds$ ls /mnt/

02:15 <steev> lost+found

02:15 <steev> steev@DESKTOP-UL9N8HT:~/git/c630/torvalds$

02:16 <steev> steev@DESKTOP-UL9N8HT:~/git/c630/torvalds$ losetup -a

02:16 <steev> /dev/loop0: []: (/tmp/test)

02:19 <steev> i think the only device out there that can't do wsl2 is the c630 :(

02:20 <steev> the galaxy book 2, which is also an sdm850, does wsl2

02:20 <qzed> wait, there are devices that can't run wsl2?

02:20 <steev> lenovo never bothered before it went EOL

02:21 <steev> and microsoft told us (kali) to get the galaxy book 2 for our wsl2 testing on arm64 way back when they were still working on it and all ways quiet

02:36 <steev> qzed: oh, https://patchwork.kernel.org/project/linux-arm-msm/patch/20220624195112.894916-1-robimarko@gmail.com/ fixes that gpio chip immutable message on the flex (and x13s)

02:36 <steev> if you didn't already grab it

02:36 <qzed> thanks! no, didn't grab that yet

10:13 <maz> steev: this patch looks buggy...

12:00 <mani_s> bamse, qzed this suspend issue looks different from the one I'm seeing on sc7280. Here the timeout seems to come from the pcie hotplug driver during suspend itself

12:01 <mani_s> this indicates that the pcie controller goes awry during suspend... and this somehow sounds familiar to me

13:59 <steev> maz: just for the record, i didn't write it :D

14:23 <maz> steev: not blaming you! ;-) I poked the seemingly party on the list...

14:24 <steev> indeed, i read, and i appreciate all the back and forth of code reviews to learn