01:01 <dgilmore> WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.37

01:13 <steev> try with .41? (should be latest in the firmware repo)

01:52 <dgilmore> linux-firmware build is less than 2 weeks old

01:55 <steev> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=c362cc882ea797f059eb3471c83d82f58569543f

01:55 <steev> it should be 41

01:56 <dgilmore> looks like it was updated 2 days after the last linux-firmware release

02:06 <steev> rip

02:12 <dgilmore> Updating the firmware. Hopefully it's happier

02:16 <dgilmore> well it did not crash on boot

02:16 <dgilmore> WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41

02:17 <steev> that's good

03:04 <dgilmore> Well it crashed

03:15 <steev> thats not

03:27 <TSIN[m]> Failed to boot on my vivobook s15 x1e with v5 image..

03:39 <dgilmore> steev: it was the same crash. Just took about an hour rather than straight away

03:53 <steev> have definitely seen 6.11 be more crashy on wifi but no idea what causes it

06:34 <JensGlathe[m]> can confirm on EL2 box, wifi crashed twice since booting it with rc5 (yesterday)

07:07 <jhovold> dgilmore: looks like the ath11k NULL deref you hit is a known issue with a fix on its way into mainline:

07:07 <jhovold> https://bugzilla.kernel.org/show_bug.cgi?id=219131

07:09 <jhovold> not seeing that here, but from a quick look it seems it only affects 6 GHz

07:11 <travmurav[m]> robclark: Jens Glathe I was thinking how slbounce could interact with dtbloader and my loose idea was for dtbloader to provide a generic api that would return dtb path (i.e qcom/sc8280xp-lenovo-blah.dtb) and then slbounce could load after, request that full name and check the soc prefix to then load overlays/fixups. Then adding/removing slbounce.efi alone would enable/disable el2, but I didn't think about this too deeply yet

07:13 <travmurav[m]> the "dtb filename protocol" I will most likely implement regardless though, this way bootloaders like sd-boot could choose to have multiple dtbs/ dirs in esp. mapped to different boot options and still use dtbloader's hardware knowledge to pick what to load

07:16 <travmurav[m]> Thankfully on sc8280xp (and seemingly on x1e too) the overlay we need to load is pretty simple

07:17 <travmurav[m]> I guess there is another funny alternative

07:17 <travmurav[m]> hm

07:19 <travmurav[m]> we boot as usual, only make sure the dtb is in the configuration table when EBS is hit, slbounce checks config table -> gets dtb, reads that `/chosen/slbounce,switch-to-el2-please;` exists, and if it does exist, does the magic

07:19 <travmurav[m]> then the enable/disable of el2 is merely having a dt overlays installed or not

07:19 <travmurav[m]> which can be bound to sd-boot/grub(?) boot options

07:19 <travmurav[m]> sd-boot has overlays option I'm pretty sure

07:21 <JensGlathe[m]> and dt overlay is the best option?

07:22 <travmurav[m]> well, or custom -el2 dtb I guess, as long as slbounce has a way to know we want/don't want the switch

07:22 <travmurav[m]> I think overlays make things a bit simpler though since we can have a generic overlay that applies to all devices on soc X

07:26 <lumag> steev, bamse, travmurav[m]: while playing with c630 & Debian distro kernels I noticed that that while the unsigned kernel boots fine, the same kernel signed with distro's keys crashes the firmware very early during boot. Does anybody know a possible reason or a workaround for that?

07:26 <travmurav[m]> I should probably draft up something for that dt option idea...

07:26 <travmurav[m]> as in it gets to linux proper but still crashes?

07:27 <lumag> travmurav[m], no, doesn't even boot

07:27 <travmurav[m]> ah "in firmware"

07:27 <lumag> Yep. It happens very early during control transfer (e.g. even before EFI exit boot services messages)

07:27 <steev> lumag: i don't think i've seen that here... or maybe i have and didn't realize that is what is going on

07:28 <travmurav[m]> hm but it launches shim/grub properly?

07:28 <steev> i'm not using the debian kernel til that rcu stall stops happening :(

07:28 <lumag> travmurav[m], no shim yet, but the grub works fine.

07:28 <lumag> steev, I think it's related to the PSCI sleep states

