GA-Z170X-Designare (rev. 1.0) - Works

[Wesselinator]

Intro

This is a an old, weird motherboard with a lot of "growing pains": weird version of thunderbolt, weird NVMe PCIe drive support, weird U.2 SATA connectors, etc.
Crazy for the time but because it so strange, I've had the displeasure of being the Edge Case more often then not.
It also has SLI support (which is fine as far as I used it RIP you magnificent bastard).
Very cool feature is that the bios status readout are 2 physical 8-segment displays! Makes troubleshooting great!

Spec

• GA-Z170X-Designare (rev. 1.0) Running F23g
• Intel® Z170 Chipset
• "Above 4G Decoding" Available in BIOS
• i5-6600 Skylake - LGA1151
• Dual MX25L12873F BIOS chips
• Intel Arc B580 Steel Legend 12GB OC
• Running Gurada Linux (Arch) on Kernel 6.13.3-zen1-1-zen
• UEFITool r230.8d6fa65-1.5
• flashrom 1.5.1-1

Attempt 1

Got a fresh copy of the F23g firmware, added the DXE module using UEFITool to the end of the volume block as described, patched and considered if DSDT was required, I don't think it is but you can correct me:

[    0.275943] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
[    0.275945] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
[    0.275946] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[    0.275947] pci_bus 0000:00: root bus resource [mem 0x60000000-0xefffffff window]
[    0.275949] pci_bus 0000:00: root bus resource [mem 0xfd000000-0xfe7fffff window]
[    0.275950] pci_bus 0000:00: root bus resource [mem 0x2000000000-0x2fffffffff window]
[    0.275951] pci_bus 0000:00: root bus resource [bus 00-7e]

I think 0x2fffffffff > 0xfffffffff

