Having now discovered the ‘UEIFTool’ I ran through the same proceedure as post 1 to make a new outimage.bin for Hydrogen. A copy is at http://www.damtp.cam.ac.uk/user/cm214/tm…ogen_remade.bin . In the UEIFTool it loads without the error I get with my ‘how to brick a PC’ .bin file. Is part of ‘what have we learnt from this post’ is that the resulting outimage.bin file should be loaded into UEFITool first before sending it to the BIOS?
This is what UEFITool shows in the ‘Parser’ tab for the hydrogen_remade.bin file:
1 2 3 4 5 6 7
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
@osk866 This isn’t consistent. This machine has a newer ME/PMC firmware and AMT/ TLS is disabled. Might be just updated, or another configuration?
I’m sorry, but it’s necessary to have: - a firmware dump of this specific machine, too, and - the value of the service tag of this specific machine, too (or a set of MEInfo -verbose, service tag value and SPI/Bios dump of the same specific machine)
You don’t happen to have these systems in China, France, Hong Kong, Israel, Korea, Poland, or Russia? (KVM should anyway be possible without TLS, and- just in case- without TPM chip, too)
Intel (R) MEInfo Version: 12.0.70.1652 … TLS Disabled … IUPs Information PMC FW Version 300.2.11.1020 LOCL FW Version 12.0.24.1314 WCOD FW Version 12.0.24.1314 … Intel(R) Active Management Technology - Intel(R) AMT State Disabled … AMT Global State Enabled …
╔════════════════════════════════════════════════╗ ║ hydrogen_original.bin (1/1) ║ ╟───────────────────────────────┬────────────────╢ ║ Family │ CSE ME ║ ╟───────────────────────────────┼────────────────╢ ║ Version │ 12.0.0.1069 ║ ╟───────────────────────────────┼────────────────╢ ╔═════════════════════════════════════════════╗ ║ Power Management Controller ║ ╟─────────────────────────────┬───────────────╢ ║ Family │ PMC ║ ╟─────────────────────────────┼───────────────╢ ║ Version │ 300.2.11.1011 ║
When I said I have 200 machines to enable AMT I should of explained that they are different models of Dell, they’re not the same as Hydrogen. There’s Optiplex 7010, 7040, 7060, 7070, 3070 and 9020’s. Are we going slightly of topic here with the MEInfo -verbose output the machine INIPC160? INIPC160 is a i5-8500 like Hydrogen, that’s why I chose that machine.
I can get a firmware dump of INIPC160 tomorrow but will this help me work out why the MEBx boot option wasn’t availableon HYDROGEN (sorry if I’m missing the link here)?
@osk866 It depends. Had this other PC been exactly the same then it had been inconsistent. If it’s another configuration it might just be that that one has AMT disabled.
The other thing is: What happened to your image?
UEFItooNE is a very fine tool for scanning images and new parser messages are always suspect. If you have a programmer and a good backup one might decide for oneself if time for hardware reflashing or exploring these messages is more important.
Service tag- I’m sorry, meant the sticker inside the chassis with the AMT code.
I still got some difficulties to reproduce your file…
- Why didn’t the first machine have AMT accessible even when all settings in ME from original bios dump are enabled and DELL sticker says ‘fully enabled’?
- For the second machine: Is MEInfo consistent with the ME sticker and settings in ME firmware? If yes can AMT enabled the ‘normal way’?
First question requires a programmer, since system is bricked. Starting point would anyway be flashing the original bios since it’s got all settings enabled.
Second question requires bios dump and info from sticker. If second machine has consistent information (sticker, MEInfo, firmware) and AMT can be enabled according to the book, everything is fine.
@plutomaniac Regarding settings for AMT/ clean ME- Do you have an idea why FIT v12 in its latest version no longer can write a correct FD version and changes order for ME boot and data partition?
Versions FIT 12.0.49.1536 Tools <= r25 FIT 12.0.64.1551 Tools >= r26 unknown FD version, changed partition order
This is consistent with the older ME/ PMC files from original image and also when exchanging with latest versions.
Would you prefer a version here? (I’d tend to making a ME region with latest tool and replacing it via UEFItool in original bios to keep FD?)
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’.
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
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.
@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.
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.
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 )
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
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
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.
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.
@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:
Created an account on these forums just to say thanks to @osk866 & @lfb6 for working through these issues on the Dell 7060. This is a great work around to enable the hardware all ready in the machine.
Took me a while to re-read everything 3 times to find the actual process but I was able to make some notes and got AMT enabled first go on a Dell that has a sticker on the inside of it indicating 3 ME Disabled.
)
