Zitat von Ghostearth im Beitrag #1076

---

In Previous version of UBU, if you had not a intel 8 or 9 series your were unable to upgrade to 13.5 on intel 7 series, in this latest version SoniX unlock the restriction of 8 et 9 series only, so you are able to install it on intel 7 series (for Raid purpose), that's all i think.

Ghostearth.

---

I also added the modules on a x79 board before the restrictions were lifted ? How strange.

Can someone explain why I can't open this bios file Z68%20Extreme4%20Gen3(L2.31A)ROM (it has to be AMI UEFI) with UBU? I can open only my backup file made by AFUDOS, but the size differs (4Mb instead of 8Mb) from the original so I'm afraid to flash it. Also I'm afraid to use AFUDOS to flash modded bios, because I've already tried it on Asrock FM2A85X Extreme6 and failed (stuck on erasing bios). But that board has "ASRock Crashless BIOS" feature (instead of this one) and I restored it. Later I succedded to mod Asrock FM2A85X Extreme6 using UEFITool to "Extract body" (because of "Bios Lock") then modify using UBU and then flash with built-in "Instant flash'.

Start UBU and point to your BIOS......
bellow is your BIOS opened with UBU:


Edit:
Hope you unzip both files......

Thanks for your try to help guys. I just gave the link that has zipped bios file. It doesn't mean that I tried to open the archive itself in UBU. I unzipped the file and then tried to open it in UBU and it said something like "No Bios file". But right now I tried to open it on the other computer and it worked. I can't even imagine how is it possible. But no more questions right now.

@SoniX

I have updated the Extractor, if you still have a use for it. The base is in this post and this post. What has been updated:

- The code ported to Python 3.x. I now use Python 3.4.2 without issues. You will need to install pywin32 (ending with py3.4.exe), since I wanted access to win32api, mostly clipboard.
- You need to update the python address in .bat file or add Python to path and just call python instead of using %python%
- I tried to make an exe of this script using py2exe, but the package came out too large and some benign errors were printed during use. The script is smaller and easier to maintain.
- Added [oromext] with full extraction+renaming feature. This works better than MMTool, because it extracts all OROMS, hidden or duplicated.
- Added [oromext2] for quick renaming. It means that it takes file.bin and extracts it as [VID-DID-Link Vendor Device Version].bin
- Added [oromext3] for aggressive extraction. This will track every possible OROM, even if no link is attached. Actual size of OROM might be smaller.
- Added [ffsext] for ffs extraction using MMTool. I hate that MMTool doesn't have a search function, so I added this caller.
- Using UEFIExtract for AptioV / Insyde extraction. You will see a separate UEFIExtract.py because it has too much code and will become obsolete when CodeRush updates his UEFIExtract for single file extraction. The script will take care of alignment and checksums (hopefully), so it should build a valid uncompressed ffs file. But this isn't the high quality UEFITool, just a dirty glue&fix, so don't expect error-proof extraction. If you get more than one file, it means that there is more than one location for that GUID or that there is already a file with that name. Check UEFIExtract.bat, you also get auto or manual rename for ffs. Drop the BIOS on UEFIExtract.bat when you want to extract some GUIDs.
- While extraction is complete for every AptioV BIOS I have tested, Insyde is still partial. Every manufacturer seems to have a dozen GUIDs for every type of module. Even if I would parse every Insyde BIOS ever made, I have the feeling that a new BIOS might come with a different GUID for some EFI driver. So, for Insyde, XSearch.bat is still necessary to track every module.
- Added [ffssplit] to extract modules from AptioV CSM-EFI ffs.
- Added [isffs] to check if GUID exists in BIOS. Works only if main FV is not compressed. This is to prevent false positives in UEFI Shell and second microcodes module.
- Added [volext] to extract LZMA volume type ffs. It also works using UEFIExtract.py, but this is cleaner. Needed for EVGA X99 and some Insyde BIOS.
- Renaming of OROMs is based on namelink function. Add new IDs there, if you get unknown device/version. Since there are so many IDs, names, devices sharing IDs - this is a permanent work in progress.
- Intel GOP section needs some rework, because there are too much variables involved. I have an idea of using using DelayedExpansion and added a template, but needs to be tested for not breaking something else.

As I said before, if you or CodeRush feel that this doesn't belong here (being the fact that it borrows code from both of you), you can just ask to be removed or published only by PM.

Back to UBU.

