Gigabyte X5 Me Firmware Issues

Special Topics Intel Management Engine
1

Hi,

I know this forum (really great one and useful) since a while but never needed help until now.

Here’s the issues I recently faced with this Gigabyte Laptop (Aorus X5). Apparently these issues was caused by a forced update from Windows 10 (silent update) and a conflict with the driver update application
provided by Gigabyte/Aorus. I did not update or touch the ME firmware manually, but somehow this one act weird now since then.

Let me explain the problem more.

Bad part:
Fan doesn’t work properly anymore
The laptop turns off by itself after 15 to 20min (when I’m on Windows). The good thing is that I can actually go on Windows,
the bad thing is I cannot boot anything else (F9/F12 seems broken, that includes the legacy mode)
Ethernet and Wifi stuff is broken
When I try to flash the full bios provided by the OEM/Brand (this one starts and after a few seconds, success and reboot with no change)
All the modifications made into the bios and saves are not taken into account. The laptop reboots by itself after saving and quitting (but the settings remain unchanged)
Bios info shows me a nice ME firmware n/a

Good part:
I can go to windows, use the laptop normally but with the risk of this one turning off after a while
I can go to the bios (that all)
I discover how to launch the recovery bios mode (not sure it is the real one, I’m sure there is another one out there, but basically
ctrl home the right time brings me to the bios menu + an unhidden recovery tab where there is NVRAM reset/Boot block stuff + proceed to flash (when I choose this one
it shows directly flash failed, that’s because I probably don’t have the right bios name for recovery or maybe that I didn’t completely figure out how to trigger the full recovery bios)

And all this because of the ME Firmware. It is obvious that this ME Region/Descriptor Region was put here to annoy the users instead of really helping.
Honestly, I don’t think it’s a hardware problem and hopefully can be resolved in a software way.

fpt info


meinfo


I add a few files to this post, if this can help (fitc decomp of the OEM official bios, the X5 bios map and the result of a backup bios made by afuwin that is a total non sense)

Thanks for your help guys.

backupbios with afuwin.rar (3.22 KB)

X5 map file.rar (576 Bytes)

Fitc decomp.rar (3.34 MB)

2

There may be extensive damage in this case, both ME and BIOS I mean. It could be BIOS mostly. Try a CMOS, if not possible then restore default BIOS settings. Then, make sure that the option “Enable ME Reflash” is Disabled at the BIOS. After a reboot, does the problem persist? Run fptw -d bios.bin -bios and attach the resulting file here.

Gigabyte usually leaves the Flash Descriptor unlocked for easy service (the downside is easy bricking as well if something goes wrong) and that is verified by the fact that their own BIOS updater batch script uses FPT to update/reflash the entire ME region which requires read/write access there and thus an unlocked flash descriptor. Why you get Error 26 in this case, I’m not sure yet. We should see if the BIOS is ok first and make it stable with settings being kept and not removed upon restart as you say.

3

I have doubt about the BIOS itself, not sure.
But here’s something new I found, checking around every possible silent log (made by Windows 10 or Drivers Update)
the ME was updated to a 10.x version, this is pretty weird because this laptop come with a ME 9.1.x.

I don’t know how this could happen, despite the Aorus X5 come with a Broadwell CPU and new HM97 chipset (by the time) it has always come with the 9.1.x ME
So why this was forced/silently updated to 10.x when this is not compatible ?

Already tried CMOS/Remove battery, 10sec holding power button etc… (going to the bios doesn’t hold certain settings) stuck in UEFI mode, can’t even go into legacy.

Enable ME Reflash is an hidden feature only visible by looking the bios file itself, not visible in the bios menu.
I know that CTRL + Home unlock the recovery part (look like partial one)

Result with fptw is the same than previously posted :wink:

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

Number of LPC Devices supported: 254
LPC Device Id: 8CC3.
Platform: Intel(R) HM97 Express Chipset
Initializing SPI utilities
Reading HSFSTS register… Flash Descriptor: Invalid

Region Limits as programmed into the SPI Registers
FREG0 - DESC Region:Base Address: 0x1FFF000 Limit : 0x000FFF
FREG1 - BIOS Region:Base Address: 0x1FFF000 Limit : 0x000FFF
FREG2 - ME Region:Base Address: 0x1FFF000 Limit : 0x000FFF
FREG3 - GbE Region:Base Address: 0x1FFF000 Limit : 0x000FFF
FREG4 - PDR Region:Base Address: 0x1FFF000 Limit : 0x000FFF
Address Limit 0x001000 Maximum Memory 4kB


— Flash Devices Found —
MX25L6405D ID:0xC22017 Size: 8192KB (65536Kb)

Using software sequencing.
Reading region information from flash descriptor.

Error 26: The host CPU does not have read access to the target flash area. To enable read access for this operation you must modify the descriptor settings to give host access to this region.


Yes I saw that the Flash Descriptor is unlocked but I’m not able to do anything at the moment, until I figure out if there is actually a fpt or something that let me able to reflash the ME.

Here’s the smartflash.ini from the OEM

[BIOS]
MACHINE=X5
BIOS=B07D07
EC=F008
HIDDEN=1
BIOSMODE=1
ECMODE=0
ECOLD=0
ECLIMIT=4
P2542GH=0
PBAR=100
2442TTP=0
SECUREDETECT=0
ISACSOURCE=0
ISRAIDMODE=1


Here’s the flash.bat they use

@ECHO off

set ROMIMG=X5BF.B07

:ROM
fpt -f %ROMIMG% -ME
afudos %ROMIMG% /p /b /n /s /r /oemcmd:1 /k /shutdown %1 %2 %3



When I try to the official bios flash, it start and after few seconds success and reboot.
But there is no change at all, like something need to be first erased/rewrite, I don’t what exactly but I was surprise to also find Invalid Flash Descriptor
when most of users found Valid Flash Descriptor.

Here’s the fparts.txt linked to the MX25L6405D

MX25L1605D, 0xC22015, 0x1000000, 0x1000, 0x20, 64, 0

I’m not sure if you saw the dump made with the Afuwin, it is pretty weird.

4

The flash descriptor is corrupted, it’s addresses are all the same and invalid. Flash Descriptor is 4KB at the beginning so for example it should have a base (start) of 0x000000 and a limit (size-0x1) of 0x000FFF as 0x1000 = 64KB. I assume fpt is trying to access an invalid location based on what it reads from the FD. Since the FD is corrupted, FPT cannot be used with region-specific commands such as -desc, -bios, -me etc. So, let’s try a test with the commands below which should dump the sections manually (based on X5BF.D07 image from Gigabyte):

fptw -d desc.bin -A 0x000000 -L 0x001000
fptw -d me.bin -A 0x001000 -L 0x1FF000
fptw -d bios.bin -A 0x200000 -L 0x600000

Regarding ME, these is no way you have ME10 firmware flashed, the platform wouldn’t even post. You still have ME9.1 firmware, maybe the logs point to the drivers being updated to v10.x, definitely not the firmware.

5

One problem, the simple fptw -d commands doesn’t work at all and return me the same error 26, the address are the one visible by using the command -verbose.
I only see the same address, fptw don’t even try to send any command, not sure why, maybe I have the wrong version.

I can understand if I had the ME10 firmware flashed, the platform wouldn’t even post but I forget to mention that when I turn on the laptop, it take like 30sec to 1min to post
and after boot normally, not sure if it doesn’t ignore the ME region if this one is invalid and keep boot like normal.

On the bios like mentionned previously it show ME Firmware N/A
When I go to the bios, it show (system : setup instead of user)

Exactly what I show on the bios



Here’s when I use the Ctrl - Home in the right timing


I don’t remember which one fpt I try like few hours before who show me a different error (PCI to Windows something) run into admin (I was actually running CMD in admin mode)

6

The fpt version you are using is correct, admin rights should not matter for this procedure. So the command fptw -I shows those aforementioned (corrupted) FD addresses? I’m asking because the fpt -I output I know looks a little different but it could be that I’m testing on older platforms.

Although I highly doubt it will be of any help in your case, try fptw -greset command and check status after the system boots up again. The long bootup probably has to do with the ME not initializing properly and entering recovery mode or similar.

Other than that, I can’t think of something else. If we can’t use software tools to read or write to the SPI chip because the FD is messed up, the only solution is a hardware programmer or free service in case it’s under warranty as the problem occurred with their own update procedure.

7

Recovery Mode is only when I use Ctrl - Home I can access to the AMI recovery mode like showed (pics)

Here’s what it said when I put fpt -I -verbose (fpt -greset -verbose show the same things)
Like I said, it could be fpt because is like fpt doesn’t even try to send the command ?
I can even have the same result by using fpt -d test.bin

fpt -I -verbose

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

Number of LPC Devices supported: 254
LPC Device Id: 8CC3.
Platform: Intel(R) HM97 Express Chipset
Initializing SPI utilities
Reading HSFSTS register… Flash Descriptor: Invalid

Region Limits as programmed into the SPI Registers
FREG0 - DESC Region:Base Address: 0x1FFF000 Limit : 0x000FFF
FREG1 - BIOS Region:Base Address: 0x1FFF000 Limit : 0x000FFF
FREG2 - ME Region:Base Address: 0x1FFF000 Limit : 0x000FFF
FREG3 - GbE Region:Base Address: 0x1FFF000 Limit : 0x000FFF
FREG4 - PDR Region:Base Address: 0x1FFF000 Limit : 0x000FFF
Address Limit 0x001000 Maximum Memory 4kB


— Flash Devices Found —
MX25L6405D ID:0xC22017 Size: 8192KB (65536Kb)

Using software sequencing.
Reading region information from flash descriptor.

Error 26: The host CPU does not have read access to the target flash area. To enable read access for this operation you must modify the descriptor settings to give host access to this region.


There is maybe a easir way using the recovery (ctrl - home) but I still need to figure out which bios name or how to fully trigger this one.
After a certain investigation I found like informed (X5.bin or AMI.ROM.CD001 CD001 representing the CD-Rom I guess but there is not physical cd/dvd rom on the Aorus X5, there is also some mention to the El Torito Specification bootable) but the problem is that I can’t even boot in pure dos because the F9/F12 is broken and force a reboot each time, can’t go to legacy too

But I could go the pure dos if I had a UEFI bootable hard drive that contain the right sequence, I know that I can only boot in UEFI mode.

So maybe the solution is using the AMI recovery mode (but still didn’t find how to push this one to read the right bios)
Make a boot UEFI hard drive that include pure dos
or maybe find a way under Windows.

I think the Aorus boot in a kind of safe mode, not sure, I’m sure there is away to resolve this issue more easier but I still didn’t find how.

Hardware programmer (don’t want to avoid the warranty)
Free service yes but they offer a pretty awkward technical service, at this point there is nothing good from this side.

Here’s the result I have with MEinfowin (FTK 10)


Intel(R) MEInfo Version: 10.0.30.1054
Copyright(C) 2005 - 2014, Intel Corporation. All rights reserved.


FW Status Register1: 0x00003006
FW Status Register2: 0x00070000
FW Status Register3: 0x00000000
FW Status Register4: 0x00000000
FW Status Register5: 0x00000000
FW Status Register6: 0x00000000

CurrentState: Disabled and waiting to timeout
ManufacturingMode: Disabled
FlashPartition: Valid
OperationalState: Transitioning
InitComplete: Initializing
BUPLoadState: Success
ErrorCode: Image Failure
ModeOfOperation: Normal
Phase: ROM/Preboot
ICC: No valid OEM data, ICC not programmed
SPI Flash Log: Not Present
ME File System Corrupted: No
PhaseStatus: INIT_HECI

FPF and ME Config Status: Not committed

HECI device is found to be disabled.

Error 9256: Communication error between application and Intel(R) ME module (FW Update client)

Error 9256: Communication error between application and Intel(R) ME module (FW Update client)

Error 9256: Communication error between application and Intel(R) ME module (FW Update client)

Windows OS Version : 6.2.9200 “”
OS BIOS Support : UEFI

Table Type 0 ( 0x 00 ) found, size of 24 (0x 18 ) bytes

Windows OS Version : 6.2.9200 “”
OS BIOS Support : UEFI

Table Type 0 ( 0x 00 ) found, size of 24 (0x 18 ) bytes
Table Type 1 ( 0x 01 ) found, size of 27 (0x 1B ) bytes
Table Type 2 ( 0x 02 ) found, size of 15 (0x 0F ) bytes
Table Type 3 ( 0x 03 ) found, size of 25 (0x 19 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 8 ( 0x 08 ) found, size of 9 (0x 09 ) bytes
Table Type 9 ( 0x 09 ) found, size of 17 (0x 11 ) bytes
Table Type 9 ( 0x 09 ) found, size of 17 (0x 11 ) bytes
Table Type 9 ( 0x 09 ) found, size of 17 (0x 11 ) bytes
Table Type 9 ( 0x 09 ) found, size of 17 (0x 11 ) bytes
Table Type 9 ( 0x 09 ) found, size of 17 (0x 11 ) bytes
Table Type 10 ( 0x 0A ) found, size of 6 (0x 06 ) bytes
Table Type 11 ( 0x 0B ) found, size of 5 (0x 05 ) bytes
Table Type 12 ( 0x 0C ) found, size of 5 (0x 05 ) bytes
Table Type 32 ( 0x 20 ) found, size of 20 (0x 14 ) bytes
Table Type 34 ( 0x 22 ) found, size of 11 (0x 0B ) bytes
Table Type 26 ( 0x 1A ) found, size of 22 (0x 16 ) bytes
Table Type 36 ( 0x 24 ) found, size of 16 (0x 10 ) bytes
Table Type 35 ( 0x 23 ) found, size of 11 (0x 0B ) bytes
Table Type 28 ( 0x 1C ) found, size of 22 (0x 16 ) bytes
Table Type 36 ( 0x 24 ) found, size of 16 (0x 10 ) bytes
Table Type 35 ( 0x 23 ) found, size of 11 (0x 0B ) bytes
Table Type 27 ( 0x 1B ) found, size of 15 (0x 0F ) bytes
Table Type 36 ( 0x 24 ) found, size of 16 (0x 10 ) bytes
Table Type 35 ( 0x 23 ) found, size of 11 (0x 0B ) bytes
Table Type 27 ( 0x 1B ) found, size of 15 (0x 0F ) bytes
Table Type 36 ( 0x 24 ) found, size of 16 (0x 10 ) bytes
Table Type 35 ( 0x 23 ) found, size of 11 (0x 0B ) bytes
Table Type 29 ( 0x 1D ) found, size of 22 (0x 16 ) bytes
Table Type 36 ( 0x 24 ) found, size of 16 (0x 10 ) bytes
Table Type 35 ( 0x 23 ) found, size of 11 (0x 0B ) bytes
Table Type 26 ( 0x 1A ) found, size of 22 (0x 16 ) bytes
Table Type 28 ( 0x 1C ) found, size of 22 (0x 16 ) bytes
Table Type 27 ( 0x 1B ) found, size of 15 (0x 0F ) bytes
Table Type 29 ( 0x 1D ) found, size of 22 (0x 16 ) bytes
Table Type 39 ( 0x 27 ) found, size of 22 (0x 16 ) bytes
Table Type 41 ( 0x 29 ) found, size of 11 (0x 0B ) bytes
Table Type 41 ( 0x 29 ) found, size of 11 (0x 0B ) bytes
Table Type 41 ( 0x 29 ) found, size of 11 (0x 0B ) bytes
Table Type 7 ( 0x 07 ) found, size of 19 (0x 13 ) bytes
Table Type 7 ( 0x 07 ) found, size of 19 (0x 13 ) bytes
Table Type 7 ( 0x 07 ) found, size of 19 (0x 13 ) bytes
Table Type 7 ( 0x 07 ) found, size of 19 (0x 13 ) bytes
Table Type 4 ( 0x 04 ) found, size of 42 (0x 2A ) bytes
Table Type 221 ( 0x DD ) found, size of 12 (0x 0C ) bytes
Table Type 16 ( 0x 10 ) found, size of 23 (0x 17 ) bytes
Table Type 17 ( 0x 11 ) found, size of 40 (0x 28 ) bytes
Table Type 17 ( 0x 11 ) found, size of 40 (0x 28 ) bytes
Table Type 17 ( 0x 11 ) found, size of 40 (0x 28 ) bytes
Table Type 17 ( 0x 11 ) found, size of 40 (0x 28 ) bytes
Table Type 19 ( 0x 13 ) found, size of 31 (0x 1F ) bytes
Table Type 20 ( 0x 14 ) found, size of 35 (0x 23 ) bytes
Table Type 20 ( 0x 14 ) found, size of 35 (0x 23 ) bytes
Table Type 221 ( 0x DD ) found, size of 54 (0x 36 ) bytes
Table Type 221 ( 0x DD ) found, size of 68 (0x 44 ) bytes
Table Type 221 ( 0x DD ) found, size of 26 (0x 1A ) bytes
Table Type 136 ( 0x 88 ) found, size of 6 (0x 06 ) bytes
Table Type 13 ( 0x 0D ) found, size of 22 (0x 16 ) bytes
Table Type 14 ( 0x 0E ) found, size of 17 (0x 11 ) bytes
Table Type 127 ( 0x 7F ) found, size of 4 (0x 04 ) bytes

Error 9256: Communication error between application and Intel(R) ME module (FW Update client)

Error 9459: Internal error (Could not determine FW features information)

8

Why are you using MEInfo v10 on a system with v9.1 firmware? These are not compatible. Use the latest MEInfo v9.1 that I have uploaded at the System Tools found at the first post of mine.

The ME recovery mode is not related to the AMI recovery mode. So ctrl+home or other such hotkeys don’t matter for ME itself but for the BIOS.

So no matter what you type at FPT, you always get the Error 26? Mmm, it could make sense. Even for a “simple” command such as -greset, FPT has to read and write a byte which triggers the reset. Maybe it cannot even do that because it doesn’t know where to write. Similar for -I as it has to read? Maybe. Honestly I don’t have currently that much knowledge/experience to really understand what’s going on. At this point, this problem looks more like a general SPI image corruption and less ME-related.

If the problem is indeed a BIOS one (doubt it, the FD should not look like that, FPT should be able to work at a basic level) then yes, you may be able to restore it via the AMI BIOS Recovery, provided that you know the filename. Maybe ask Gigabyte or search around for other users with the same system? I know PhoenixTool suggests some recovery names for some BIOS but I’m not sure if it will work in your case.

9

It doesn’t matter which MEInfo I use, it give me exact same error with V9.1 too (there is just one more error with V9.1)
Error 0099: Unknown error code (this is the only difference between MEInfo 10 or 9.1, all the rest is exactly the same)

When I was talking about the AMI recovery mode, I was talking about trigger a full bios flash (that include the ME/Descriptor region)
No matter what I type in FPT I have this error, I had a different error with another FPT (asking about Admin mode, PCI access something) but don’t remember which one I used to have this result.

I saw some users facing the Error 26 with different FPT and found one who worked for them (but not related to my laptop)
If FPT can find the flash part, there is probably a way to erase/rewrite somehow but I guess need to find the right FPT maybe ?

Or maybe what cause this is the address informed in fparts.txt

; 3) Device Size (in bits)
; 4) Block Erase Size (in bytes - 256, 4K, 64K)
; 5) Block Erase Command
; 6) Write Granularity (1 or 64)
; 7) Enable Write Status Register Command (1- True, 0- False)

See the 3 to 7 part

Here’s the one
MX25L6405D, 0xC22017, 0x4000000, 0x1000, 0x20, 64, 0

Could be related to that.

Concerning Gigabyte nor Aorus, weird position, the main problem is the timeline and how long to see my machine back.
I also doubt they will reveal the software solution, I remember that the P25 come with a smart+ switch that could boot directly to bios flash features etc…
Somehow there is a lot of keys trigger possibility but go find which one they are.

Like I said, I doubt that the issue is caused by the Bios but mostly by the ME region part, maybe it could be the fact the address changed, different one and
because fpt is based on the fparts.txt that can bring a false error too, do not know where to send the command, I don’t know, I guess

See I removed the MX25L6405D part from the fparts.txt
Here’s another return from fpt (finding a second MX25L6406E this time)


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

Platform: Intel(R) HM97 Express Chipset
Reading HSFSTS register… Flash Descriptor: Invalid

— Flash Devices Found —
MX25L6406E ID:0xC22017 Size: 8192KB (65536Kb)


Error 26: The host CPU does not have read access to the target flash area. To enable read access for this operation you must modify the descriptor settings to give host access to this region.


So I guess there something to look into the fparts.txt no ? maybe

If I remove all the ID:0xC22017 related
Maybe we found something, hopefully

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


