Question regarding bios flash

[R5Eandme]

eSATA problem was traced to dead drives. Two of them. Totally dead. Surprised me. Aside from that, the method works.

If anyone is interested, I can put together a guide for resuscitating your BIOS using a BIOS programmer (won't fix non-BIOS problems, but if flashback isn't working, or if you bricked the BIOS, it should work).

Hi, and congrats on recovering from a corrupted BIOS chip w/o an RMA! I just did that myself with the dual BIOS R5E. I used an EEPROM programmer to copy the good BIOS image onto a replacement Winbond chip to replace the corrupted one. I am curious to know if you used the Pomona clips to read a known good bios image into a BIN file, then wrote that to the bad chip? Or did you use a file from the downloaded CAP file? The latter would not have the MAC address, UUID and motherboard Serial No, which I understand can be added using the FD44Editor utility. If you didn't add those identifiers, is it working ok? Maybe they are on protected memory blocks of the original chip and adding the new code from the CAP file doesn't disturb it?

[lightknightrr]

Hi, and congrats on recovering from a corrupted BIOS chip w/o an RMA! I just did that myself with the dual BIOS R5E. I used an EEPROM programmer to copy the good BIOS image onto a replacement Winbond chip to replace the corrupted one. I am curious to know if you used the Pomona clips to read a known good bios image into a BIN file, then wrote that to the bad chip? Or did you use a file from the downloaded CAP file? The latter would not have the MAC address, UUID and motherboard Serial No, which I understand can be added using the FD44Editor utility. If you didn't add those identifiers, is it working ok? Maybe they are on protected memory blocks of the original chip and adding the new code from the CAP file doesn't disturb it?

I did end up using the Pomona clips (I had ordered a different set of test clips, but what arrived didn't match what was shown on the product page; it also was so chunky that I couldn't grab the Winbond chip, because there are some (mysterious) headers next to it that physically prevent the clip from attaching). The BIOS programmer was a CH341A. I downloaded the vanilla BIOS from Asus's website, versions 1403 and 1501; then I used UEFITool (https://github.com/LongSoft/UEFITool...ses/tag/0.21.5) to convert the .CAP file to a .BIN file. I didn't add any identifiers, but I might do that later; seems to be running just fine (actually, I finally got my G.Skill F4-3200C14-16GTZ (32GB total, 2 sticks) to run at the promised 3200Mhz, and it seems stable thus far; took some tweaking, but that's a story for another time). I would think that the MAC address for the NICs would be a part of the NIC's chipset, not the BIOS, but I could be wrong; in either case, I'm using my wired NIC right now, and it's working just fine. According to the AI Suite 3, my motherboard's current serial number is MB-1234567890, so I might patch that later (I think the tool UEFIPatch might help there, but I haven't used it yet); as for my UUID, I imagine I will need to boot into the BIOS to get that, and if it needs to be changed, again, I'll change it later on.

Here's some useful videos:

Using a CH341A programmer:
https://www.youtube.com/watch?v=L0ChYNwunUE

Asus CAP to ROM file (same process for converting to BIN files):
https://www.youtube.com/watch?v=REOYyszYgF4

[R5Eandme]

I did end up using the Pomona clips (I had ordered a different set of test clips, but what arrived didn't match what was shown on the product page; it also was so chunky that I couldn't grab the Winbond chip, because there are some (mysterious) headers next to it that physically prevent the clip from attaching). The BIOS programmer was a CH341A. I downloaded the vanilla BIOS from Asus's website, versions 1403 and 1501; then I used UEFITool (https://github.com/LongSoft/UEFITool...ses/tag/0.21.5) to convert the .CAP file to a .BIN file. I didn't add any identifiers, but I might do that later; seems to be running just fine (actually, I finally got my G.Skill F4-3200C14-16GTZ (32GB total, 2 sticks) to run at the promised 3200Mhz, and it seems stable thus far; took some tweaking, but that's a story for another time). I would think that the MAC address for the NICs would be a part of the NIC's chipset, not the BIOS, but I could be wrong; in either case, I'm using my wired NIC right now, and it's working just fine. According to the AI Suite 3, my motherboard's current serial number is MB-1234567890, so I might patch that later (I think the tool UEFIPatch might help there, but I haven't used it yet); as for my UUID, I imagine I will need to boot into the BIOS to get that, and if it needs to be changed, again, I'll change it later on.

