Last week I bought a Dell original mobile keyboard with internal battery for my Dell Venue 7130 tablet. When I docked the tablet for the first time with the keyboard everything seemed to work fine until I tried to put the tablet to sleep mode. Instead of going to sleep it just powered off. When I switched it on again I felt the short haptic vibrations but the screen didn’t come on. Only when I undocked it and after waiting for about 25 seconds it would switch on and Windows would boot up. Basically the tablet works okay except the ME driver cannot start (errorcode 10 STATUS_DEVICE_POWER_FAILURE), the NXP (nearfield proximity) driver can’t start, hibernate and sleep don not work and the slow switch on problems. I suspect the ME filesystem got corrupted because the battery in the mobile keyboard wasn’t charged yet and the ME didn’t like that. I tried a CMOS reset by removing the battery for about a minute, but it didn’t help. Official Dell firmware upgrades do not work, after the reboot the flash engine does not start and the system boots staright in Windows again.
I found this great forum and started reading and reading. I then got the Intel flash tools (fpt, meinfo and fwupdate) with the proper version so that they work with my device. First thing I obtained was the ME FWSTS which confirmed the ME file system is corrupted:
Intel(R) MEInfo Version: 9.5.35.1850 Copyright(C) 2005 - 2014, Intel Corporation. All rights reserved.
FW Status Register1: 0x00004191 FW Status Register2: 0x163B2140 FW Status Register3: 0x00000300 FW Status Register4: 0x00004000 FW Status Register5: 0x00000000 FW Status Register6: 0x40000000
CurrentState: Init ManufacturingMode: Enabled FlashPartition: Valid OperationalState: Bring Up InitComplete: Initializing BUPLoadState: Success ErrorCode: Debug Error ModeOfOperation: Normal Phase: BringUp ICC: No valid OEM data, ICC not programmed ME File System Corrupted: Yes PhaseStatus: UNKNOWN
FPF and ME Config Status: Match
I then tried to dump the entire bios using fpt, but get the infamous error 26 error showing the flash descriptor is locked. Of course I tried the tools also in a DOS and EFI shell but all to no avail. Tried a -greset as well, but also a no go. I only managed to dump the desc, bios, and gbe components. I can't dump or flash the ME region. I was able to dump the ME (and also desc, bios and gbe) from the Venue 7130 of my friend.
So as far as I know my only chances are to find the BIOS chip (according fpt it is a W25Q128BV) on the mainboard and flash it with a SPI programmer, which I luckily posess, but only after I found it because the mainboard is covered with EMI shielding covers :( and then again if it is indeed a 8-pad chip and not a 16-pin or 24-ball package... Or try the pinmod on the audio chip which is a Realtek ALC5505 (HDAUDIO\FUNC_01&VEN_10EC&DEV_0283).
Now for my questions: - does any of you have the pinout of the Realtek ALC5505 - is the pinmod to be carried out with a cold boot, i.e. by reapply battery power, or can it be done with a warm boot too (by just rebooting windows) - how can I assemble a full bios image out of the components I dumped from my friend's Dell 7130 so that I can flash it with my SPI programmer - i investigated my bios region dump and started disassembling a few PE parts (MeFwDowngrade and DellMe90LocalFwUpdateDxe-Edk1_06-Pi1_0-Uefi2_1) with IDA Pro and I just wonder whether it is possible to do a bios mod which bypasses the flash descriptor lock check? it this is theoretically possible I prefer to go for this option first and try to develop a bios fwupgrade patch
Many thanks in advance and best wishes to all of you, JockyW
Impressive research done so far, good work. You clearly have both the required tools and knowledge to fix the problem so it will work in the end for sure.
1) Try pins 1 & 5 as all the Realtek chips I’ve encountered have DVDD and SDATA_OUT there. If you cannot find the exact chip datasheet, try a similar one but it should be 1 & 5. 2) Cold boot. Shutdown the system, short the two pins and disengage when the OS starts to load. It is valid until the next reboot. 3) You can assemble the parts needed from your’s friend’s dump (not recommended) but I suggest you dump your own SPI image and work on that. 4) You can leave the FD unlocked via its Straps. You can easily do it via Flash Image Tool or manually.
Thanks for your answers and having so much faith in me
I am still curious whether there might be a sw-only solution. For example by bypassing the Flash Descriptor access control checks, either by patching the fpt flasher (unlikely) or by patching some bios fwupdate module. Basically it drills down to know where the flash descriptor is checked and whether that code can be patched. For a bios code patch to work it should be unsigned code. But even in case it is signed code, it might be possible to spawn a modified bios from the current running OS (Windows, DOS, Linux, EFI shell or whatever). Similar tricks were done for unlocking windows mobile based phones a decade ago.
The lock check is done in hardware. FWUpdate has nothing to do with all of these things, it is not affected by the FD lock status as the ME itself performs the update. Depending on OEM implementation, there can be a motherboard jumper to disable the ME for servicing (HDA_SDO) or BIOS options such as “Enable ME Re-Flash” or similar.
"Lock check in hw" can only mean bootrom code in either cpu or pch. But if in some bios there are sw overrule flags it means that the bootrom code must check those. Therefore to me it sounds a sw solution is feasible. It might be useful to reverse the sw flag behavior of the "overwrite ME" flag.
I was searching these forums for problems with the exact same tablet when I came across your post. My symptoms are a bit less disastrous and point less obviously to ME, but I still suspect it.
The BIOS double POSTs when booting or coming out of hibernate (happens really a lot with rapid start enabled), adding 20s or so to an otherwise fast boot. BIOS log always shows "ASF2 force off", some googling shows this can have several causes but ME is possible. It happened after I ran the tablet for a while with a low CMOS battery, which constantly reset/unprovisioned ME. I recognize the symptoms you describe after you tried to suspend yours with the keyboard. With the empty CMOS, whenever I pulled or drained the main battery there was a normal boot buzz and then a black screen, needing at least 3 attempts to boot it. CMOS battery has since been replaced but problems persist. MEInfo shows no problems, and AMT functions do work over the network.
After reading through these forums, I am tempted to try the pinstrap method to unlock the flash descriptor, mine is also locked. How did your friend dump his? There is a post here somewhere that shows how to clean your dump and reset ME that way, it looks promising. Alternatively, on ebay I saw some people sell preflashed BIOS chips for this model. I do have experience soldering small SMD things and access to hot air rework stations, but that seems a bit too invasive.
Perhaps I should renew my CMOS battery too, though I don’t suspect any problems with it, cuz there are no problems to change and save settings. Have you tried to reflash BIOS with the same or with a newer BIOS? A23 is the latest. Actually I want to downgrade to A10, A13 or A16, because I read quite a few users with nearly the same problems and a stuck BIOS, who managed to solve it by disconnecting CMOS for a minute and then reflashing the same firmware version. Apparently by doing that they can flash a corrupted ME region. I tried that with A22 to no avail, so I want to try it again with a downgraded BIOS. Here you can read about this method. My problem is to first extract the firmware components from the Dell Updater file (e.g. 7130vPro_A13.exe).
I dumped the regions of my friend’s 7130 with these steps:
The EMI shielding covers are complicating doing a pinmod or BIOS upgrade using a programmer. If you go for the pinmod any time soon please let me know under which cover(s) you find the BIOS and Realtek audio chips.
I have the A23 bios. Downgrading ME after flashing the A23 BIOS is probably not possible, it contains a ME version with a security fix for the AMT vulnerability uncovered in may (v9.5.61.3012). It has a higher VCN (Version Control Number) which disables downgrading of ME the regular way. In other words, running e.g. A22 probably only downgrades your BIOS but doesn’t touch your ME. I haven’t tried yet though, so it is worth a shot. I have tried running A23 again with no results.
Another thing I tried is running FWUpdLcl64.exe -save test.img to get a dump, and after that flashing the image back with FWUpdLcl64 -F test.img -OEMID xxx -ALLOWSV. Flashed successfully but problem still persists. I think FWUpd doesn’t really give a full raw dump like fptw gives, that would be a security leak if it leaked ME credentials etc. The only real way of fixing it is by unlocking the flash somehow.
I will attempt to find a way to pinstrap it when I find the time this week. I haven’t looked into it yet but the EMI shielding you speak of doesnt give me high hopes…
FWUpdate -save outputs ME Update images (UPD) and not full regions as found at the SPI chip. FWUpdate can only update a working ME to a newer version and it cannot dump anything useful. Dell’s updater uses a FWUpdate bios efi module to update the ME so it can neither repair nor downgrade to insecure older versions. As I said, you need to unlock the FD to service it.
I started exercising in situ programming (ISP) with the bios chips in my Dell E7440. The E7440 has two bios chips, as can be seen from the attached pic (next to the wifi and cellular cards). Unfortunately it didn’t work with both of my programmers, a CH341a and an EZP_XPro. The information given on the flashrom ISP page gives some reasons and in particular with Intel chipsets I think there is little chance to dump and flash using ISP and it will be necessary to remove the chip from the mainboard. Interestingly the board design of the Dell 7440 and the Venue 7130 look very similar. So I am pretty sure the BIOS chip can be found underneath the EMI shield shown on the second picture.
Before attempting to dump, clean and flash the 7130 BIOS chip, I want to downgrade the BIOS region from currently A22 to A10 and then perform the steps described here. This involves resetting CMOS and flashing an A13 BIOS from a USB drive. A couple of users having the same symptoms as I have were successful with that method.
Is there a tool to extract the regions from a Dell HDR file? Or can it only be done manually with a hexeditor?|addpics|hck-1-3f13.jpg,hck-2-affd.jpg|/addpics|
I have started disassembling my 7130, and the winbond chip is indeed under the EMI shield that has the heatsink pipe going under it. It is relatively easy to unhook, initially I was afraid it was soldered down. The markings indicate it is a winbond W25Q128FV.
I was planning to try ISP flashing it to unlock the flash descriptor and service it like that, but your research already indicates that might be difficult. Perhaps I can continue and find the audio chip to do the pinstrap method. Alternatively, the BIOS chip is luckily not a QFN package and I think I could unsolder it if I really needed, but I’d rather not risk that if it is not required.
I found the attached python script at My Digital Life. It works fine with python 2.7 ("python dell-extract-hdr.py A22.exe"). With newer python versions it spits errors.
Excellent, works fine. The attached .exe works fine in Windows and takes the HDR file as input.
I see that the BIOS region consists of 4 parts: section_0_A.22.data, section_0_A.22.meta, section_0_A.22.mtsg and section_0_A.22.sign I guess the last 2 files are signatures of the meta and bios payload respectively. Should I concatenate those 4 parts if I want to flash a BIOS region with fpt ?
EDIT1: I compared the extracted BIOS part (section_0_A.22.data) with my fpt dump of the BIOS region (bios.bin) and see that they have the same size (0xB00000), but they are not binary identical. Starting from offset 0xF48 the bios dump includes NVARs which are not contained in the extracted bios part. How save is it to flash the extracted part and what are these NVARs? Is that area preserved when flashing with fpt?
EDIT2: Hm, I found more deltas in other areas?! Perhaps the A22 bios I dumped is not the same version as the 7130vPro_A22 where I compare it with.
How many hooks are there and what tool did you use to unhook it? Can the shield be remounted afterwards? Tomorrow I will try if I can ISP the bios chip. That is, if the downgrade to A13, reset CMOS and reflash A22 (or A23) fails.
EDIT: would be cool if you can find the audio chip and test the pinstrap ! I will try to ISP the bios chip regardless whether or not the downgrade path works.
The EMI shield can definitely be placed back. There is a frame soldered down (I think you can see it in my pictures), which has little sharp bumps punched in the metal facing outwards. The removable EMI shield has holes in the folded over sides that snaps over these bumps and grab the frame.
I used the smallest screwdriver I have and used mainly upward force (perpendicular to the board), but sometimes I tried to pry the holes away from the bumps very gently without bending the metal.
I currently don’t have a clip the can grab the 8 pin SOIC package, so I am going to order that first. I looked at it again, and I am quite sure that if I need to I can even desolder it relatively easily. If this is a dead end, I will try to find the pinstrap. My guess is that it is either under the shield closest to the headphone jack, or on the other side of the board under the CPU.
1. You’ve guessed correctly, .mtsg is a signature for .meta and .sign is a signature for .data. The only file you need is .data (or .payload, if .data is in HDR subsection format, but it’s not the case for your file), others are used by Dell’s flash writing driver. 2. Those NVARs are NVRAM variables, that will be created on first boot of the flashed image. There are some rare cases that will require preserving them (because sometimes manufacturing data for a particular motherboard may be stored there), but AMI-based firmware very rarely use NVRAM for such purposes. 3. FPT doesn’t perform any parsing of BIOS region, so it won’t preserve anything in it.
After cutting off a small corner of the frame and bending the edge away, I could firmly put the SOIC clip on the bios chip and dump it. See the attached pictures. I then binary patched the FD at offsets 062, 0x66 and 0x6a, see here and flashed it.
I have just made another full dump with fptw64 and will check how to clean it. I hope my next post will be my final one in this thread.|addpics|hck-3-1242.jpg,hck-4-11b8.jpg|/addpics|
OMG, step 8 of the cleaning guide fails. See the attached pictures. Perhaps it is related to the warning at the end of the ME Analyzer output: “Warning: File size exceeds firmware, unneeded padding!”. Can you help? I have uploaded my spi.bin and me.bin here. Yes I know, not my last post in this thread …|addpics|hck-5-29f9.jpg,hck-6-bc07.jpg|/addpics|