Platform: Intel(R) HM97 Express Chipset
Reading HSFSTS register… Flash Descriptor: Invalid

— Flash Devices Found —

Error 103: There are no supported SPI flash devices installed. Please check connectivity and orientation of SPI flash device.


What is weird is the Flash Descriptor keep stay invalid !
despite I removed all the supported SPI flash devices installed

this is what I removed from fparts.txt

MX25L6405D, 0xC22017, 0x4000000, 0x1000, 0x20, 64, 0
MX25L6406E, 0xC22017, 0x4000000, 0x1000, 0x20, 64, 0
MX25L6436E, 0xC22017, 0x4000000, 0x1000, 0x20, 64, 0
MX25L6445E, 0xC22017, 0x4000000, 0x1000, 0x20, 64, 0
MX25L6455E, 0xC22617, 0x4000000, 0x1000, 0x20, 64, 0
MX25L6473E, 0xC22017, 0x4000000, 0x1000, 0x20, 64, 0
MX25L6475E, 0xC22017, 0x4000000, 0x1000, 0x20, 64, 0
MX25L6450F, 0xC22017, 0x4000000, 0x1000, 0x20, 64, 0

There is something to do between fpt and fparts.txt

Another interesting part, using -verbose while fparts.txt spi/me removed

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

Number of LPC Devices supported: 254
LPC Device Id: 8CC3.
Platform: Intel(R) HM97 Express Chipset
Initializing SPI utilities
Reading HSFSTS register… Flash Descriptor: Invalid

