Take the download link for the latest bios and replace bf with 53.
Finally, received the wson8 cable, following the steps you mentioned above. My P350 Tiny is fixed and work like solid.
Thanks for your help 
Thanks for the feedback 
Good to hear that it can be enough to transfer the machine specific data block for newer machines, too.
Sorry for the late reply @lfb6 my posts were flagged and hidden and then my account was on temporary hold. Reached out to a very kind moderator, chinobino, who fixed up my account!
Thank you for your help on the download link, it worked!
So, I think i did what you instructed me to do, you can see the modified file Here
I was not able to copy from 0x680000 to 0x61DFFF, but was able to copy from 0x61DFFF to 0x680000 (Just swapped the two around) as it would not allow me, from there I replaced the sections 0xE80000 to 0xED1FFF with the copied data from the downloaded Lenovo Bios. I used HxD to select the block region and copy/paste.
I opened it up in UEFITool, but still seem to have Parser errors:
Did I mess up?
I’sorry, that’s a typo:
Download bios KT53 (old bios version), unpack it, open bios it in hex editor, copy 0x680000 to 0x6D1FFF. Open your own dump, replace 0xE80000 to 0xED1FFF in your dump with the copied bytes from stock KT53.
Result should look like
(will correct it in the original post, too.)
Thanks!
I’ve done the updated change as you requested, see below:
Including the FIT console log:
Is this ready to be flashed back to the BIOS?
Seems OK. If unsure attach the file.
Juuuuust to be safe, although I think there is not much I could break since I have the CH341A Programmer, I have attached the “Fixed” BIOS: 2-CRC32-0x6DCD498E-FIXED.zip (9.1 MB)
Yes, looks good annd I’d try with this file.
It. Freaking. Works!
@lfb6 I have no words to describe how grateful I am! Thank you SO much!
Out of interest and to better my knowledge of this, how did you get to the start and end points to copy the data, is this something learnt over time or is there a trick to this?
Thanks for the feedback- good work
Try to find out the versions before and after update. Find which parts of the bios region are original, which are ‘new’ by comparing to corresponding stock bios regions, if accessible.
In your bios region the flashing began with the last UEFI volume but stopped very quickly. The original bios still was accessible, so smallest operation was to restore the small area already flashed with the original bytes.
You could’ve exchanged the complete bios region with stock, possibly loosing your board specific data (but they might be stored in other places, too, like TPM for example and get automatically repopulated in NVRAM), or a stock region and have transfered at least one or two NVRAM volumes to keep the data. If it’s just a small area of static code then I prefer just to replace it. Afterwards you are right there where you started.
It’s (almost) always better to search for the error than to blindly flash “something” like a foreign bios from unknown source.
I’d recoommend to update bios region and Intel ME, both are rather old!
https://download.lenovo.com/pccbbs/thinkcentre_bios/fwjybfusa.exe
https://download.lenovo.com/pccbbs/thinkcentre_drivers/11.8.92.4249_corporate.exe
1 Like
Hi again !
I havent given up hope yet on this M900. I did actually find my most ‘original’ dump of the bios immediately after it had been bricked. I’ve been trying to repair it.
UEFITool reports multiple problems - I’d appreciate any guidance on rebuilding it. I can make the microcode errors go away by replacing those sections in HxD from the official bios region from lenovo, but these errors hint to me there some problem with the structure:
FfsParser::parseVolumeNonUefiData: non-UEFI data found in volume’s free space
FfsParser::parseVolumeNonUefiData: non-UEFI data found in volume’s free space
FfsParser::parseIntelMicrocodeHeader: invalid microcode checksum 1C53FB94h, should be 18676471h
FfsParser::parseIntelMicrocodeHeader: invalid microcode checksum 56A790FFh, should be 37102A75h
FfsParser::parse: not a single Volume Top File is found, the image may be corrupted
MeParser::parseFptRegion: FPT partition is located inside another FPT partition, skipped
MeParser::parseFptRegion: FPT partition is located inside another FPT partition, skipped
MeParser::parseFptRegion: FPT partition is located inside another FPT partition, skipped
NvramParser::parseNvarStore: unable to parse AMI NVAR storage
NvramParser::parseNvarStore: unable to parse AMI NVAR storage
Something bad in the NVRAM area, or bad alignment somewhere not sure.
m900_corrupt.zip (9.7 MB)
Try the attached file. Confirm that it was flashed correctly by reading back the updated content again directly from the SPI in a separate process, store the freshly dumped content to a file and compare it to the original.
m900out.zip (8.7 MB)
Thanks for your continued assistance lfb6! Sorry for the delay replying, no time for BIOS tinkering over the weekend im afraid 
Unfortunately that one didn’t work. Did you take a stock bios area and replace the 1st volume’s nvram storage area from the corrupted dump?
Meanwhile last night Ive started a similar process of taking a stock rom and populating variable by variable the NVRAM area from my corrupted dump , ensuring the file passes the parser checks each time. I did find the section which is corrupt. Theres a beginning of a variable at offset 0x82227B which is then filled either with junk or a section of another variable with what looks like licensing info or certificate storage. If I fill the remainder of the volume with FF and restore a GUID store section then the file starts to parse correctly again in UEFI tool.
No success yet but Ill keep trying. Im convinced its not the board itself - my rationale is that some roms I’ve tried will give some different behaviour such as turning itself off and on again before staying bricked again .This hints to me that at least the BIOS is being read.
Ive also had the logic analyser on the SPI flash, and can see it negotiating up to the fast dual / quad data rate, at which point at 400Mhz, my logic analyser cannot keep up.
If the firmware from #53 with a minimal set of variables doesn’t work then a firmware with even more variables won’t work either… 
Try that file, re-initialized latest ME and latest bios- region stock/unchanged.
m900.zip (9.3 MB)
There are same differences in standard setup variables, and both bios and ME were very old, so there’s a minimal chance.
If this file against all odds would work then one could see if it’d be needed to add the old DMI variables to NVRAM again.
If this file doesn’t work, it’s not firmware related.
1 Like
ok lol. I was hoping if uefitool and similar utils couldnt parse the nvram areas then that would be why the machine wont boot if there’s something in there that is required.
Ill give that a try thank you.
Hello, I need someone to help me, I have seen that there are several experts here, the BIOS was updated through Windows and it died in the update process, I have tried everything, and in the end I bought a programmer to try to read the original another similar device and exchange it with the broken one, but I have not been successful, let’s see if one of you can repair the file for me WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free
Thanks in advance
Replace 0xE80000 to 0xE94FFF in your dump with 0x680000 to 0x694FFF from imagefw.rom of the update B3 (fwjyb3usa.exe).
(All values ‘including’)
Post / attach your result if unsure.
Thank you very much for your help, but I have not had a positive result, I connect the power and without touching anything the fan and the power light activate, black screen… I attach the bin with the modifications that you have told me. WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free
Yes, that image won’t boot. There’s just 4 bytes changed in the header of the lasti EFI volume. As written: