[SOLVED] BP 3.5 + Flashrom on Asus Laptops

[ph1ph1l0u]

Hello everybody.

I'm ph1ph1l0u, a new French user and I recently buy a BP v3b ... to recover an Asus Laptop from a bad BIOS flash.
This is an X93SM/K93SM with an Winbond W25Q32BVSSIG SOIC 208-mil SPI EEPROM on it, here is the datasheet:
hwwp://xxx.winbond com tw/NR/rdonlyres/B573ABE4-0DD6-4C10-AA9F-906945FC52B5/0/W25Q32BV.pdf
(to get the real & full URL, replace w by t in hwwp, x by w in xxx, and space by . after winbond & com)

I upgrade the BP v3b to v3.5 / FW to 6.1, so here is the output of "i" command:

Code: Select all

HiZ>i
Bus Pirate v3.5
Firmware v6.1 r1676  Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
http://dangerousprototypes.com

For the connecting, here is what I use
- Pomona 5250 SOIC8-Clip
- independant wires (less 10 cm) with different colors
- USB cable with mini-B connector to power on the BP from my M70VN laptop ... and allow the I/O.

Here is how the connections are done (cf page 6 of W25Q32B's datasheet)

Code: Select all

On BP .......... On SPI (W25Q32B)
CS     <=======> CS (1)
GND    <=======> GND (4)
CLK    <=======> CLK  (6)
3V3    <=======> VCC (8)
MOSI   <=======> DO (IO1)
MISO   <=======> DI (IO0)

I have done a Selt-Test of BP: no errors.

I want to use flashrom to:
- read the content of the chip
- dump this content in a file (2 times)
- edit, if possible, this output file in a Hex editor
- reflash the chip with the new file edited
- try to boot the machine to see if it work.

--> In Windows Se7en 64 bits, can't use flashrom, even if I follow many tutorails found on the web.
Then, I give up this way. Too painfull for no result.

--> So, as I have an Ubuntu 12.04 installation in a VirtualBox, to do the things I want in this OS, with help of minicom and flashrom.
It works partially.

I've tried to follow the topic intitled Pirate Bus and ASUS laptop bios on this forum, but no help, here:
viewtopic.php?f=40&t=4709
So, same SPI chip, and it works: in the facts, we know it's feasible!

The BP is well detected:

Code: Select all

philippe@philippe-VirtualBox:~$ dmesg | tail
[ 5903.389589] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 5903.389643] ftdi_sio 2-2:1.0: device disconnected
[ 5927.696259] usb 2-2: new full-speed USB device number 16 using ohci_hcd
[ 5928.256827] ftdi_sio 2-2:1.0: FTDI USB Serial Device converter detected
[ 5928.256907] usb 2-2: Detected FT232RL
[ 5928.256909] usb 2-2: Number of endpoints 2
[ 5928.256910] usb 2-2: Endpoint 1 MaxPacketSize 64
[ 5928.256911] usb 2-2: Endpoint 2 MaxPacketSize 64
[ 5928.256913] usb 2-2: Setting MaxPacketSize 64
[ 5928.267889] usb 2-2: FTDI USB Serial Device converter now attached to ttyUSB0

The minicom is well set:

Code: Select all

serial port: /dev/ttyUSB0
baud rate: 115200
data/parity/stop/flow control: 8/N/1/N

Yesterday evening, I can see the chip with flashrom:

Code: Select all

sudo flashrom -p buspirate_spi:dev=/dev/ttyUSB0
Found Winbond flash chip "W25Q32" (4096 kB, SPI).
This chip may contain one-time programmable memory. flashrom cannot read
and may never be able to write it, hence it may not be able to completely

but, ... but, if I run this command:

Code: Select all

sudo flashrom -r dump.bin -p buspirate_spi:dev=/dev/ttyUSB0

it displays the same message but with:

Code: Select all

Reading flash ...

and a glowing prompt, but after waiting 30 mns, nothing else happen ...
clone the contents of this chip (see man page for details).

I stop all process because I'm tired and bored.

This morning, new tries.
Now, with same connections / same settings in minicom / same detection, I have this:

Code: Select all

philippe@philippe-VirtualBox:~$ sudo flashrom -p buspirate_spi:dev=/dev/ttyUSB0
[sudo] password for philippe:
flashrom v0.9.6.1-r1648 on Linux 3.2.0-25-generic-pae (i686)
flashrom is free software, get the source code at hxxp://xxx flashrom org

