13:59 <qzed> I've been looking through the windows driver and there seem to be two GMU (like?) firmwares embedded in it

13:59 <qzed> the first one seems to resemble the a640 one based on the block addresses

13:59 <qzed> the second one the a660

14:00 <qzed> I've only been able to exactly pin down and extract the first one yet, but that didn't work

14:00 <qzed> I assume it's for the a680 and the driver contains both fw for a680 and a690

14:01 <qzed> in contrast to the a640 firmware it's quite a bit larger though (~100k vs ~37k)

14:02 <qzed> also based on `strings` it seems that the firmwares contain the same strings as the a640 and a660 respectively

14:02 <qzed> (or rather strings containing "GMU")

14:57 <robclark> the sqe fw is defn bitter on a660 family than earlier, because it essentially contains two sqe fw's.. not sure about the gmu fw.. the gmu fw is cortex-m, fwiw.. if you want to try and disasm and see if it looks like valid instructions. The sqe is something "custom" (there is the "afuc" disassembler and assembler for sqe in the mesa tree)

14:57 <robclark> you won't find any strings embedded in the sqe fw, fwiw

14:57 <qzed> yeah, figured the string part out already

14:58 <qzed> I've found some firmware loading thing that differentiates between 3 types of firmware in the windows driver

14:59 <qzed> one that I don't know (although I somewhat doubt it's sqe) and two gmu-type block loading ones

14:59 <qzed> thanks to that I think I now have the a680 and a690 gmu firmwares pinned down

15:00 <qzed> haven't tried the a690 one yet though, as I'm still trying to figure out what the first one is supposed to be

15:01 <qzed> if it's not in the loader function that I've found, sqe will probably be quite a bit harder to pin down

16:07 <qzed> okay, so this unknown firmware is loaded to two memory regions

16:08 <qzed> one seems to be at some offset 0x1b400 * 4 and the other at 0x1c400 * 4 (*4 as those seem to be 32 bit registers)

16:09 <qzed> size is 16KB per region

16:09 <qzed> I don't think it's sqe though as the second region mostly gets filled with zeros

16:11 <qzed> also in the first region there's a "SIGABRT: Abnormal termination" string

16:36 <robclark> elf file with different sections, perhaps?

16:48 <qzed> there's no elf header as far as I can tell

16:49 <qzed> seems a bit like this legacy thing: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/adreno/a6xx_gmu.c#L708

16:50 <qzed> would at least fit with the image size, except that it's split into two blocks instead of just one

20:01 <CosmicPenguin> silly oftc with the nics. You can match up the load addresses with the open kernel - the load process should be pretty similar

23:43 <qzed> so I'm fairly certain that I have found the sqe firmware for both a680 and a690...

23:43 <qzed> but it still times out

23:44 <qzed> I've tried using afuc-disasm to verify the sqe firmware and things look okay

23:44 <qzed> at least for the a680 one

23:45 <qzed> it does show a bunch of assembly code which I guess could make sense

23:46 <qzed> also the firmware version numbers seem to be fairly close to the already known ones (i.e. a680 is slightly lower than a630 and a690 is slightly higher than a660)

23:46 <qzed> unfortunately afuc-disasm doesn't seem to like the a690 firmware... it seems to be stuck in a loop

23:47 <qzed> robclark, bamse: any ideas? could the timeout be caused by something else?

23:48 <qzed> also what's with the zero-length blocks in the gmu firmware?

23:48 <qzed> the windows driver does something with them but I haven't quite figured out what yet