First off my membership to this forum is long overdue. I’ve been referencing it for little bits and bobs for years, and the community here is one I’m happy to now be a part of. While I’m no Guru like so many others on here, I hope that someday I too can contribute content here as well to pay back all the times I’ve been helped.
Some background on how I ended up with a blank BIOS:
Initially, I had fallen victim to a failed BIOS update that left me with a machine that wouldn’t even post or run recovery operations. As the title suggests, I was able to resurrect my cooked Sapphire PURE Mini E350 (IPC-E350M1) motherboard by using Pacman’s RaspberryPi repair technique (thanks Pacman!). Just to be safe, I used “flashrom -r backup.rom” to save what was already on the ROM chip to a file, just in case.
After performing the erase/write operations with the fresh .ROM image from the Sapphire, it booted fine and I breathed a sigh of relief. However the low-level nature of repair or course wiped out all the unique information that the SPIROM holds, such as MAC address, UUID, Serial #, and probably others that I’m just not aware of. These changes have made many programs and Windows 8.1 very grumpy, since to them it appears that I’m trying to bypass license authorization. My goal is to get the board exactly like it was, with all unique information restored, which should be possible because I imaged the ROM chip before rewriting it, if only I knew how to get the UUID, MAC, and Serial# out of the saved backup.rom file.
So here are my main questions:
1.) How do I get the unique info extracted out of the old ROM file? My assumption is that while the microcode in the old ROM image was corrupted, it is likely that the unique stored values may still be intact and extractable.
2.) Once I have those values, what is the best technique for putting them all back into the board? Do I use a tool like DMI236 to individually shove them all back in one at a time? Do I take the old corrupt ROM file’s unique strings and copy it into the fresh, new, working ROM and use the RasPi to just burn the whole thing again but this time with the missing unique bits?
The biggest issue is that I cant seem to find any tools that will let me extract those bits from the old ROM image. FD44Editor looked promising but only seems to work on ASUS images.
Any help would be appreciated, I’ve spent a few hours trying to find ways to extract the data, and I’ve even successfully written the MAC because it was on a sticker on the mobo, but the dizzying number of tools is making hard to find out how to extract the UUID and serial# from a ROM image instead of a live system. It seemed like getting it to boot would be the hard part, and not getting the unique info back into the ROM chip .
Well I have spent a couple more days digging around trying to figure out how to proceed with little success.
* I cant find any utilities that allow me to pluck the lost UUID, serial #, etc out of the SPI image I backed up before the RasPi rescue.
* I’ve stared at the two files under a HEX editor, but that’s not been useful in finding the UUID in the old ROM.
* I could burn the corrupt ROM image back on to the ROM chip using the raspberry pi again, then selectively write parts of the factory fresh rom, but I’ve no idea what addresses I want to preserve when I write the current factory image.
* I’ve downloaded every weird russian/AMI tool I could find in hopes of extracting my old UUID and Serial#, with no luck. Though there are so many I’m shocked one doesn’t exist to do this.
So, some concise questions Ive come up with:
1.) Is there any way I can extract what the UUID or Serial# was from the windows registry? All the windows tools Ive seen seem to query the Mobo live, or at least what was read at boot. Nothing seems to pull from what windows activated or installed with.
2.) Is there any wizard that can guide me through extracting the unique info from the backed up ROM image? Can I send someone exotic beers to do it for me?
3.) If the above two ideas are impossible or stupid, can anyone tell me what regions of the chip I would flash over to replaced the corrupt image, but retain the unique info?
OK, well I have learned more and can share an approach on how to solve this issue. I looked into it and learned that I have an APTIO IV bios from AMI. There is a tool called AMIBCP (i used version 4.55.0070) that allows you to open a ROM image and view pertinent data inside of it. One of the tabs called "DMI Tables" contains unique system information. Here is a breakdown of the first few entries for that tab:
Type 00 = BIOS Information (Handle 0000h/0x0000/0)
Offset 04 = BIOS Vendor
Offset 05 = BIOS Version
Offset 08 = BIOS Release Date
Offset 14 = BIOS Major Release
Offset 15 = BIOS Minor Release
Type 01 = System Information (Handle 0001h/0x0001/1)
Offset 04 = System Manufacturer
Offset 05 = System Product Name/Model
Offset 06 = System Version
Offset 07 = System Serial Number
Offset 08 = System UUID
Offset 25 = SKU Number
Offset 26 = Family
Type 02 = Base Board Information (Handle 0002h/0x0002/2)
Offset 04 = Base Board Manufacturer
Offset 05 = Base Board Product Name/Model
Offset 06 = Base Board Version
Offset 07 = Base Board Serial Number
Offset 08 = Base Board Asset Tag
Type 03 = System Enclosure Information (Handle 0003h/0x0003/3)
Offset 04 = System Enclosure Manufacturer
Offset 06 = System Enclosure Version
Offset 07 = System Enclosure Serial Number
Offset 08 = System Enclosure Asset Tag
Different APTIO version will require different AMIBCP versions, but I am not entirely sure how to associate a version of the tool to a BIOS version. Hopefully there is enough info on the net to help people find that info.
but you could try to show some photos on how you did ? plus a link to the famous post that helped you…
EDIT by Fernando: Off-topic remarks and links to various YouTube videos removed
why do you re-edit posts ?
you should do that with UBU…that kills mainboards : of course the more expensive$
The post that helped me restore the system is Pacman’s lovely guide to restoring a BIOS with a Raspberry Pi. It is full of useful photos, and you can find it >>>>Here<<<<
The only difference is that I used a Raspberry Pi 3 Model B, which has additional pins on the GPIO header, though everything up to pin 26 appears to be pretty much the same. I was unable to restore my UUID, but at least my system boots now!