Region Limits as programmed into the SPI Registers
FREG0 - DESC Region:Base Address: 0x1FFF000 Limit : 0x000FFF
FREG1 - BIOS Region:Base Address: 0x1FFF000 Limit : 0x000FFF
FREG2 - ME Region:Base Address: 0x1FFF000 Limit : 0x000FFF
FREG3 - GbE Region:Base Address: 0x1FFF000 Limit : 0x000FFF
FREG4 - PDR Region:Base Address: 0x1FFF000 Limit : 0x000FFF
Address Limit 0x001000 Maximum Memory 4kB


— Flash Devices Found —

Error 103: There are no supported SPI flash devices installed. Please check connectivity and orientation of SPI flash device.


So I guess is really FPT/Fparts.txt the problem and not the ME/Bios/SPI, because the FPT/Fparts.txt doesn’t inform properly or don’t even
send the command, I may need another FPT or better values in fparts.txt.

Another new stuff, I try FPTW from the FTK9 pack
Here’s the error I have (it was this one who show me the PCI access error)

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


Error 284: Fail to load driver (PCI access for Windows).
Tool needs to run with an administrator priviledge account.

10

1) To my knowledge, AMI BIOS Recovery deals only with the BIOS and not the whole SPI image. It may depend on OEM implementation but I wouldn’t know what stands true in this case.
2) For each platform you can use only the same major.minor tool versions. For ME9.1 you need 9.1 tools, not 10.0, not 11.0 or so. The only exception is ME7 with ME8 tools but that’s irrelevant here. There are no “other” versions of FPT. FTK includes what is posted here, it’s even said by CodeRush himself at the github readme. He may not have updated the versions used at FTK but that doesn’t make them more compatible with given systems or “different”, just older and possibly buggy with less features etc.
3) As far as Intel tool error codes, do not trust them. Sometimes unexpected errors show after irrelevant changes. For example removing the contents of fparts.txt results in a “admin rights required” error which is completely irrelevant in reality. It just thinks that it cannot read the file because it’s empty. So no, admin rights are not needed for it to work but you can always launch it as such, noone is saying that’s not a good practice in general.
4) The problem is not with fparts.txt, the chip info are correct. The size is correct (8MB), the chip block erase (20) is correct etc as can be seen at the official specs. By removing the spi chips from the fparts.txt file you neither gain nor see anything new. It tells you that it cannot detect your SPI chip, simply because it was removed from it’s database. The HSFSTS register may not rely at fparts.txt at all, read the SPI Programming Guide found at the System Tools v9.1 package and search for HSFSTS to learn more about it.
5) The problem is not with FPT or fparts.txt, you saw the output of AFU: garbage. It cannot read data if it doesn’t know where they are located. Another sign of a corrupted Flash Descriptor. The goal is to dump the firmware. Try some other BIOS dumping tools which do the same job, even though I suspect you won’t see anything different. Maybe that Universal BIOS Backup tool or something newer. I’m not following such 3rd party tools as FPT has been enough for Intel systems.