Here's some useful videos:

Using a CH341A programmer:
https://www.youtube.com/watch?v=L0ChYNwunUE

Asus CAP to ROM file (same process for converting to BIN files):
https://www.youtube.com/watch?v=REOYyszYgF4

Good news that the BIOS programmed with the CH341A is working! And without entering all the identifiers.

I too wondered why the BIOS code would contain the MAC address of the NIC but I searched for it in the binary image of my BIOS and it was found at two different addresses. I understand you can access the NIC from within BIOS, maybe it has something to do with that, or maybe it has something to do with security because every MAC is unique. The UUID might also have to do with security. Other than writing to the chip with a EEPROM programmer, the usual flash process involves a signature verification so that the boot can start from a trusted source, to my knowledge.

Your mobo S/N from AI Suite 3 must be a general placeholder? On my R5E the S/N was on a sticker at the top of the board: 15 digits after "000-". The MAC was on the 24 pin ATX power connector. Don't know if it is the same locations for C6H. The UUID is hard to get, unless you have previously run from the cmd prompt: wmic csproduct get name, identifyingnumber,uuid as described in the BIOS Chip Recovery Program post and video https://www.youtube.com/watch?v=1TaZqJPG75A or you can use your Pomona clips to read from an original good chip that came on the mobo from ASUS, and it would contain those three identifiers and you can see and record them using the FD44Editor.

The replacement BIOS chips from www.bios-24chip.com can't contain the unique identifiers for your specific motherboard, yet customers seem to have great success with them. But still I'd be curious to know if future flashes with BIOS FLASHBACK work without those identifiers, or if Windows authentication still works without them. Sorry for the long post, this stuff is not only interesting, it's useful.

[lightknightrr]

Well, I'll officially care about the UUID when Asus's warranty support requires it for registration. ;-)

As for the uniqueness of MAC addresses...they are not unique (randomized), but you are (hopefully) unlikely to encounter another computer on the same network with the same MAC address (DHCP servers love that...). One of my old instructors told me a story about how they bought some NICs from some company, and bought enough of them that they ran into the same MAC address on more than one NIC (the addresses were insufficiently randomized). But it ultimately doesn't matter, since most OSs will let you specify a different MAC address for the NIC than the one it ships with (if you really want to do that).

Flashback has never worked on the two Hero boards I've tried to use it on thus far. Followed the instructions, but it just won't work. I'm starting to think it hates Sandisk USB drives or something. But I will say that upgrading from a programmed BIOS does work -> I programmed in the 1403 version, then used the UEFI's Flash program to download and upgrade to the 1501 version.

What I'm tempted to do (and won't, because my soldering skills suck; need to apprentice myself to someone for like 6 months to learn to do it right) is add a DIP-8 socket, making the Winbond chip removable.

[R5Eandme]

Well, I'll officially care about the UUID when Asus's warranty support requires it for registration. ;-)

As for the uniqueness of MAC addresses...they are not unique (randomized), but you are (hopefully) unlikely to encounter another computer on the same network with the same MAC address (DHCP servers love that...). One of my old instructors told me a story about how they bought some NICs from some company, and bought enough of them that they ran into the same MAC address on more than one NIC (the addresses were insufficiently randomized). But it ultimately doesn't matter, since most OSs will let you specify a different MAC address for the NIC than the one it ships with (if you really want to do that).

Flashback has never worked on the two Hero boards I've tried to use it on thus far. Followed the instructions, but it just won't work. I'm starting to think it hates Sandisk USB drives or something. But I will say that upgrading from a programmed BIOS does work -> I programmed in the 1403 version, then used the UEFI's Flash program to download and upgrade to the 1501 version.

