On Tue, 19 Mar 2013 16:12:43 +1100 James Cameron quozl@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@flashrom.org - our mailing list, thanks.
On Tue, 19 Mar 2013 09:15:33 +0100 Stefan Tauner stefan.tauner@student.tuwien.ac.at wrote:
On Tue, 19 Mar 2013 16:12:43 +1100 James Cameron quozl@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. […]
Hi James!
You have never reported back. Have you found the problem?
On Sat, Aug 24, 2013 at 02:24:56PM +0200, Stefan Tauner wrote:
On Tue, 19 Mar 2013 09:15:33 +0100 Stefan Tauner stefan.tauner@student.tuwien.ac.at wrote:
On Tue, 19 Mar 2013 16:12:43 +1100 James Cameron quozl@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. […]
Hi James!
You have never reported back. Have you found the problem?
No, sorry.
There were problems with the two lab-bench level shifters constructed, our existing Open Firmware based programming tools were hindered by the level shifter problems, and we had changed from that 1.8V chip to a 3.3V chip in the next revision of the motherboard.
The task began to take too long, and was abandoned, and the bricked B1 placed in the discard pile.
For brick recovery of our later revision boards for XO-4, we use Open Firmware on an XO-1.5 (x86), and have documented that here:
http://wiki.laptop.org/go/SPI_FLASH_Recovery/XO-4
(Normally the motherboard is self-reflashing, with Open Firmware on the host CPU rewriting the chip via SPI.)
CC: because I've since unsubscribed.