11

1) Look like it can deals with the whole SPI image. OEM Implementation like you said.
2) I was not recommending anything, I was simply pointing out that no matter each version of Meinfo I use, it provide the same errors, like MEInfo, FPT, etc… do not know where to look.
Some users faced error 26 with different FPT (OEM use also FPT who look like different, not same size ) and you can even find devcon, messageP, etc… when you unzip the official bios
itself (see the attached file)http://www.filedropper.com/biosx5
3)I don’t trust the Intel tool error, this is the reason why I’m doubtful with the error 26 (FPT) because there is not even a command return or anything else.
Actually removing the contents of fparts, FPT try to look for another SPI revision that share the same the device ID (0xC22017)
so far FPT looked at the wrong SPI too, because it is actually MX25L6406EM2I-12G and not MX25L6405D like fparts/fpd aim to point out.
4) actually the problem could be FPT/Fparts that do not know where to look, FPD even pointed the wrong chip info, looking only for the device ID.
Looking by the software itself, it pretty obvious that FPT send the wrong command and provide wrong error when it don’t know how to provide correct information

THIS IS A DEBUG VERSION! NOT FOR DISTRIBUTION…----------------------------------------------…9.1.10.1000…%s %s …Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved…%s…%s %s …fparts.txt…Reading FW Status failed!..Retrieve Operation: Failed…Retrieve Operation: Successful…Commit Operation: Failed …Commit Operation: Successful …Compare Operation: Failed.

That doesn’t explain the Flash Descriptor : Invalid.
5) Afuwin could be pretty limited in terms of backup too, concerning other bios dumping tools, well, I didn’t find anything, Universal Bios Backup tool doesn’t work with UEFI bios type.
I try my best finding something but I didn’t find the tool to do a correct backup.
Anyway thanks for taking time trying to help me :slight_smile:

