But there seem to quite a lot of ways doing this. The HP bios region update is there for comparison. The two parts of bios regions in chip 2 arent same version, didn’t look further.
How Lenovo did it- we’ll have to see.
But that’s the reason that this kind of second chip is afaik only accessible through bios routines. The chip of your P330 is part of the main bios and is defined in the flash descriptor. But those number are valid only for the working firmware!
FFF - this has been done with a Hex editor or MFIT when cleaning an ME. It can be reversed, of course.
The brick happened possibly as only one bios region was updated and the system compared backup bios parts to booting bios parts and found them changed- someone had fiddled with / compromised the firmware.
Regarding adapter- it’s size dependant, size / width is normally given in mm- something like that:
(Just a google search how things might look like- no recommendation)
Will check it and get a double check confirmation from you.
Do you think the machine will be back to life? Also, you didn’t mention on which chip i should write the bios dump and how, i mean using FPT, we can use -bios flag but how that can be done when programming externally? And how do we know which chip has that BIOS region?
Chips are U52 and U53 as far as I can see. Please double check this since the pic is taken with an angle, might be hidden another marker behind/over the upper chip?
Begin with your machine and dump the chips until you find the one which not is the working bios. If it’s the first you pick, mark it, save it’s position (U52 or U53 or…), If the first one is the working bios you have to read the second one, too.
Oh, and regarding fpt version- there’s only one main version working and it depends on the Intel ME generation. There might be different sub- versions of the tools like 16.1.xx.yyyy but those are less relevant. There’s not vendor specific preset versions like AMI Tools- where it’s for example important to spare the sections with machine specific settings and NVRAM which might be located to different places depending on vendor.
fpt can write regions which are defined in flash descriptor, but also smaller ranges when start address and length of a block are given. It doesn’t check what you ask to write!
Well, Lenovo often services EC firmware separately, and S0JES08A fits into Lenovos normal schemes for update naming. (Doesn’t mean that you may be able to download it separately, though), simply stumbled over it.
Bu this area there isn’t just EC firmware, it’s (probably) part of the security or recovery mechanisms, too. It contains 2 (signed?) copies of the FD, one identical to the ‘official’ one, one a little different. (That’d fit into the concept from the HP taken as an example- 2 older bios regions (code only) on the second chip)
One of these flash descriptors is identical to the one used, one is different. Since the FD contains some data configured with FIT I tried the different FD and opened the resulting firmware in FIT- there’s only one difference in settings- slave chip enabled is set to ‘no’:
It’s just guessing but this may be the reason for the empty second chip (and maybe the bios refusing to update since a bios update would require transfer of the old bios parts to the second chip- that doesn’t exist). But I can’t say that for sure.
GbE: Since the NICs have separate SPIs there’d be no noeed for an additional GbE
Now regarding your dumps / the last post::
The empty file is quite unexpected. The other file is a correct result of the earlier actions.
Do you have the possibility to get the result of fpt -i from your friends machine?
And to fix this properly we’d need dumps of both chips from your frineds machine. Even if it’s a slightly different config it will help to understand the proper config of the empty chip. We need a possibly unchanged ME configuration.
So a fpt dump of your friends running machines firmware would be helpful, and we’d need a dump of the second chip of your friends machine, too.
Ways to proceed which wouldn’t fix the original problem (bios updates not possible):
Flash back your original dump and hope the machine boots
Flash back your updated dump with machine specific data
Flash back your updated dump with machine specific data and cleaned ME
Ways to proceed which could fix the original problem:
Get the configuration of a working machine and try to recreate a proper config for your machine
Get the configuration of a working machine, clean ME and transfer the machine specific data
And I’d recommend you to put this into badcaps, too. They do a lot of recovery for newer machines. But they have quite strict rules and close to zero patience when not following them (in the best case one reminder or simply not answering at all).
@Fastline ,
Didn’t you notice the other firmware update on Lenovo’s support page for the P3 Ultra?
Whenever you update the BIOS it is normal for the board to startup and shutdown multiple times (5x~8x, validating blocks I believe after a BIOS upgrade) before it boots normally to your OS’ loader. It’d be wise to not interrupt the procedure/validation - but I imagine you can let it continue where it last left off. Try powering up the device and let it run and see if it will eventually post either your BIOS and/or OS.
I’m just not sure why it got bricked when i followed your instructions. But as this was my second flash work, i should have taken a backup using the hardware programmer.
I think it’s because you omitted the first padding in the bios region, containing machine specific data and at least 3 blocks that look like signatures. But might as well in addition something stored in NVRAM.
A dump with fpt normally is safe / safer as a dump with the programmer. I don’t rely on the verify of the programming software, I always read the chip back in a separate process after flashing and compare the result with the file intended to flash.
But you still can read the chip now again and compare if it contains what was intended to program.
Thanks for the info from the other machine. Still a dump would be nice to compare ME config and settings in FD!
