The BIOS Lock setting is stored in an UEFI variable called "Setup". It stores all your settings from the BIOS menu as well, and if you do a reset to default in the BIOS menu it will be gone.
It is stored in the BIOS region of the flash, by using my dump you probably have overwritten it already with the settings I had and where BIOS is locked.
Yup, I had to disable it again.
Do you still have any remaining issues besides the double POST? Can you look up the driver version of the ME Interface driver? I am on 9.5.15.1730
Generally, from past Dell experience, it is best to first update to the latest BIOS and then update the ME. That’s because the Dell updater tries to first update the ME firmware (via an efi version of FWUpdate inside the BIOS) and then the BIOS. If the flashed ME firmware is newer, it stops at the first step (ME) but usually proceeds to the BIOS regardless. But, to be on the safe side, I suggest you first update to the latest Dell BIOS and then deal with the ME.
Regarding that double post, the MEI driver has nothing to do with it. Does it show any message before restarting again? I was wondering if the BIOS tries to restore the ME to a specified version but Dell never does that so it is highly unlikely. It’s probably something BIOS related.
Edit: Regarding the padding that jockyw2001 asked about, FITC v4-10 always cuts the ME firmware at the “Decomp” folder way too much. The images are proper but they are missing padding which should be there. So never flash that image (from Decomp) directly. Instead, build a cleaned ME region properly and then adjust padding manually. Generally, the size of the ME region to be flashed must be the same as the one you dumped. That size can be seen at the FD of course (start offset of ME and size).
I couldn’t test fully, but I had the impression that it wouldn’t remain in sleep before. After sleeping for a random amount of time, at wake it would do a full reboot with the slow double flashing Dell logo. If suspend would work properly the double POST wouldn’t bother me so much.
I don’t think the double POST is normal, BIOS logs show that it effectively boots twice every time with a forced shutdown in between. Also, I remember that initially it did not show this behaviour. I don’t have much time today, but I will keep investigating. Maybe it is the Dell EC (embedded controller? seems to be based on an MSP430), which is in charge of some power management functionality and also has a firmware image in the HDR file.
Anyway, great that your worst problems are fixed, I was happy to help 
@plutomaniac I was also considering that option. I will try to load the clean BIOS region extracted from the Dell HDR onto the computer through FPTW tomorrow and see what happens.
Yes, try with Dell’s clean BIOS (get it via CodeRush’s tool) and leave the ME & FD as it is. I think one used the BIOS dump of the other (never do that) so it is very much possible that whatever is wrong with one BIOS transitioned to the other.
I’m about to do that now. Power eventlog always shows "Power Off - ASF2 force off" followed by a "Power On - Not applicable" 4-5 seconds later. That’s not normal and I want to solve it.
Yup that’s exactly the issue I have been trying to solve. Normal BIOS down/upgrades didn’t solve anything, so hoping that flashing through FPTW will help.
Yes, it’s fixed 
All is well now. Fast boot and no more spurious ASF2 entries in the power eventlog.
1
2
3
4
2
3
4
fptw64.exe -f section_0_A.23.data -bios
fptw64.exe -greset
Ah so it was the BIOS region indeed. That makes sense, the ME shouldn’t be the cause of these issues. By the way, “-greset” is relevant to ME and not BIOS but it doesn’t hurt I suppose.
Fantastic! Not home till tomorrow but I look forward to trying it on my end too
My tablet is working 100% okay now. Actually I had to redo the steps of flashing first your cleaned spi dump immediately followed by flashing the clean dell bios region and finally greset the device. The reason was that my ME firmware log in password didn’t work anymore. It said wrong password and the default “admin” didn’t work either. So I advise to do it the same way as I did. Good luck with it tonight!
I just did mine too and all problems seem to be fixed I did notice one minor side effect: the manufacturing date and the ownership date in the BIOS system overview are blank now. I’m assuming this is stored somewhere in an UEFI var but got cleared now.
The unique dell service tag however is correct, so I’m wondering where that is stored. Out of curiosity, @jockyw2001 could you check if yours is still the same as the one printed on the chassis? You might have mine now because you used my full dump
For those interested and future reference, this is how I unlocked the FD with a Pi:
- I used a raspbian lite install; no GUI required and wanted to do it headless (didn’t have a screen/keyboard handy)
- Enabled ssh by creating empty filed called ‘ssh’ in boot partition
- Boot up with ethernet cable in, figure out IP somehow (I used nmap to portscan for port 22) and log in over ssh with default user and password
- Edit config.txt in boot partition to enable SPI
- sudo apt-get install flashrom
- Wire up as described here: https://www.flashrom.org/RaspberryPi
- Use usual commands for dumping and flashing. I also patched the FD on the Pi with a CLI hex editor like hexcurse
I have attached some pictures too
|addpics|hcn-3-fcf0.jpg,hcn-4-4374.jpg|/addpics|
Yes, I had noticed that too, the manufacturing and ownership date are blank. Apparently they are stored in some kind of manifest UEFI var. My service tag and expresscode are my original. Perhaps they are stored in the RTC chip in a NVRAM area?
Glad you solved your problems too and very glad you originally suspected the ME and you found my thread
Dirty BIOS-es, corrupted MEs, what disasters can we expect in the future …
Hi all,
Last update from my side on this thread. I have noticed another more bothersome side-effect of using a stock BIOS region from the updater EXE file: the unique Windows 8/10 key embedded in the MSDM table is also gone. This might be important for @jockyw2001 as well as he also wrote a stock BIOS to his tablet.
I have done some research, and I noticed that all the board specific BIOS parameters (win key, production date, etc) are stored in the BIOS image from 0x40000-0x90000. This is not an UEFI volume recognised by UEFItool, it shows there as non-empty padding. My key/production date appears twice in there in plaintext, once around 0x3020, and another time at 0x87d0. The section starts with “DVAR” in ASCII, I don’t know if that rings any bells for anyone. I think it is Dell specific.
Anyway, splicing in that section into the stock BIOS I got from the Dell update EXE restored the keys and production dates, and also fixed my slow boots. The stock Dell image has two dummy UEFI volumes there, one empty and another one containing “DUMMY PERSONALITY” in ASCII.
Lastly, out of curiosity I have tried updating the normal way with the Dell exe to see if that worked. I first downgraded bios manually to A22 and loaded cleaned ME release that comes officially with that release (9.5.60.1952). The update ran fine and does not relock the flash descriptor. I did notice something strange with ME: the automatic reboot after update fails: system shuts down abruptly at Dell logo. Manual power on after that shows “Error sending end of post message to ME, System HALT!” multiple times (4 or 5 times). After getting to windows, no ME is detected, but another reboot solves all problems and shows the new ME version.
Is this because internally ME is still “applying” the update? I have a feeling that the Dell bios update process rebooted too early, causing these problems.
Indeed, the original Win8 key is gone and in fact at offset 0x40000 I don’t have the DVAR marker. I checked with RW-Everything, and a correct SLIC table (“DELL CBX3”) is shown as a part of the ACPI table. Also my Win 10 Pro is correctly licensed and I can read a key with various SLIC dump tools. I still have an intact “DVAR” table in some of my earlier SPI dumps, and I will prolly try to flash it later on. I am a bit hesitant because everything works fine, but to make things perfect I will try tomorrow.
Concerning the ME v9.5.60.1952, did you flash a padded version?
PS: the service tag can be found as a unicode string multiple times in BIOS between 0x0 - 0x40000. I guess it can be generated from MAC addresses and/or IMEI of the WAN card
I did notice there is a generic SLIC table, but for Windows 8 and up an MSDM table is required with an unique key embedded during production. RWEverything shows it, but you can also use something like neosmart’s OEMKey to just view the key. My Windows 10 also kept working without the MSDM table, but I didn’t want trouble during future reinstallations.
I think in your case it is safe to just overwrite only the BIOS region with what you have dumped before. You don’t have BIOS corruption like I do so no need to hack and slice it. Or maybe your original dump was not A23? Perhaps you can try to load the older BIOS and run the Dell updater exe. The ME update will do nothing because you have the latest version already.
About the ME, what I did is a full image flash (descriptor, bios, gbe and me) created with FITC, so no padding problems. I think it was just a minor glitch of an update that took longer than expected, after all ME is an isolated system. I am not too worried, everything seemed to be OK in the days after when I extensively tested it.
Nice find on the service tag. That is in the UEFI NVAR store, so you’re probably right that it gets generated from some static data at first boot and is stored in an UEFI variable so the OS can see it.
I merged the Dell DVAR part (size = 0x50000) taken from my SPI dump from when I was still on A22 with a corrupted ME fs, with a clean A23 bios part and then flashed it. The first cold reboot took a bit longer than usual, subsequent reboots are fine. Win 8.1 key and manufacturing dates are back. An additional improvement is that during POST, the Dell logo is now displayed just one time and no longer 2 times with a 0.5 sec interval.
The Windows key can be found in the DVAR part by searching the DVAR item header FA FD FB F8 FE 72 FB CE. It appears 2 times.
The only weird thing is that the SLIC Toolkit can no longer find an OEM SLP String when the SLP1.0 tab is selected. I am pretty sure something was shown there before. Anyways, all seems well and if something happens in the future I am sure we can solve it
That flash I had too, but it is not caused directly by the DVAR section being absent. In my case it was because “Load Legacy OROMs” was on by default when the DVAR section is gone, but when it is present it is off. The BIOS seems to have different default settings with DVAR there or not. Switching the load legacy ROM option off with a stock BIOS (no DVAR) also removes the flash. I guess the legacy VBIOS is causing that.
About the SLP tables: maybe v1 is a fallback when it doesn’t find the info in DVAR for SLPv3, which is what Win 8 and up use. I do believe what we see now is as it was intended to leave the factory.
I think we finally have the tablets to fully working condition again. I have been testing it for the last week and everything seems to work flawlessly.