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.

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!!!

@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.

Zitat von Fernando im Beitrag #516

---

The best performant driver/OROM combo for RAID0 systems is still v11.2.0.1006/v11.2.0.1527.

---

Zitat von cybersm im Beitrag #517

---

Zitat von Fernando im Beitrag #516

---

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?

---

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!