Could someone update the UEFI 2.10 for AsRock Fatality H87 Performance.

http://www.asrock.com/mb/Intel/Fatal1ty%...ownload&os=BIOS

Intel RST OROM v13.1.0.2030 and an Intel EFI SataDriver v13.1.0.2030,
EFI GopDrivers Haswell 5.0.1037
Intel LAN OROM 1.5.53 EFI 6.2.08

@Fernando,
@Sonix,

Do you know a tool working for ASUS AMI BIOS board or for any AMI BIOS board to save the current BIOS with all its settings ?

The ASUS 'flashback operation' only works to restore an original or UBUed AMI BIOS, but it will be helpfull to save on a USB key a current working BIOS with all its settings before testing a new BIOS version.

Sorry for the delay.

Zitat von asrlab im Beitrag #492

---

when development for AMD?
little by little ...

---

Zitat von RMK_99 im Beitrag #494

---

Could someone update the UEFI 2.10 for AsRock Fatality H87 Performance.
http://www.asrock.com/mb/Intel/Fatal1ty%...ownload&os=BIOS
Intel RST OROM v13.1.0.2030 and an Intel EFI SataDriver v13.1.0.2030,
EFI GopDrivers Haswell 5.0.1037
Intel LAN OROM 1.5.53 EFI 6.2.08

---

Zitat von 100PIER im Beitrag #495

---

Do you know a tool working for ASUS AMI BIOS board or for any AMI BIOS board to save the current BIOS with all its settings ?

The ASUS 'flashback operation' only works to restore an original or UBUed AMI BIOS, but it will be helpfull to save on a USB key a current working BIOS with all its settings before testing a new BIOS version.

---

@ Fernando
I had an idea to make support for AMD. But I have built on the motherboard chipset from AMD. A risk strangers motherboards I do not want, even on tests. Besides OROM SATA may not be compatible between different controllers. If anyone has a desire to write support for AMD, very good, but I'll pass. Sorry if anyone disappointed.

As for the BIOS from AsRock. There is no free space, all culled pictures and they can not be removed, you can get a brick. In support AsRock contact useless we've tried.
Of course, you can update some modules, for example:
GOPDriver, CPU microcode.
You can try to refresh the OROM and EFI IRST, but then it will be necessary to remove OROM VBIOS or OROM network card.
In general, if RAID-mode is not used, then there is no sense that menstruation.
But if used, then built OROM VBIOS better not touch.
OROM network card is only needed to boot the OS on the local network. If not used, it can be removed.

Zitat von SoniX im Beitrag #501

---

@ Fernando
I had an idea to make support for AMD. But I have built on the motherboard chipset from AMD. A risk strangers motherboards I do not want, even on tests. Besides OROM SATA may not be compatible between different controllers. If anyone has a desire to write support for AMD, very good, but I'll pass. Sorry if anyone disappointed.

---

@SoniX and all other ninjas

Maybe you will find this useful, if you do a lot of search for BIOS modules. Place them in UBU folder. You will need Python installed in its default location C:\Python for the full version to work. I used Python 2.7, maybe 3.x will also work.
Extract1 was the original version, working with a database and hexfind. It is the most reliable, but it will throw a lot of unknowns, since the database is small and it will never be sufficient. Only useful if you want to store the modules.
Extract2 was the second version, using oromver when possible. A lot better, but with a few false results in GOP, VBIOS, Intel Lan.
Extract3 was developed the past week, using a Python script, oromver and drvver for a fully automated setup. It should produce a reliable result in 90+% cases. But it needs a lot of real world testing, since the patterns might not be always accurate. I had zero knowledge of Python coding, all was done using web search for specific actions, and I must say that Python was up to the task. It might not be pretty, but I haven't even reached the point where I start to think about better structure, distinctive labels, cosmetics. And since this is just a script that does its job in seconds, it might be a while. Right now I need to do a lot of testing.

Since I wanted to extract ME and Gbe firmwares, I had some inspiration from UEFITool, particularly Intel regions. But I ignored the bug with BIOS base, which gives this the advantage of working even with Gigabyte boards. CodeRush should do the same in UEFITool and just display a warning. It is not like the BIOS would actually overlap ME, otherwise the board wouldn't even POST. I had also separated ME in 1.5M and 5M, plus I instructed the script to extract 1.5M without its usual padding, i.e. ME 1.5M will always have 1524 KB. I haven't found a standard size for 5M, unfortunately.

