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.
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.
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).
@SoniX I’ve always wondered why you’re using precisely the version 0.25.0 of UEFITool and UEFIReplace and not the latest version 0.28.0. I’m just genuinely interested if there is any particular reason for it. I am not trying to be rude or anything. Thank you for your support of BIOS modding. UBU is really awesome tool.
But all versions of UEFITool/UEFIReplace, unfortunately, create unpleasant problems for modding.
v0.25.1 and above - Loss of i-SDA for Intel 300 series and above.
v0.2x.x - - Memory overclocking stops working. You can select the frequency using the XMP profile or the manual method, but in fact there will be a regular
I do not know if the old utilities will be changed or not. I need to consult with CodeRush.
OK, I’ve come a full circle, and now I see your point a bit more clearly First of all, the BIOS boots fine with the inserted NVME & ReBar modules, so there are no issues there if things are added to the empty area in the back:
Now, to the MC replacement story.
I tried to run UBU tool, and then in MMTool_a4.exe tool I extracted the MC block from the original BIOS, extracted the same block from the UBU MC modded BIOS where the MC block shrunk, then padded the modded MC block back to the original size with FF, and did a replacement in MMTool_a4.exe for that particular GUID. Unfortunately, it’s a no go and it then could not find any microcode for the cpu that happened not to be listed first. Also, MMTool_a4.exe seems to have changed some bytes before 0x580060 where the microcode is supposed to start.
UBU tool thought the MC modded bios was OK, but I guess that did not help much.
Do you then recommend that I take the orig BIOS, pull each MC code I want from the library, pad it first with FF to the prior size, then paste these MC file contents on top of the BIOS at the right address? So everything would have dead space at the end since microcodes shrink. For example, I have dead space with FF between 2nd and 3rd microcodes in the original BIOS that UBU tool simply removed (see the 2 images below) and that’s probably a bad thing.
I wish UBU tool tried to honor the pre-existing sizes a bit more strictly if that’s possible to achieve …
P.S. Here is an extreme BIOS for this computer that had tons of microcodes. It seems they all get padded to either X000 or X800 sizes, so non-round microcodes get extra FF.
SoniX - how simple would it be to have the UBU tool try to place the new microcodes at the pre-existing boundaries? Basically, if the new size is smaller or the same as before, keep the next MC start address as it was. A padded bios file is attached for reference, same as the picture above, J318. J61_0318.zip (6.0 MB)
I tried your UBU_v1_80_a5 alpha on a AM5 Gigabyte B650E Aorus Master F30 bios F30 bios
As someone already noted, would be really great if UBU recognizes I225/226 NICs.
But nevertheless I would like to mention one error notice on scanning ucodes (5) which states an error
Alright, the manual editing process ended up being very idiosyncratic. Kept the microcode area the same in size, padded excess at the back with FF when microcodes shrunk. Also tried to pad each microcode instead to keep the same addresses - created issues! The original BIOS already had 8KB of padding at the end of the microcodes, so I ended up increasing that area by a bit when microcodes shrunk. Offsets had to be either 0x060 or 0x860 at the end, since all official bios versions did that. Original:
I am looking for some help to update the BIOS of an NZXT N5 Z690 board with the latest Ubutool from Sonix (1_80_A5).
Where do I have to put the Intel VMD EFI file?
In which directory am I supposed to put the latest Intel VMD EFI file which is named VmdDriver.efi? Neither >Files>intel>RSTe_VROC nor >Files>intel>RST work. At least the tool doesn’t recognize that file. Also creating a new folder named VMD under >Files>intel doesn’t seem to work either.
Failed safety check
I’ve managed to update the latest LAN components of the BIOS, but the modded BIOS file doesn’t get past the safety check of the instant flash utility of the motherboard. Does anyone know a save method to circumvent this check without bricking the board? Asrock is the manufacturer but couldn’t find a solution yet.
First of all, the BIOS boots fine with the inserted NVME & ReBar modules, so there are no issues there if things are added to the empty area in the back:
