The location/offset of Boot (BPDT/IFWI) and Data ($FPT) partitions within CSE region do not matter, as long as they are correctly referenced/adjusted in CSE Layout Table. You can check these offsets via "MEA -dfpt" parameter but FIT does these things correctly by itself of course. You can ignore them.
The FD version does not matter. You can ignore it. TLDR, Intel added FD version at CNP (CSME 12) but originally it was set to 0.0 and later revised to the more sane one of 1.0. UEFITool does not understand value 0.0, which is the old/initial value.
This is a very good question, no idea why the MEBx boot menu was never visible. As the user needed the machine back and it was under warranty Dell are replacing the motherboard. While this ‘solves’ the problem it doesn’t answer why MEBx never showed.
This second machine (same chipset and CPU as hydrogen), called INIPC160, the ME sticker in the case says ‘3 ME Disabled’.
A resulting dump file from running ‘fptw64.exe -d’ can be found at http://www.damtp.cam.ac.uk/user/cm214/tm…60_original.bin
I load this image into FIT. Change the AMT settings:
Intel AMT Support = YES
Intel ME Network Services Supported = YES
KVM Redirection Supported = YES
Build menu -> Build Settings -> Generate Intermediate Files = NO
Save xml file.
Close FIT
Run MEA.exe on the inipc160_orignal.bin:
Family │ CSE ME ║
╟───────────────────────────────┼────────────────╢
║ Version │ 12.0.24.1314 ║
╟───────────────────────────────┼────────────────╢
║ Release │ Production ║
╟───────────────────────────────┼────────────────╢
║ Type │ Extracted ║
╟───────────────────────────────┼────────────────╢
║ SKU │ Corporate H ║
╟───────────────────────────────┼────────────────╢
║ Chipset │ CNP/CMP-H B,A ║
╟───────────────────────────────┼────────────────╢
║ TCB Security Version Number │ 1 ║
╟───────────────────────────────┼────────────────╢
║ ARB Security Version Number │ 4 ║
╟───────────────────────────────┼────────────────╢
║ Version Control Number │ 14 ║
╟───────────────────────────────┼────────────────╢
║ Production Ready │ Yes ║
╟───────────────────────────────┼────────────────╢
║ OEM Configuration │ No ║
╟───────────────────────────────┼────────────────╢
║ FWUpdate Support │ Impossible ║
╟───────────────────────────────┼────────────────╢
║ Date │ 2019-02-13 ║
╟───────────────────────────────┼────────────────╢
║ File System State │ Initialized ║
╟───────────────────────────────┼────────────────╢
║ Size │ 0x77C000 ║
╟───────────────────────────────┼────────────────╢
║ Flash Image Tool │ 12.0.0.1069 ║
╟───────────────────────────────┼────────────────╢
║ Latest │ No
From this information I chose the firmware file ‘12.0.24.1314_COR_H_BA_PRD_EXTR-Y.bin’ from ‘Intel CSME 12.0 Firmware Repository r24’ as it closest matches the version number and the SKU. Rename this file ‘ME Sub Partition.bin’ and copy it into '\Intel CSME System Tools v12 r28\Flash Image Tool\WIN32\inipc160\Decomp' overwritting the existing ME Sub Partition.bin (I notice they are a different size!)
Open FIT again, load saved xml, check settings for AMT, then run BUILD.
The resulting file is then loaded in UEFITool NE, no warnings. The output of the ‘Parser’ tab =
FfsParser::parseIntelImage: unknown flash descriptor version 0.0
FfsParser::parseVolumeNonUefiData: non-UEFI data found in volume’s free space
FfsParser::parseVendorHashFile: new AMI hash file found
FfsParser::parsePadFileBody: non-UEFI data found in pad-file
FfsParser::findFitRecursive: FIT table candidate found, but not referenced from the last VTF
FfsParser::findFitRecursive: real FIT table found at physical address FFD20100h
The bin file is available at http://www.damtp.cam.ac.uk/user/cm214/tm…c160_remade.bin
I have not/dare not send the file to the BIOS until you’ve read and looked at what I’ve done. I really don’t want to brick another PC, my confidence level is very low at the moment.
As for what you were asking @plutomaniac about, way over my head I’m afraid, I’m beginning to get a bit lost with what’s going on so far, sorry.
Once again thanks for your help and patience with this.
@osk866 Procedure seems to be fine and if I use the same settings I get a bitwise identical file- but wait flashing it!
Regarding settings I’d recommend to use these settings:
Management Application Supported is necessary, the other marked settings would be standard for AMT enabled machines, too.
In addition for your other machines- you might check the TLS setting- last item in the AMT section (it’s already enabled for this machine).
About your fear for flashing- you have 199 machines to go, right? But the better argument is that you flashed a corrupted file that had an extremely high probability og bricking. So there’s a reason for what happened. Hope you ordered a programmer as insurance, when you have one at hand you’ll feel better at once.
Please change the other settings, build a new file and post/ attach it.
@ plutomaniac: Thanks a lot for the information!
@lfb6 Thanks for checking and for the recommendations.
Something I have done and I should of possibly held off doing was that I upgraded the BIOS to the latest version available from Dell - boot PC, F12, update flash from USB stick. I thought while the flashing was taking place that maybe I should of waited but it’s done now. Hopefully it won’t mess anything up.
Two new web links.
Dump file made from ‘fptw64.exe -d’ = http://www.damtp.cam.ac.uk/user/cm214/tm…60_new_bios.bin
New .bin file after running BUILD = http://www.damtp.cam.ac.uk/user/cm214/tm…bios_remade.bin
ME Analyser on inipc160_new_bios_rename.bin:
Family │ CSE ME ║
╟─────────────────────────────┼───────────────╢
║ Version │ 12.0.24.1314 ║
╟─────────────────────────────┼───────────────╢
║ Release │ Production ║
╟─────────────────────────────┼───────────────╢
║ Type │ Extracted ║
╟─────────────────────────────┼───────────────╢
║ SKU │ Corporate H ║
╟─────────────────────────────┼───────────────╢
║ Chipset │ CNP/CMP-H B,A ║
╟─────────────────────────────┼───────────────╢
║ TCB Security Version Number │ 1 ║
╟─────────────────────────────┼───────────────╢
║ ARB Security Version Number │ 4 ║
╟─────────────────────────────┼───────────────╢
║ Version Control Number │ 14 ║
╟─────────────────────────────┼───────────────╢
║ Production Ready │ Yes ║
╟─────────────────────────────┼───────────────╢
║ OEM Configuration │ No ║
╟─────────────────────────────┼───────────────╢
║ FWUpdate Support │ Impossible ║
╟─────────────────────────────┼───────────────╢
║ Date │ 2019-02-13 ║
╟─────────────────────────────┼───────────────╢
║ File System State │ Configured ║
╟─────────────────────────────┼───────────────╢
║ Size │ 0x77C000 ║
╟─────────────────────────────┼───────────────╢
║ Flash Image Tool │ 12.0.64.1551 ║
╟─────────────────────────────┼───────────────╢
║ Latest │ No
inipc160_new_bios_rename.bin loaded in UEFITool NE, no warnings. The output of the ‘Parser’ tab =
FfsParser::parseIntelImage: unknown flash descriptor version 0.0
FfsParser::parseVolumeNonUefiData: non-UEFI data found in volume’s free space
FfsParser::parseVendorHashFile: new AMI hash file found
FfsParser::parsePadFileBody: non-UEFI data found in pad-file
FfsParser::findFitRecursive: FIT table candidate found, but not referenced from the last VTF
FfsParser::findFitRecursive: real FIT table found at physical address FFD20100h
I wonder what you did, latest bios update contains ME update, too, and other stuff, see picture. And yes, the bios region is updated…
Anyway:
I did the same modifications and got a bitwise identical file. I’d propose you flash this file the way you described before. Make a new dump right after flashing without rebooting. Please run a MEInfo -verbose after reboot / fptw64 -greset and poste it.
When the system is working fine, you might run the Dell installer for updating the whole package. And don’t worry, for ME this will not change the settings.
We save success @lfb6 with the upgrade to full KVM on inipc160 :).
As requested, here is the dump right after flashing and before rebooting - http://www.damtp.cam.ac.uk/user/cm214/tm…_pre_reboot.bin
Here is the output of MEInfo after reboot - http://www.damtp.cam.ac.uk/user/cm214/tm…_and_reboot.txt
Is the moral of this thread that you should always look at the output of FIT (outimage.bin) using UEFITool to make sure it loads OK? Do we need to worry about what the Parser output says in UEFITool if the new bin file loads without error? I guess the question is when we use UEFITool and load outimage.bin, what do we look for to tell us NOT to flash the new .bin file, what should be look at to ring alarm bells that we’re about to brick the PC?
Thank you for all your help with this. I’ve learnt a bit more (a rather costly learning exercise mind you). Mainly the use of a new tool to me, UEFITool. thanks
@osk866 Thanks for reporting the result and good to hear that everything works now! 
I really can’t tell what went wrong with the first build.
What you need or should do for checks depends your personal thirst for adventure/ need for safety and the consequences. If it’s your own system, you have a flasher at hand, are pretty sure you did it right and are eager to try- the worst thing that could happen ist diasassembling the machine, flash the backup, try again. If a customer is waiting for a machine one would possibly play more carefully.
To put the file into UEFItoolNE is a very simple measure to check for structure and parser errors. As written before, you can’t 100 % exclude a brick, but with severe errors or an unreadable file it’s quite likely a brick. I put most files in UEFItoolNE and MEA, sometimes MCE and somtimes I compare the files in HxD to check where to find first changes/ if changes are where they’re expected. In case you change something in ME region and find first discrepancy in bios region (like in your first file), I’d become suspicious.
When doing this first time it’s also possible to describe what one did, attach the file here and ask for a check before flashing. That’s normally less work/ writing than fixing a brick. (But would possibly not work so well for all your 199 machines 
)
Good luck with your other systems!
Flushed with success I thought I’d try out the new UEFItool on a different model of Dell, Optiplex 7010. The output of UEFItool on the dumped image didn’t error in red and a warning, neither was it happy with the image. Let me explain.
New PC, INIPC204. Dell 7010 (out of warranty). Label in the case ‘ME Disabled 3’. BIOS version A29
Processor=Intel(R) Core™ i5-3470S CPU @ 2.90GHz
Intel(R) 7 Series/C216 Chipset Family SATA AHCI Controller
Intel(R) 7 Series/C216 Chipset Family USB Enhanced Host Controller - 1E2D
Intel(R) 7 Series/C216 Chipset Family USB Enhanced Host Controller - 1E26
Intel(R) Q77 Express Chipset LPC Controller - 1E47
Intel(R) 7 Series/C216 Chipset Family SMBus Host Controller - 1E22
fptw64 -d inipc204_original.bin > http://www.damtp.cam.ac.uk/user/cm214/tm…04_original.bin
load into UEFITool.exe, Parser tab shows ‘MeParser::parseFptRegion: FPT partition table header checksum is invalid’ - doesn’t look good. Also, UEFITool.exe doesn’t show contents of the ‘Structure’ window in yellow.
I ran fptw64 -d three more times, same output in UEFITool.exe
Output from MEInfo http://www.damtp.cam.ac.uk/user/cm214/tm…4_MEinfo_op.txt Interesting following lines:
Intel(R) Active Management Technology - NOT PRESENT
Intel(R) Standard Manageability - NOT PRESENT
Output from ME Analyser on inipc204_original.bin
inipc204_original.bin (1/1) ║
╟───────────────────────────────┬────────────────╢
║ Family │ ME ║
╟───────────────────────────────┼────────────────╢
║ Version │ 8.1.72.3002 ║
╟───────────────────────────────┼────────────────╢
║ Release │ Production ║
╟───────────────────────────────┼────────────────╢
║ Type │ Extracted ║
╟───────────────────────────────┼────────────────╢
║ SKU │ 5MB ║
╟───────────────────────────────┼────────────────╢
║ Security Version Number │ 1 ║
╟───────────────────────────────┼────────────────╢
║ Version Control Number │ 4 ║
╟───────────────────────────────┼────────────────╢
║ Production Ready │ Yes ║
╟───────────────────────────────┼────────────────╢
║ Date │ 2017-10-24 ║
╟───────────────────────────────┼────────────────╢
║ Size │ 0x4A4000 ║
╟───────────────────────────────┼────────────────╢
║ Flash Image Tool │ 8.1.40.1416 ║
╟───────────────────────────────┼────────────────╢
║ Chipset Support │ CPT/PBG/PPT ║
╟───────────────────────────────┼────────────────╢
║ Latest │ Yes
Does it look like AMT isn’t possible on this motherboard even though the spec of this PC on the Intel website says vPro should be possible. I’m baseing this on that UEFItool doesn’t like the dumped image.
I’ve not gone any further with this PC - running FIT etc as it looks like it’s failed at the first hurdle.
Your thoughts would be appreciated.
@osk866 There’s nothing wrong with this image it seems.
I’d recommend to look into this thread for the different versions:
[Guide] Clean Dumped Intel Engine (CS)ME/(CS)TXE Regions with Data Initialization
There are always some specific recommendations for the different ME versions (but since you don’t want to clean ME firmware you don’t have to follow all steps always). For ME 8 it reads:
For ME 8 settings are named different, here you ‘disable’, so the answer is almost always "no"
And for disabling Anti-theft do the 2 mentioned changes in PCH strap 2 in addition!
- There may be some trouble with some (newer) SPI chips- some flash programs can’t read different chip-types correctly, read the post of @Lost_N_BIOS ( After reading BIOS chips, Dell Latitude 3510 won’t start ) I don’t know of any consistent and complete information source which program won’t read which chips, unfortunately…
- You might check with "fptw??.exe -fwsts" if the ME filesystem is corrupted before dumping. This will also display correct chipset of the system. Alternatively MEInfo -verbose does also display ME filesystem corruption, but I’m not sure if that’s true for older versions like ME8.
- Use the newer FIT version for this ME 8
- Colours in UEFItool: Regions covered by bootguard (can be disabled in menu ‘view’) No BootGuard- no colours
Thanks @lfb6 once again for your input. Sorry if I’m asking dumb questions here, as you can tell it’s all a bit new to me.
I thought I’d listed all of the spec for INIPC204 except I failed to add that I was using ME tools for v8, Intel ME System Tools v8 r3. I ran ‘\Intel ME System Tools v8 r3\Flash Programming Tool\Windows64\fptw64.exe -d’ to make the initial image. I knew I’d forget to include one piece of potentially useful piece of information 
After reading your reply a few times I don’t think I understand why UEFITool.exe reports the dumped .bin file as invalid. Is the error ‘MeParser::parseFptRegion: FPT partition table header checksum is invalid’ something to worry about?
When you say
are you basing this on the fact that you can load the dumped .bin file in FIT? I’m trying to learn when an initial dumped image is not good, when you can’t use it to create a new .bin file that would be used to flash the BIOS.
Did you mean ‘MEInfoWin64.exe -fwsts’ when you said
?
@osk866 No problem with Intel ME System Tools v8 r3. If you’d have continued you’d have seen that there are two FIT versions included:
Use the newer one of the two.
I happen to know some Ivy Brigde bios that have a checksum error for the FPT partition table and they work just fine. This wont be of any concern. In addition: If you change settings and exchange ME region with a ‘blank’ ME from the repository the FPT partition table will be rebuild by FIT. And MEA is rather rigid and checks the ME regiosn very thoroughly but doesn’t give any warnings for both versions .
You can change the checksum to the correct value (FD), UEFItool_NE will read without any error. Then make the changes in FIT, replace ME region.bin, build, check the new image- and there’s your error again, checksum is again C0/wrong. It’s an error in the tool…
Being able to load a dump in FIT doesn’t mean too much. Don’t rely on that!
And yes, my fault, it’s as you state "MEInfoWin64.exe -fwsts"
EDIT For ME 9.1 you get the info regarding corruption either by “MEInfoWin64.exe -fwsts” or “MEInfoWin64.exe -verbose”, but I think you’ll have to try for different ME versions, syntax may change with ME versions.
Answering myself, not editing this time
@osk866 You see, it isn’t strict rules always… Regarding the FPT partition table checksum error in UefitoolNE, I think the error might be in UEFItool itself, maybe. At least FIT and MEA are on the same side here:
@plutomaniac I assume UefitoolNE is wrong here?
Yes