UBU does not work on bios AsRock H87 Fatality
Error in saving
@ RMK_99:
Welcome at Win-RAID Forum!
According to the error message given by the AMI Aptio MMTool there is not enough space to add a specific file.
I hope that SoniX or someone else can help you to solve your problem.
Regards
Fernando
@RMK_99
I take it you mean AsRock H87 Fatal1ty Performance and BIOS 1.60A, right? You only have 5KB left in the nested firmware volume containing the modules to be updated and only 3KB left in the container firmware volume. Anyway, I managed to update all components, but it is up to you to decide what risks to take. You have a backup BIOS on your board, but I don’t know how Asrock treats a corrupted main BIOS.
In the H87mod.rar you have a H87mod.rom with the following updates:
- OROMs = Intel RST from 12.5.0.1815 to 12.7.0.1936 ; Intel PXE from 1.4.10 to 1.5.48
- EFI = Intel RST from 12.5.0.1815 to 12.7.0.1936 ; Intel GOP from 5.0.1023 to 5.0.1037
- Microcodes = CPUID 06C3 from rev. 07 to rev. 17
This was done using MMTool and UEFITool, but since the later is still in beta, you can’t expect 100% safety, even though CodeRush is dedicated in fixing all possible bugs.
You also have a 2178mod.bin which can be used to update the VBIOS from 2166 to 2178. It was done by transferring the settings from the onboard VBIOS for maximum compatibility, but you can never know. If you decide to try this, use MMTool and open H87mod.rom, go to “Replace” tab, check “Link present”, select 8086-402, browse for 2178mod.bin, hit Replace button, save new image.
I can also provide an update with all from above + VBIOS updated from 2166 to 2178mod + EFI VBIOS addon from 1215 to 6767, but you must express your full agreement concerning the risks involved.
Third, the lack of space is preventing the updating of EFI Intel Undi from 5.1.00 to 6.1.24, but this can be done by taking space from firmware volume 3 (free 123KB) and add it to firmware volume 2, but the risks increases with such low level of editing. It is already done and neither MMTool, nor UEFITool shows any warning message after checksums correction.
If you agree to take the risk and full responsibility for the outcome, just say what do you want updated from the remaining VBIOS, EFI VBIOS addon, EFI Intel Undi and I will post that image.
Finally, I don’t know if Asrock implemented some security checks to prevent flashing a modded BIOS, so check different methods of flashing.
H87mod.rar (5.52 MB)
There are some bugs in 0.17.3 that I already know they exist, but I have no time to fix them now. Nothing particularly serious, some cosmetics, deeply modified BIOSes can run a bit slower then original ones because of wrong volume base address calculation, which leads to more runs of PE\TE relocation routine, then in original BIOS.
If volume base address is changed (which is obviously so for volume 3 above) all PEI executable images must be relocated to fulfill executable-in-place constraint. That can be automatically done in UEFITool, just mark first file of the volume to rebuild and all affected PEI files will be marked for rebuilt automatically.
Volume sizes must be corrected in 2 places: VolumeHeader->FvLength and VolumeHeader->BlockMap. Because of this changes, checksums of both volumes must also be corrected, what can also be done in UEFITool by marking both volumes for rebuild. Sizes, in other hand, can be corrected only manually in hex editor, but UT will show a message, if they are different.
I will definitely automate this someday, but now I have no time, my master thesis must be done in 3 months, and I’m only at the very beginning of it.
@CodeRush
This is what I’ve done:
In FV3 (count from 0) changed length from 00000200 to 00200000 (should be UINT64, I know) and BlockMap from 20000000 00100000 to 02000000 00100000. The volume has only D8h bytes of data, so plenty of free space. Corrected checksum using UEFITool, which did the smart and simple thing of turning the rest of 1E000 inner padding into standalone padding between FV3 and FV4. I then added this 1E000 space into FV1 (which has a nested FV2 containing drivers) by changing 00F01F00 to 00D02100 (1FF000 + 1E000) and BlockMap from FF010000 00100000 to 1D020000 00100000, then cutting that 1E000 padding and insert it before FV3, to be counted in FV1. Corrected checksum of FV1, FV2, FV3 by rebuilding and saved the image. What I hadn’t done was relocating PEI, because I thought that rebuilding FV will include this. Good thing you corrected my wrong assumption. The one thing I couldn’t understand was the checksum. I never got a 0000 checksum for the 48h bytes header, so I let your tool do the job.
@lordkag , you’ve done everything right, I think.
I will add PEI rebase to volume rebuild procedure, it makes sence.
I normally update my bios manually, and just tested this tool with the newest version of my Gigabyte GA-X79S-UP5-WIFI boards bios and noticed 2 things that seemed a bit odd that I would like to verify here before flashing.
First off it is an odd board, it has a C606 chipset instead of X79 and has both RST and RSTe modules, and you can select which one you want to use in the bios. With either selection you have access to the separate RSTe SCSI module, and when using the normal RST Module, you need to install the driver for the SCSI controller separately (either by installing the RSTe driver first then removing it, or by extracting the contents of the RSTe driver and doing a manual install in device manager)
The Board also has 2 onboard NIC ports, 1 Intel and 1 Realtek.
This is a screenshot of the UBU tool with the stock bios freshly loaded:
This is after all module updates to the newest version:
The RST updates perfectly to 13.1, but when selecting to update the IRSTe module to 3.8, it seems to create a second SCU module instead of updating the existing one. If you select to update back to 3.7 (which was the stock version) it goes back to normal.
I tested this with an older version of the bios that had IRSTe 3.5, and it did the same thing when updating to 3.8, but 3.7 seemed to work as expected and just upgraded the 3.5 SCU module in place.
It seemed wrong to me but for all I know that is the expected outcome so I thought I would check here first.
The second thing I wasn’t sure about was in the LAN OROMs, there is 2 entries for Realteks PXE, one of them is labled LIDv1.63 (the older bios had .60, so it is something actively being updated), I have no idea what that is but it is removed when you select to update the LAN OROMS.
Anyone have any input on any of this? Right now I’m thinking the safest bet is to update this specific bios manually still, maybe use this tool as a module repository for now (update with UBU, manually extract updated modules and then manually insert them into a fresh bios).
Thanks!
@ Krause:
Welcome at Win-RAID Forum!
Your questions should be answered by SoniX. So I hope, that he will read your post.
Regards
Fernando
@ Krause
OROM IRSTe SCU -> Make update 2 times in a row.
OROM Realtek LAN LIDv1.60 - an outdated format RPL network boot. It has few uses. If you want to use it, download it here (PXE and RPL ROM code PXE 2.59/LIDv1.63).
Hi, Fernando!
Can you link for me please the Intel Vbios OROM 2158 only so I can download it and copy into the OROM\VGA folder of the UBU?
I need to keep the original Efi files and update to the OROM 2158 only, is it possible still maintaining the two default Efi GOP Drivers?
Thanks!
You can find the suitable download link within the start post of >this< thread.
Don’t forget to check the DeviceID of the VGA OROM v2158 and to rename the OROM file v2158 to "2170.bin", when you are going to change the VGA OROM module within the UBU directory.
Yes, as long as you are running the OS in LEGACY mode, the GOPDriver BIOS modules will not be used by your system.
You can find the suitable download link within the start post of >this< thread.
Don’t forget to check the DeviceID of the VGA OROM v2158 and to rename the OROM file v2158 to "2170.bin", when you are going to change the VGA OROM module within the UBU directory.
Done it!
However I only modded with the following:
OROM_12.7.0.1936, Efi: 11.6 original
Patch 19/28
VGA 2158
There was no room left for anything else, I only wanted to upgrade the lan orom too but is seems I’ll have to keep the original one
EDIT by Fernando: Not needed quoted text has been deleted.
First Thanks to developers providing this easy UBU tool and the forum admin placing the modules to available.
Fernando,
updated from UBUv1.1.1.2 with the Intel VGA ROM 2170.bin and everything went fine along others i did update too (I haven’t done the Cpu microcode).
My question is that you listed the “Intel VGA Rom v2170 for DEV-102” only >here<, but in the VerDID.txt from UBUv1.1.1.2 is listed as “2170.bin - 2170 - Device ID 102/162” compatible.
Is the UBUv1112, 2170.bin is still valid for both DEV_102/162?
My Device ID is “PCI\VEN_8086&DEV_0162” so just in case i took to downgrade to v2158-DEV_162 from your linked modules and followed instruction renaming in quoted post. All is fine now.
EDIT by Fernando: Fully quoted text deleted to save space and to keep the Forum performance.
@ N607:
Welcome at Win-RAID Forum!
I think so, but I am not 100% sure about that.
SoniX will know the correct answer.
Regards
Fernando
Yes.
Yes.
Thanks for the clarification.
To avoid any future misunderstandings I have customized the "Intel VGA ROM" part within the start post of >this< thread.
CPU Microcode 06D2 - 20D / 06D3 - 308 (LGA2011) inside:
http://66.226.78.21/downloadsite/bios/20…on(2.80)ROM.zip
or
https://www.mediafire.com/?0xddtb272dfnx3o
Preparing to release UBU v1.2.0.