I implemented a way to extract microcodes from Intel and AMD. AMD yet again plays by erratic rules, so I had to restrict the extraction to those I had already found and know their size, otherwise the script will display the info without extraction. Intel microcodes on the other hand is a walk in the park, working well with padding, where MMTool fails to see beyond. It will even work on full BIOS, but it is better to use it on the ffs containing microcodes.

AGESA is extracted only for my needs, to compare different boards and see if it can be extracted. It appears to be constructed for each BIOS and cannot be ported.

Asmedia firmware can be extracted, but it is missing a valid header. If you find anything newer, please share, so I can take a look.

NEC-Renesas firmware is not yet extracted, but it can be done easily. It is not yet implemented because I always find the same versions, 3.0.3.2 and 4.0.1.8.

Marvell firmware is a little complicated. Version 92xx is easy to tag, but 91xx needs special care and might not always work. From the other firmware's components I have only opted to extract the version of Autoload. The Loader should be located in the same module as Autoload and it is easy to extract the version, but I have only found one case of 91xx/92xx firmware, so it is on hold.

I added a Z.version.bat where you can test the version finder on specific files, by simply inputing "file type". When you want to exit just input "q".

I will say this again. I am not a coder, so don't expect miracles and bug-free results. I only started to use Python and I keep adding things without fully testing them. Maybe someone else will find the bugs faster than me. And believe me, they are plenty. The end result must not be used without double checking. This is only to speed things up. If you find a new or strange version, use the manual way of extracting + renaming.

Examples:

@lordkag

Motherboards from MSI. Notice the following GUID C57AD6B7-0515-40A8-9D21-551652854E37 ;)
For Asus Z87-WS GUID AC91C28D-9244-4623-92CA-0AFBF3F07035 why is not saved.

Edit:
Does not save if you use:
#OROM and EFI Extract1-manual-drvver.bat
#OROM and EFI Extract2-oromver-drvver.bat
I checked does not want to work with Python version 3.4.1. With version 2.6 everything is fine. :)

It seems that Python 3.x changed some code. Anyway, I used Python 2.7.x (link here), which works for x86 and x64 OS.

I only worked on Extract3 the past week and then ported the changes to the older versions. The error for Z87-WS comes from calling :mvfw, but I don't know why is doing this. Maybe it is too much for batch to handle all of this. The only solution is to comment lines 966-967 in Extract1 and lines 1038-1039 in Extract2.

About MSI and UEFI Shell. Have you compared different boards and they are the same? I know the UEFI Shell can be downloaded from different places, but is the MSI UEFI Shell easily ported to other boards?

The 91xx EFI and firmware has some quirks. This is how it should look in P8Z77-V-DELUXE-ASUS-2104. If you find something out of order in other boards, please let me know:



The 92xx EFI and firmware looks like this, in Z87-WS:



Based on this, it would seem that the Marvell EFI Sata is universal, meaning for 9172, 9192, 9230 etc.. Not sure if it is AHCI or RAID or both.

A complete AMD set can be found in MSI A88X-G45-G 7900v11:



And a full set of firmwares in FM2A88X Extreme6+(2.90). These are the latest versions I have seen inside boards:



Aspeed and MegaRAID are found in WS boards. Example in Z9PE-D8-WS-ASUS-5404:

Zitat von lordkag im Beitrag #505

---

About MSI and UEFI Shell. Have you compared different boards and they are the same? I know the UEFI Shell can be downloaded from different places, but is the MSI UEFI Shell easily ported to other boards?

---

Zitat

---

If you find something out of order in other boards, please let me know:

---

Basically firmware seen only in Asus. But may meet at other brands other GUID. I just think, add to these UBU update firmware. The main thing is not to make a mistake in the hardware chip release,, for example, in 9230, available at S-D, A0 and A1.

I am attempting to edit the bios for a Gigabyte GA-Z87X-OC Force. I have tested the most recent stable build (F9) and beta build (F10a). My problem occurs with both builds. The issue is that the Marvell SATA controller is identified as a 88SE9192 and loads the Orom for the 88SE91xx when the board actually has an 88SE9230 and needs the Orom for the 88SE92xx. I attempted to search for this issue on the boards and didn't find any prior reference, so I apologize if this has already been addressed. Any suggestions on how to load and use the correct 88SE92xx Orom?

@ jasonsansone
In your BIOS is initially set OROM from Marvell 9192. You'd better contact support GigaByte and ask "Why is a controller on the motherboard is Marvell 9230 they set OROM from 9192?"