-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flashing a Blank Chip with Patched BIOS File in *.fd Format Using the CH431A Module. #213
Comments
Just change the extension to rom or bin and flash ... |
Thank you for your reply. I did give that a try, but no joy. That got me wondering and I opened the existing official BIOS and the patched one next to each other in a HEX editor. The two files are radically different, so I'm a little lost now. I read through the entire tutorial on here about patching BIOS to enable ReBar and from what I understood the differences should be relatively minor after patching. Do you set the voltage using the jumper on the pins marked 1, 2, 3, TX, RX, GND, and 5V? The jumper is currently sitting on 1 and 2. |
Haven't flash Asus bios with CH before, so I'm not sure if capsule needs to be removed or not, but fd extension is from mmtool and you can safely rename it. Do a dump of current bios and compare... |
The BIOS files ASUS provides are definitely CAP files. Although I'm not sure what removing a capsule means. So looking at both the cap file and the *.fd file (which I have renamed to be a *.rom file now) I can see the most obvious difference is that in the cap file the entire structure is contained within a master heading called "AMI Aptio capsule", and in the patched file the begins one step below this with "Intel image". Does that mean anything? I have compared both files with the UEFITool, and with the exception of the above discrepancy, the differences are in fact quite small. Just the few lines added or changed during the patching process. So it looks like the patched file is actually what it claims to be, which is good. Now I just need to figure out how to get it onto a chip that will post. |
You can remove capsule with uefitool or hex editor. |
Are you sure chips are compatible? What are the serial numbers on them? |
I bought the blank one from a highly-rated seller on eBay who specializes in BIOS related hardware. Chip preinstalled on M/B: Winbond 25Q128FVIQ - 1825 Chip I received: GigaDevice GD25Q128CPIG - EP16262E - AH1319 |
Okay, you may be on to something there. I tried reading the BIOS off the Winbond chip, saving it, and writing it onto the GigaDevice chip. The GigaDevice chip won't post when I install it. The only other thing I can think of is that my CH431 module is bad and garbling things up during reads and/or writes. |
From specs, both chips should be compatible. Pinout is the same but their clocks are different - although I don't think that should be the problem. Problems when opening bios dump are not normal. Is the chip correctly recognized by software when connected? |
I recently came across a thread on here (now closed) started by community member LatiosAeon detailing his frustrations with getting his patched BIOS working to enable ReBar on his ASUS Prime Q270M-C motherboard. It was the only reference I had been able to find discussing how to do this on my motherboard, and to my everlasting joy not only did the user solve the issue, but they also provided a copy of the pathed BIOS file that ultimately did the trick. The thread can be found here: #68.
So I have now downloaded the patched file. I have also purchased a CH341A programming module and a blank BIOS chip compatible with this motherboard (although it is not the same make and model as the existing one). What I have not been able to do is bring these three things together to create a working chip that will post. The BIOS (Q270.zip) provided is an *.fd file, whereas the programming software only appears to recognise *.rom, *.bin, and *.hex files. I did begin the experiment by downloading the most recent BIOS directly from ASUS to test if the programmer was working, but this failed as it was a *.cap file and the programming software threatened to cut part of it off as it was too big. The actual warning was written in unintelligible English, but that seemed to be the gist of it. I did try writing the *.fd file directly to the chip, which the program appeared to at least try, but the result did not work.
As will be obvious by now, I am no programmer. But I generally quite good at following even detailed instructions and getting a positive result. In this case, however, I have been unable to find any instructions about converting a *.fd file to one of the formats I need that did not assume a level of knowledge I sadly do not posses. And yet I am convinced it can't be that hard if the user who created it uploaded it in this format for others to use.
If anyone out there with the know-how is willing to take a minute or two and point me in the right direction on this I would be eternally grateful.
ps. I did originally post something similar to this as a reply to the thread mentioned above, however, it would seem that while the GUI for this website has no problem allowing one to do this, it also deletes said reply immediately if the discussion is already closed. You'll pardon my frustration I hope, but isn't this just a tad idiotic?
The text was updated successfully, but these errors were encountered: