Re: [flashrom] [PATCH] 4 byte address mode for Macronix MX25L25735F

[Tim Chick]

Hi David,

There was a mistake in the logic, which I have corrected.

I was also asked by someone else on the list if it worked with the MX25L25635F, which is 32Mbytes, but uses 3-byte addressing by default.

So I made the attached changes, which switch the chip to 4-byte mode. It also has some dedicated 4-byte commands, and a BAR register, but it seemed easiest to just use what I had tested for the MX25L25735F. I can’t actually test the MX25L25635F though, as I don’t have one.

Thanks,
Tim

From: David Hendricks [mailto:[e-mail]]
Sent: 04 April 2016 23:21
To: Tim Chick
Cc: [e-mail]
Subject: Re: [flashrom] [PATCH] 4 byte address mode for Macronix MX25L25735F

On Thu, Mar 31, 2016 at 8:21 AM, Tim Chick <[e-mail]> wrote:
Hi List,

Flashrom would not detect this chip. When the definition was added, everything failed as the chip only supports 4 byte address operation.

Interesting - I didn't know such chips existed. The ones I've used have backwards-compatible commands that support 3-byte addresses. FYI - Some other high-capacity chips have 4-byte address enable bit in a config register that will make the usual read/write/erase instructions accept 4 byte addresses. And yet other large chips have alternative instructions that function the same but only accept a 4-byte address.

The attached patch adds 4 byte address support for 4 byte only chips, as determined by the JEDEC flash parameter table, and support for this chip specifically.

I’ve only allowed it to work with the SPI_CONTROLLER_FT2232 controller, as that is the only one I have to test.

I’ve also only ported spi_block_erase_20 – the other block erase functions will fail.

Please let me know what you think!

Good stuff! FWIW, I have a work-in-progress patch on chromium.orghttp://chromium.org (https://chromium-review.googlesource.com/#/c/323359/) for the other types of high-capacity flash chips. I've tested on a Spansion S25FS256 using linux_spi and ft2232. It needs a lot of clean-up, but might be of help. Most of the changes were to convert read/write/erase functions to use allocated buffers whose length depends on whether we're using a 3- or 4-byte address.

I'll borrow some ideas from your patch as well to support the "4-byte address only" chips.

[PATCH] 4 byte address mode for Macronix MX25L25735F

[Peter Martini]

Hi all,

I'd asked about support for the MX25L25635E earlier on this list [
https://www.flashrom.org/pipermail/flashrom/2015-September/013855.html],
and have confirmed with the patches referenced there that I can read and
flash my chip.  I'll try this patch tonight when I get home and report
back; I'd love to see this support main-lined.

Peter

On Tue, Apr 5, 2016 at 3:18 AM, Tim Chick  wrote:
> Hi David,
>
> There was a mistake in the logic, which I have corrected.
>
> I was also asked by someone else on the list if it worked with the
> MX25L25635F, which is 32Mbytes, but uses 3-byte addressing by default.
>
> So I made the attached changes, which switch the chip to 4-byte mode. It
> also has some dedicated 4-byte commands, and a BAR register, but it seemed
> easiest to just use what I had tested for the MX25L25735F. I can’t actually
> test the MX25L25635F though, as I don’t have one.
>
> Thanks,
> Tim
>
> *From:* David Hendricks [mailto:[e-mail]]
> *Sent:* 04 April 2016 23:21
> *To:* Tim Chick
> *Cc:* [e-mail]
> *Subject:* Re: [flashrom] [PATCH] 4 byte address mode for Macronix
> MX25L25735F
>
> On Thu, Mar 31, 2016 at 8:21 AM, Tim Chick  wrote:
>
> Hi List,
>
> Flashrom would not detect this chip. When the definition was added,
> everything failed as the chip only supports 4 byte address operation.
>
> Interesting - I didn't know such chips existed. The ones I've used have
> backwards-compatible commands that support 3-byte addresses. FYI - Some
> other high-capacity chips have 4-byte address enable bit in a config
> register that will make the usual read/write/erase instructions accept 4
> byte addresses. And yet other large chips have alternative instructions
> that function the same but only accept a 4-byte address.
>
> The attached patch adds 4 byte address support for 4 byte only chips, as
> determined by the JEDEC flash parameter table, and support for this chip
> specifically.
>
> I’ve only allowed it to work with the SPI_CONTROLLER_FT2232 controller, as
> that is the only one I have to test.
>
> I’ve also only ported spi_block_erase_20 – the other block erase functions
> will fail.
>
> Please let me know what you think!
>
> Good stuff! FWIW, I have a work-in-progress patch on chromium.org (
> https://chromium-review.googlesource.com/#/c/323359/) for the other types
> of high-capacity flash chips. I've tested on a Spansion S25FS256 using
> linux_spi and ft2232. It needs a lot of clean-up, but might be of help.
> Most of the changes were to convert read/write/erase functions to use
> allocated buffers whose length depends on whether we're using a 3- or
> 4-byte address.
>
> I'll borrow some ideas from your patch as well to support the "4-byte
> address only" chips.
>
> David Hendricks (dhendrix)
> Systems Software Engineer, Google Inc.
>
> ************* Email Confidentiality Notice ********************
> The information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or otherwise
> exempt from disclosure under applicable laws. It is intended to be
> conveyed only to the designated recipient(s). Any use, dissemination,
> distribution, printing, retaining or copying of this e-mail (including its
> attachments) by unintended recipient(s) is strictly prohibited and may
> be unlawful. If you are not an intended recipient of this e-mail, or believe
> that you have received this e-mail in error, please notify the sender
> immediately (by replying to this e-mail), delete any and all copies of
> this e-mail (including any attachments) from your system, and do not
> disclose the content of this e-mail to any other person. Thank you!
>
> flashrom mailing list
> [e-mail]
> https://www.flashrom.org/mailman/listinfo/flashrom