07:29 <steev> my c630 still uses dtbloader (rob's version... or whatever)

07:29 <lumag> maybe we should add device-specific workaround.

07:29 <lumag> steev, mine too, rob's version

07:29 <lumag> I thought that there might be some kconfig or compiler option, but I've really tested linux-image-signed vs linux-image-unsigned

07:30 <travmurav[m]> I wonder if it fails to hash/validate a big binary or something like that?

07:30 <travmurav[m]> i.e. if it nevere gets to linux efistub code

07:31 <lumag> travmurav[m], any idea how to check it?

07:32 <lumag> I have a serial dongle attached, so I see 'Synchronous Exception at 0xfoo', most likely coming from EFI

07:32 <lumag> Data abort: Translation fault, third level

07:32 <travmurav[m]> Not a clear idea but assuming you sign with your keys, I guess putting a print in grub right before it loads the image might be interesting

07:33 <lumag> hmm. Maybe I should start by updating grub.

07:33 <travmurav[m]> Ugh efi should have everything identity mapped

07:33 <lumag> I think I still have a very old one

07:33 <travmurav[m]> So if it's an unmapped memory it touches then it's pretty weird

07:33 <lumag> https://paste.debian.net/1327826/

07:36 <travmurav[m]> I wonder if it's related to that thing where efi remaps functions to virtual memory, efi=novmap thing iirc?

07:36 <travmurav[m]> I don't remember at which point it comes into play though

07:36 <travmurav[m]> But digged unsigned difference would make no sense then

07:40 <lumag> updating grub didn't help.

07:42 <travmurav[m]> (s/digged/signed/ and I should probably kill this autocorrect dictionary at this point...)

07:46 <travmurav[m]> lumag: or hm do you even have SB enabled?

07:46 <lumag> travmurav[m], no :-D

07:46 <travmurav[m]> Perhaps the signing tool just corrupts the kernel image?

07:46 <lumag> shim doesn't work yet on c630, it needs alignment fix

07:47 <travmurav[m]> Or like something funny like it corrupts the pe header magic values that allow grub to skip efistub

07:47 <travmurav[m]> As in the first 8 bytes where it puts funny nop instruction that happens to start with "MZ"

07:48 <travmurav[m]> But would also be weird if it's a tool specifically for signing linux...

07:48 <travmurav[m]> Perhaps worth trying to load the linux image via efi shell?

07:50 <lumag> travmurav[m], the same image boots on x13s, no SB, same grub

07:50 <travmurav[m]> Weird

07:51 <lumag> Checked, the difference between PE headers is really minimal - Checksum and Security Dictionary

07:51 <lumag> Maybe I should try rewriting that part

08:06 <lumag> travmurav[m], ok, miix630 boots such kernels without issues. So it might be that something is off with C630 EFI

08:07 <lumag> maybe bamse has some ideas

08:13 <anonymix007[m]> travmurav: can slbounce just implement the dt fixup protocol?

08:14 <travmurav[m]> Well then it would clash with dtbloader which does the same, but also it would imply slbounce needs to know the soc again

08:15 <travmurav[m]> I think leaving dtb handling out of slbounce would simplify thi gs quite a bit

08:16 <travmurav[m]> So whether a pre-baked el2 dtb or overlay loading, letting slbounce to only read it would allow user to pick el1 vs el2 in the boot menu since most bootloader allow to set dtb in the boot option

08:17 <travmurav[m]> If slbounce unconditionally fixes up, we're back at the Initial problem of "need too much work to pick el1 or el2"

08:17 <travmurav[m]> And booting el2 only is sadly currently unfeasible due to no remoteproc booting stuff

08:32 <anonymix007[m]> The SoC name can certainly be extracted from the fdt buffer provided to the implementation, can't it? The conditionality problem is another one though. Can we maybe do it in sd-stub somehow? Recent PR has a concept of profiles, maybe it could be extended a bit to support this use-case (pass some parameter for slbounce to decide whether it actually will do any fixups)

08:34 <MrCatfood[m]> anyone tried gpu over thunderbolt on windows?

08:48 <HdkR> Does any PCIe GPU vendor even provide ARM64 Windows drivers?

08:52 <JensGlathe[m]> Wifi is crashy on X13s, too

08:56 <JensGlathe[m]> no real reason to be seen

08:56 <MrCatfood[m]> <HdkR> "Does any PCIe GPU vendor even..." <- windows has default display drivers, i'm not sure about the quality

08:58 <Jasper[m]> JensGlathe[m]: Yep, same issue

08:58 <Jasper[m]> got worse on 6.10

09:01 <HdkR> MrCatfood[m]: Might be enough to get display output

09:01 <HdkR> Obviously won't be doing D3D, GL, Vulkan on that driver

09:17 <travmurav[m]> anonymix007: right, as long as slbounce doesn't have to change uefi memory map, it could check board compatible and load overlays, I actually didn't think of that somehow lol... otherwise slbounce runs at/after EBS so it can do whatever it wants with the dtb I guess

09:18 <travmurav[m]> anonymix007: but yeah I guess the main question is letting slbounce know if it's "go" or "no go"

09:19 <travmurav[m]> Though I guess this still requires slbounce to cache all possible overlays in ram if it only knows which it needs at the time of ebs (when bootloader has put the dtb to efi config table)

09:19 <travmurav[m]> And actually unsure if efistub's cmdline dtb= does hm

09:22 <travmurav[m]> Sad seems like it won't register the dtb passed on cmdline

12:18 <dgilmore> jhovold: ahh, two of my access points have 6Ghz radios.

15:37 <robclark> lumag: tell me about this serial dongle thing.. that sounds useful

16:24 <steev> JensGlathe[m]: that's https://bugzilla.kernel.org/show_bug.cgi?id=218623

19:03 <AladdinSane> Hi, what is the current state on X13s? Is the webcam working?

19:56 <steev> if your distro has a new enough libcamera, and you're using either 6.11 rcs or the wip branches, it should, mostly

19:56 <steev> https://github.com/jhovold/linux/wiki/X13s

21:57 <AladdinSane> Looks promising. Thanks for the link. I hope these are my last days using Windows!

21:59 <steev> there are still definitely some kinks, but i've been using it (fairly) stablely for the past 2 years on linux