Here’s what I saw using AMIBCP.


12

Newer version of the ME tools will report the “platform not supported” error. I don’t know if Intel forgot to error it out at v10 but if, for example, you run the v11 MEInfo, there is no way you won’t see that message. Based from experience I can tell you that using the latest tool versions of the same generation is the way to go. Anyway, that’s not important right now and off-topic.

Another reason I don’t believe FPT is the cause: Gigabyte includes it at their own BIOS release. They know it works, they have flashed the same way, a lot of people using that system have flashed that way properly. That cannot be true unless FPT and it’s SPI chip database are working just fine for the system in question. Also, all three fpt included at the latest BIOS (DOS, Win32, Win64) are exactly the same as the ones found at any ME9.1 package after 9.1.10.1000 which is the last time they were updated. The hash is identical, nothing different. Moreover, the OEMs use that same version of FTP, there is no OEM-only version. These are all valid facts after almost two years of “research”. Seeing that text inside the spoiler tag, I have to ask though: What exact tool (link) showed the text “THIS IS A DEBUG VERSION! NOT FOR DISTRIBUTION”? I’m curious as I’ve never seen that in any Intel tool so far. It makes no sense to me.

The BIOS options don’t matter anymore. “Enable ME Reflash” would only make sense if it was a) visible at the BIOS and b) set to Yes, Enabled. So that’s not any more helpful at this point.

For other software flashers/dumpers with their own SPI database etc, a very well known one is flashrom. Definitely give it a try.

13

Well on my side I didn’t face any platform not supported, the only one ME Tools I faced this was with ME Tools 8, ME Tools 9 to 10 didn’t showed the the platform not support error.

I can understand that different version can not work. But here’s is definitely a different issue, I was just provided the MEinfo from 9 to 10 that show the exact same weird address.

FPTW, FPT, FPTW64 seems to not share the same hash. I’m sure that FPT could also be the problem because like I said, if I try this with other computer, the FPT can get/set/read command but here
there is no return at all and point to wrong commands/chip, I can show you multi spi that share the same id put FPT send wrong command or don’t even try to read something. It is this what happen here.

see by yourself (the debug part)



FPT is not a perfect tool, it do is job for some stuff and for other not at all, the main problem is that most of the action taken by FPT are based on a standard information, if the address and co was altered/changed, it can not do anything about that and for this you need to find a work-around, fparts.txt is also one of the issue (just keep informed about the SPI and co… but you can change easily the ID part and FPT won’t be able to do anything than complaint)

About the ME Reflash, there is a way but the main issue is that, the PC Boot only with a Windows 10 UEFI boot sector, if I replace the main hard drive by Windows 8 UEFI boot sector, it won’t boot and stuck into a eternity bootloop/reboot and take while before reboot actually. So I can’t not boot into a Shell EFI that will let me unlock certain features without the need of flashing.

There is maybe good news but could be weird, I can flash with afudos + /gan under Windows 10



But here’s the result before and after flash backup (using afudos /o)



Remember, down (garbage similar to afuwin bios backup) top garbage made after flashing with afudos /gan (flash work)
Edit : Do you see the top, what is weird is that, information is repeated a multiple time, instead of being a full unique one.

So yes I can read, write, etc… with the /gan but after reboot, it won’t be take in consideration and the bios stay the same than previously.
Look like because of the missing ME region, the PC boot into a safe mode/secure lock, I don’t yet, I didn’t figure out what caused this.

But I read somewhere there is could be a way to force the settings of the flashed bios keep save. Need to find out.

But remember I’m stuck into a UEFI kind of bootloop and because of the missing ME region, the PC turn off by itself (some sort of timer)

I found was caused all this problem, it is a silent forced update from a bad software made by Gigabyte that actually contain some kinda of malware/virus.
Deep ME Region log show that it was really updated to a Frmware ME 10.0 1.5M Production (success) (forced silent update) I don’t know how this was possible (usually you can’t not flash with
a higher version not compatible but the log show that it passed ?!!?)
but I guess because the flash descriptor is well open/unlocked on their product, that anything could be possible. So now how to go back to how it was before
I don’t know yet and Gigabyte/Aorus seem to not have real answer to what happen, despite they know what caused that.

14

Your system comes with a desktop BDW cpu, not HSW as I thought. ME10.0 is targeting BDW mobile (LP) but I suppose it works for BDW desktop as well. That’s why it partially works and doesn’t show “unsupported platform” error. The debug text seems to exist at all ME9.x and 10.0 FPTs so it’s normal, I just hadn’t noticed it before. The hashes between fpt, fptw and fptw64 are different of course as they are compiled for DOS, Windows x86 and Windows x64 respectively.

I can’t really understand what you mean by wrong fpt commands/chip or what’s the correlation with fparts.txt. Based on what AFU is dumping, it cannot read the chip properly as well. If it cannot read then it cannot write of course. It’s obvious that it cannot read properly, otherwise the system wouldn’t even post with such SPI chip contents (repeating garbage). Generally, keep in mind that /GAN can be buggy for some configurations and can result in unexpected results. It was worth a try but didn’t really lead you anywhere.

I cannot understand what happened and the system is so messed up. I cannot understand how it still works to be honest and at what state it’s at. Do you know what exact update package caused this issue from gigabyte? It must exist somewhere. Regarding the shutdown, I think the ME shuts down the system after 30 minutes in case of an unsupported configuration so maybe that’s what you are seeing.

