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…
@ Prema:
Welcome at Win-RAID Forum and thanks for your statement regarding the Clevo notebooks BIOS anomalies.
Enjoy the Forum!
Fernando
THX Fernando for maintaning this site, it saves all of us a lot of time in diggin the web for the latest files. I just saw that it was my first post here, even though we shared a few PMs before. 
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
@ 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
I’ll give it a try a soon as possible and i’ll let you know how it’s gone.
thanks,
Alex
Edit:
Sorry Fernando, but I have first an other question: I wonder if both bios (the mod one and the original) must have the same checksum result. If so, then I do something wrong because the checksums does not match
The checksum of a modded BIOS is always different from an original BIOS unless you correct the checksum after the modification.
In your case a checksum correction is not needed, because you only have replaced the Intel RAID ROM module, which is not checksum sensitive. Furthermore your ASUS BIOS has a .ROM extension, which means, that you will be able to flash a BIOS with updated Intel RAID ROM.
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.
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.
Oh, and you may notice in the BIOS that the CPU Microcode doesn’t change (should show revision 7 instead of 17). It’s because the first GUID string (17088572-377F-44EF-8F4E-B09FFF46A070) in MMTool is the one getting modified. The second one which is further down still has the older revisions. It’s pretty easy to fix. I simply selected the second one (it’s at Volume 04, Index 03) and use the file 306C3-17.ffs that SoniX included with the UEFI BIOS Updater.
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.
Will have to think about the utilities for automatic cutting header.
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.
Thanks for the info. I have not checked the wake from sleep.
Then it’s a problem. At the command prompt, so MMTool not set parameters of module replacement in a certain volume and index. 
@ 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.
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
Please tell me, what I shall write and I will do it.
Sorry. Do not write. Need to clarify the problem of CPU microcode update.
Ok, I have already mentioned, that the update of the CPU Microcode may be risky with some mainboards.
The risk is always there, even just flashing the original BIOS.
You are certainly right, but I think, that the following text makes clear, that there are some additional risks for users, who are going to update the CPU Microcode:
You are certainly right, but I think, that the following text makes clear, that there are some additional risks for users, who are going to update the CPU Microcode:
Ahhh ... Now it's all good. We have reduced the risks to a minimum when you update the module with CPU microcode. :)
Edit:
But this warning is necessary.
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.
Oh, and you may notice in the BIOS that the CPU Microcode doesn’t change (should show revision 7 instead of 17). It’s because the first GUID string (17088572-377F-44EF-8F4E-B09FFF46A070) in MMTool is the one getting modified. The second one which is further down still has the older revisions. It’s pretty easy to fix. I simply selected the second one (it’s at Volume 04, Index 03) and use the file 306C3-17.ffs that SoniX included with the UEFI BIOS Updater.
Thanks for the assistance, I tried what you suggested using HxD. I was able to delete that section of the file, but was warned the size of the file would be changed (no surprise) when I saved it. I did that anyway, and exited HxD.
I then tried to flash with that file, but the ASRock Instant Flash utility did not recognize the file, so no file to use for the update. For a test, I copied an earlier BIOS version, different file name, unmodified, to the same USB flash drive. So both BIOS files were on the flash drive, with correct file names. Instant Flash only recognized the earlier BIOS file.
So deleting that area of the BIOS file does not seem to result in a useable file. Does it make sense to write zeros to that block? What information is in that header area?
EDIT: I tried filling the 0 to FF0 area with zeros instead of deleting it, and then the BIOS file is recognized by Instant Flash. I did not flash the BIOS with that file yet… wondering about the contents of that "header" area.
I could also copy the original contents of that area from the original BIOS file to the modded BIOS file, but I’m wondering what was changed in the header area in the modded file that caused the first problem I had.