[Solved] Laptop dead after reading BIOS with CH341A

Hello everyone! Hope you are all doing well.

TL:DR - Read bios chip with CH341A programmer while laptop was plugged in with charger, now laptop won’t boot.

Recently I decided to do a full backup of my bios as a failsafe for a bios update. To cut a long story short, I ended up using a CH341A programmer and after a few failed attempts at reading, I deducted that it must have been an issue with 3.3v not being applied at a stable rate. Some forum searches later and people recommended to keep the laptop plugged in and read the bios chip in that state.

I tried this and successfully read the contents of the bios chip and verfied correctly too. Did a secondary read and compared the bin files in a hex editor and no differences were found.

Good, I thought, until I assembled the laptop and it didn’t turn on. The screens backlight didn’t turn on and no image was displayed. The caps lock and num lock LED’s flashed momentarily but did not respond to any further inputs. However, fan speed was not just full blast, it seemed to ramp up and slow down when cpu was getting hot and when cooled down. Also the LED’s for showing the laptop is on and for charging also worked. The LED for power button also worked. I had to hold it down to turn the system off but, earlier I would’ve just had to press it once before booting.

Interestingly, i repeated the read from CH341A again and discovered that the bios file changed. This happened every single time I tried turning on the laptop.This changes also occurred at the beginning of the bin file and the the rest was the same.

The laptop is a Toshiba L50-B-1P1, the motherboard is called DABLIDMB8E0 REV:E, the BIOS chip is a GD25B64B, but it is also the same as GD25Q64C.

I made a thread on Tom’s hardware that has more info on my situation: https://forums.tomshardware.com/threads/ch341a-programmer-bios-dumps-are-corrupted-and-fail-verification.3851937/

How would I go about diagnosing this? Should I try flashing back the first successful bin file I read? Should I flash a completly new version? I would be grateful for any recommendations and input. Thank you for your attention.

Did you tried only with main battery on… the programmer already provides power to the circuit…

You may have a corrupted EC…many modern systems don’t use only one IC anymore…
EC can be the U17 and an SST M24C08
This you have to confirm visually, the IC and brand/model, as it varies across revisions.

image

You can search also on Badcaps and Elvikom forums

Wait for other users POV, good luck

Seems you have a valid backup, that’s good.

That might be normal, for example ME gets changed/initialized when run first time for Intel systems. But depends where the changes are. In bios region (Intel) NVRAM gets changed, but that’s later in the boot process, after several boots mostly by OS.

I doubt errors in the EC- then system firmware wouldn’t get changed and basically also system wouldn’t be charging.

Most probably removed some ‘small parts’ when working with the clip or made a short in a sensitive place or nor properly reassembled?

No I have only tried with charger when I was reading with programmer. If I am understanding you correctly, should I try future reads with the battery instead of the charger?

Crap, I was hoping this wasn’t the case. Although I think I may have found the EC. I will post what I see soon.

Thank you for the photos, schematics and website recommendations I very much appreciate it.

Thank you for the info! I’m not sure how to tell this information apart. All I can tell is that stuff is being changed at the beginning of the bin files. I assume UEFITool is used to see the difference?

This is possible but I doubt it as I clipped it very carefully and all the little resistors and parts around the bios chip seem to be in place.

UEFIToolNE, HxD

If you want me to have a look attach / post a link to the original dump and one of the changed dumps.

Here attached are pictures of my motherboard and the chips I presume to be the EC and BIOS chip. I can’t seem to identify the chip with just numbers but I got a hit with google lens on a similar laptop with a similar chip.

https://imgur.com/a/p9l2p2Y

This is the website I found that had the similar chip:
https://www.elektroda.pl/rtvforum/topic3568084.html

Thank you so much! Here are the dumps I did. Each time I tried turning on the laptop and after the failed boot I did another dump (for the DC dumps).

The ones that are just “bios” are the ones where I just attached the programmer without the laptop charger. The ones with “biosDC” in the name are the ones where I attached the charger. The ones with “crap” are after I discovered the laptop doesn’t turn on anymore lol.

For some reason it won’t let me upload onto here even though its in a zip file and below the file limit. I have sent a MEGA link instead, I hope thats fine!

https://mega.nz/file/HXgl3JQY#eVfi6n39WMILVDPvPBOIK4hYP5I7U3-EK4a98J2KvMc

Which dumps are the identical ones made before you became aware that your machine no longer starts?

Almost all the dumps are different and have differences at different places and with a quick glance all the dumps are corrupt, even the 2 identical dumps (biosDC4(crap) and biosDC5(crap)) have a very good reason to brick.

I’d recommend to stop anuthing to the machine just for now!

All the ones that don’t have crap in the name. So the bios and biosDC ones.

That does make sense, “bios.bin” and “bios2.bin” I knew where somehow messed up. I read these without the external power. These did not verify correctly in AsProgrammer. However laptop worked okay after read.

“biosDC3.bin” was the first one I did with external power. This verified correctly in AsProgrammer. AFTER doing this read, I assembled laptop and did not boot.