Calibrating delay loop... OK.
Bus Pirate firmware 6.1 and older does not support SPI speeds above 2 MHz. Limiting speed to 2 MHz.
It is recommended to upgrade to firmware 6.2 or newer.
Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI) on buspirate_spi.
===
This flash part has status NOT WORKING for operations: PROBE READ ERASE WRITE
The test status of this chip may have been updated in the latest development
version of flashrom. If you are running the latest development version,
please email a report to flashrom at flashrom org if any of the above operations
work correctly for you with this flash part. Please include the flashrom
output with the additional -V option for all operations you tested (-V, -Vr,
-VE, -Vw), and mention which mainboard or programmer you tested.
Please mention your board in the subject line. Thanks for your help!
No operations were specified.

What's the hell? Why it display:

Code: Select all

Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI) on buspirate_spi.

today? What are the changes between yesterday and now?

EDIT: I forget to specify this point: the mobo is outside the case, no power (no battery, no supply).

If there's somebody who can help me ... 'cause, I'm beginning to loose hope and to be very frustrating...

Thanks for any help.

[ph1ph1l0u]

Okay, read this topic:
viewtopic.php?f=40&t=4157
Almost the same chip ... so I would have to be the same connections.

So I check mine ...
and found my connections are wrong, my mistake, I change them this morning after a wrong movement which disconnect the wire ^^

so, here is the new conections:

Code: Select all

On BP .......... On SPI (W25Q32B)
CS     <=======> CS (1)
GND    <=======> GND (4)
CLK    <=======> CLK  (6)
3V3    <=======> VCC (8)
MOSI   <=======> DI (IO0)
MISO   <=======> DO (IO1)

and if I run flashrom:

Code: Select all

philippe@philippe-VirtualBox:~$ sudo flashrom -p buspirate_spi:dev=/dev/ttyUSB0
[sudo] password for philippe:
flashrom v0.9.6.1-r1648 on Linux 3.2.0-25-generic-pae (i686)
flashrom is free software, get the source code at hxxp://xxx flashrom org

Calibrating delay loop... OK.
Bus Pirate firmware 6.1 and older does not support SPI speeds above 2 MHz. Limiting speed to 2 MHz.
It is recommended to upgrade to firmware 6.2 or newer.
Found Winbond flash chip "W25Q32" (4096 kB, SPI) on buspirate_spi.
No operations were specified.

it detects the chip! Yes!

[ph1ph1l0u]

New edit, new news ^^

The dump is done

I run this command:

Code: Select all

philippe@philippe-VirtualBox:~$ sudo flashrom -VVV -p buspirate_spi:dev=/dev/ttyUSB0 -r dump0.bin

anf after that, the reading is launched and flashrom display that (only an extract):

Code: Select all

buspirate_sendrecv: write 9, read 257 Sending 0x04 0x00 0x04 0x01 0x00 0x03 0x3f 0xff 0x00, receiving 0x01 0x09 0xb0 0x06 0x66 0xba 0xf9 0x0c 0xee 0xeb 0xfe 0xb8 0x60 0x00 0x00 0x80 0x66 0xba 0xf8 0x0c 0xef 0xb2 0xfc 0xb8 0x04 0x00 0x00 0x00 0xef 0xed 0x0d 0x01 0x00 0x00 0xf8 0xef 0xb8 0x40 0x00 0x00 0x80 0x66 0xba 0xf8 0x0c 0xef 0xb2 0xfc 0xb8 0x01 0x90 0xd1 0xfe 0xef 0xb8 0x48 0x00 0x00 0x80 0x66 0xba 0xf8 0x0c 0xef 0xb2 0xfc 0xb8 0x01 0x00 0xd1 0xfe 0xef 0xb8 0x68 0x00 0x00 0x80 0x66 0xba 0xf8 0x0c 0xef 0xb2 0xfc 0xb8 0x01 0x80 0xd1 0xfe 0xef 0xe9 0x2d 0x00 0x00 0x00 0xcc 0xcc 0xcc 0xcc 0xcc 0xcc 0xcc 0xcc 0xcc 0xcc 0xcc 0xcc 0xcc 0xcc 0xe9 0x24 0x00 0x00 0x00 0xcc 0xcc 0xcc 0xcc 0xcc 0xcc 0xcc 0xcc 0xcc 0xcc 0xcc 0xe9 0xbb 0xfe 0xff 0xff 0xe9 0xc6 0xfb 0xff 0xff 0xe9 0x61 0xff 0xff 0xff 0xe9 0xb3 0xfb 0xff 0xff 0xe9 0xd7 0xff 0xff 0xff 0xe9 0xce 0xf9 0xff 0xff 0x00 0x00 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 0x24 0x32 0x69 0x32 0x4e 0x33 0x6f 0x33 0xc3 0x33 0x7a 0x34 0x95 0x35 0xa7 0x35 0xb8 0x35 0xc6 0x35 0xb6 0x36 0x00 0x00 0x44 0x00 0x00 0x19 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xbf 0x50 0x41 0xeb 0x1d 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xc2 0xdd 0xfb 0xff 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x90 0x90 0xe9 0xfb 0xf8 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xfa 0xff
done.
buspirate_sendrecv: write 1, read 0 Sending 0x00
buspirate_sendrecv: write 0, read 4 , receiving 0x42 0x42 0x49 0x4f
buspirate_sendrecv: write 0, read 1 , receiving 0x31
Raw bitbang mode version 1
buspirate_sendrecv: write 1, read 0 Sending 0x0f
Bus Pirate shutdown completed.


