Zitat von SoniX im Beitrag #586

---

Zitat von AndreyPopov im Beitrag #585

---

or you want that print on chip?

---

Yes.

---

Already it is possible to say, OROM ASMesia v3.70 does not work on the controllers ASM1061.
Who has the onboard motherboard is ASM1062?

Hello All.
If anyone needs the support of an update GOP and OROM ASPEED video, then please specify the BIOSes for example.
Displays the version already implemented in version 1.6.7 beta.

Zitat von Fernando im Beitrag #591

---

@ SoniX:

You have titled your last post "UEFI BIOS Updater v1.7.0", but I can neither find the download link nor the changelog of an UBU version 1.7.0.
Has it been a typo or can we expect a new version very soon?

---

Zitat von SoniX im Beitrag #592

---

Version 1.7.0 is expected soon. But given the message from Pacman, a new GOP driver for the Broadwell, a new version of UBU until delayed.

---

Zitat von killkernel im Beitrag #593

---

In the expected V.1.7.0 of U.B.U have you revised the Rev. 1B of Ivy Bridge? If you read some posts before you'll see that the mictlan checksum revised versions of CPU micro-code worked flawlessly.
Thanks a lot for your efforts and great work...much appreciated!

---

Hello guys, first of all thanks for your work and continued support, you rock !
Second, it seems that I can't get to update all the AsMedia SATA OROM but only 2 of the 4 I have, here's a screenshot. The Mobo is a Rampage IV Extreme and the BIOS is the latest version 4901


Thanks in advance for your help

@lordkag
Do you have any thoughts about anything [Tool] "UEFI BIOS Updater" (UBU) (40)
I have no ideas, but to remove the 2 modules.

By the way, has long wanted to ask. You did not get the VBIOS OROM how to distinguish between versions 5.0.xxxx and 5.5.xxxx? And then we see only build version.

Zitat von SoniX im Beitrag #594

---

The module microcode checksums and status byte true. I have positive reports on the microcode 1B package of UBU. No one had any problems during upgrade and flashing the BIOS.

---

Hi I've got a p8p67 deluxe b2 with bios 2302 (i can't install other bios) and i'd like to know if i can mod the bios to update all roms. Is there a risk to brick the card if i do this?
Thanks a lot for your answers.

Zitat von SoniX im Beitrag #594

---

The module microcode checksums and status byte true. I have positive reports on the microcode 1B package of UBU. No one had any problems during upgrade and flashing the BIOS.

---

@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.

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.

@SoniX

1. I have the same info about Marvell as you. Maybe in the future we will see more boards, more versions.

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.

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.

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

5. Shub has duplicated modules, sharing same link. He should delete one 0612 and one 0611. Nothing you can do, this is a bug in CSMCORE, would be too much trouble to correct this.

6. I see this as a difference between older and new Haswell VBIOS. Older vs new:



Only in new:



You can use that section to differentiate them, until a new version appears.