Yes, you can exclude it, since it is not important. Print only 2.0.xxxx/3.0.xxxx/5.0.xxxx/5.5.xxxx.

Please note that there are also Sandy GOP that are in the format 2.0.xxxx, like 2.0.1023, 2.0.1024 and so on. So you need to test those bytes and decide for all the variants out there. At least we don't need to use the EFI Shell like in Atheros case, so I would say it is not that bad.

Zitat von lordkag im Beitrag #633

---

Please note that there are also Sandy GOP that are in the format 2.0.xxxx, like 2.0.1023, 2.0.1024 and so on. So you need to test those bytes and decide for all the variants out there.

---

It is indeed odd. So it might be a bug in there, in the modules. Check Z77X-UP5-TH BIOS F12, they both appear as 2.0. and 3.0. when it should be 2.0.1020 and 3.0.1018.

Zitat von lordkag im Beitrag #635

---

It is indeed odd. So it might be a bug in there, in the modules. Check Z77X-UP5-TH BIOS F12, they both appear as 2.0. and 3.0. when it should be 2.0.1020 and 3.0.1018.

---

You need to drop --- has_rev = (check[2] == 0x2E); --- since it is not reliable because of above bugged modules, instead use the method from here. Or at least this is my first impression.

Or search until you reach FF, then go back 5 bytes, which will be the end of version. Then based on the length (0x10, 0x18, 0xC) you extract only relevant bytes.

@lordkag
Until I found one solution. Changes in the code on GitHub. if only will not get very radical version. :)
Meet version DrvVer 0.9.2

@All
I ask everyone who uses UBU 1.6.1 and later, update the file DrvVer.
If there are problems in displaying GOP versions soobshaet immediately.

Edit:
Included in UBU v1.7.0

Hello i would like to ask how do you check if MMTool got a error or not like could not find bios file or something using the command prompt.
I am developing my own BIOS modding feature to put into my program and i would like to be able to error check it.

Unfortunately nothing. MMTool has no return errorlevel. Instead, he gives out error messages on the screen, which is extremely convenient.

Zitat von SoniX im Beitrag #640

---

Unfortunately nothing. MMTool has no return errorlevel. Instead, he gives out error messages on the screen, which is extremely convenient.

---

Hi, i've succesfully updated the most of the oroms on my mb asrock z77 oc formula thanks to UBU. My only problem is that i have two marvell 9172 onboard controllers to update and ubu only updates the first three distinct marvell modules it finds.
Ubu in main menu detects a total of 6 marvell modules: 2 for mv9172, 2 for mv927a and 2 for 9192 but after the update only 1 for each chipset is updated. Can be fixed in future release? In the meantime i'll try to do it manually using mmtool.

Zitat von SoniX

---

@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

---

Yup, that's what I meant. Had not seen it mentioned before so figured I'll post/ask but seems it's known.

@ GlitchyHack
The window that opens when MMTul error, has nothing to do with the windows command processor Windows.

@ Herrnobiz
Unfortunately, using MMTool, nothing can be done. If only remove 2 modules 9172 and 917a.

@ error-id10t
Problem confirmed your message, no one had unsubscribe to it. There was hope that someone module works, but apparently not.
I think, or will return the version 6.1.16 (it work) or wait 6.3.hh version (should have come out)

@SoniX

Yes, it works. I have checked with all the Intel GOPs I have. But the intriguing part is that ---if ((check[2] == 0x2E) || (check[2] == 0x00) || (check[10] != 0x00))--- always evaluates to true, isn't it?
Wouldn't ---if (check[12] == 0x00)--- be the better option? No need to change drvver again, since it already works. I'm just wondering.

@Fernando

Am I the only one who finds this message intriguing? I do hope I will be wrong and embarrassed by finding that the tool will be for personal use only or totally something else than UBU, because the alternative is unsettling.

Sure, MMTool is available for anyone to use, it has a list of commands, nothing secret about that. But UBU is more than a wrapper for MMTool. It was developed by Sonix (and maybe others? Maybe Coderush?), it was supported by the community, it was refined by feedback, hints and ideas. In a sentence, developed by Sonix, powered by community.
How can anyone release a competing product and complete as UBU, without copying UBU? It will be pretty hard to state that no code was borrowed, behind a closed source. And again, why should anyone take an open source project as UBU and turn it into a separate one? This will only force Sonix to lock his UBU and possibly remove it from win-raid.

I do hope I'm wrong, because otherwise I would think twice about being part of a community that approves this kind of treatment. Either this is a project that gets backed up by the forum/community (most desirable), or it is each on its own with his own ideas (less desirable). I would be disappointed to see the author of UEFI Download Tool going down this path. I offer you my apologies, if I should be proven wrong in my assumptions.

@lordkag

Zitat

---

But the intriguing part is that ---if ((check[2] == 0x2E) || (check[2] == 0x00) || (check[10] != 0x00))--- always evaluates to true, isn't it?

---

Even I do not know how, pure intuition. :)

Zitat

---

Wouldn't ---if (check[12] == 0x00)--- be the better option? No need to change drvver again, since it already works.

---

I have a couple of ideas on how to do a background check for Intel GOP versions 2 and 3. I'll check them and your idea too, as soon as I have time to add another block of code to support the next module EFI.

EDIT by Fernando: Quoting code corrected