Try flashrom, your chip seems to be supported. Finding pre-built Windows binaries for it is not easy but try what’s attached, maybe it works. For me it doesn’t, says no supported EEPROMs found. It’s probably the Windows build being broken but I don’t use it so I don’t know.

flashrom-0.9.6.1-r1705-mingw.rar (416 KB)

15

Weird, it come with a Intel 9 chipset (HM97 is for the mobile one), 5700HQ CPU. Broadwell CPU (Brystalwell actually hybrid) Mobile one that come with the HM97 mentioned.

I was talking mostly about the return commands. What is weird also about the afudos dump is that the garbage differ after and before flash, so it actually try to write to the all address but
only repeat the same data each time, which is weird.

I don’t understand either but I guess it is probaby a safe mode/recovery boot ? I don’t know, I know that it take like 1min before turn on (routine ?) and keep the same bios settings all the time, no matter the change I made. Stuck in a UEFI mode.

I actually found what package caused all this mess and I’m really not happy that Gigabyte/Aorus didn’t take a closer look at the package tool they release to end users.
I check the driverupdate.bin and did a MEanalyzer.


File: driverupdate.bin

Firmware: Intel ME
Version: 10.0.47.1006
Release: Production
Type: Region, Stock
SKU: 1.5MB
VCN: 4
PV: Yes
Date: 18/08/2015
Platform: Mobile
Latest: Yes


Yes it is actually a ME 10, this is pretty pretty weird, so in the end it look like that the ME 9.1 was updated with a ME 10, making ME region partially accessible ? Like I said, this is weird.
never something like that happen to me, this is the first time.

Sorry I don’t know Flashrom, I’m not familiar with this, do you have any command that you recommend ?
I read somewhere that you need a programmer or is it compatible somehow without a programmer ?

Apparently I need to find a binary version of Flashrom compatible Windows x64 (10,8) that contain the internal programmer.
The one you share doesn’t contain the internal programmer (meaning software way, only support hardware way usb spi and co)

Here’s actually a good spot where to find all the Flashroom builtbot, last one, doesn’t work, need to find the right one
http://buildbot.flashrom.org/buildresults/latest-build/
http://buildbot.flashrom.org/buildresults/

16

I don’t know flashrom either. In theory you can use the dummy programmer (software) by “-p dummy” and it should try to detect your chip. Command “-help” shows the available options.

At this point I have nothing else to suggest other than to use the warranty and fix it that way. They will just use a programmer and fix it in 5 seconds on their end. You should tell them what was flashed to fix it.

17

I try some commands with verbose.

Probing for Macronix MX25L6405(D), 8192 kB: RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0xff, id2 0xffff
Probing for Macronix MX25L6406E/MX25L6436E, 8192 kB: RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0xff, id2 0xffff
Probing for Macronix MX25L6445E/MX25L6473E, 8192 kB: RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0xff, id2 0xffff
Probing for Macronix MX25L12805(D), 16384 kB: RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0xff, id2 0xffff
Probing for Macronix MX25U1635E, 2048 kB: RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0xff, id2 0xffff
Probing for Macronix MX25U3235E/F, 4096 kB: RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0xff, id2 0xffff
Probing for Macronix MX25U6435E/F, 8192 kB: RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0xff, id2 0xffff
Probing for Macronix MX25U12835F, 16384 kB: RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0xff, id2 0xffff
Probing for Macronix MX25L6495F, 8192 kB: RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0xff, id2 0xffff
Probing for Micron/Numonyx/ST M25P05-A, 64 kB: RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0xff, id2 0xffff


This is all the possible chip but there is a problem, I still need to find a binary version (winx64) that contain internal.
Dummy doesn’t find the chip because the binary version doesn’t contain internal support.

Warranty, well right now, the solution they had is to contact a service abroad that doesn’t even speak English, real problem
and they do know they have a software way to do a full recovery bios but I didn’t find how to trigger this one.
I try to ask them to share this information but for now on, they are completely silent and don’t even argue on the fact that one of their tool
is affected and can cause issue to their users.

This is also the reason why I try to fix on my own, so I don’t need to deal with a bad technical service when this could be resolve in a more easier way if
Gigabyte/Aorus could provide the correct information.

18

I didn’t know the binary doesn’t include the dummy. If you manage to find anything, I’d be interested in one as well.

Well unless the Recovery menu works, warranty seems to be the only solution. That Recovery menu at the BIOS, how does it work? Does it search the file somewhere such as USB? Maybe if you format a usb flash driver to fat32 and try all possible names like AMIBOOT.ROM (default, OEMs tend to change it though) or maybe X5BF.ROM etc. What have you tried?

19

The dummy is include but not the internal (what needed to detect/read/write/etc… without external programmer).
flashrom -p internal (command needed but internal is not included on the one you shared, I check also other binary that actually have more chip added but
what is weird is that the windows doesn’t have the internal programmer included).

Concerning recovery menu, I know that there more than recovery menu, there is even a blind mode too but I can’t not find how to trigger this one.
The recovery menu I found work with Ctrl-home after successive holding on power button 3 time. But before going to this recovery menu, it take even more
to boot on it than boot normally to windows, basically, the PC turn on after like 3 to 5min, there is this G light (left corner of the keyboard who turn on, after like 2 to 3min it turn off)
and after 1min it show the logo (it take like 1min more to go to recovery) and it goes to the bios menu with recovery.
I guess there a lot of routines behind this.

