@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:
[[File:FM2A88X Extreme6+(2.90).png|none|auto]]
Aspeed and MegaRAID are found in WS boards. Example in Z9PE-D8-WS-ASUS-5404:
Also MSI more while EFI shell never seen. Yes, EFI Shell Extensions can be downloaded from the specified source, but there is not a new version for a long time. At MSI fresher.
Edit:
Marvell 91xx/92xx
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?”
Thank you Sonix. After 30 minutes arguing with Gigabyte I gave up. I’ll just leave that section of the bios alone since they weren’t understanding what I was saying at all.
@ jasonsanone:
Welcome at Win-RAID Forum!
Since the developer of the UBU tool himself was not able to help you, I cannot do anything else for you regarding your problem.
That is really a pity!
Regards
Fernando
The official website of Realtek available EFI UNDI driver version 2.027.
In the near future to add UBU.
@SoniX
I have attached the firmwares for Asus boards. But there are a few things to consider. First, there are two types available - 91xx ; 92xx - and they share the same GUID. The best way to tell them apart is to check the ID of the OROM. As an alternative you could hexfind for CODE3_HDR, which is present only in 92xx.
The firmware header is explained here. Even though it is for 91xx, the logic is the same for 92xx. The rest of the header is like this:
Notice the size, which will tell you where the firmware ends. There is no need to add the MV_Flash section, because that is needed only for the flasher and it contains info and checksum concerning the full image, not just the firmware, so another reason not to use it. For the firmware inside ffs you will need either the firmware extracted from a full 512KB image, or the image_fw_dump, which I will explain later. This is the difference, the first one is ready for flasher, the second is already expanded for chip. Top bytes is the checksum, the rest are the position in chip.
The bytes at the end of the ffs are just a logging done by the flasher, nothing important.
The Autoload is a critical component. I have added the latest versions for 91xx and 92xx, but it is better to find someone who can test them before releasing to the public. Also, the 91xx autoload seems to be coded for 9123, but the board P8Z77-V-DELUXE-ASUS is using it for 9128 with no problems.
I have added some packages for extracting and building. The Marvell_split folder has some scripts for splitting the image into components. Marvell_split.bat should be used for small images of 200-300KB, named “image”, which start with the signature MAGIIMGF and the full header needed for the flasher to expand it. Marvell_SplitBin.bat should be used for full images of 512KB, named “image.bin”, which start with A5A5A5A5 (autoload signature) and that are already expanded for the chip. There is one other case for U3S6Rx images, that are 516KB sized and need Marvell_split.bat to extract the image as bios.bin, rename it to image.bin and then Marvell_SplitBin.bat to split the components.
Rename.bat is to remove the number in front of the components extracted, because I find it easier to see what is missing when they are numbered. Once the components are obtained, we can proceed to the next step.
Marvell workplace 91xx/92xx is used for reversing the process, by building images from components. RAW_Comp.BAT will create image_load_raw = raw Autoload, image_fw = raw Firmware and image_fw2_dump = raw Firmware for 512KB images. RAW_Image.BAT will create raw 512KB image from image_fw or image_all. Only image_all is recommended at this step.
W_img_all.bat will create a small image named image_all with all the components, which will be used by the flasher. W_img_min.bat will skip the BIOS/OROM, not recommended. Only imgCreate_new.exe will create a valid header for image_all. For the rest of the images they are the same, but it is better to check.
In order to build any image, you will need to replace the needed components with the ones you have chosen, then change line 3 in all config_…txt to the image version (like VERSION = 0100001807 for 91xx or VERSION = 0203001055 for 92xx), which is the one that follows signature MAGIIMGF and is calculated as in this example.
The last step is to test if the updating works, if it will reflash internally or just load them instead of the chip content. First option is to use Ctrl+M during POST, the second is to use Marvell RAID Utility.
Use with caution!!!
Marvell 91xx ffs.rar (284 KB)
Marvell 92xx ffs.rar (363 KB)
@lordkag
Thank you very much.
Unfortunately the tester, which was ready to check firmware update for Marvell 9230, became the motherboard is brick. Therefore, there is no way to verify. Wait for the new motherboard is.
Hi Fernando. This is my doubt: nowadays I have installed Intel RST Orom 13.1.0.2030 and not an IRST Universal TRIM in RAID0 Addon. But I am upgrading to RAID 0 with two Kingstons SSDNow V300 next week.
SO, as my mobo is a P8Z68-V/GEN3, what should I do?
Insert the addon to the RST Orom 13.1.0.2030 via UBU or flash back to 12.9.0.2006 TRIM-in-RAID0 via UBU?
Why UBU does not offer to insert the Addon via UBU? OROM 12.9.0.2006 gets better performance?
Thanks in Advance.
I do not recommend to use any Intel RST(e) driver or OROM module v13 for users with a 6-series chipset RAID0 system.
It does offer TRIM modded RAID ROM modules since v1.4. There is no addon requred anymore.
It is more stabile than v13, but the best performant driver/OROM combo for RAID0 systems is still v11.2.0.1006/v11.2.0.1527.
Even for RAID0 using Hard DRivers as I am using right now?
Yes, but the performance differences will be smaller.
Even for RAID0 using Hard DRivers as I am using right now?
What are "Hard DRivers"?
EDIT by Fernando: Double quoted text deleted
What are "Hard DRivers"?
He certainly meant "Hard Disk Drives" (HDDs).
SoniX,
I was using UBU to update a ASUS Sabertooth 990FX R2.0 just for the 3rd party controllers. Curiously the program listed the Asmedia SATA orom twice (existing version was 0.93) but after running UBU it appears only one gets updated to .954 and the second entry is still listed as .93. Is this working as intended?
@ D2theZ
The fact that both modules OROM message is used the same Device ID 612. MMTool can update only one.
Edit:
You can try to divide by 2 the Device ID, such as 611 and 612. But accuracy should look first at the "Device Manager" - "Properties" - "Information" each device AsMedia.
@SoniX I thought I can’t go more lazy, but now, I’ll never manually update a module anymore… I would like to thank you for every revision of your UBU, but as I’m actually too lazy, just one bigbigbig thank for all your work!
Yup! Very nice tool and a great forum! 