After I had recovered the dump0.bin, on another laptop, I open it with Hex Editor; it's the good file:

Code: Select all

....BIOSINFO..P.`. .°.À..........
....úÿ..........âÿ..........àÿ......
áÿ......âÿ....204.............12/1
6/2011.............................
.........................46..........
....K93SM...............B.i.o.s.I.
n.f.o...ÿÿÿÿÿÿÈ...........

Now, need to create another dump to compare with the first and check if theay match each other.

It's great! thanks!

[ph1ph1l0u]

OK

I realise a new dump wuth success and then, I compare the 2 dumps to see if they match each other and assume there's no error in the readings.

They do! So, I suppose there's no error ... the dumps are valid.
That's all for this: one step done!

Now, next: see what is corrupt in, if this is the case, and possibly edit the dump to fix the issue.
After that, try to flash!

Great device and great software!!! Thanks for all.

I'll come back for the next steps, to upgrade the topic, and perhaps, ask help.

[ph1ph1l0u]

Some news of my progress (if I can say that).

OK,

now I want to know what is wrong.

Remember the SPI chip W25Q32BVSSIG is 4 Mo.
The dump file is also 4 Mo and I've saw the BIOS is a 204 version.
I've downloaded the v204 BIOS from Asus webite for the K93SM, which is 2,12 Mo.

Now, open the v204 BIOS and dump.bin with HxD Editor, and search for a text string enough significant and with only little repetition in them;
I choose this text string: K93SM.

In all these 2 files there are only 3 repetitions of the K93SM string.
The first is enough for my goal: determine where the BIOS begins in the EEPROM.

So:
- in the dump file (dump.bin), the first occurence "K93SM" is at offset 239370
- in the BIOS file (K93SM.204), it is at offset 39370
Then, by simply subtraction:
239370 - 39370 = 20 0000
I can deduce that BIOS begins at offset 20 0000 in the dump of EEPROM.

That's it, see the following screenshots, it's obvious that's right:
- in the K93SM.204 file:
hxxp://img3 uplood fr/free/7ku9_334.jpg
- in the dump.bin file:
hxxp://img3 uplood fr/free/9med_335.jpg

Next, in HxD Editor, I copy all content from offset 0x200000 to offset 400000 (end of the dump), which I paste in a new blank window in HxD, and backup the result into a new file I intitled MainBIOS.bin.

But, here is the heck! This file is 2 Mo only (so: the sizes didn't match!) and has rather content compare to the one of downloaded BIOS v204.
Also, I repet the same operation 3 times to be sure I don't a mistake the 2 first times: and this is not!
And, as a result, I can't do as Sir Robin in the G74Sx' topic (see above): simply copy the content of the v204 BIOS to create a new file which could be used to flash the EEPROM, 'cause the size of the new output file will exceed the size of the EEPROM flash itself! The size of the output won't fit with the size of the EEPROM.

I'm locked here!

EDIT: Also, I must mention that FITC 7.1.20.1119 identifies very well the dump with 3 (4) regions
- FD region, ME region, OEM region (as part of FD region) and BIOS region
- there are no GbE region nor PDR region

If someone can provide some help, he's/she's welcome!

[ph1ph1l0u]

Hello everybody

Just to tell you, I've succeeded with the reflash: the laptop works again!!!!

How did I make that?
Simply as mentionned in the Sir Robin's G74Sx' topic.

In a brief summary way:
You remembered, I've extracted the MainBIOS from the SPI's dump, and this file was smaller in size than the binary BIOS flash file from Asus website: 2 MB for the dump file versus 2,12 MB for the flash file.
Then, after a close look, I've saw & understood that the supplementary 0,12 MB in the flash file was caused by the EC Firmware (ENE KB930QF).

This one is located at the end of the binary flas BIOS file (between offset 200000 and offset 220000):


Here is a picture of the EC on the mobo:

And an extract of the diagramms schems of the mobo (Compal PBL80):


So, I deduced that: if the EC FW was not present in the SPI's dump file, it's only because this same EC FW is not written in the SPI during the BIOS flashing process ... but, obviously, in the EC itself.
And so, if I want to reworking the X93SM by rewriting the SPI with a clean image, I have to forget this EC FW from this part by cutting this area in the binary flash BIOS file to rebuild the image to flash in the SPI ...
Simply, not?

Then, here is what I did:
- I have one dump file from the SPI with a size of 4 MB and a length of 400000 in hex;
- I have one file for the MainBIOS v204 which it's an extract from the dump file: its size is 2 MB and its length is 200000 in hex;
- I have one binary flash BIOS v204 from Asus website which have a size of 2,12 MB and a length of 220000 in hex.

-- With HxD Editor, I've cut from the dump file to only keep the area from offset 0 to offset 1FFFFF (remember: the MainBIOS in this image begins at offset 200000), opened a new file and pasted insert the content in it.
First:
Then:


-- Always with HxD, I determined where the MainBIOS (without the EC FW's area) begins in the BIOS file (K93SM.204): at 200000 too, of course! So, I cut the binary file (aka K93SM.204) to only keep the zone beginning at offset 0 and finishing at offset 1FFFFF:


-- Finally, I pasted insert this second area into the previous new opened file, after offset 1FFFFF:


-- Then, I've backup the new file with the name flash.bin: its size is 4 MB and its length is 400000 of course.
At this step, I have an image ready to flash.

After that, I've reconnected the BP to the SPI, the BP to my laptop, run Ubuntu in Virtualbox and launched minicom ...
So, I've executed the writing:

Code: Select all

sudo flashrom -VVV -p buspirate_spi:dev=/dev/ttyUSB0 -w flash.bin

After some minutes, the writing finished without errors

Then, I checked the SPI against the file:

Code: Select all

sudo flashrom -VVV -p buspirate_spi:dev=/dev/ttyUSB0 -v flash.bin

No errors too:


When finished, time to test the result.
I've reassemblied the laptop, quickly and with the minimum of hardware (CPU, ventirad, 1 RAM stick, screen, keyboard, power circuit), the mini to allow the boot:


Then, I plugged the power adapter and powered on the laptop..
.. in the beginning I saw nothing in the screen, only the power LED on ... then, after a brief instant, the power LED off, then On again, and here I saw the Asus logo ... YEEEEEES!

And now, the laptop is fully working, reviving, here is a BIOS Setup picture:


That's all folks!!


Thanks for reading ...

[biosflasher]

Congratulations! I'm always happy when someone can use flashrom to revive a machine.

[ph1ph1l0u]

Congratulations! I'm always happy when someone can use flashrom to revive a machine.

You have no idea how I'm happy too ;-)

yes biosflasher, it's a very GREAT soft, very usefull and very efficient ^^

and also for BP: a cheap device, but how is usefull and efficient, a real GREAT device.

Thanks a lot all of you who create and develop these tools...
I won't have enough words to say: THANKS!!!

[ph1ph1l0u]

re,

To finish this topic, you can read the full process story here (sorry, in french tongue!):
Récupérer 1 X93SM après 1 mauvais flashage du BIOS


Bye ^^

[ph1ph1l0u]

Hello,

So, yesterday, I repeated the same thing with an Asus R900VM (equal to: K95VM):
COMPLETE SUCCESS!!

The laptop is now reviving & fully functional!!

Again, full story here (in French too):

Récupération du BIOS d'1 R900VM (K95VM)

Very powerfull and usefull device + software!!! Thanks!!!

[ph1ph1l0u]

Hello


Today, I saved one more K93SM sent to me by doublle14, member of La communauté des utilisateurs de portables Asus.

I met some problems: on first try, the SOIC 8 pin clip wasn't well connected to SPI chip; however, the flash was proceeded but, it fills the chip with 0x00 and 0xff. It took more of one hour to do that.
After that, of course, the flash failed and the chip was at unknown state.
I don't understand why the flash was realized with bad connection? Normally, in this case, the chip isn't identified.

So, I checked the connections, and I observe what is wrong: fix it, and retried again.
This time, I could see the writing was good, and, the flash was OK (took 15 to five minutes).

Summary re-assemblied the laptop, with only few essential components as in the primary case, ...
and booted it: then, it works!

Again, full success.

I upgraded the BIOS to the latest version 208: done without problem.

Now, need to make some more checks to see if everything is OK.