Zitat von greg.chalk im Beitrag #198

---

with GA-Z77X-UP5TH and 12j bios, at "EFI INTEL UNDI" I get the message "Unknown version. Please contact me."

---

Zitat von greg.chalk im Beitrag #198

---

At Marvell sata option rom i get double entry "Marvell 88SE91xx/92xx -1.0.0.0027" instead of one entry.

---

Zitat von greg.chalk im Beitrag #200

---

so when I will replace the efi module, it doesn't matter if it is compressed or uncombressed?

---

Zitat von Fernando im Beitrag #172

---

I suspect, that your problems to detect the TRIM activity within the OCZ Vector RAID0 are caused by the special SSD Controllers (Sandforce), which are known to react curious regarding TRIM support. You probably would have the same unsecure TRIM test results after a switch to an actual RST OROM/driver combination.

---

@greg.chalk

The Intel EFI Undi is named IntelGigabitLanx64. You can also look inside UBU -> VerDID.txt and check name, Device ID or GUID for quick finding.

There are 2 Marvell OROM's in your BIOS, but the second one is not valid.
Let me see if I got this right: extract CSMCore uncompressed, look for string PCIR for finding OROM name in its proximity, the Dev ID is stored in hex little-indian next to PCIR. A valid OROM is stored with a header like 20 00 ID Hex-length (e.g. for your Intel Lan 8086-1502 and length F800 = 20 00 86 80 02 15 00 F8 00 00, and then the module - 55 AA ....)

Your second Marvell OROM is for 1B4B-9230, but it is missing a valid header, an anchor for MMTOOL. Not sure if you should try to add one, if you don't have this controller. Also, in the case of your Lan 8086-1503, it is the anchor that it is wrong, thus confusing the tool, but the OROM is right. My guess is that only the Device ID from the OROM matters, the header being just for proper structuring. You can check this by flashing this BIOS and checking in Device Manager and in your BIOS.

@Sonix
How did you extracted the version from that EFI module? I couldn't find anything related to that number, except some meaningless(?) hex values.

Zitat von lordkag im Beitrag #205

---

@ Sonix
How did you extracted the version from that EFI module? I couldn't find anything related to that number, except some meaningless(?) hex values.

---

So,what is happen now with latest OROM VBIOS for Haswell iGPU ...?

@ Fernando
I read it, but there was a request to add. If unsubscribe, then everything will become clear.

Edit:
I was very confused by the checksum. CS is not equal to 00.

Zitat von ex58 im Beitrag #208

---

So,what is happen now with latest OROM VBIOS for Haswell iGPU ...?

---

Zitat von SoniX im Beitrag #210

---

Search for BSF files and customize OROM VBIOS Haswell.

---

Zitat von ex58 im Beitrag #211

---

Zitat von SoniX im Beitrag #210

---

Search for BSF files and customize OROM VBIOS Haswell.

---

So,
OROM VBIOS Haswell is excluded from UBU now?
(latest has been 2177)

---

@Sonix

Are you saying you flashed a BIOS just to check the version of an EFI module? I have searched a better way and since you have access to a larger database, could you confirm my findings?

For Intel Lan EFI just check for 20 0C 9A 66 and look a few lines bellow. It is located alone on that line and just above a white line.



For Intel RAID, GOP, SCU just check for 49 00 6E 00 74 00 65 00 6C 00 (hex for I.n.t.e.l.) and look bellow. If you want to be more precise, for coding a finder (if you haven't already):

For Intel RAID RST check for 52 00 53 00 54 00 (hex for R.S.T.) and the version is next to it.



For Intel RAID RSTe check for 52 00 53 00 54 00 65 00 (hex for R.S.T.e.) and the version is next.



For Intel RAID SCU check for 52 00 53 00 54 00 65 00 (hex for R.S.T.e.) or 53 00 43 00 55 00 20 00 44 00 72 00 69 00 76 00 65 00 72 00 (hex for S.C.U. .D.r.i.v.e.r.) and the version is next.



For Intel GOP check for 47 00 4F 00 50 00 20 00 44 00 72 00 69 00 76 00 65 00 72 (hex for G.O.P. .D.r.i.v.e.r.) and the version is somewhere bellow.



For Broadcom Lan EFI check for string UNDI_VER and the version is 3 lines above E4 14 45 16 E4 14 and also directly above a white line.



For Realtek UNDI EFI I couldn't find any pattern, but it doesn't matter, since they are posted in Realtek download section.

The number of digits seems to follow the power of 2, for both groups and overall (e.g. 1.5.48, 2.024, 2.0.6.6, 15.4.7, 12.7.0.1936, 1.0.0.1038).
All the above search was done in uncompressed modules. If you have some that don't follow the rule, maybe you could share them.

@lordkag
Correctly. :)
Add a little.
Version EFI Realtek UNDI almost as Intel UNDI version. In all versions in one place.


And unfortunately not yet sorted out the modules Qualcomm-Atheros/Bigfoot. Therefore it is necessary to use the EFI Shell to determine the exact version before looking in Hex-editor.
If there is interest in finding versions QCA, then attach the archive known and not known versions.

@Sonix
Thanks for the samples and for the Realtek tip. I haven't found anything yet for Atheros and I'm afraid it could require some disassembly. If you search for 25 64 2E 25 64 2E 25 64 2E 25 64 you will find the version in blank, that it is probably filled by a call to some instructions.



This is how it looks for qca_1.1.0.3.efi. Maybe someone fluent in this language can spot something in there.



I have found a more precise way for Intel Lan EFI.



Now something that might not be related to UBU. In the BIOS posted here by greg.chalk there is a problem with Marvell controllers. UBU sees the first 9192, but fails to see the second 9230 (because it is invalid).
This is how the first looks, which UBU wrongly reports as being inserted twice.



This is the second, which can't be detected or replaced.



This is how I solved it: replace the yellow section with valid input (in this case 20 00 4B 1B 30 92), correct the checksums in CSMCORE (I only had to replace something in a padding zone until the module's checksum-8 became F8), save and reinsert CSMCORE, then use UBU or MMTOOL for replacing that OROM with a new one. The only problem was that UBU still reported the first one twice (alongside the newly detected 9230), which is a bug in UBU, I think.

How can the checksums recalculation in CSMCORE be automated after hex editing? Is there a tool for this? How many checks there are, besides checksum-8 for module (=F8?) and hex length in header? Is 10h and 11h involved like in Insyde headers?