- I have found some types of BIOS that are Aptio4, but are missing "USB Storage" in CSMCORE, like this one. I have added a search for "USB Device".
- On the other hand, EVGA X99 Micro BIOS E995_107 is AptioV, but not detected as such.
- Found 1022-7802 AMD RAID 3.3.1593.20 in sp69074. Sadly, no 7803 pair.
- Found 1002-4391 AMD AHCI 3.2.2.0 in Toshiba Satellite C7xD-B/L7xD-B. As opposed to 3.2.1.0, all I see is two patches, it could be a bug fix or nothing.
- Found a new ROM in X99 boards, in padding. It is 8086-8D7C Intel X99 SPSR, no version detected. An example is this BIOS, but I have detected it in others. It could be server related.
- I think I know where the problem with Atheros Lan UNDI is. The pair 1.1.0.3 EFI + 2.1.1.4/2.1.1.5 OROM is normally for regular controllers, while the pair 1.1.0.4 EFI + 2.1.1.5 OROM is for Killer cards, former Bigfoot-Bitfoot.
- Found some errors in AMD and EFI GOP version. Files attached.
- AMD VBIOS names should be Kaveri, Trinity, Kabini. See Kaveri, Trinity, Kabini or here.
- Is hexfind set to test wb as default, instead of rb? It has problems with read-only files.
- Since there could be some false positives in drvver, could you add a check for those affected? Like checking for Realtek or Aspeed or Intel in unicode? This doesn't affect UBU of course, since you already check before calling drvver, but it affects the normal testing, where "drvver file.ffs" could show version "Realtek 0.000" even when file.ffs has nothing to do with Realtek.
- Added some other files.

OMG, I asked a question here about overclocking and now I can't find it. Do these forums have option that will show me all my previous posts???

Zitat von Fernando im Beitrag #1092

---

Zitat von MonarchX im Beitrag #1091

---

OMG, I asked a question here about overclocking and now I can't find it.

---

>Here< is the post, which you obviously mean.

Zitat

---

Do these forums have option that will show me all my previous posts???

---

Have you ever tried to click onto your name as the author of any of your posts?

---

Thank you, but nope, not it. It was a later post where I provided my CPU specifics and a screenshot too (might be gone now), asking whether CPU Micrcode for overclockers would or could actually affect my CPU/system. Just tell me how to view all my posts and then I can find it. I'm not lazy - I just can't find the right options anywhere... I tried to click on my username from within forums and most forums have this "View all of this member's posts" option, but not these forums. I use Mozilla Firefox if that's of any help.

Just in case, here's my CPU info:



Would the microcode for overclockers (Sandry Bridge / Ivy Bridge) that is available through UBU benefit my CPU overclock somehow???

I am talking about Microcode 6A9-1B (newer) vs. 6A9-19 (older). The 6A9-19 is older, but supposedly better for overclockers. I remember a while back UBU stated somewhere that it was for Sandry Bridge overclocking, NOT Ivy Bridge. Now it seems it also benefits Ivy Bridge. Is that so? Would it help achieve higher clocks?

@SoniX

Here is what I have found inside the BIOS from Intel ME 10.0.30.1072 Tools:

- Intel Broadwell GOP 5.5.1028
- Intel RST RAID 13.5.0.2164
- Intel RST NVMe RAID 1.0.0.2063 (no idea what it is for)
- 8086-0406 Intel Haswell-Broadwell VBIOS 5.5.1032
- 8086-2822 Intel RST RAID 13.5.0.2164
- 8086-2822 Intel AHCI 2.00b 02222011 (it is not the first time I see an AHCI for 8086-2822. An older one also attached)

You won't be able to use Extractor or UEFITool, for two reasons:

- there are two GUIDs 0F9D89E8-9259-4F76-A5AF-0C89E34023DF which seems to be a signed container for the actual LZMA section. In order to use them, you will have to extract each one as is, remove first 0x240 bytes, save, replace as is.
- there are two volume images containing drivers and OROMs, 4E35FD93-9C72-4C15-8C4B-E77F1DB2D792 and 9E21FD93-9C72-4C15-8C4B-E77F1DB2D792. Will have to think of a way. For now, I have run Extractor once, removed 9E21FD93-9C72-4C15-8C4B-E77F1DB2D792 with UEFITool, run Extractor again.

I will report this to CodeRush, but will have to recheck my list first, since I have several others to report and I want to offer a clear bug report.