Good thing I did save the full backup. It appears 2MB is used for BIOS and other 2MB probably the EC code. I almost soldered back the chip with 2nd region all Fs. What is frustrating is that MeManf still thinks the VSCC is programmed to 2019. I verified the VSCC is correct now via fptw dump and viewing. Do I need to add JEDEC ID and VSCC settings for the 2MB version that this SPI is "pretending" to be? (guessing on boot no VSCC matches and defaults to 2019 since nothing in the SPI has 2019)
Intel(R) MEManuf Version: 6.0.40.1214 Copyright(C) 2005 - 2010, Intel Corporation. All rights reserved.
Platform stepping value is 3
Ignition firmware is detected on the system. FW Status Register: 0xE2110605 FW Status Register1: 0x000B0007
vsccommn.bin was created on 00:29:16 07/16/2009 GMT Ignition FW Status(FAD_IDX): Using Data from Factory Default Image Ignition FW Status(BOOT_IMAGE): FW booted from Factory Default Image Ignition FW Status(EVENT_LOG): Event Log is empty Ignition FW Status(ICC_STS): Clock programming successful Ignition FW Status(CF): Processor feature configuration successful Ignition FW Status(SWC): SWC application successful Ignition FW Progress: Intel(R) ME is sleeping
Factory Default Partition Data is validated and healthy. Runtime Partition Data is validated and healthy. Factory Default Partition Code is validated and healthy. Runtime Partition Code is corrupted.
Error 9271: Flash ID 0xBF254A Intel(R) BIOS VSCC value mismatch Programmed value of 0x2019 doesn't match the recommended value of 0x2009 See PCH SPI programming Guide for more details FPBA value is 0x0
FRAP register value is 0x0000FFFF Flash Master1 (Host/BIOS) value is 0xFFFF0000 Flash Master2 (ME) value is 0xFFFF0000 Flash Master3 (Gbe) value is 0xFFFF0118
Error 9279: SPI flash Intel(R) ME region is not locked
Error 9280: Intel(R) Gbe/ME has read or write access to BIOS region
Error 9281: SPI flash descriptor region is not locked
Error 9283: Region access permissions don't match Intel recommended values
Error 9286: Ignition firmware check was not successful
BTW I found and read the 5 series chipset PCH SPI programming guide (doc # 403598). Very neat and has a section about disabling the ME ignition firmware just like your post. Its an Intel doc but can find it as PDF hosted via a search.
Is the issue the greset not working?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Intel (R) Flash Programming Tool. Version: 6.0.40.1214 Copyright (c) 2007-2010, Intel Corporation. All rights reserved.
--- Flash Devices Found --- SST25VF032B ID:0xBF254A Size: 4096KB (32768Kb)
Warning: There are some addresses that are not defined in any regions. Read/Write/Erase operations are not possible on those addresses.
Could not set the GlobalReset bit
Error 205: Failure. Unexpected error occurred.
I've ordered some AT26DF321 since that pn weirdly appeared in the original BIOS when opening the M file with FITC. I think the schematics calls for SST25VF016B (0xBF2541) vs. the found SST25VF032B (0xBF254A) but both are in VSCC.....
There should be one SPI chip which starts with an Intel Flash Descriptor and that’s the one we’re looking for. Use the programmer to re-flash it using the previously attached fixed/updated SPI image and we’ll go from there.
Yes I found that SPI with the Intel start flash descriptor at offset 10. (valid for ES2 and production chipset)
That descriptor has bf 25 41 & bf 25 4A VSCC entries which are programmed with 2009. But then the MeManuf tool gives the output above in post #21
Is there any other ME tools that can view the VSCC? Reading the SPI it’s correct:
Is there something that is intercepting and altering the VSCC to stop the execution? "Runtime Partition Code is corrupted."
20h -> Lower block/sector erase size set to 4 KB 09h -> Upper write enable on Write status & Upper block/sector erase size set to 4KB
No where do I even see 19h but that’s byte 5 asserted in Reserved area. I thought FITC generates FLIMAP1 so don’t think that is wrong. (offset EFCh ->ED 08 )
Update: Ok reading doc#403598 I found section 4.4.3 that details VSCC setting of "0x20012001, 0x20192019 or 0x20112011 will result in slower Intel ME Firmware performance" but doesn’t specify that it is invalid or why my platform could think to use that.
Perhaps just need to swap the SPI to a AT26DFxxx1 part to match up to this mysterious 2019 single byte write capable VCSCC setting.
I flashed the descriptor you uploaded. I even read it back out of the chip and it’s the same. Above I removed a few ending FF but same as read file.
That’s why I am confused too. “vsccommn.bin was created on 00:29:16 07/16/2009 GMT” looks all valid but runtime partition is corrupted and the ME ignition fw does not execute and defaults. Trying to fix it.
It is almost as if there is some runtime registers that loads up 0x20192019 and not from the SPI. Thus looking to swap the SPI chip to one that actually does support this VSCC setting and hope it’s a work around?
I think that VSCC is controlled by BIOS as well but I don’t remember exactly. Did you flash the FD only? In order to rule out any other possibility, flash the entire 2MB image into the chip to have proper/intended FD, BIOS and ME regions in place. If it still happens after that then clearly the BIOS is doing something. But to reach that conclusion for sure the entire chip should be re-flashed. There is no harm, you have both a backup and a programmer.
I did perform that full replacement and external flash. It’s totally crazy that the VSCC from the SPI does not match what MeManuf is checking. I really hope I am missing something somewhere a register is configured wrong. There is a section about the upper and lower VSCC registers that I believe exist in memory after BIOS boot.
I am thinking I might succeed if I swap to the JDEC spi chip that can accept 2019 setting. Unless you know of other regions to check for this 2019 settting?
Despite what MEManuf says, do you still have the initial problem? I supposed that yes you can replace the SPI chip and it will accept it but I don’t see why that must be done, seems weird. You are certain that your current SPI chip IDs are in VSCC, right? To know everything there is, you can read the documentation from that generation. For example, from what I can see at the 5-series PCH Guide:
SPIBAR is what I think is the issue. The initial "Me firmware is corrupt, reflash your BIOS" (or something close) is still present and what I want to solve. I assumed the descriptor region was just setup wrong and that any factory update was only doing BIOS region. Sadly that assumption was only partially correct and with the updated desc the problem still exists!
So looking at the later ME info packages they can check the BIOS VSCC setting but I don’t get that output on the 6 series:
Borrowed this below output from the later tool: (not my system) MEI Driver Version: 10.0.30.1054 Wireless Hardware Version: Not Available Wireless Driver Version: Not Available
FW Capabilities: 0x01101C40
Intel(R) Capability Licensing Service - PRESENT/ENABLED Protect Audio Video Path - PRESENT/ENABLED Intel(R) Dynamic Application Loader - PRESENT/ENABLED
CPU Upgrade State: Not Upgradable Cryptography Support: Disabled Last ME reset reason: Power up Local FWUpdate: Enabled BIOS Config Lock: Enabled GbE Config Lock: Enabled Host Read Access to ME: Enabled Host Write Access to ME: Enabled SPI Flash ID #1: EF4017 SPI Flash ID VSCC #1: 20052005 SPI Flash BIOS VSCC: 20052005
What offset is that bolded line above on the ME ignition v6?
I don’t know these things but certainly any BIOS VSCC are reported from the BIOS itself so they are not found at the Flash Descriptor or Engine regions. A quote I posted above from a doc did say that Ignition does not use the VSCC tables so it could be from the BIOS only and that’s why any alterations to the FD make no difference.
The quote seems to say that not only the ME uses the SPI VSCC table. So wondering if BIOS is using the descriptor for flash updates but then makes a change in SPIBAR where it wants to use 2019 for ME runtime. So I will try and swap on a new SPI chip that supports 2019 and change the descriptor to match.
Too bad I can’t figure out where the 2019 setting is inside the BIOS region to edit.
For that I would try searching via UEFITool. You may get a lot of results due to the small pattern but it is a possibility. It would be interesting to see if you can change it in the BIOS. Otherwise, yes the ultimate solution would be to replace the SPI chip with whatever the BIOS is happy with.
Probably PhoenixTool and manual hex searching in DUMP directory. It is meant for SLIC injection but works with other modifications as well, provided that the Advanced Options are configured a bit. I have no experience working with it but it might help in your case.
Now just the Runtime Partition Coded is corrupted but now the ME is not sleeping but active! No idea why it defaulted to VSCC 0x201D below. Changing the Descriptor VSCC seems to have no effect and defaults to mbw setting. (going to set desc as 0x201D to match)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
vsccommn.bin was created on 00:29:16 07/16/2009 GMT Ignition FW Status(FAD_IDX): Using Data from Factory Default Image Ignition FW Status(BOOT_IMAGE): FW booted from Factory Default Image Ignition FW Status(EVENT_LOG): Event Log is empty Ignition FW Status(ICC_STS): Clock programming successful Ignition FW Status(CF): Processor feature configuration successful Ignition FW Status(SWC): SWC application successful Ignition FW Progress: Intel(R) ME is active
Factory Default Partition Data is validated and healthy. Runtime Partition Data is validated and healthy. Factory Default Partition Code is validated and healthy. Runtime Partition Code is corrupted. SPI Flash ID #1 BIOS VSCC value is 0x201D SPI Flash ID #1 (ID: 0x1F4700) BIOS VSCC value checked FPBA value is 0x0
So now that the ME is active, can I repair the runtime code somehow with a tool like FWUpdfLci? I still get the error ME fw corrupted at BIOS boot which I want to go away.
Edit: Hrm seems still shows ME sometimes sleeping. But at least that 0x2019 error went away. Still not solved, need to remove ME boot error message
Tried a few times to follow the clean-up procedure with same failure. Frustrating as the FITC tool should output the "corrected" ME region and I can just use fptw, right? Or do I need to do the entire SPI via external programmer? Could you offer any tips or generate one for me from the posted image?
At this point I don’t think the problem is FITC or the ME region itself. To rule them out for sure, I took W6702MB.A09 and followed the CleanUp Guide in the most conservative way (same firmware version, same settings etc). Attached is the resulting ME region which can be flashed via “fpt -me -f W6702MB.A09_ME_Clean.bin” followed by a “fpt -greset”. If that doesn’t work, the problem is caused by the BIOS/FD/SPI. In such case, I would try flashing via the programmer both W6702M.A09.bin and W6702MB.A09.bin, exactly as they are provided by Dell, to see if something works. One of those two should work either with the previous or with the current SPI chip, it doesn’t make sense otherwise.