It's not this Tools fault but Clevos, unlike other manufacturer Clevo doesn't adhere to many standards when it comes to their BIOS.
Also the things they do don't apply across their whole line-up.

Like for example IV P-Series has additional patching bytes in between an array of microcodes, if they go missing or even the order in which the Microcodes are inserted the system won't even boot.
They don't do this on the W-Series. Then on WM Models the old MMTool can't even read the CPU codes and they have to be even read manually.

I have my SPI chips socketed to re-flash them on each brick, but the EC on the Haswell models which is part of the main BIOS is no longer in use. Instead they have a custom ITE KBC controller which has a Master SPI (SSPI) located directly in the not correctly documented 133PIN chip itself, so my own board has gone puff last week and I am waiting for the replacement to show up...

If you are patient enough to wait I am going to re-base the Mod to v1.03.xx at that time, which always has all these modules up-to-date anyway...;)

Zitat von Fernando im Beitrag #136

---

@ Prema:

Welcome at Win-RAID Forum and thanks for your statement regarding the Clevo notebooks BIOS anomalies.
Enjoy the Forum!

Fernando

---

Hallo Fernando,

I’ve got an ASUS P8Z68-V PRO with the latest original bios (version 3603), with OROM version 11.2.0.152. With your tool UBU I edited this bios file and checked if it had worked with a hex editor, and it had. De mod bios file now has the OROM 12.7.
After that I tried updating the mod bios with the EZ option from the bios on the motherboard, but this failed. Fortunately I was able to recover the original bios via the recovery mode. I used a checksumtool to compare the original one with the mod bios and they do not match. Could it be that the motherboard refused to update it because the two files are not the same?

Alex

Zitat von Fernando im Beitrag #139

---

@ Alex_nero:
Welcome at Win-RAID Forum!

Now to your question:
Provided, that you have done the modding procedure correctly, you should be able to flash the modded BIOS into the mainboard BIOS chip without any problems by using the ASUS Bupdater in a real DOS environment.
Please download the actual version of the ASUS BIOS tool named Bupdater. You will find it >here< after having entered the "Driver & Tool" section.

Regards
Fernando

---

It works

Thank you very much

Hi Fernando, just tried the UBU tool to update the RST OROM and EFI SATADriver modules on my ASRock Z87 Extreme 6 board. The latest UEFI version 2.10 has versions 12.5.0.1815 for both of those modules.

I just tried option 1, and chose the update to 12.7.0.1936. The tool said the update was successful, and displayed the new version numbers correctly.

I then tried to flash the UEFI using the modded file, by using the ASR Instant Flash method. The UEFI file was seen by Instant flash, but the flash failed with a "Security Flash Error", that was the only message displayed. No problems after that, but just wanted to let you know.

I used UBU v 1.0.0 Pre-Release 14 test 28.10.2013.

Thanks for providing this tool, it makes it all to easy to change these modules! I haven't tried it yet on my ASRock Z77 boards.

Zitat von parsec im Beitrag #143

---

Hi Fernando, just tried the UBU tool to update the RST OROM and EFI SATADriver modules on my ASRock Z87 Extreme 6 board. The latest UEFI version 2.10 has versions 12.5.0.1815 for both of those modules.

I just tried option 1, and chose the update to 12.7.0.1936. The tool said the update was successful, and displayed the new version numbers correctly.

I then tried to flash the UEFI using the modded file, by using the ASR Instant Flash method. The UEFI file was seen by Instant flash, but the flash failed with a "Security Flash Error", that was the only message displayed. No problems after that, but just wanted to let you know.

I used UBU v 1.0.0 Pre-Release 14 test 28.10.2013.

Thanks for providing this tool, it makes it all to easy to change these modules! I haven't tried it yet on my ASRock Z77 boards.

---

For Gigabyte and ASRock and similar, you can update the first module GUID 17088572-377F-44EF-8F4E-B09FFF46A070. I tested it on some motherboards and it works. CPU microcode update can be done in UBU.

Zitat von SimpleTech im Beitrag #144

---

Open the BIOS file with a hex editor such as HxD. Select from Offset 00000000 to 00000FF0 (just before 00001000) and delete it. Then save and you should be able to flash again in the BIOS.

---

Zitat von SoniX im Beitrag #145

---

For Gigabyte and ASRock and similar, you can update the first module GUID 17088572-377F-44EF-8F4E-B09FFF46A070. I tested it on some motherboards and it works. CPU microcode update can be done in UBU.

---

Zitat von SimpleTech im Beitrag #146

---

The one problem with that is that if you put your computer to sleep, it loads the older microcode. It was driving me nuts until I realized that both modules need to be updated. I've only tested this on ASRock boards.

---

Very strange. Can this problem only on the ASRock?
On my Forum asked for the check.
Gigabyte Z87X-D3H
Mod BIOS F8c
In Volume 01 - new CPU microcode
In Volume 03 - old CPU microcodes
Result
Before
After sleep
After Hibernation.
As you can see the CPU microcode was not dropped from 17 to 09..

Add

Zitat von Fernando im Beitrag #148

---

Zitat von SoniX im Beitrag #147

---

@ Fernando
I think this must be specified at the beginning of the topic.

---

Please tell me, what I shall write and I will do it.

---