What I'm tempted to do (and won't, because my soldering skills suck; need to apprentice myself to someone for like 6 months to learn to do it right) is add a DIP-8 socket, making the Winbond chip removable.

It would be nice to have removable DIP8 chips, don't know why they went to SOIC8 after so many years with DIP8 sockets. Especially considering how easily these chips can be corrupted. I have never seen an SOIC8-to-socket adapter, I wonder how people retrofit those chips to a socket for easy removal of chips? Didn't find anything on youtube.

I believe you answered my question about being able to use an ASUS flash utility after having programmed a chip with an EEPROM programmer. You programmed in 1403 (originally downloaded as a CAP file), then used the UEFI flash utility to update to 1501, and all without putting in the identifiers. I wonder what all the identifiers are used for still.

Thanks for the good discussion and good luck.

[Clouseau]

Only way was able to get the flashback/recovery method to work was by using an old USB 2.0 drive had laying around. None of the 3.0 drives worked. The old drive had lying around was 128MB, the 1GB stick works as well.

[R5Eandme]

Only way was able to get the flashback/recovery method to work was by using an old USB 2.0 drive had laying around. None of the 3.0 drives worked. The old drive had lying around was 128MB, the 1GB stick works as well.

Now that you mention it, the times I've used the FLASHBACK button successfully it was with a USB 2.0 thumb drive, 16 GB, and formatted FAT32. There is a BIOS setting "USB Configuration" > "Intel xHCI Mode" and you can set it from [Smart Auto] to [Enabled]. Enabled will turn on the USB 3.0 controller and not wait for OS drivers for USB 3.0. Maybe that setting will allow FLASHBACK to work with a USB 3.0 drive? Just guessing. I had to set it to Enabled so my USB 3.0 keyboard and mouse would not have severe lag and otherwise go nuts when navigating BIOS before installing Windows.

[PeZzy]

I suspect the cold boot problem will become more prominent as we head to winter. Temperature does seem to affect the problem, as I haven't had a single cold-boot problem this past summer.

[lightknightrr]

And I'm back to tweaking the RAM. The G.Skill F4-3200C14-16GTZ (or something...could have been the memory controller on the CPU for all I know) collapsed after I started putting some weight on it (fired up a game...Disciples III:Reincarnation, with all the eye-candy set to maximum). I'll post my current settings (which are good enough to boot into Windows, and work for a while) later on.

As for the USB 2.0 drive thing, that could definitely be it. All the drives I've been using are USB 3.0 drives. Still, if this is actually the problem...*facepalms*...

[lightknightrr]

Old settings:

Extreme Tweaker:
Ai Overclock Tuner: Default (Nothing special here)
Memory Frequency: DDR4-3200Mhz
EPU Power Saving Mode: Disabled
TPU: TPU II

CPU SOC Voltage: Manual mode
- VDDSOC Voltage Override: 1.125
DRAM Voltage: 1.35

DRAM Timing Control:
DRAM CAS# Latency: 14
DRAM RAS# to CAS# Read Delay: 14
DRAM RAS# to CAS# Write Delay: 14
DRAM RAS# PRE Time: 14
DRAM RAS# ACT Time: 34
Trc_SM: 48
TrrdS_SM: 6
TrrdL_SM: 8
Tfaw_SM: 39
ProcODT_SM: 96 ohm
Cmd2T: 1T

Extreme Digi+ Power Control:
DRAM Current Capability: 130%
DRAM VBoot Voltage: 1.35

Tweaker's Paradise:
VDDP Voltage: 0.975
VDDP Standby Voltage: 0.975



I've since altered them so that
ProcODT_SM: 80
DRAM Voltage: 1.375
TPU: Use current settings

And enabled some more extreme VRM stuff.

Thing is being an absolute PITA. It will work for a while, then reboot...sometimes hours later. Seems to dislike Flash, or my video card, a XFX RX480.