Zitat von lordkag im Beitrag #602

---

@killkernel

There is nothing wrong with what Sonix did, mainly because he used MMTool for doing the job, by adding a microcode at a time. Either Gigabyte is doing something odd like storing microcodes in descending order, or this is the general rule for all - higher order first, i.e. Ivy first and Sandy later. Since no one reported any error so far and this is rather dangerous to test, I don't see how this can be easily solved. My vote goes for placing Ivy microcodes in front of Sandy ones.

Here is what mictlan did. I'm not an expert of this stuff, CodeRush is, so I might be wrong in my interpretation. This is the header of ffs. This is what mictlan changed.





Original EFI_FFS_FILE_ATTRIBUTES is 0x48 = 01001000b, which would mean alignments of 4, 8, 16 bytes and checksum of module is set. He changed it to 0x08 = 00001000b, which cleared the module checksum and needed to be 0x55AA or 0xAA in 8 bits. Then he recalculated header checksum. This is more or less of a hack: not entirely wrong, but not exactly right. Every important module (especially such as the microcodes module) must have a full integrity check, not just header checksum. Chucky88 just changed the order of microcodes.

---

Zitat von lordkag im Beitrag #602

---

Without a proper feedback - CPU used, BIOS used, UBU vers, what else was updated, did it worked with older UBU, manual replace of ffs, manual add of microcode, different order of microcodes etc.. - there is not much Sonix can do without risking everyone's board.

---

@killkernel

My take is that the microcodes must be placed in reverse order, starting from higher CPUID. Don't know if you will be willing to test it again, but here is LGA1155over.ffs with reversed microcodes. Just replace in UBU 1.6.7 and select Sandy for overclockers rev28. But I don't see why would this have such an impact on the system.

@error-id10t

It is possible that the dependencies are important. Updated to Intel 6.2.08 and Realtek 2.027 for your board. Just replace in UBU -> Modules -> lan -> ffs. If you need space, just replace with compressed modules. Update with UBU the Lan section.

@diskodasa

The same goes for you.

@SoniX

I have updated Extractor. Added "<file> pcir", which will find actual OROMs in file. Should be relatively accurate, filters non-OROMs. Added "<file> oromlink", which will find (in CSMCORE) the links that show up in MMTool. Barely tested, might not work. Added "<file> oromext", which will extract OROMs from CSMCORE. Just finished it, still a long way from doing something good, tested only on 2-3 files. Useful only when MMTool fails or doesn't see the OROM.

And while we are at it, here is something else I use to hunt new modules. It uses PhoenixTool, Module Helper by Donovan6000 and XSearch.

I usually use it after UBU or Extractor, to find new headers. Place #XSearch.bat in UBU folder. Unpack PhoenixTool to desktop and rename the folder to PhoenixTool or change line 8 from #XSearch.bat to your needs.
Place Module Helper in PhoenixTool, rename it to EFI_Module_Helper_0.2-fix_don6k.exe or change line 20 and rename it to your needs. Move XSearch folder to %Program Files (X86)% or change line 41 to your needs.

Run #XSearch.bat. It will copy bios.bin to PhoenixTool folder and start PhoenixTool.exe. Load the copied bios.bin and wait to finish extraction, then close PhoenixTool. Press Rename button in Module Helper, then close Module Helper. Close XSearch window once you inspected one particular search, the next one will start.

I would have used UEFIExtract, but you will only get many body.bin or header.bin. Plus it pushes a too complicated folder structure. If it will rename the modules to <UI>_<GUID>_[body|header|user].bin and provide a switch to unpack all in one folder, then It would be easy to switch.

Hello who is the leader of this UEFI BIOS Updater project? that pretty much makes all the updates.
I have some information for you.

Zitat von Fernando im Beitrag #607

---

Zitat von GlitchyHack im Beitrag #606

---

Hello who is the leader of this UEFI BIOS Updater project?

---

It is SoniX.

Zitat

---

I have some information for you.

---

Please post them or send SoniX a PM.

---

Last time i PM'd him i got no reply.

Zitat von GlitchyHack im Beitrag #608

---

Zitat von Fernando im Beitrag #607

---

Zitat von GlitchyHack im Beitrag #606

---

Hello who is the leader of this UEFI BIOS Updater project?

---

It is SoniX.

Zitat

---

I have some information for you.

---

Please post them or send SoniX a PM.

---

Last time i PM'd him i got no reply.

---

Sorry.. I simply can not respond to all in PM. :(
@GlitchyHack
You may have to try to update the program.
If you need the source code utilities, you can find them on GitHub

-----
Ladies and gentlemen. My apologies, but I take time out for a while. Excuse me, but I also need to rest, at least a week.

Zitat von lordkag im Beitrag #604

---

@error-id10t

It is possible that the dependencies are important. Updated to Intel 6.2.08 and Realtek 2.027 for your board. Just replace in UBU -&gt; Modules -&gt; lan -&gt; ffs. If you need space, just replace with compressed modules. Update with UBU the Lan section.

---

@error-id10t
Update LAN for those who use the boot OS on the LAN.
If you do not use this option to load the OS, then this update do not need.

Zitat von SoniX im Beitrag #609

---

Zitat von GlitchyHack im Beitrag #608

---

Last time i PM'd him i got no reply.

---

Sorry.. I simply can not respond to all in PM. :(
@GlitchyHack
You may have to try to update the program.
If you need the source code utilities, you can find them on GitHub

---

Zitat von lordkag im Beitrag #604

---

@killkernel

My take is that the microcodes must be placed in reverse order, starting from higher CPUID. Don't know if you will be willing to test it again, but here is LGA1155over.ffs with reversed microcodes. Just replace in UBU 1.6.7 and select Sandy for overclockers rev28. But I don't see why would this have such an impact on the system.

---

@lordkag

Hello lordkag! It's me again to inform you that your LGA1155over.ffs worked well!
Your thoughts about the microcodes that must be placed in reverse order, starting from higher CPUID is right.
Two friends of mine have modded their BIOSes of their respective Gigabyte Z77X motherboards that are different from mine and each others (e.g. 3 different models tested) and all went fine from the first boot after BIOS flash.
With previous LGA1155.ffs module coming from UBU 1.65/1.67 they were experiencing same issues as i indicated in my previous posts but now everything seems fine.
Thanks a lot from me and my friends for your collaboration and time that you deserved to check and solve this issue.

@SoniX

Hello SoniX! The LGA1155over.ffs prepared by lordkag is safe for Gigabyte motherboards. Thank you and have a nice week-end!

Zitat von GlitchyHack im Beitrag #612

---

wanted to say i recreated all three of those tools you use in your UBU into one tool. HexFind OROM Version find and efi option rom version find. It's coded in c#. would you rather use one .exe file rather than three? if so when i finish this up i'll send you it.

---

Problem with UBU 1.6.1 microcode updating (the first one that's SB-E and IB-E). Can anyone confirm if it works or fails for them?

1) Extracted .CAP and placed in UBU folder
2) Started UBU.
3) Enter 8, seems to scan correctly.
4) Enter 1 and fail. The second window (MMtool) reports "file size exceeds the volume size".

BIOS download: http://dlcdnet.asus.com/pub/ASUS/mb/LGA2...E-ASUS-0801.zip

Also a note for UBU developers - any chance of checking that spaces in filenames will work? I had a BIOS named "ASUS-X79-0701 (2014-02).CAP" and UBU fell over on the spaces in the filename until I renamed it. Shouldn't be an issue, presumably some command or other needs quotes!