hi, thank you. flashing that image results in caps/numlock-blinking (code 5 - systemboard). the same thing happend when i tried to exchange the stock-bios chip with a new programmed chip. i think the chain of trust fails bc it detects a non-matching bios image (CRT in TPM?). that's why i wanted to enter MPM and reset that darn thing. I'll dig further into this and keep you updated if you want to. i'll try overwrite the efinvram volume next.... we'll see. cheers
I have actually flashed other model BIOS and had them boot. Looking at system information would report say an HP 1040 when it was in fact a 9470m (just as an example). But you also get the same results when you write back the original dump?
hi, when i got this notebook, i noticed bitlocker was enabled and a pw was set in bios/uefi. i don’t care about the data. my first attempt to remove the pw was to replace the stock bios-chip with a new preprogrammed chip i bought from a vendor here. it came with a bios without a pw set. when i booted the notebook with the new bios-chip, i got the caps/numlock-flashing error mentioned above. i dont get the error with the stock-chip/the dump i uploaded. i started searching for the reason (i‘m no expert when it comes to trusted computing!) and read about intel TXT and TPM. from what i understand, once TPM/TXT is enabled, it creates measurements (DRTM; SRTM?) to make sure the system was not changed/compromised = generates hashes based on installed software/hardware which get stored in the TPM and checked at boot. if the generated hashes of (certain parts?) of the bios do not match with the ones stored in TPM, the system holds and will not boot. at least this is what i understand how TXT / TPM works. feel free to correct me though. i‘m not sure if i‘m right. but it would explain the systems behavior when tampering with the bios. cheers
yepp, OTP confirmed. the notebook will not boot anymore, even if i flash the original dump. i can't rly explain why, but it's a fact. that would explain: a) the (possibly) missing $VSS store in the dump b) the bootfailure when a new chip is used to replace the old one if anyone comes up with a solution, feel free to contact me meanwhile i'm gonna get a new mobo cheers
hi, maybe. but the bios seems to store UUID and other factorydata in OTP memory regions, which can‘t be read from / written to by flashrom. earsing these regions on the chip will render the chip useless. see my post above. the only way to recover the bios now would be a full image dump (including OTP data) flashed to a new chip. and i have no idea where to obtain the full image from... at least that‘s what i think. i might be wrong, though. maybe a mod could cut the last posts out of this thread and move them to a new topic? i think i‘m going off-topic here... at least i can clearly confirm that the „flashrom/$VSS method“ does not work for 640 G2 Probooks. cheers
Hi mazzif can you help me please, I have problem with my laptop Hp 2560p, problem is when i start my laptop always open screen " Product Information Not Valid
its here. https://forums.mydigitallife.net/threads/slp-marker-file-update-utilities.9055/#post-131386 you will need to do some reading.. the stickers under battery have the infos. version 1.x or 2.x u will have to try a few
Product Number is: XB208AV#ABF Serial Number is 10 Characters Feature Code can 14 Zeros (00000000000000) It looks like you are running a very long string for Product #. Try again with correct values.
This is exactly what it says. The system cannot detect the chip. I usually do this to check for the chip first: sudo flashrom -p linux_spiev=/dev/spidev0 .0 A couple things to try. Double check pinnouts. Also, after you make your connection, try plugging in the the AC Adapter to the laptop. Also, the SOIC clips can be touchy. My best success came from to the Pomona brand. Adjust your clip on the chip to ensure solid connection and try to 'detect' chip again.
Thanks for sharing your experience. Keep in mind, that I have seen some 8570 model that use a 16PIN SOIC. That would really test your soldering skills. Something else I am looking at is taking a BIOS dump of a non password protected laptop, and mapping the areas for Serial Number and SKU. My flashing script will ask for user input for SN and SKU and write those values to the dump file at the exact location required (no more messy hex editor!), and then flash the newly modified file. So far I have found this is less destructive than blowing out the entire VSS store and has the added benefit of not needing to run WNDMIFIT to reprogram. Once flashed, the system will have the correct SKU and SN. No warning messages. It's pretty clean. I could take it a step further and have input for say the PCID, but I dont feel thats needed. The challenge with this scripting this process for me, was that each byte written, needed to be separated by a NULL byte. But, I worked it out.
hi! Happy to share! I'm by no means expert in soldering but i think my 2570 are soic 16 also...and yes it was a test at my skills! i have original dump with password and the one i flashed if you need!! that scfript would be gold for guys like me for whom hexeditors are scary.... thanks
i had the same issue. i solved it by passing the spispeed-argument to flashrom: Code: sudo flashrom -r bios.bin -VVV -p linux_spi:Dev=/dev/spidev0.0,spispeed=1000 cheers