@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
For the µcodes I assume that they might work if the start address is the same or maybe it’s enough if FIT is correct. But there’s no warranty and HP was very early in protecting the flash process. So I thought you were already using a programmer.
Only a person that has done all these mods already on precisely that machine might be able to tell what’s aworking and what doesn’t work.
I have a way to flash it through software only, but yeah, for recovery, I also got a clip that worked.
So there is one report of NVME module working for this HP model. I looked at the BIOS diff, it did not even update any checksums, just module insertion.
I can probably pad the microcodes to the latest full size with zeros (?), at least, they’d be inserted in the same place.
The 2 modules above (nvme/rebar) are probably clean insertions. But the patches afterwards are probably tricky, especially if the try to “fix” the checksums.
As I open this stock HP bios, it already complains about the incorrect checksum. So something is clearly off, and touching that is not a good thing.
P.S. I am super tempted now to just get a faster cpu ($12 only!), and forget the whole BIOS thinggy. The procedure I have to flash any BIOS requires me to trash the existing ME, and then force the computer into manufacturing mode. Then I need to restore the ME together with the new BIOS - this way the USB drive recovery should work if the computer fails to boot.
So I tracked every step of my daisy chained BIOS updates. The manual steps (NVME/rebar) modules did not change anything else other than the module area which replaced empty space. I have a report from 1 guy who patched in the NVME module, and it worked fine. So that works, but cannot touch any checksums in the header it seems. I got his patched BIOS too to look at as well. Here is that report:
The MC replacement and 1 of rebar patches shifted things around a lot. MC module got smaller, and 1 of rebar patches done via UEFIPatch.exe patched PciBus module byte for byte - except this module is stored compressed and became 2 bytes longer! Of course, that moved things around a lot since it had to gain those 2 bytes.
I am thinking - I can patch in NVME/Rebar which have no other impact since they go to the empty space. And then do copy/paste on the other patches after doing auto-patching such as MC & PciBus. So stuff will get moved around, but at least no changes to checksums in the BIOS header. MC area says it’s “raw”:
File GUID: 17088572-377F-44EF-8F4E-B09FFF46A070
Type: 01h
Attributes: 48h
Full size: 14018h (81944)
Header size: 18h (24)
Body size: 14000h (81920)
State: F8h
Header checksum: DEh
Data checksum: 42h
I still need to test my USB recovery procedure, and make sure it actually works (LOL). I think I got the method to write the BIOS to the chip well clarified, but I am a little hazy what would happen if it bricks, and if the USB recovery works. Here is that other post on the BIOS writing procedure:
I’ve chased BIOS region changes, so I think I have a good handle on what area does what, and when it does change. I have a handy DOS workflow to dump the regions, and do MD5, so I can see if stuff changed already in the DOS window.
Anyway, do you have any suggestions on the BIOS modding? I am a little hazy how different microcodes for several chips are stored together, I guess there are some descriptors in that raw area that allow the CPU to find its microcode? The raw chunk starts at 0x580060 which checks out in a Hex editor of course.
I could not find a way to re-compress the PciBus module to achieve higher compression and match the prior size byte for byte when compressed, no tools seem to have any options for that.
I’m not following you here, I’ve no idea about the patches needed. My point was, that UEFITool does it’s own thing and rebuild far more that it needs to. So one might need to use manual action in between.
Example from a different machine: That happens when I ask UEFITool 0.28 to exchange a single volume with a prepared volume- it rebuilds the complete bios region and the complete firmware where a simple 1:1 exchange is asked
The result is a brick since the structure of the volume is changed
(upper left OK bios, upper right after change-no FIT, changed structure, brick, lower prepared volume with correct structure.
To get it right one just has to do the exchange with a hex editor. => Combine several methods/tools (MMtool might work on this fw, too)
1 Like
I am not really sure what it means but on SoniX’s Mega folder is a new UBU version v1_79_18a dated 5/19/2024, 21:26. I have no idea what changed but I hope SoniX is alive and doing okay.
1 Like
Yes, it is very interesting, that the UBU maker SoniX is active again (with his nickname LS_29) within the Overclockers.ru Forums.
Interested users can find >here< the latest discussion between Michael_Code and LS_29 (aka SoniX).
2 Likes
v1.79.19d out.
7 Likes
@SoniX
Welcome back to the Win-Raid Forum!
It is wonderful, that you are still working on the UBU tool!
>Here< is the download link (as *.rar archive).
Changelog (as far as I could recognize it):
- Renamed:
- UBU command file to “UBU.cmd”
- Updated:
- The tools named “drvver.exe”, “UEFIExtract.exe” and “UEFIFind.exe”
- the MCE files named “MCE.db” and “MCE.py”
- various BIOS modules stored within the “Files” folder
Good luck!
Dieter
1 Like
Changes:
EFI GOP Driver TigerLake (v17) CHANGED TO EFI GOP Driver Xe
Updated:
Updated EFI Realtek UNDI Driver 2.065
- NEW version available on Realtek downloads section 2.066 (2024/05/24), now correctly identified in UBU.
Report:
We still have an “Unknown Intel LAN version” for the Intel I225/226 (2.5Gb) on Intel 600/700 bios releases.
2 Likes