Zitat von SoniX im Beitrag #615

---

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.

---

Thank you. Ñ# utilities will require installed .NET framework, so it's not an option.

---

Usage of .NET framework makes the program bound to Windows (I know about Mono and stuff but it doesn't work as expected nearly 100% times), which is not a problem right now (because of MMTool usage, that is Windows-only app), but can become a problem later when MMTool will be replaced.
The main reason I've started UEFITool project was that PhoenixTool was closed-source Windows-only .NET 3.5 application. Yes, C# lets you write software quicker and don't bother about memory leaks, but nothing comes without it's price and having to download the whole .NET framework to use a very simple commandline utility - it's a bit too much for me.

Fixed CPU microcode modules. Made in order from highest to lowest.

Edit:
Fixed in UBU 1.7.0

Zitat von lordkag im Beitrag #602

---

@SoniX
2. Are you sure that you want to support ASPEED? If you open the latest 0.99.10 pack, you will see that they use 4 types (UEFI, UEFI_ROM, VBIOS, VBIOS+UEFI ROM) and 12 controllers. I have only seen ASPEED in Z87-WS or Z97-WS boards. You will have a terrible time supporting all 48 combinations for just a hand of boards. You could either use the same method as you did with Haswell VBIOS (user adds aspeed.ffs or aspeed.bin in folder), or just display the version.

---

Zitat

---

3. DrvVer doesn't work with all ASPEED Gop (example uefi_2050_1g.efi). Doesn't work with Intel GOP when the format is 2.0.xxxx. Ivy GOP 3.0.1020 attached as example.

---

ASPEED:
I focused on those modules that are in the BIOS from Asus P9D series.
Intel GOP:
Version 3.0.1020 has a small bug.

00 33 00 !2E! 00 30 00 00 00 31 00 30 00 32 00 30 00..... == 3.0.
 

!2E! - must be byte 0x00.
Quite possibly the same bug and 2.0.xxxx version. We can conclude the full version for the old format as 3.0.15.0019.

Zitat

---

4. New Z97 Asus boards have a PXE Lan with 8086-15A0 or 8086-15A1 link ID.

---

Added.

Zitat von Fernando im Beitrag #623

---

Zitat von SoniX im Beitrag #622

---

Zitat von lordkag

---

4. New Z97 Asus boards have a PXE Lan with 8086-15A0 or 8086-15A1 link ID.

---

Added.

---

Where? Is there already a new UBU version available or is it a silent update of the v1.6.1?

---

Oops! Sorry. :) Added in 1.7.0. I think next week will lay out the release until I test.

Zitat von SoniX im Beitrag #621

---

Fixed CPU microcode modules. Made in order from highest to lowest.

---

@error-id10t

Are you saying you used the files I posted, by replacing the ones from UBU, but still get the same problem? Then either this new EFI driver is not for your board (not likely, since they should be compatible with multiple IDs), or another PEI/DXE file needs to be updated for full compatibility. This can only be done by manufacturers.

But as Sonix pointed, you should only care about this if you need Wake-On-Lan or Boot from Lan.

@lordkag
I want a clarification on version Intel GOP 3.0.1020. It's not like a bug as I thought.
Just very strange division between the numbers. Here are 3 examples.
Version 3.0.15.1016 or 3.0.15.0.1016? (I did not understand.)

33 00 2E 00 30 00 00 00 31 00 35 00 00 00 00 00 31 00 30 00 31 00 36 00
 

3.0.1020

33 00 2E 00 30 00 00 00 31 00 30 00 32 00 30 00
 

3.0.1027

33 00 00 00 30 00 00 00 31 00 30 00 32 00 37 00
 

Note the position of the bytes 0x2E and 0x00 who must share major, minor, revision and build. As a result, there are difficulties to write code to properly display version.

@error-id10t
You mean that stitched Intel LAN version 6.2.08 in UEFI mode in the Setup section of UEFI LAN settings are not available? Example

Edit:
There is a suspicion that Intel LAN version 6.2.08 no one works. I'm waiting for the newer version 6.3.xx or version 6.1.xx will have to return

Zitat von CodeRush im Beitrag #620

---

Usage of .NET framework makes the program bound to Windows (I know about Mono and stuff but it doesn't work as expected nearly 100% times), which is not a problem right now (because of MMTool usage, that is Windows-only app), but can become a problem later when MMTool will be replaced.
The main reason I've started UEFITool project was that PhoenixTool was closed-source Windows-only .NET 3.5 application. Yes, C# lets you write software quicker and don't bother about memory leaks, but nothing comes without it's price and having to download the whole .NET framework to use a very simple commandline utility - it's a bit too much for me.

---

@SoniX

I would say to test bytes 12-16 or 0xC-0x10. If they are 0000000000, then size of version is 0x18 and version is 3.0.15.1016, but display 3.0.1016 anyway. If bytes 0xC-0x10 are different then 0000000000, then size of version is 0x10 and version is 3.0.1016, display 3.0.1016.

The reason is, even if version is something like 0.0.0000, bytes 0xC-0x10 would still be 0030003000.

Edited:

We need to account for Broadwell too. If bytes 0xC-0x10 and 0x12-0x16 are 0000000000, then it is Broadwell and size of version is 0xC, version is like 5.1018, but display 5.5.1018.
If only bytes 0xC-0x10 are 0000000000, then size of version is 0x18, version is like 3.0.15.1016, display 3.0.1016.
If bytes 0xC-0x10 are NOT 0000000000, then size of version is 0x10, version is like 3.0.1016, display 3.0.1016.

Zitat von lordkag im Beitrag #629

---

@SoniX

I would say to test bytes 12-16 or 0xC-0x10. If they are 0000000000, then size of version is 0x18 and version is 3.0.15.1016, but display 3.0.1016 anyway. If bytes 0xC-0x10 are different then 0000000000, then size of version is 0x10 and version is 3.0.1016, display 3.0.1016.

The reason is, even if version is something like 0.0.0000, bytes 0xC-0x10 would still be 0030003000.

---

I have edited my previous post for Broadwell.

I don't think that middle group is important. Not likely you would see 2.0.15.1016 and 2.0.18.1016, for instance. For example, I have Sandy GOP 2.0.35.1018 and 2.0.36.1019 in my folder of modules. They were definitely released one after the other, so the middle group follows last build.

Here is what I have extracted.

@lordkag
GOP Broadwell we still have one and it appears correctly, 5.5.1018. There will be more versions will look.
By version 2/3.0.xx.zzzz "old format". Value in the middle is not critical (.xx.), but not for experienced users can be misleading, so we tried to exclude from the display. If for you it is also not critical, then leave it as is. Will only find a solution to version 3.0.1020.
Thank you for your art collection. :)