I don’t know which name bios the it try to check, I was thinking it was X5.BIN, AMIBOOT.ROM or AMI.BIN like mentioned inside the FSrecovery (bios file) but apparently not that.
I also try different name (X5BF, X5K, X5WT, BIOS.BIN, AMI.ROM, X5.ROM, X5BF.B07, etc…) nothing, when I press process to flash, it don’t even check anything or don’t even try,
it directly said flash failed, probably because I don’t have the right name.

I tried fat32, ntfs, gpt part, etc…

20

Just to keep you updated.

I found other flashrom binary (last one pre built in date was February 2016) I will share it with you.
But doesn’t contain internal.

I have some good news and bad news.

Let’s start with the good one.

I kinda cheat the bootloader of Windows and forced a boot to GRUB instead of the Windows BootLoader
But, I need another storage to point a different chainloader boot.
I was after able to boot into Ubuntu for example.

Now I have the possibility to boot in Linux ! this was a big step, I just remind you that I can’t not boot anything else than Windows 10.
F12/F9 broken bootloop, even more when I put another storage, the only one who boot is the one with Windows
Bios settings not saved, etc…

So this is good, I also compiled a version of Flashrom under ubuntu with the internal feature.
Everything seem to work good under Linux + Flashrom (chip seem to be detected)

Now the bad news, I faced another problem and it seem that the real problem is not the ME nor the BIOS but the flash descriptor itself
that seem broken or not valid, probably the reason why I can’t not flash with official tools etc…

I guess I need to force somehow the usage of a external flash descriptor to be take into account and flash the chip.
Here’s the verbose of Flashrom under Linux

sudo ./flashrom -p internal -V
flashrom v0.9.9-r1955 on Linux 4.4.0-21-generic (x86_64)
flashrom is free software, get the source code at https://flashrom.org

flashrom was built with libpci 3.3.1, GCC 5.3.1 20160413, little endian
Command line (3 args): ./flashrom -p internal -V
Calibrating delay loop… OS timer resolution is 1 usecs, 3448M loops per second, 10 myus = 10 us, 100 myus = 99 us, 1000 myus = 988 us, 10000 myus = 9929 us, 4 myus = 4 us, OK.
Initializing internal programmer
No coreboot table found.
Using Internal DMI decoder.
No DMI table found.
W836xx enter config mode worked or we were already in config mode. W836xx leave config mode had no effect.
Active config mode, unknown reg 0x20 ID: 85.
Found ITE EC, ID 0x8587, Rev 0x06 on port 0x4e.
Found chipset “Intel 9 Series” with PCI ID 8086:8cc3.
This chipset is marked as untested. If you are using an up-to-date version
of flashrom and were (not) able to successfully update your firmware with it,
then please email a report to [email protected] including a verbose (-V) log.
Thank you!
Enabling flash write… Root Complex Register Block address = 0xfed1c000
GCS = 0xc61: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI)
Top Swap: enabled (A16(+) inverted)
0xfff80000/0xffb80000 FWH IDSEL: 0x0
0xfff00000/0xffb00000 FWH IDSEL: 0x0
0xffe80000/0xffa80000 FWH IDSEL: 0x1
0xffe00000/0xffa00000 FWH IDSEL: 0x1
0xffd80000/0xff980000 FWH IDSEL: 0x2
0xffd00000/0xff900000 FWH IDSEL: 0x2
0xffc80000/0xff880000 FWH IDSEL: 0x3
0xffc00000/0xff800000 FWH IDSEL: 0x3
0xff700000/0xff300000 FWH IDSEL: 0x4
0xff600000/0xff200000 FWH IDSEL: 0x5
0xff500000/0xff100000 FWH IDSEL: 0x6
0xff400000/0xff000000 FWH IDSEL: 0x7
0xfff80000/0xffb80000 FWH decode enabled
0xfff00000/0xffb00000 FWH decode enabled
0xffe80000/0xffa80000 FWH decode enabled
0xffe00000/0xffa00000 FWH decode enabled
0xffd80000/0xff980000 FWH decode enabled
0xffd00000/0xff900000 FWH decode enabled
0xffc80000/0xff880000 FWH decode enabled
0xffc00000/0xff800000 FWH decode enabled
0xff700000/0xff300000 FWH decode enabled
0xff600000/0xff200000 FWH decode enabled
0xff500000/0xff100000 FWH decode enabled
0xff400000/0xff000000 FWH decode enabled
Maximum FWH chip size: 0x100000 bytes
SPI Read Configuration: prefetching enabled, caching enabled,
BIOS_CNTL = 0x09: BIOS Lock Enable: disabled, BIOS Write Enable: enabled
SPIBAR = 0x00007f7e07d53000 + 0x3800
0x04: 0xb008 (HSFS)
HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=0, FLOCKDN=1
Warning: SPI Configuration Lockdown activated.
Reading OPCODES… done
0x90: 0x00 (SSFS)
SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0
0x91: 0xf84030 (SSFC)
SSFC: SCGO=0, ACS=0, SPOP=0, COP=3, DBC=0, SME=0, SCF=0
0x94: 0x0006 (PREOP)
0x96: 0x8400 (OPTYPE)
0x98: 0x05000000 (OPMENU)
0x9C: 0x5a00019f (OPMENU+4)
Enabling hardware sequencing because some important opcode is locked.
Hardware sequencing was requested but the flash descriptor is not valid. Aborting.
FAILED!
FATAL ERROR!
Error: Programmer initialization failed.
Restoring PCI config space for 00:1f:0 reg 0xdc


I won’t give up so easily but little tired about this issue.