[ARCHIVE] Outdated UBU Tool related Questions, Reports and Suggestions

So I still don’t get why I don’t need modded OROM’s and SATA driver modules for my chipset. AFAIK the X79 belongs to Intels 6 series as P67 and Z68 do…

Best regards hanson

X79 chipsets belong to the Intel C600 Series Chipsets and are at least 6-Series ones, but contrary to the "normal" 6-Series chipset desktop systems (P67 and Z68) Intel has enabled the TRIM in RAID0 support within the RSTe RAID ROM/EFI SATA modules for the special "Alternate" DeviceID of X79 RAID Controllers since v3.8 and within the RST RAID ROM/EFI SATA modules since v11.x.x.xxxx.

Thanks for clearing that Fernando. I was just unsure because I get negative TRIM results with the unmodded SATA driver module 12.9 I use right now. But as you said in another thread the TRIM check tool is not very reliable.

Best regards hanson

@SoniX , I knew that…

Thanks Fernando, that just what i wanted to know about functional restriction.



What`s wrong ? Bios 4804 for Rampage IV Formula.

Thanks

@ donaneves:
Welcome at Win-RAID Forum!

SoniX hopefully will be able to answer your question.

Regards
Fernando


Excuse me, overlooked. Thank you for your report.
Bug corrected, use the UBU version 1.4.2

@ SoniX:
Thanks for the new UBU version v1.4.2!

@ all:
The start post has been updated as well.

@ Fernando:
@ SoniX:

when development for AMD?
little by little …

thanks

@ asrlab:

Thanks for your request regarding the support of AMD ROM/EFI SATA module updates.
SoniX is the developer of the UBU tool and will answer your question.

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.

@ RMK_99:
I justed tested it and can confirm, that it seems impossible to update the EFI SataDriver or EFI LAN/UNDI modules of the latest ASRock Fatality H87 Performance BIOS named H87PERF2.10.
When I tried to update the SataDriver to v13.1.0.2030, the UBU tool hangs. The MMtool gives the following error message:

UBU hangs while updating SataDriver_pic2.png


When I start again from scratch and choose to update the Intel LAN ROM/EFI UNDI version, I get this message:

UBU hangs while updating Intel EFI LAN.png


Conclusion:
Only ASRock or SoniX may be able to help you.

Some mainboard BIOSes offer to do a backup uf the current BIOS settings.
Since the individual BIOS settings cannot be saved within the BIOS file itself, I do not know any other option than either to save the settings from within the BIOS (if applicable), or to note all individual BIOS settings.

@SoniX

Realtek LAN OROM v2.59a (02/13/14)

2.59a.rar (28.6 KB)

Sorry for the delay.


Support for AMD will not.


You can express a "special" thanks to the developers of BIOS AsRoñk. This BIOS is no free space for the upgrade modules.


Sorry. I do not quite understand your question.

@ asrlab:

Support for AMD will not.


To avoid any misunderstandings: I am sure, that SoniX has already spent a lot of time trying to implement the support of AMD ROM and EFI modules into the UBU tool.
AFAIK it is the complicated structure of the different AMD BIOS modules and their dependencies (example: RAID ROM + MISC.BIN), which makes it so difficult to develop a universally usable AMD OROM update mechanism.

@ RMK99:

You can express a "special" thanks to the developers of BIOS AsRoñk. This BIOS is no free space for the upgrade modules.


SoniX has confirmed, what I already suspected: If you want to be able to update the BIOS modules, you have to contact the ASRock Support. Only your mainboard manufacturer is able to enhance the available space for the BIOS ROM/EFI modules.

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



thank you anyway
is not a problem, I will continue to use MMTool for module AMD

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

ex1.png



ex2part1.png



ex2part2.png

Extract.rar (44.2 KB)