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.