Flashing a Winbond W25Q64FV using a RaspberrPI model B

[Emanuele Santoro]

Hello everybody!

I am trying to revive a Dell XPS15 9530 laptop whose BIOS was 
corrupted during a BIOS update (this seems to be a fairly 
common problem with this laptop) and I am having some troubles.

The BIOS chip is a Winbond flash: 25Q64FVS1Q (this is what is written 
on the chip, assuming I read that correctly).

I am using a RaspberryPI model B (one of the first units issued), its
SPI interface and a pair of test clips (the chip is a SOIC8 unit,
soldered on the mother board).

The operating system is Raspbian GNU/Linux (freshly installed last
week). uname -a from PI is:

Linux raspberrypi 4.1.19+ #853 Wed Mar 9 18:04:48 GMT 2016 armv6l GNU/Linux

The spi modules (spidev and spi_bcm2708) seems to be built into the
kernel, as the devices appear in /dev but modprobing the kernel modules
result in errors.

I built flashrom from sources (checked out from the svn trunk):

flashrom v0.9.9-r1954 on Linux 4.1.19+ (armv6l)

So this is the environment.

Please note that before attempting anything, I disconnected the CMOS 
battery as well as the main battery. Power supply is also disconnected,
and has been disconnected for the last three weeks.

First things first, when I try to probe the chip, flashrom cannot
manage to probe the chip at all, and i get this message:

Calibrating delay loop... delay loop is unreliable, trying to continue OK.

Today I tried again, and finally got this message:

root@raspberrypi:~# flashrom -p linux_spi:dev=/dev/spidev0.0
flashrom v0.9.9-r1954 on Linux 4.1.19+ (armv6l)
flashrom is free software, get the source code at https://flashrom.org

Calibrating delay loop... delay loop is unreliable, trying to continue OK.
Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI) on linux_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 [e-mail] if any of the above operations
work correctly for you with this flash chip. Please include the flashrom log
file for all operations you tested (see the man page for details), and mention
which mainboard or programmer you tested in the subject line.
Thanks for your help!
No operations were specified.
root@raspberrypi:~#

Now...

1. I do not trust this RaspberryPI completely (I bought it second hand, and it
has always worked somehow weirdly). I will try with another RaspberryPI as soon
as I can find someone to lend me one.

2. Is this chip even supported? Can support be added? If you suggest me what
sources to look at I might try and add support for it myself, otherwise I'd be
happy to help someone add support this chip.

3. does the "unknown SPI chip (RDID)" mean that the chip is damaged and needs 
to be replaced?

4. Shoud I get a Bus Pirate? Is it so much better than Raspberry PI at this
sort of stuff?

5. Any hints / suggestions in general?

Thanks in advance,

[Stefan Tauner]

On Tue, 22 Mar 2016 01:08:41 +0100
Emanuele Santoro  wrote:
> I do not trust this RaspberryPI completely (I bought it second hand, and it
>
> has always worked somehow weirdly). I will try with another RaspberryPI as soon
> as I can find someone to lend me one.

Good idea because the described behavior is not normal.
> Is this chip even supported? Can support be added? If you suggest me what
>
> sources to look at I might try and add support for it myself, otherwise I'd be
> happy to help someone add support this chip.

Should be working fine.
> does the "unknown SPI chip (RDID)" mean that the chip is damaged and needs
>
> to be replaced?

More likely that the communication between the chip and flashrom does
not work as it should. This can have various reasons, see
https://www.flashrom.org/Common_problems
> Shoud I get a Bus Pirate? Is it so much better than Raspberry PI at this
>
> sort of stuff?

It is worse - very slow - without any advantages.
> Any hints / suggestions in general?

Providing verbose log files (generated with -o logfilename) might help
us diagnosing the issue.