QFlash (Gigabyte's bios flashing solution) didn't work, verification issues.

Needed to do the Gigabyte Workaround by breaking verification, just flipped the hex from 01 to 02.
QFLash STILL didn't want to flash.
Was considering using flashrom -p internal when, I stumbled on a BIOS setting called "Intel BIOS Guard" or something.
Switched that to disabled and now I can flash!

Take a backup inside of QFlash (cool feature!, you can straight up dump a working flash to your usb device!)
Flashed it using QFlash.

Bricked.
Frick.
Boot loop with the BIOS readout at 0 constantly
Tried to force the use of the backup BIOS chip
Frick. It got flashed as part of the QFlash process (wtf that's very stupid, usually that goes later and copies a WORKING main chip over to the backup chip instead of flashing them BOTH AT THE SAME TIME!?)

Bought a CH341A (the bad black board), needed to mod it for 3.3V (I didn't want to break my chips) hooked up my RPI (I should have just bought a SOIC8 clip with jumpers for my RPI but whatever, I have the crappy programmer now), was a struggle to get the clip seated correctly.

SUCCESS! Flashrom can see it.

It AUTO detects MX25L12805D and is asking me if I want to use MX25L12835F/MX25L12845E/MX25L12865E instead.
Frick. My chip is MX25L12873F and isn't explictly supported.
Umm, YOLO, it's a brick regardless. I pick -c "MX25L12835F/MX25L12845E/MX25L12865E",

SUCCESS! Flashrom dumps it!

Cool. I then write my backup to the chip directly and reboot.

SUCCESS! I am back!

I immediately try to re-flash the backup image using QFlash to make doubly sure all is good (take a backup2 in case)

Semi-Bricked.
WTF?

Re-flash again, and again, all the same outcome.
Re-flash with the CH341A, all GOOD?!
WTF?
Check the diff of backup and backup2.
They are different.
backup2 has sections missing (FFFF...) backup1 also has some.
Yikes.
That means the builtin QFlash is not perfect. Probably a Southbrige that is going bad or some SPI line that's bad or a clock crystal that's bad... or WHO KNOWS!

I later try to use the flashrom -p internal in my OS and it auto detects MX25L12805D WITH NO alternatives, weird.
Reading is fine, I think, until I dump multiple times and EACH one is different with different blocks missing.
Yikes.
This COULD be because the chip is the wrong type inside of flashrom OR it could be the maybe bad data interface between the southbridge and the bios chips.
The internal read was VERY fast (1m) while the CH341A was slow (10m).

This could be related, but it's unimportant now, I know now that:

1. QFlash can't be trusted
2. CH341A works
3. I don't want to break the descriptors.

Attempt 2

Now instead of running off of the fresh F23g firmware I will be running off of the flashrom dumped firmware binary.

I use the dumpped one which probably has some holes, but is ultimately functional.
I add the ReBar blob and the patched PciBus blob.

I saw that the uefipatch changed the layout of the a big block of binary inside the image and was afraid that that was what caused the original issue.

I flash and... all is good?

I boot and run the ReBarState @ 13 first.
No dice.
Bump it up to 32.
Nope.

I can't get rebar to work.

I'm not 100% it is even loaded.
The efi variable is set correctly, so that's good at least.

bootup

Everytime I reboot I look to see if this block is fixed.

This might be a DSDT, maybe one of the holes, IDK.

The RPI has similar issues but they are figuring out ReBAR support so it checks out:

raspberrypi/linux#6621 (comment)
geerlingguy/raspberry-pi-pcie-devices#695

[    6.912668] xe 0000:03:00.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=none:owns=io+mem
[    6.913722] xe 0000:03:00.0: [drm] Attempting to resize bar from 256MiB -> 16384MiB
[    6.913729] xe 0000:03:00.0: BAR 2 [mem 0xc0000000-0xcfffffff 64bit pref]: releasing
[    6.913758] pcieport 0000:02:01.0: bridge window [mem 0xc0000000-0xcfffffff 64bit pref]: releasing
[    6.913760] pcieport 0000:01:00.0: bridge window [mem 0xc0000000-0xcfffffff 64bit pref]: releasing
[    6.913763] pcieport 0000:00:01.0: Assigned bridge window [mem 0xc0000000-0xd07fffff 64bit pref] to [bus 01-04] cannot fit 0x400000000 required for 0000:02:01.0 bridging to [bus 03]
[    6.913765] pcieport 0000:02:01.0: bridge window [mem 0x00000000 64bit pref] to [bus 03] requires relaxed alignment rules
[    6.913768] pcieport 0000:00:01.0: Assigned bridge window [mem 0xc0000000-0xd07fffff 64bit pref] to [bus 01-04] cannot fit 0x400000000 required for 0000:01:00.0 bridging to [bus 02-04]
[    6.913771] pcieport 0000:01:00.0: bridge window [mem 0x00000000 64bit pref] to [bus 02-04] requires relaxed alignment rules
[    6.913775] pcieport 0000:01:00.0: bridge window [mem size 0x400000000 64bit pref]: can't assign; no space
[    6.913777] pcieport 0000:01:00.0: bridge window [mem size 0x400000000 64bit pref]: failed to assign
[    6.913779] pcieport 0000:02:01.0: bridge window [mem size 0x400000000 64bit pref]: can't assign; no space
[    6.913780] pcieport 0000:02:01.0: bridge window [mem size 0x400000000 64bit pref]: failed to assign
[    6.913782] xe 0000:03:00.0: BAR 2 [mem size 0x400000000 64bit pref]: can't assign; no space
[    6.913783] xe 0000:03:00.0: BAR 2 [mem size 0x400000000 64bit pref]: failed to assign
[    6.913785] pcieport 0000:00:01.0: PCI bridge to [bus 01-04]
[    6.913790] pcieport 0000:00:01.0:   bridge window [mem 0xec000000-0xed3fffff]
[    6.913794] pcieport 0000:00:01.0:   bridge window [mem 0xc0000000-0xd07fffff 64bit pref]
[    6.913807] pcieport 0000:01:00.0: PCI bridge to [bus 02-04]
[    6.913815] pcieport 0000:01:00.0:   bridge window [mem 0xec000000-0xed3fffff]
[    6.913820] pcieport 0000:01:00.0:   bridge window [mem 0xc0000000-0xcfffffff 64bit pref]
[    6.913830] pcieport 0000:02:01.0: PCI bridge to [bus 03]
[    6.913838] pcieport 0000:02:01.0:   bridge window [mem 0xec000000-0xed1fffff]
[    6.913852] pcieport 0000:02:01.0:   bridge window [mem 0xc0000000-0xcfffffff 64bit pref]
[    6.913872] xe 0000:03:00.0: [drm] Failed to resize BAR2 to 16384M (-ENOSPC). Consider enabling 'Resizable BAR' support in your BIOS
[    6.913875] xe 0000:03:00.0: BAR 2 [mem 0xc0000000-0xcfffffff 64bit pref]: assigned
[    6.913903] xe 0000:03:00.0: [drm] VISIBLE VRAM: 0x00000000c0000000, 0x0000000010000000
[    6.914101] xe 0000:03:00.0: [drm] Small BAR device
[    6.914102] xe 0000:03:00.0: [drm] VRAM[0, 0]: Actual physical size 0x0000000300000000, usable size exclude stolen 0x00000002fb800000, CPU accessible size 0x0000000010000000
[    6.914104] xe 0000:03:00.0: [drm] VRAM[0, 0]: DPA range: [0x0000000000000000-300000000], io range: [0x00000000c0000000-d0000000]
[    6.914106] xe 0000:03:00.0: [drm] VRAM: 0x0000000300000000 is larger than resource 0x0000000010000000
[    6.914107] xe 0000:03:00.0: [drm] Total VRAM: 0x00000000c0000000, 0x0000000300000000
[    6.914109] xe 0000:03:00.0: [drm] Available VRAM: 0x00000000c0000000, 0x00000002fb800000
[    6.924288] xe 0000:03:00.0: [drm] Finished loading DMC firmware i915/bmg_dmc.bin (v2.6)

I have tried with pci=realloc and with xe.vram_bar_size=16384, xe.vram_bar_size=8192, even xe.vram_bar_size=1024
Same (but with the 256MiB -> 16384MiB diffrent)

If you have any suggestions I could try/verify I am all ears.

Conclusion

IDK. might work in windows.
¯\_(ツ)_/¯

[Wesselinator]

Ok IDK What I did differently this time but I double checked my EFI vars and IT WASN'T there!

So I reran the ReBarState (used 32) and it's working now! :D

dmesg

6.837682] xe 0000:03:00.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=none:owns=none
[    6.838745] xe 0000:03:00.0: [drm] VISIBLE VRAM: 0x0000002000000000, 0x0000000400000000
[    6.838848] xe 0000:03:00.0: [drm] VRAM[0, 0]: Actual physical size 0x0000000300000000, usable size exclude stolen 0x00000002fb800000, CPU accessible size 0x00000002fb800000
[    6.838851] xe 0000:03:00.0: [drm] VRAM[0, 0]: DPA range: [0x0000000000000000-300000000], io range: [0x0000002000000000-22fb800000]
[    6.838853] xe 0000:03:00.0: [drm] Total VRAM: 0x0000002000000000, 0x0000000300000000
[    6.838855] xe 0000:03:00.0: [drm] Available VRAM: 0x0000002000000000, 0x00000002fb800000
[    6.849521] xe 0000:03:00.0: [drm] Finished loading DMC firmware i915/bmg_dmc.bin (v2.6)

lspci -vv | grep Arc -A10

03:00.0 VGA compatible controller: Intel Corporation Battlemage G21 [Arc B580] (prog-if 00 [VGA controller])
        Subsystem: ASRock Incorporation Device 6020
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin ? routed to IRQ 144
        Region 0: Memory at 60000000 (64-bit, non-prefetchable) [size=16M]
        Region 2: Memory at 2000000000 (64-bit, prefetchable) [size=16G]
        Capabilities: <access denied>
        Kernel driver in use: xe
        Kernel modules: xe

[Wesselinator]

I'll do a comment with everything I did on the #11
I suspect the descriptors are actually stored somewhere else, I want to try to load up a fresh F23g, and see what it does.