I updated the drivers, no luck (I wouldn’t assume that they’d fix the slow booting).
I did reset the bios multiple times in the past, that didn’t work either.
As lfb6 previous mentioned, this is most probably a corruption on the ME FW partition, NO reset, no bios update, etc will fix a corrupted ME FW image on a working system.
It must be reinitialized and flashed back or full SPI IC(s) programm with a fixed/initialized image.
No, they wouldn’t.
I’m having a tough time seeing how a dell bios update would corrupt your ME, but I guess it’s possible. If that’s it, you’ll have to follow the guide lfb6 pointed you to.
The issue with ME is that I’m not sure there’s a way to test it for corruption. I think you just have to assume it, and then clean and physically flash. I’m pretty sure it will require a physical flasher.
What I didn’t know (and still don’t know) is whether a new dell bios update would get around the “need to clean” issue, since dell bios updates will overwrite current ME data versions. I’ve had my issues, but thankfully never a corrupted ME.
Mine has a Winbond 25Q256FVEQ.
I have a CH341A and a programmer clip that seems to fit the size. I’ll see if I can pull a copy from it.
Carefull, this is a WSON IC pachage, the standart SOIC8 clips wont attach correctly.
You need a a needle type one or working on it desoldered from the pcb.
Yep. Unfortunately, mine is for a SOP8. While it does have the right pitch, the plastic sides don’t allow the pins to reach the soldering blobs. So I’ll have to order a specific clip.
To be continued…
@lfb6 (or anyone who wants to take a shot at this), Dell usually posts BIOS Recovery Image Files, and that’s the case here. The latest Precision 5520 has a BIOS Recovery Image File/BIOS_IMG.rcv, and Dell has instructions on how to apply the recovery. Would there be any benefit in trying to apply the BIOS Recovery Image File process?
1 Like
user lfb6 has a different “EGO” of mine
Well we found something we agree on.
1 Like
Regarding the recovery file for the 5520 you could’ve found out yourself. The file unpacks with Dell_PFS_Extract and its content has the same structure as a normal update. You can simply check the ME binary with MEA and found out that it’s ‘unconfigured’ (and it has ‘update’ in it’s name). I haven’t seen this changing for newer ME versions where update and region have a different structure.
.
Corruption:
If you had checked MEInfo output once you’d have found a line that says “ME File System Corrupted Yes/No”. if it says ‘yes’ you can be quite sure that there’s corruption, but if it’s no you can’t be completely sure that there’s no corruption.
If you had checked ME tools set more thoroughly you’d have found a tool called MEManuf which checks the ME and - run with ‘-verbose’ switch - gives some information about the ME state, se output for ME 14
MEManuf64 -verbose (ME 14)
LPC Device Id: 687.
Platform: Cometlake Platform
General FW Information
FW Status Register1: 0x94000245
FW Status Register2: 0x38850106
FW Status Register3: 0x00000030
FW Status Register4: 0x00004000
FW Status Register5: 0x00000000
FW Status Register6: 0xC0400000
CurrentState: Normal
ManufacturingMode: Disabled
FlashPartition: Valid
OperationalState: CM0 with UMA
InitComplete: Complete
BUPLoadState: Success
ErrorCode: No Error
ModeOfOperation: Normal
SPI Flash Log: Not Present
Phase: BringUp
PhaseStatus: CM0_MKHI_HANDLER_STOP
ME File System Corrupted: No
FPF and ME Config Status: Committed
RPMC status: OK
FW Capabilities value is 0x7DF6D147
Feature enablement is 0x5DF6D147
Platform type is 0x42001492
No Intel Wireless device was found
Feature enablement is 0x5DF6D147
ME initialization state valid
ME operation mode valid
Current operation state valid
ME error state valid
MFS is not corrupted
PCH SKU Emulation is correct
Request Intel(R) ME BIST status command… done
Get Intel(R) ME test data command… done
Get Intel(R) ME test data command… done
Get Intel(R) ME test data command… done
Total of 19 Intel(R) ME test result retrieved
Policy Kernel - Power Package : Live Heap Test - Passed
Common Services - LAN : Connectivity to NIC in M3 - Passed
Policy Kernel - Boot Guard : Self Test - Passed
VDM - General : VDM engine - Passed
GFX - General : Sampling engine - Passed
USBr - General : Storage - Passed
USBr - General : KVM - Passed
Common Services - LAN : Connectivity to NIC in M0 - Passed
AMT - KVM : Compression engine - Passed
AMT - KVM : Compare engine - Passed
PAVP - General : Verify Edp and Lspcon Configurations - Passed
PAVP - General : Set Lspcon Port - Passed
PAVP - General : Set Edp Port - Passed
IP Loading - TCSS IPL Tests : TCSS IPL Health Test - IOM - Passed
Policy Kernel - ME Password : Validate MEBx password - Passed
Common Services - EHBC State : EHBC and Privacy Level states compatibility - Passed
Common Services - EHBC State : Valid Embedded Host Based Configuration (EHBC) state - Passed
Common Services - Privacy Level : Valid Privacy Level settings - Passed
AMT - Power : Valid LAN power well - Passed
Clear Intel(R) ME test data command… done
MEManuf Operation Passed
If ME updates by FwUpdLcl don’t run you can be quite sure that there’s corruption. So if you have a machine where the firmware updates contains a ME update binary (like many Dell) and the bios region get’s updated but ME doesn’t you can be quite sure, too.
All other cases it’s on a ‘might be worth a try’- base
plutomaniac earlier asked users to run MEInfo and MEManuf, but there’s a lot of cases where you can’t come to a conclusion. So if in doubt about firmware, reset your firmware (NVRAM and re-initializing ME) to come as close to a stock ‘new’ firmware. If this is done properly and you still have problems with your machie you can rule out firmware issues for good.
2 Likes
Thanks once again, my friend. For the BIOS Recovery Image File issue, many have said that you can’t overwrite a corrupted ME with a new ME firmware to fix/correct the corruption, so I was wondering if implementing the Dell BIOS Recovery Image File process would overcome the “need to clean”. In other words, I was wondering if the Dell process was so thorough, that it did the cleaning at re-boot. Come to think of it, if you were not in boot dire straits, and could use the regular exe upgrade, I guess the same question would apply.
I still have my doubts about a Dell update corrupting the ME region, but one thing is for sure; your post will get to the answer/solution one way or another! Thanks again.
I just ran the commands to see the outcome.
Here’s the MEInfoWin64 output:
> .\MEInfoWin64.exe
Intel(R) MEInfo Version: 11.8.86.3877
Copyright(C) 2005 - 2020, Intel Corporation. All rights reserved.
Intel(R) ME code versions:
BIOS Version 1.40.0
MEBx Version 11.0.0.0012
GbE Version 0.8
Vendor ID 8086
PCH Version 31
FW Version 11.8.96.4657 H
Security Version (SVN) 3
LMS Version 2316.5.1.12
MEI Driver Version 2433.6.3.0
Wireless Hardware Version 2.1.77
Wireless Driver Version 23.90.0.2
FW Capabilities 0x31111140
Intel(R) Capability Licensing Service - PRESENT/ENABLED
Protect Audio Video Path - PRESENT/ENABLED
Intel(R) Dynamic Application Loader - PRESENT/ENABLED
Intel(R) Platform Trust Technology - PRESENT/DISABLED
Re-key needed False
Platform is re-key capable True
TLS Disabled
Last ME reset reason Global system reset
Local FWUpdate Enabled
BIOS Config Lock Enabled
GbE Config Lock Enabled
Host Read Access to ME Disabled
Host Write Access to ME Disabled
Host Read Access to EC Disabled
Host Write Access to EC Disabled
SPI Flash ID 1 EF4019
SPI Flash ID 2 Unknown
BIOS boot State Post Boot
OEM ID 68853622-eed3-4e83-8a86-6cde315f6b78
Capability Licensing Service Enabled
OEM Tag 0x00000000
Slot 1 Board Manufacturer 0x00001028
Slot 2 System Assembler 0x00000000
Slot 3 Reserved 0x00000000
M3 Autotest Enabled
C-link Status Enabled
Independent Firmware Recovery Disabled
EPID Group ID 0x1FDD
LSPCON Ports None
5K Ports None
OEM Public Key Hash FPF 963847BF4FA55A02B326C561C56BCE68820041CAC285B43AE1F1B1FEB3FED4A4
OEM Public Key Hash ME 963847BF4FA55A02B326C561C56BCE68820041CAC285B43AE1F1B1FEB3FED4A4
ACM SVN FPF 0x2
KM SVN FPF 0x0
BSMM SVN FPF 0x0
GuC Encryption Key FPF 0000000000000000000000000000000000000000000000000000000000000000
GuC Encryption Key ME 0000000000000000000000000000000000000000000000000000000000000000
FPF ME
--- --
Force Boot Guard ACM Enabled Enabled
Protect BIOS Environment Enabled Enabled
CPU Debugging Enabled Enabled
BSP Initialization Enabled Enabled
Measured Boot Enabled Enabled
Verified Boot Enabled Enabled
Key Manifest ID 0xF 0xF
Enforcement Policy 0x3 0x3
PTT Enabled Enabled
PTT Lockout Override Counter 0x0
EK Revoke State Not Revoked
PTT RTC Clear Detection FPF 0x0
And here’s the MEManuf64 output:
> .\MEManufWin64.exe -verbose
Intel(R) MEManuf Version: 11.8.92.4222
Copyright(C) 2005 - 2022, Intel Corporation. All rights reserved.
Windows OS Version : 10.0
FW Status Register1: 0x94000245
FW Status Register2: 0x000B0506
FW Status Register3: 0x00000030
FW Status Register4: 0x00684004
FW Status Register5: 0x00001F01
FW Status Register6: 0x47C00BC9
CurrentState: Normal
ManufacturingMode: Disabled
FlashPartition: Valid
OperationalState: CM0 with UMA
InitComplete: Complete
BUPLoadState: Success
ErrorCode: No Error
ModeOfOperation: Normal
SPI Flash Log: Present
FPF HW Source value: Original FPF HW Fuse Bank
ME FPF Fusing Patch Status: ME FPF Fusing patch NOT required
Phase: ROM/Preboot
ICC: Valid OEM data, ICC programmed
ME File System Corrupted: No
PhaseStatus: CALL_NEXT_MODULE
FPF and ME Config Status: Match
FW Capabilities value is 0x31111140
Feature enablement is 0x11111140
Platform type is 0x11240421
No Intel Wireless device was found
Feature enablement is 0x11111140
ME initialization state valid
ME operation mode valid
Current operation state valid
ME error state valid
OEM ICC data valid and programmed correctly
MFS is not corrupted
PCH SKU Emulation is correct
FPF and ME Config values matched
Request Intel(R) ME BIST status command... done
Get Intel(R) ME test data command... done
Get Intel(R) ME test data command... done
Total of 17 Intel(R) ME test result retrieved
Policy Kernel - Boot Guard : Self Test - Passed
Policy Kernel - Embedded Controller : Power source type - Passed
MCA - MCA Tests : Blob - Passed
MCA - MCA Tests : MCA Manuf - Passed
SMBus - SMBus : Read byte - Passed
VDM - General : VDM engine - Passed
GFX - General : Sampling engine - Passed
USBr - General : Storage - Passed
USBr - General : KVM - Passed
PAVP - General : Verify Edp and Lspcon Configurations - Passed
PAVP - General : Set Lspcon Port - Passed
PAVP - General : Set Edp Port - Passed
Policy Kernel - ME Password : Validate MEBx password - Passed
Policy Kernel - ME Configuration : PROC_MISSING - Passed
Clear Intel(R) ME test data command... done
MEManuf Operation Passed
I booted the bios recovery and had a FAT32 USB inserted with the BIOS_IMG.rvc file.
It created a BOOTEX.LOG file.
Checking file system on \\?\Volume{46e2e73c-d4fd-11ef-a489-d481d732eef7}
The type of the file system is FAT32.
One of your disks needs to be checked for consistency. You
may cancel the disk check, but it is strongly recommended
that you continue.
Windows will now check the disk.
Volume Serial Number is EF5A-EBDF
Windows has scanned the file system and found no problems.
No further action is required.
30704976 KB total disk space.
13632 KB in 1 files.
30691328 KB are available.
16384 bytes in each allocation unit.
1919061 total allocation units on disk.
1918208 allocation units available on disk.
After it reflashed the BIOS and stuff, it booted Windows.
No change, still a very slow boot.
I see you updated to latest 5520 firmware 1.40 and ME updated, too.
For a Lenovo 13th gen Thinbook it takes 34s from pressing the start button to Lenovo logo and 23s from end of Post to Windows logon screen. It was faster once, but I think they added protections and code checks to the firmware.
Taking the output of MEInfo and MEMAnuf and the fact that your ME seems to update fine I don’t think that you’ll win much by doing the procedures - except knowing for sure that this wasn’t ME corruption. But since this procedure aren’t risk free I would take it as it is.
The symptoms I have with this pc:
Super slow boot. It takes about a minute to get to the POST screen and another minute to start the bootloader (from Windows).
Once I make changes to the BIOS settings, pressing save freezes the laptop for about a minute.
When I use the bootable setup_var tool (which allows me to pretty much write anything to any address. I use it to undervolt the CPU by 100mV), making a change takes about a minute before I can do something again.
So there’s something wrong with writing to the BIOS. Could it be a dying BIOS chip or something else?
I ordered the clip so that I can at least make a backup. Maybe it’s worth a shot to replace it?
It never occurred to you that fiddling with the NVRAM this way might itself be the cause? I thought we’re talking a stock firmware here…
Dump the firmware, replace your NVRAM with a stock NVRAM EFI volume and check then how the system reacts.
NVRAM isn’t like CMOS where you simply can reset by removing the battery…
One of these histories where you get told the relevant parts first completely at the end…
Good luck.
I used the efi tools to figure out which address contains the voltage for the CPU by extracting the v1.18 bios.
I have to add to this that this happened before I ran the setup_vars. It was already slow at around bios v1.20 up to the latest 1.24. I then flashed 1.18 (but since it didn’t downgrade ME, I couldn’t undervolt with the Intel XTU tools, but I was able to use setup_var with success). So the things I did with setup_var did not affect the system. I obviously first did a read to check the value before changing
I’ll read out the BIOS chip once the clip arrives.
Unfortunately the Dell bios recovery 3 on my laptop doesn’t specifically mention NVRAM reset (as in the documentation), so I’m not sure if it resets (nor do I know if it picked the recovery file from the USB or one saved on the hard drive). The automation of recovery 3 is annoying to say the least.
By the way, won’t the service switch on the motherboard be useful in this case?
Can you post a couple pictures of what you believe is the service switch on this motherboard? I would love to be wrong on this for a few reasons, but I don’t think the board has that.
Can you post a couple pictures of what you believe is the service switch on this motherboard
See my comment here. The switch is there and it’s spring loaded.
OK, I missed that. If you can get the computer into physical service mode, you shouldn’t have to mess with a programmer. You’re only looking to clean NVRAM and ME (even though that’s probably not a problem), flash, and move on.
Have you tried to get it into service mode, and then run fptw64 -d backup.bin?
If you can get it into service mode, you should be in great shape. Take a look at my last post in this thread, and give it a go.
If you can flash a clean NVRAM and ME and you still have a problem, then it may be a hardware issue.
I would discontinue worrying about undervolting for the time being. I don’t want to read about this issue, but with new Precision 1.40 firmware, it shouldn’t be an issue.
I moved the switch and held it (as it’s spring loaded). Booted windows and ran the command, unfortunately error 318, no read access.
Running the meinfo program shows that it indeed has no read access.
I also came across this thread stumbling on the same issue (when it comes to dumping the bios without a programmer).