thank you to stay withe me withe this problem...

this what i have

\Flash Programming Tool\Windows64>fptw64 -dumplock

Intel (R) Flash Programming Tool. Version: 9.1.2.1000
Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.

Platform: Intel(R) Z87 Express Chipset
Reading HSFSTS register... Flash Descriptor: Valid

--- Flash Devices Found ---
W25Q64BV ID:0xEF4017 Size: 8192KB (65536Kb)


Lock Settings.
=======================
Host CPU master: 00 00 0B 0A
ME region master: 00 00 0D 0C
GBE region master: 18 01 08 08
FPT Operation Passed


do you think i dont have other solution except buy another one ? :/


if its can help : My Asus Maximus VI Gene official link:

http://www.asus.com/fr/Motherboards/MAXIMUS_VI_GENE/

this:



i am actualy at home and can do many operation for many hours if you need

yes samething and yes under waranty for 8months and this black plate look solder :/

can do pinmod in another chip or area ?

Zitat von plutomaniac im Beitrag #21

---

No, this is the only way. Maybe @CodeRush knows something more regarding alternate descriptor unlocking methods altough I doubt it.

---

Right now, the easiest way out is to use a hardware programmer, either by using FD44Copier/FD44Editor to copy your serials to the official BIOS and flash that with the programmer, or dump the BIOS with the programmer, replace the ME region with the one from official BIOS, flash with programmer.

There could be a dirty alternative. I have located two calls for the "... SKU mismatch error" message. By patching them will only get you to another one "... not initiated due to an internal error", but it will tell us if FWUpdLcl can be run after patching. To prevent SKU mismatch I need to prevent the entire error branch from being called, which is a total of 33 times.

The time is the least of the worries, however. I have no idea how FWUpdLcl will behave once I suppress the errors. It could just flash as if no errors occurred, or it could end up writing gibberish, which will lead you to the programmer again.

There is no method of unlocking ME access other then asserting ME Security Override line ether by pinmodding or by using GPIO line connected to it, if any. The easiest way to solve this problem is to buy either cheap SPI programmer, or a compatible preprogrammed SPI chip.

@lordkag, ME update process is made by ME code itself, so I doubt that any modifications of FwUpdLcl can solve the problem.

hello

if a new release of firmware me 9.0 i can solve my problem ? or i can upload now only withe 9.1 version ?

oh then no choise except buyin a programer... i think i will order a new mother board and take the new VII Gene version :/

thank you all for your help especialy plutomaniac you are very great thank you a lot ! :)

@Fraizer

Disclaimer: if you decide to do what follows, then it is your responsibility for what might happen. I offer no guarantee, just the method.

As it would seem that FwUpdLcl is not the way to revert, let's go the other route, by unlocking SPI access. You have three files attached, open your original BIOS and replace them as is by using MMTool or UEFITool, then flash this new BIOS. If all goes well, you should have read/write access. The simplest way to test this is to use FTK, start backup.bat and check for a backup.bin in that folder. If no error printed and backup.bin exists, you can move to phase two, which is merefl.bat. You will place your original BIOS file (MAXIMUS-VI-GENE-ASUS-1603.CAP) in the FTK folder, and rename it to bios.bin, run merefl.bat. Check for errors.

If you want to do it all by hand, this is the way. Not sure if all are needed for this task, but I switched them all. There was a rumour about corrupted output when saving signed images, that is way I only extracted the corresponding modified files.



The more advanced way is here.