On Wed, Feb 6, 2013 at 4:35 AM, Николай Николаев evrinoma@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