“biosDC4(crap).bin” was then done after realising the laptop won’t boot. This also verfied in AsProgrammer correctly but, did not match “biosDC3.bin” in hex editor.

“biosDC5(crap).bin” is the same story. Verifies correctly however does not match the previous two mentioned in hex editor.

same for “biosDC6(crap).bin”.

Each time i did the “biosDC” dumps I tried turning the laptop on.

OK, you problem is reading properly (and therefore writing properly, too).

Your last 4 dumps were almost identical, 4 and 5 are, 3 and 6 have differences in ME region (which shouldn’t be there). Since it’s almost impossible to create two dumps with identical errors we have to assume that dump 4 and 5 are the current content of the chip.

Common for all the 4 dumps is that the bios region is bitwise identical and therefor all 4 dumps do have the same obvious fault that’ll brick a machine: The compressed DXE driver volume can’t be decompressed / expanded (left your dumps- see error in parser, right stock firmware). Normally that doesn’t happen accidentally.

Anyway, since Toshibas updates are a complete firmware I transfered the machine specific data which were consistent over several images to the latest stock image.

Bios_200_msd.zip (3.7 MB)

Please use the method you used for flashing dumps DC4 to DC6 for writing/ flashing. After flashing- whatever the flashing program is telling you regarding verify- close the program, open it again, read the chip, save it to a file with a different name. Compare this file with the original file (the one unpacked from the attached zip- file). They have to be a 100% identical.

Wow, genuinely thank you so much, I am really interested in all of this but I would have definitely not found that myself.

Speaking of that, I have found some dumps online that seem to be for the laptop and motherboard. I have also found schematics that seem to be also for the laptop or atleast very close. Could that be of any use?

I’m a little hesitant on this, I used the wall charger for the previous reads. What if I were to use the battery? According to the schematics I found, the battery acts as the CMOS battery (this laptop doesn’t support a CMOS battery), perhaps that is much better?

Just to Clarify, should I wipe before flashing? I should be doing this:
Flash → Ignore verification error (if any) → Read → compare bin’s.

Also just in case, should I do another read before i do this?

Again, thanks for your attention and help. I really do appreciate it.

Erase - program - verify

Flash - if any verification errors - begin from start again
OR
Flash - if no verification error - read - compare bin’s

@lfb6 Should I do another read before I start all of this?

Don’t power up the machine again.

Reading would be meaningfull. This new dump should in theory be identical to dump biosDC5(crap).

If it is you can continue to erasing, programming, …

If it is not you read again so that you have again two dumps, which should be a 100% identical.

If the 2 dumps are identical you can continue to erasing , programming, …

If the 2 dumps are not identical - check your setup and begin from start again

I just did two reads/dumps of the chip right now, they verified and are identical. Unfortunately, the CRC32 hash does not match the biosDC5 or biosDC4.
biosDC7-8.zip (7.7 MB)

I am now going to start the flashing process with the file you sent.

OKAY! Good news, everything went well. Erased → Flashed → Verified. The bin file you have sent me is identical to the contents of the bios chip.
Here is the dump I got AFTER I flashed with your bin file.

biosDC9.zip (3.7 MB)

CRC32 hash: 0x988C9D74

OK, then try to start the machine- it may take longer time and/ or reboot spntaneously some times, but it should start?!

(The don’t start was just meant until you’re sure that the SPI chip contains what it should)

Ok i’m gonna try now!!! :crossed_fingers: :crossed_fingers:

EDIT: (I can’t make anymore messages as new user)

@lfb6 She’s still dead :sob: :sob: :sob:

Ahahahah maann it’s even worse now. Power button doesn’t light, no fan spin, cpu isn’t heating up, hdd not spinning up, no screen.

I probably should’ve meantioned this earlier, there are bios version from toshiba that are higher than mine but should be compatible with the laptop. What if we try those?

EDIT2: @lfb6 Dayumm I have to wait 17 hours before I can start posting again.
If I udnerstand you correctly, you modified the file from the dynabook site? Since im already knees deep in this, what if I just go on a flashing frenzy and try flashing the other versions just like they are now?

EDIT3: @lfb6 Okay I see, I think I actually have that saved somewhere too. I have one from a telegram group I found and some other sites too. Would it be okay if we could revisit this when my post limit resets? Thanks for your help and attention, have a good day/night!

This was version 2.00 from this page:

Structure, ME revision and µcodes were comparable
.

https://www.badcaps.net/forum/troubleshooting-hardware-devices-and-electronics-theory/troubleshooting-laptops-tablets-and-mobile-devices/bios-requests-only/101532-toshiba-l50-b-psktae-firmware#post1758607

The firmware provided here at badcaps in #2 “Toshiba L50-B-1P1 PSKTAE DABLIDMB8E0 REVE.rar” is the unchanged 2.00 firmware, same firmware I used.

Modified - the block from 0x220000 to 0x221FFF contains machine specific data- and this block was identical in several of your dumps.

If those dumps really were your original dump, you can try versions from 1.70 to 2.00, they contain ME 9.5 as your 4 last dumps. Version 1.50 and earlier versions contain TXE 1.1