[flashrom] MX25U1635E (on OLPC XO-4 B1) with flashrom r1657

[Stefan Tauner]

On Tue, 19 Mar 2013 16:12:43 +1100
James Cameron <quozl at laptop.org> wrote:

> G'day,
> 
> I'm an Open Firmware developer working for One Laptop per Child.
> 
> We have used the MX25U3235E chip in revision B1 of our XO-4 design,
> and I am trying to use flashrom (r1657) with a Bus Pirate to read from
> a chip.
> 
> I see you pushed a patch for this chip in the past few days.  A happy
> coincidence perhaps.
> 
> Is there anything I can do to help you change TEST_UNTESTED to
> something else?
> 
> (Sorry if this is an obvious question, but I have very little
> knowledge of flashrom, having used for the first time yesterday with a
> different chip.  Mostly we program the chip from within Open
> Firmware.)
> 
> I changed TEST_UNTESTED to TEST_OK_PR on my system, and captured the
> attached logs.
> 
> While the identify worked, the read gave errors, and the output file
> contained 0xff only.  We have never intentionally enabled any block
> protection on this chip.
> 

Hello James,

the .tested field is only used for QA and telling the user about it.
Changing it does not influence functionality.

If you are in a hurry skip this paragraph. :)
I am a bit puzzled at the moment regarding the (read) log. If you look
at the detailed output of the contents of the status register at line
132 ff. you see that flashrom (mistakenly) reads 0xFF, which leads to
the assumption that a block protection is enabled (see bottom of page
26 in the datasheet of the chip; that's quite a standard layout of a
SPI flash status register...). It then tries to disable the
"protection" and fails because another bit in the status register - the
WIP bit - remains at 1.

I have no idea why it (always) reads 0xFF from the status register... I
have checked the opcode and it is correct, and there is nothing fancy
about... apart from one thing I just noticed which you could test:
in spi_read_status_register() in spi25_statusreg.c replace 2 with 1 in
the array declaration readarr[2] so that this line becomes 
	unsigned char readarr[1]; /* JEDEC_RDSR_INSIZE=1 but wbsio needs 2 */

wbsio is our driver for a very annoying winbond SPI master and as the
fixme in the function says, this hack should not be in the generic code.
If the macronix chip does not repeat the status register contents when
one reads more than one byte after sending the RDSR (read status
register) opcode (which chips usually do) but 0xFF then we have found
the culprit.

PS: please send further mails to flashrom at flashrom.org - our mailing
list, thanks.
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner