16:49 <HdkR> Oops, ran the battery flat overnight

16:50 <Penguinpee> At least that's not a kernel OOPS ;)

17:30 <steev> HdkR: i've done that a number of times :(

17:50 <HdkR> it's a shame it takes so long to come back after being plugged in

17:51 <HdkR> Had to wait like 20 minutes before it finally decided to come back online

17:53 <steev> weird

17:53 <steev> mine doesn't take that long, but i do notice that the first time i try to power it back on it shuts itself back off

17:55 <HdkR> definitely noticed that, but then hammering the power button again, long pressing, combination doesn't seem to bring it back until it is charged enough

17:57 <steev> i usually just have to press it 1 time, not long, or any sort of combination

17:57 <HdkR> weird

18:01 <steev> oh, because you wiped out windows, you are probably on older bios

18:02 <steev> i have no idea if it would be possible to download the lenovo bios update exe, extract it with innoextract (i'm assuming they use innosetup) and apply it via fwupd manually or not

18:02 <HdkR> Definitely on older BIOS at this point

18:05 <steev> oh, interesting

18:05 <steev> you can do it from a usb drive

18:06 <steev> https://paste.debian.net/1253413/

18:08 <steev> so they basically do "copy Rfs\Usb\Bootaa64.efi %Drive%\EFI\Boot\Bootaa64.efi" and "xcopy /S /E Rfs\Fw\*.* %Drive%\Flash\"

18:08 <HdkR> oh, huh

18:09 <steev> yeah, looks like lenovo does innosetup for all their stuff, so the exe's can be ripped apart with innoextract

18:10 <HdkR> Will need to give it an update once I'm done tinkering then

18:12 <HdkR> Would be nice if it also solves the issue where sometimes it doesn't see any boot devices, including internal nvme

18:12 <steev> so yeah; usb key -> fat32; mkdir $drive/{EFI/Boot/,Flash}; cp Rfs/Usb/Bootaa64.efi $drive/EFI/Boot/; cp -a Rfs/Fw/* $drive/Flash; boot machine, f12 -> usb device, it should boot from it and start the EC update stuff

18:14 <HdkR> https://gist.github.com/Sonicadvance1/a7824004d2ba3174d6daefe5eee3a7e7 Hm, wierd linked list issue

18:17 <HdkR> Which I think is from a freshly created list

19:48 <HdkR> https://gist.github.com/Sonicadvance1/f1403b28d76fb6f8139a608b0fd047fd Those are some fun errors

19:51 <HdkR> So gmu_set_oob with GMU_OOB_GPU_SET is timing out

20:07 <clover[m]> doing some more gpu bring up today?

20:08 <HdkR> Trying to break my face on this wall anyway

20:08 <HdkR> Seems like gmu is angry

20:18 <clover[m]> steev: did you see this? https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2620

20:26 <HdkR> Hm. Are devices in the DT supposed to have overlapping memory regions?

20:26 <HdkR> Is there a tool to see what has overlapping regions?

20:26 <HdkR> Are these supposed to be in very specific locations or does it not matter?

20:27 <HdkR> gmu is currently overlapping gpucc

20:29 <clover[m]> <clover[m]> "steev: did you see this? https:/..." <- Didn't work for me :(

21:27 <HdkR> "fixed" address overlap and it boots at least. Now complaining about "cx_gdsc status stuck at 'off'"

21:36 <HdkR> hm, adreno_smmu angry when moved

22:21 <steev> as someone who is horrendous at math, i wish there was an easy way to look at the regions and maths

22:27 <HdkR> Sounds like a script someone could generate quick