Question?
When you update the Intel Ethernet and Intel GOP firmware with UBU Tool, like in Z390 BIOS’s, does it actually only affect them on boot but not in the O/S, I think it transfers over to the drivers in the O/S and the firmware isn’t actually used in Windows at all?
@KedarWolf
LAN modules I do not update. They do not make sense at all.
GOP driver is essentially VBIOS. Without it, there will be no video kernel initialization. The driver is responsible not only for stable operation in BIOS, but also in the OS.
OLD UBU Archive.
In general, you can create a separate archive of "UBU_helper_utils". And transfer some utilities to this archive, such as:
– current/last version
– DrvVer
– FindHex/HexFind
– FindVer
– cecho
– VBIOS2Pad
– SetDevID
– BRenamer (asus)
In these utilities there is no binding to versions of UBU.
mCodeFIT - Adapted to the version of UBU.
MEA/MCE - leave as is
UEFIFind - I don’t remember which build was the change in the command line.
Other versions of UT/UE/UR are not critical. UBU checks for the necessary files.
@plutomaniac
Isn’t “UBU_v1.54-incl-Upd.1.rar” the same as “v1.5.4 (Missing → UBU v1.54 Update 1)”?
You can find it in the 2016 collection.
It seems that MEA v1.5.4 was an UBU-only release included at UBU v1.54.1 Update 1 but we have v1.54.0 actually (source 1, source 2).
So we’re actually looking for another old UBU version. I have fixed the version above accordingly.
An example as to why UEFIFind and UEFIExtract are important. UEFIExtract v0.13.5 or newer breaks the (now old/outdated 2016) last version of Extractor/UEFIStrip lordkag was releasing privately because "FFSv3 support with large files and large sections" was added. UEFIStrip was not coded to handle that and would often crash or show wrong output. The same would apply to UBU in which older UEFIFind or UEFIExtract used different command line options or showed/extracted less things or in different order. Anyway, separating everything will be too much work and it’s not really worth it for a few megabytes at best. Only UEFITool executables are not needed IMO.
Is it useful to discuss all these different files?
If "saving identical files as references" works as expected (and the high compression rates indicates it does) then all double microcodes, efi drivers, oroms and tools would cook down to one copy and a lot of references.
The archive size is strikingly small and having all UBU versions stored in a way that one could extract easily a complete and working copy of any version sounds compelling.
(I find 24 different UefiExtract, 17 different UefiFind- different filesize/ checksum)
Well, I found this and some links were still alive, including UBU_v1_54_1_1 so I got MEA v1.5.4! Updated the list at [Discussion] UBU Tool related Questions, Reports and Suggestions (75). In total, found these UBU versions:
@chinobino
UBU_v1_53_0_0 → new
UBU_v1_53_0_8 → new
UBU_v1_54_0_0 → new
UBU_v1_54_0_1 → replaces UBU_v1_54_1
UBU_v1_54_2 → rename to UBU_v1_54_0_2
UBU_v1_54_1_0 → new
UBU_v1_54_1_1 → new
Link: https://mega.nz/file/GY9Hyb6S#Gwxhgz6_IG…2WBK9QiRvuHRNXY
@plutomaniac Your updates have been applied with some changes in bold.
UBU_v1_53_0_0 → new → added but removed a zero i.e. UBU_v1_53_0
UBU_v1_53_0_8 → new → added but removed a zero i.e. UBU_v1_53_8
UBU_v1_54_0_0 → new → added but replaced UBU.bat with earlier date/timestamp 28/05/2016 (file is identical with UBU.bat 29/05/2016 only the metadata differs)
UBU_v1_54_0_1 → replaces UBU_v1_54_1 → done
UBU_v1_54_2 → rename to UBU_v1_54_0_2 → done
UBU_v1_54_1_0 → new → added
UBU_v1_54_1_1 → new → added
How to use UBU 1.79
Pay attention to the following messages
- GUID not supported
- Unknow section
After a successful replacement, follow the list in the "Main Menu". Nothing should be lost or duplicated/ That is, the list should not change.
If you see these changes or messages, then take a screenshot and write here.
Attach a screenshot, indicate what kind of replacement you are making and a link to the BIOS file.
PS Do not load the topic with the same messages.
Thank you
Got the following problem here with my ASUS X299 SAGE/10G:
in ASUS original latest BIOS for that board rev. 3101 is microcode 02000060 for my SkylakeX i9-7920X CPU implemented.
Whenever i use UBU (latest rev.) to update the microcode for CPU 50654_platB7 to any newer version than 02000060, my machine will let me boot into BIOS, but after finishing my settings the same way i use as for microcode 02000060, it will no longer boot my WINDOWS10 Installation (still from the same drive) anymore.
It hits WIN10 bootloader and immediatly stops the bootprocess. Do i flashback a BIOS with implemented microcode 02000060, it will boot WIN10 (still on the same drive [untouched]) fine immediatly and also OpenCore Hackintosh. I have tried so far the following revisions of microcode for my CPU:
cpu50654_platB7_ver02000060_2019-06-03_PRD_CFAE8439.bin
cpu50654_platB7_ver02000065_2019-09-05_PRD_460640CD.bin
cpu50654_platB7_ver02000068_2019-11-18_PRD_707F7CDD.bin
cpu50654_platB7_ver02006901_2020-02-12_PRD_2F78C3D8.bin
cpu50654_platB7_ver02006906_2020-04-24_PRD_B163D4FA.bin
So my question would be: does anyone here uses x299 board with SKYLAKE-X CPU like i9-79x0X and have updatet their BIOS with latest microcode revs using UBU with the same behavior as described above?
PS: same behavior with same CPU and same updated microcode revisions on an ASRock x299 OC Formula (also ASRock just use microcode rev. 02000060 as latest rev in their original (unmodified) x299 BIOS files).
NEVER experienced such a behavior on all my Zx90 Boards before. Always used latest UBU microcodes on these boards.
Upload 1.79 RC1
@MDoehler
I think your bios only supports upto 64. The same happend to me with earlier versions Rampage VI Extreme bios’
cpu50654_platB7_ver02000064_2019-07-31_PRD_8E7C22B2
All you can do is to wait for newer versions of your bios, and to keep trying cpu50654_platB7_ver02006906_2020-04-24_PRD_B163D4FA.bin
Download UBU 1.79 RC1 and replace mCode folder with the folder I sent you
cpu50654_platB7_ver02000064_2019-07-31_PRD_8E7C22B2.rar (2.29 MB)
@biozzz
Thanks and indeed: microcode 02000064 is working with my BIOS now. So all is good now here.
Did not test all the other microcodes with ASUS latest BIOS 3101 for thier x299 SAGE/10G.
But for now, this one is ok for me. Thanks again for supplying that rev. of microcode to me.
@MDoehler
Between mc60 and mc64 i would stay with mc60 in terms of performance. The mc64 addresses more vulnerabilities, but not enough to justify the update.
My Gigabyte X99-DesignareEX has a dual OROM for the Intel SATA controller. I’ve attached a picture of this configuration.
What is the naming scheme I need to update both OROM files independently?
RaidDriver.efi = EFI ROM
RaidOrom.bin = OROM
??? = Second OROM
@Ryu_Connor :
Welcome to the Win-RAID Forum!
Why do you want to update both Option ROM modules independently?
The BIOS of your mainboard obviously contains 1 EFI RaidDriver, but for unknown reasons 2 different Option ROM (RaidOrom) modules.
If your on-board Intel SATA Controller is running in "RAID" mode and you are using a v14 platform Intel RST RAID driver, I recommend to update all 3 modules to v14.8.2.2397. If your SATA disk drives should run in AHCI mode, there is nothing to do for you.
Regards
Dieter (alas Fernando)
Can updating the RST, RSTe (EFI / OROM), LAN, etc. modules affect the graphics card bios ?
I don’t think so, but I don’t see what it can be
No problem yesterday after changing the CPU, and only problems since this morning
Since I have my graphics card which is no longer recognized 1 time out of 2 at boot and I got this message au boot
The VGA card is not supported by UEFI driver
Thanks
