Heya,
I’ve used the OSD Sidekick tool to upgrade the firmware of my monitor, it is showing all the signs of brickage as reported on reddit etc. RMA is the only solution they suggest, which isn’t an option for me 
.
So far, I have found 1 post on reddit where someone sold the monitor for parts, and the buyer fixed the firmware with a spi programmer. ( r/gigabyte/comments/18i2cmn/comment/kwrf1ix )
Where I am at now is that I have bought a CH341a, was able to read a corrupt firmware off of it.
Was able to (when opening the zip file in asprogrammer) sucessfully program contents onto the GD25D40 chip. And read that as well, but it is not functioning.
Issues I am having is that the F10 firmware ( see gigabyte/aorus support site for the file ) is packaged in a zip file. As a zip file it has the correct size to be flashed to the IC.
When extracted it seems to have a load of padding and can’t be flashed as it is too big…
I am wondering how I either use the zip file directly (whilst it seems to have some start and end padding of a ZIP file when loaded into asprogrammer/hxd).
Or how I correctly remove the padding from the extracted file to end up with the file size fitting inside the 524288 by(/i)tes…
I am willing to experiment but as it is likely obvious quite inexperienced in how to fix this.
P.s. I dunno if this is the right part of the forum
you can use a hexeditor to remove the padding but be sure to ONLY remove the trailing and leading zeros
If you remove the last character, that is a checksum bit and using a PROM programmer you can bork the image further
best of luck and be sure to disable all power management functions on your workstation before attempting this. Don’t want Fedora or Windows powering down your programmer mid push.
p.s. update this thread with your results
1 Like
I’ve tried removing leading and trailing padding. Even padding inbetween. But it seems the provided bin file gets some magic sauce applied by the OSD sidekick (or it’s dll’s)
The padding doesn’t seem to account for the 500k bytes that are too much…
I even opened the RFlash.dll in Ghidra and saw (with my limited programming understanding) some weird stuff it does with incoming data.
Such an amazingly painful proces but ah well. I gave up and as a last ditch effort, asked Gigabyte support for a bin file that can be directly flashed.
1 Like
It’s likely just verifying the checksums after encoding and stripping most of the checksums
This is standard operating procedure
If I have a G32QC open I would dump the .bin
Unfortunately I only have the knockoff one (can’t remember name) with a burned out driver board
1 Like
Knockoff one? The G32QC A? Or some random knockoff brand.
Maybe with the knowledge of a knockoff brand I have better luck finding the info.
The chip was readable without any power to the board so with a bit of luck and a ch341a you could read the chip 
1 Like
Whole knockoff brand with same plastics, unsure if it’s the same panel.
Would love to compare
Will dig it out after my meetings
2 Likes
@TryTwiceMedia I can’t post pictures yet. But the board is AmTRAN labeled and has a
BT8290A
GSP7C31N chip under the AmTRAN logo
The Bios/firmware chip seems to be close to the USB port and is labeled
HH1829
25D40CT
AP 16566.
1 Like
I am starin at a Viotek GN32C
Looks like it’s an MSI (and Lenovo) knockoff, not Gigabyte.
My fault
2 Likes
No worries!
Gigabyte support for now didn’t seem to understand the question, and went to a boilerplate “You need to send it in, because it can be a hardware issue”.
Instead of “Oh we have that file” or “We don’t provide that kind of firmware file”.
So I am still looking for a way to get the Bin file to fit on the chip. Or a copy of someone’s working firmware 
Thanks for (as we say in NL) thinking along @TryTwiceMedia 
1 Like
I now wonder if this is the right forum section to ask this question