[flashrom] flashrom OPCODES for SPI

David Hendricks dhendrix at google.com
Wed Feb 6 21:28:17 CET 2013


On Wed, Feb 6, 2013 at 4:35 AM, Николай Николаев <evrinoma at gmail.com> wrote:

> Hi Stefan
>
> Sorry but i don't want disprove you, i just have a many free time and i
> want to improve this project. But the dispute burning truth. 8)
> All time from my last mail i'm searching spi flash chips documentation and
> I found about 445 chips different brand and sorted them.
> May be it will be useful for all community. We will made host with
> SPI(Parallel and other) flash chips documentations and add link on wiki
> page.
> for example
> Eon EN25Q64(link to pdf) 8192 SPI ? ? ? ? 2.700 3.600
>
> Studied documentation i regularity see that all chips has a support
> standard OPcodes like this
> WR DATA 0X02
> READ DATA 0X03
> WR DIS 0X04
> READ STATUS 0X05
> WR ENA 0X06
> ...
> exclude 10 Atmel chips from amount 445 and for him we will must write
> special driver
>
> and special OPcodes like a
> Fast Dual read 0x3B
> Auto Address increment 0xAD
> and others - that codes is a different fetches spi flash chips
>
> What does this mean. This mean that a spi controller has a standard
> OPcodes for all flash chips and special OPcodes for each one flash chip.
> But if we will change flash chip on other flash chip with different special
> OPcodes that we will must replace special OPcodes. If we will not do it
> that we can't use special OPcodes, but we can use standard OPcodes.
> So, for more compatibility we will must verify - Does flash chip support
> special OPcodes?. And if chip will support them that we will use them, but
> if chip will not support them that we will use a standard OPcodes.
> for example:
> MX25L6405
> The function write chip used standard OPcodes flash chip called function
> spi_chip_write_256
> SST25VF016B
> The function write chip used fetches OPcodes flash chip called function
> spi_aai_write
> If we can't change OPcodes in registers our SPI controller that we will
> not write data to chip if we replace them.
> But we will make a program check supporting OPcodes and switch a function
> from spi_aai_write on spi_chip_write_256
> After that we can easy write to flash
> or fast - our SPI controller has supporting fetches OPcodes
> or slow - our SPI controller hasn't supporting fetches OPcodes
>

We usually use the .feature_bits member to distinguish these capabilities.
The feature you describe uses "FEATURE_ADDR_AAA" and corresponds to
spi_aai_write().


> Also i want to suggest exclude from struct flashchip {} parameters
> voltage, name and add array of struct like a chipdata.
> The struct chipdata contains information about all possible chip names and
> various parameters
> Because looked chips documents i see chips that have a one model_id but
> have a various chips name, various voltage and various capacity
> for example
> MX25U6435F and MX25L6439E

MX25L12805D and MX25L25835E
>

You're correct about the naming of similar chips. We introduced a schema to
work with this last year to try and deal with the naming:
http://www.flashrom.org/pipermail/flashrom/2012-July/009598.html

I think adding an array of structs struct inside of the flashchip struct
would be more effort than it is worth. It would make working with the
flashchip data structure more complicated, and we'd need to add nested
loops whenever we iterate over the flashchip array. It would also require
flexible arrays which may cause problems with certain compilers.

The MX25L25835E actually should look the same as MX25L12805D from a
software perspective. The difference is that MX25L25835E is stacked (two
128Mbit flash memories). Each bank is selected by a different chip-select
line (referred to as CS#1 and CS#2 in the datasheet).

HTH!

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.flashrom.org/pipermail/flashrom/attachments/20130206/30e70621/attachment.html>


More information about the flashrom mailing list