01:09 <leezu> On sc7180 v6.1-rc8 wifi does not work and there is a "qcom-q6v5-mss 4080000.remoteproc: PBL returned unexpected status -284098560" kernel error. I've also observed this on v6.1-rc5 but didn't have time to bisect back then. Is anyone aware of a solution to this issue? I'll also go ahead and run bisect now

01:09 <leezu> Specifically, lazor device

01:53 <steev> init: added in the v4's. i should probably rebase it before i push otherwise the kernel robot will probably yell, but i'll push out -rc8 here in a few. audio still won't work here, but i did try pulling in a v2 of one of the patches i noticed that i didn't have the v2 of

01:55 <steev> pushing now, i don't feel like rebasing

01:55 <steev> will see what the kernel bot screams about

08:13 <steev> hm, so, assuming that the firmware should look similar to the other stuff inside the board-2.bin file, it *should* be one of bdwlan.e8c, .eb8, .elf, or bdwlang.e8c, but, none of those 4 are working

08:14 <steev> are we maybe returning 0x8c instead of 0xe8c ?

08:25 <steev> fwiw.. what i did was, grabbed kalle's latest board-2.bin file, grabbed the qca-swiss-army-knife repo, ran ath11k-bdencoder -e board-2.bin (disclaimer: do this in a directory you don't care about otherwise you're gonna have a bad time) - this spits out a json file and all of the .bin files. then i edited the json file and added what we seem to report looking for in it

08:25 <steev> (bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=0108,qmi-chip-id=2,qmi-board-id=140 for name, (and qmi-board-id=140.bin for the data); then i did a quick strings on some of the other bin files that were extracted, noticed they all had the string bdwlan_bin_start, so grabbed all the bdwlan files, ran the same grep across them, and the 4 previously mentioned were the only ones that have that string in them;

08:25 <steev> copying each one to the above named file (the data= line should be file name in the directory with the rest... and build the board-2.bin and then tried to insmod the ath11k_pci module, but it still just times out :/

08:27 <steev> (oh, and i reverted the wifi hack in the kernel, but instead of installing the kernel, jsut attempted to load the modules)

08:29 <steev> oh, i also had to edit the ath11k-bdencoder script because the max size is too small to extract the board-2.bin

08:33 <steev> and i did check with -i of the board-2.bin file, and it does report that the 140 i add is in there :/

08:37 <steev> i did also find out, that it will read either board.bin or board-2.bin, falling back to board.bin if board-2 doesn't exist

17:51 <hexdump0815> leezu: i did and do not have much time recently and now, so i did not test any newer kernels on sc7180, but i hope to have more time in two weeks and plan to move to v6.1 then and might help looking at this too - but of course any biscting beforehand would be welcome :)

18:24 <steev> hmmm, so, this isn't so good

18:24 <steev> now the wifi is just refusing to work at all

18:24 <steev> even with the override

19:40 <steev> ah

19:41 <steev> the driver does not like the windows version of the regdb.bin

19:42 <steev> i wonder

20:43 <steev> hm, i have no idea what it expects for regdb and i suck at reading python

20:45 <clover[m]> M1 just got gpu drivers

20:46 <HdkR> Well "just", The project just started shipping it to users.

20:49 <HdkR> It's been many many months in the making

20:56 <clover[m]> So are you gonna use it for dev work hdkr

20:57 <HdkR> No, I need them to support 4kb pages with it first.

21:05 <steev> 48 months or so

21:06 <HdkR> :D

21:06 <HdkR> Or never because of the hardware limitation

21:06 <steev> oh i meant 48 months in the making

21:06 <HdkR> ah

21:06 <steev> afaik, it's not a hardware limitation at all

21:07 <steev> just that marcan wants to force people to fix their software

21:07 <HdkR> the GPU's iommu only supports 16kb pages so it has...problems

21:07 <steev> oh, the gpu

21:07 <HdkR> Yea, makes it hard to mix 4k CPU + 16k GPU pages

21:08 <HdkR> I'm not going to say impossible, just really hard

21:12 <steev> oh, i see... the regdb is basically the same as the boards, would need each name/data, which i don't have, and dunno how to extract it from their file

23:57 <kettenis> HdkR: the apple iommu has sub-page protection, so the 16k iommu page size isn't a fundamental problem

23:57 <kettenis> the reall issue is the Linux iommu abstraction layer which is a bit too much focussed on virtualization