@Fernando, nothing new. But, I will think… 
May be, you right.
It is great that work still continues! Has anyone actually been able to use UBU to update and flash UEFI on Z690/Z790 motherboards? Do companies like ASUS and MSI still function with modified UEFI via Flashback feature?
The UBU tool is able to update some modules of an UEFI BIOS, but not to flash any BIOS.
Questions regarding the flashing of a modded UEFI BIOS should better been asked within >this< thread.
@Michael_Code
I think the best thing to do is start a separate topic and keep a list of changes.
1 Like
8 Likes
@Michael_Code
Thanks for having offered the updated UBU v1.80.01.
It worked flawlessly with the latest BIOS v5.61for my ASRock X570 Pro4 mainboard, but I got a mysterious “User GOP Driver file” message while trying to update the “Video OnBoard” AMD modules.
Here is the screenshot:
Do you know the reason?
Note: I haven’t touched the UBU\Files folder of the UBU tool v1.80.01.
1 Like
- About “User GOP Driver file”
We can place ANY GOP Driver file (include AMD) in path
*\Files\intel\GOP\Usr_GOP*
but with name IntelGopDriver.efi
Read \Files\intel\GOP\Usr_GOP_Readme.txt by SoniX
For example
- Unknow - Unknow
First, code name CPU (now was AlderLake-P). UBU and drvver.exe dont know about newest CPU.
Second, version number. After change method numeration, we heve problem with drvver.exe. Also with network UNDI.
Hello Michael,
thank you for your quick reply.
This is the content of SoniX’s _Readme.txt file:
“In this folder you can place the Intel GOP Driver you need.”
If you should be right regarding the location, where the desired AMD GOP Driver has to be inserted (as file named “IntelGopDriver.efi” into the sub-folder named “intel”), this would be absolutely irritating for the UBU users and should be corrected with the next UBU version.
By the way - why is the Intel GOP Driver v1.0.4.6 within the Files\intel\GOP\Usr_GOP sub-folder of the UBU tool v1.80.01 you have delivered? There should only be the _readme.txt file and no GOP Driver in it.
This is the picture I get after having deleted the file named IntelGopDriver.efi and redone the UBU work:
This means, that my reported tiny problem while using your offered UBU_1_80_01 can easily been solved by deleting the file named IntelGopDriver.efi, which is within the Files\intel\GOP\Usr_GOP sub-folder.
Now your updated UBU tool runs perfectly for me (without any issue).
Well done! 
1 Like
@Michael_Code
Thank you for your continued support of UBU. I wanted to ask you, maybe you know why UBU does not see Intel UEFI x64 PCI-E gigabit driver v9.8.40.efi in bios?
@Dagal, yes, we know about this problem. drvver.exe old version. I ask our friend SoniX , source last version 0.29.0
Waiting… I chang only with my hands, by UEFItool. Sorry for my pingving English, this my second language, after Russian. I princile dont use any translaters.
1 Like
That would be great Michael… the last i know that is public is 0.19.0 based.
Keep us updated on his good will (SoniX).
Regards
2 Likes
No Michael, not the assembled exe 0.29.0… this one we know it, i mean the C code file “drvver.c” base file.
I tried to update microcode in HP Z620 Workstation BIOS, and it seems a lot of stuff gets shifted around if I diff the original/updated BIOS files in WinMerge.
Is there a way to minimize the changes to the absolute minimum - to make diff easy?
Well, I was actually trying to put in the old ones - pre-2018. So if anything - they were smaller (see the pictures). And the tool could have padded the empty space - but it seems like it shifted a lot of stuff up, to take the space.
If I insert an nvme module, it’s very surgical - a local change, and nothing else.
Manual replacement is possible - but there is a great tool already, probably it could be tweaked just a bit?
So I ran this on the modded BIOS, and indeed, Offsets now shrunk - so I guess it moved up the entire following section? Also, the 2nd panel above shows Offsets which are not correctly looking - they become different after the actual replacement takes place. Here is what it looks like:
OK, I thought you might be interested in a working solution. If you’re interested in the theoretical part, you mignt want to address @ Michael_Code directly.
It might help if you could find out more about this by trying the different versions of UEFITool, maybe. They will probably behave differently…
Oh, my issue is if I do it manually - and mess up ? What’s the procedure? I already messed things up once, and was not easy to recover.
The big deal is that the stock flasher on this HP workstation would not allow anything to be flashed without the proper checksum, so the workaround I used killed the BIOS recovery option. One can probably be more careful, but it’s still quite error prone.
Btw, is there a quick way to kill the checksum verification in the stock DOS flasher? I’d be a lot quicker to try different BIOS versions that way. Here is the link (which you already have):
https://ftp.hp.com/pub/softpaq/sp100501-101000/sp100699.exe
Last time I daisy chained a lot of updates, I guess one of those did not work. So I am now chasing differences 1 by 1, and MC update moved a lot of stuff around!
Here is the daisy chain:
10/29/2019 02:45 PM 16,777,216 J61_0396.bin
03/15/2024 10:14 AM 16,777,216 J61_0396_mc_only.bin
03/15/2024 10:41 AM 16,777,216 J61_0396_mc_nvme.bin
03/15/2024 10:58 AM 16,777,216 J61_0396_mc_nvme_rebar.bin
03/15/2024 11:19 AM 16,777,216 J61_0396_mc_nvme_rebar_uefipatch.bin
03/15/2024 11:23 AM 16,777,216 J61_0396_mc_nvme_rebar_uefipatch_usb.bin