01-09-2021, 04:42 PM
(This post was last modified: 01-09-2021, 05:15 PM by manolo_number_two.)
Just recently, I were faced a bricked Laptop Toshiba Satellite C50-A-1M0, which did nothing more than lighting some LEDs and switching off after about a minute.
The Problem came due to a stuck BIOS upgrade from version 1.10 to 1.40. The BIOS of this model is from Insyde.
To be honest, this Laptop is pretty old, but I never had such a case on my desk and there was no risk to break it even more - it was broken already. The only thing that could happen was that I'd get this PC running again, so I decided to give it a try.
First, I tried to restart the Flashin process as indicated on diverse pages, as also here: extracting the .fd file from the BIOS update on a USB-Stick and pressing special keys (Win+B, Fn+B,....) during Power-on. It was visible on the Stick's LED that the PC somehow did something on it. But I could never get to the point that the PC would beep or do anything else than switching off after a minute. I also tried the same with a similar CD in the drive, as the drive sounded as if it would do something. I tried every possible combination of keys - nothing.
All this did not work, so I needed another solution.
I stumbled across this page: https://www.rototron.info/recover-bricke...pberry-pi/
This guy is explaining very clearly how I could reprogram the Flash chip using a Raspberry Pi.
I still had a Raspberry Pi 3 in the drawer, so why not give it a try?
In his example, he had the Macronix MX25L8005 Flash IC, where in contrast, my PC used a Winbond W25Q64F. But that should be handled by the flashrom tool used on the Raspberry Pi.
I decided to solder the chip out, as I currently don't own such a clamp for contacting the SOIC8 in-circuit. Plus, several guys out there reported that due to other circuits on the board, signal level and power supply might be insufficient, if just supplied by the Pi.
There are a lot of working descriptions on how to connect this Winbond Flash IC to the Raspberry Pi, but I found this one to be fine and it worked as well: https://github.com/nopnop2002/Raspberry-W25Q64
I am not aware of the software this guy has on the page. But I used his Fritzing wiring plan.
As I had the IC soldered-out and wired to the Raspberry Pi, I just followed the instructions from the rototron page above:
And after some other beginner-faults, flashrom showed me the result I were looking for:
- Okay, let's go.
I took a dump of the bricked Flash using
in order to be safe if anything would happen.
Then, I were ready to flash the new content. - But which one?
I read in several comments that the .fd file in the installer .exe is the BIOS content and that it can be used the same way as a .bin file is used. So, I extracted the .fd file from the 1.40 Update and tried to flash it to the device:
Unfortunately, that failed!
And the error message was really confusing:
Does that mean, I can't use this file? - It seems like!
But what would I use then?
An internet search did not reveal anything new about .fd and .bin files, so I had to find the solution by myself.
Assumption was that the right content must be contained in this file.
When I open this file in 7-Zip, it turns out that it has different sections. One of them ".text" - the by far largest one - is 9054304 Bytes long. Highly probable that this further contains the content I need, plus some overhead I don't need.
What could I do in order to find that out?
Well, just out of pure luck, I also had the brick.bin flash dump. So, maybe I could find some hints in that file?
So, I openend that file using HxD:
So, the brick.bin file starts with one line of 0xFFs and the second line starts with "5A A5 F0 0F".
The .text file beginning is completely different. So, let's see it we can find the upper sequence in the .text file... Tada!
The beginning sequence of the brick.bin is stored at offset 0x0430! Seems to work. And in the line above, there is a text saying "IFLASH_BIOSIMG". So, it really looks like there is a section marked, which contains the flash binary I need.
I erased the part before offset 0x0430 and saved the file under a new name "DM10S140.BIN".
So, let's do the same with the end of my brick.bin:
Interestingly, the brick.bin file size is exactly 8388608 Bytes (= 0x800000 Bytes), just as the chip size.
The file concludes with a line "0F 09 E9 1B...". Let's seek that in the .text file...
And: BAM! - That's it!
So, the End of the brick.bin file, Offset 0x7FFFFF is stored in the now shortened .text file at Offset 0x7FFFFF!
It seems pretty clear that everything between is my flash content and below is some text overhead I can just cut off...
Did that, and saved the file. The new "DM10S140.BIN" file now had exactly the same size as the "brick.bin" file, which made perfect sense.
I prayed once that it would work and flashed it on the device:
After some time (and many pages of output due to the -V switch :-), flashrom concluded its process:
Seemed like the flash had worked. Now, there was no other way than the re-assembly of the Laptop in order to get the proof.
Unsoldered the chip from the wires, soldered it back to the mainboard and assembled the PC.
And... It is fixed and running! --> SDG
Most of this surely is not new to the readers of this forum. But I have not found anything about how to extract the .bin file from the fd file.
Maybe, some other tools do this automatically. But flashrom - or at least the implementation I were using - was not able to do so.
I believe, I am not the only person ever facing this problem, so hopefully, this will help anyone else...
In order to help others not having the necessary files, I also attach the now running Insyde BIOS 1.40 .bin file for the Toshiba Satellite C50-A-1M0 ready for flashing.
The Problem came due to a stuck BIOS upgrade from version 1.10 to 1.40. The BIOS of this model is from Insyde.
To be honest, this Laptop is pretty old, but I never had such a case on my desk and there was no risk to break it even more - it was broken already. The only thing that could happen was that I'd get this PC running again, so I decided to give it a try.
First, I tried to restart the Flashin process as indicated on diverse pages, as also here: extracting the .fd file from the BIOS update on a USB-Stick and pressing special keys (Win+B, Fn+B,....) during Power-on. It was visible on the Stick's LED that the PC somehow did something on it. But I could never get to the point that the PC would beep or do anything else than switching off after a minute. I also tried the same with a similar CD in the drive, as the drive sounded as if it would do something. I tried every possible combination of keys - nothing.
All this did not work, so I needed another solution.
I stumbled across this page: https://www.rototron.info/recover-bricke...pberry-pi/
This guy is explaining very clearly how I could reprogram the Flash chip using a Raspberry Pi.
I still had a Raspberry Pi 3 in the drawer, so why not give it a try?
In his example, he had the Macronix MX25L8005 Flash IC, where in contrast, my PC used a Winbond W25Q64F. But that should be handled by the flashrom tool used on the Raspberry Pi.
I decided to solder the chip out, as I currently don't own such a clamp for contacting the SOIC8 in-circuit. Plus, several guys out there reported that due to other circuits on the board, signal level and power supply might be insufficient, if just supplied by the Pi.
There are a lot of working descriptions on how to connect this Winbond Flash IC to the Raspberry Pi, but I found this one to be fine and it worked as well: https://github.com/nopnop2002/Raspberry-W25Q64
I am not aware of the software this guy has on the page. But I used his Fritzing wiring plan.
As I had the IC soldered-out and wired to the Raspberry Pi, I just followed the instructions from the rototron page above:
Code:
flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=2000 -V
And after some other beginner-faults, flashrom showed me the result I were looking for:
Code:
Found Flash chip "W25Q64".
I took a dump of the bricked Flash using
Code:
flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=2000 -V -r bricked.bin
Then, I were ready to flash the new content. - But which one?
I read in several comments that the .fd file in the installer .exe is the BIOS content and that it can be used the same way as a .bin file is used. So, I extracted the .fd file from the 1.40 Update and tried to flash it to the device:
Code:
flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=2000 -V -w DM10S140.FD
Unfortunately, that failed!
And the error message was really confusing:
Code:
Error: Image size (9056560 B) doesn't match the flash chip's size (8388608 B)!
Does that mean, I can't use this file? - It seems like!
But what would I use then?
An internet search did not reveal anything new about .fd and .bin files, so I had to find the solution by myself.
Assumption was that the right content must be contained in this file.
When I open this file in 7-Zip, it turns out that it has different sections. One of them ".text" - the by far largest one - is 9054304 Bytes long. Highly probable that this further contains the content I need, plus some overhead I don't need.
What could I do in order to find that out?
Well, just out of pure luck, I also had the brick.bin flash dump. So, maybe I could find some hints in that file?
So, I openend that file using HxD:
So, the brick.bin file starts with one line of 0xFFs and the second line starts with "5A A5 F0 0F".
The .text file beginning is completely different. So, let's see it we can find the upper sequence in the .text file... Tada!
The beginning sequence of the brick.bin is stored at offset 0x0430! Seems to work. And in the line above, there is a text saying "IFLASH_BIOSIMG". So, it really looks like there is a section marked, which contains the flash binary I need.
I erased the part before offset 0x0430 and saved the file under a new name "DM10S140.BIN".
So, let's do the same with the end of my brick.bin:
Interestingly, the brick.bin file size is exactly 8388608 Bytes (= 0x800000 Bytes), just as the chip size.
The file concludes with a line "0F 09 E9 1B...". Let's seek that in the .text file...
And: BAM! - That's it!
So, the End of the brick.bin file, Offset 0x7FFFFF is stored in the now shortened .text file at Offset 0x7FFFFF!
It seems pretty clear that everything between is my flash content and below is some text overhead I can just cut off...
Did that, and saved the file. The new "DM10S140.BIN" file now had exactly the same size as the "brick.bin" file, which made perfect sense.
I prayed once that it would work and flashed it on the device:
Code:
flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=2000 -V -w DM10S140.BIN
After some time (and many pages of output due to the -V switch :-), flashrom concluded its process:
Code:
Erase/write done.
Verifying flash... VERIFIED
Seemed like the flash had worked. Now, there was no other way than the re-assembly of the Laptop in order to get the proof.
Unsoldered the chip from the wires, soldered it back to the mainboard and assembled the PC.
And... It is fixed and running! --> SDG
Most of this surely is not new to the readers of this forum. But I have not found anything about how to extract the .bin file from the fd file.
Maybe, some other tools do this automatically. But flashrom - or at least the implementation I were using - was not able to do so.
I believe, I am not the only person ever facing this problem, so hopefully, this will help anyone else...
In order to help others not having the necessary files, I also attach the now running Insyde BIOS 1.40 .bin file for the Toshiba Satellite C50-A-1M0 ready for flashing.