On Sat, 9 Jun 2012 14:51:15 +0200

frederic.temporelli@bull.net wrote:

> Hello

> 

> 

> Numonyx/Micron N25Q128 is used on new X9 motherboards from Supermicro
(X9DRT, ...)

> 

> Specs are availbale on Micron WWW site:

> 
http://www.micron.com/~/media/Documents/Products/Data%20Sheet/NOR%20Flash/Serial%20NOR/N25Q/N25Q_128_3_Volt_with_boot_sector.pdf

> 

> Following patch add this chip to flashrom. Probe is OK.

> Due to Manageability Engine, some work is required before being able
to test READ/ERASE/WRITE...

> 

> =================================================================================

> Signed-off-by: Frederic Temporelli <frederic.temporelli@bull.net>

> 

> diff -urN flashrom-0.9.5.2-r1540/flashchips.c flashrom-0.9.5.2-r1540-n25q128/flashchips.c

> --- flashrom-0.9.5.2-r1540/flashchips.c 2012-05-20 23:32:32.000000000
+0000

> +++ flashrom-0.9.5.2-r1540-n25q128/flashchips.c 2012-06-09 14:41:07.064141076
+0000

> @@ -5453,6 +5453,37 @@

>         },

> 

>         {

> +               .vendor  
      = "Numonyx",

> +               .name    
      = "N25Q128",

> +               .bustype  
     = BUS_SPI,

> +               .manufacture_id
= ST_ID,

> +               .model_id  
    = ST_N25Q128,

> +               .total_size  
  = 16384,

> +               .page_size  
   = 256,

> +               .feature_bits  
= FEATURE_WRSR_WREN | FEATURE_OTP,

> +               .tested  
      = TEST_OK_PROBE,

> +               .probe    
     = probe_spi_rdid,

> +               .probe_timing  
= TIMING_ZERO,

> +               .block_erasers
 =

> +               {

> +                    
  {

> +                    
          .eraseblocks = { {4 * 1024, 4096 } },

> +                    
          .block_erase = spi_block_erase_20,

> +                    
  }, {

> +                    
          .eraseblocks = { {64 * 1024, 256} },

> +                    
          .block_erase = spi_block_erase_d8,

> +                    
  }, {

> +                    
          .eraseblocks = { {16 * 1024 * 1024,
1} },

> +                    
          .block_erase = spi_block_erase_c7,

> +                    
  }

> +               },

> +               .unlock  
      = spi_disable_blockprotect,

> +               .write    
     = spi_chip_write_256,

> +               .read    
      = spi_chip_read,

> +       },

> +

> +

> +       {

>                 .vendor  
      = "PMC",

>                 .name  
        = "Pm25LV010",

>                 .bustype  
     = BUS_SPI,

> diff -urN flashrom-0.9.5.2-r1540/flashchips.h flashrom-0.9.5.2-r1540-n25q128/flashchips.h

> --- flashrom-0.9.5.2-r1540/flashchips.h 2012-05-14 01:51:46.000000000
+0000

> +++ flashrom-0.9.5.2-r1540-n25q128/flashchips.h 2012-06-08 20:46:47.225385676
+0000

> @@ -587,6 +587,7 @@

>  #define ST_M29W040B            0xE3

>  #define ST_M29W512B            0x27

>  #define ST_N25Q064            
0xBA17

> +#define ST_N25Q128             0xBA18
 /* also Numonyx N25Q128 */

> 

>  #define SYNCMOS_MVC_ID         0x40  
 /* SyncMOS (SM) and Mosel Vitelic Corporation (MVC) */

>  #define MVC_V29C51000T         0x00

> =================================================================================

hello and thanks for your patch!

this chip is a bit complicated and we cant merge the patch as it is.

they have used the same plane RDID for multiple variants of the chip.

some attributes are not important for flashrom and can be ignored, but

some are very important, namely the boot sector layout. quote from p.52:

> The N25Q128 is available in the following architecture versions:

> Bottom version, 64 KB uniform sectors plus 8 bottom boot sectors (each
with 16

> subsectors),

> Top version, 64 KB uniform sectors plus 8 top boot sectors (each with
16 subsectors)

> Uniform version, 64 KB uniform sectors without any boot sectors and
subsectors.

the good news is that this differences can be detected by an extended

RDID command in its 5th byte (1 manufacturer, 2 device, 1 length of the

following extended data, the first EDID byte we want), see table 15.

of this 5th byte we need to look at the first two bits to determine the

architecture, see table 16.

our current infrastructure (probe_spi_rdid_generic) cant handle that,

but should... so we will plan a change, but please dont expect it to

happen too soon.

the bad news is that i am not even sure if the subsector erase commands

work as flashrom expects. flashrom wants to use the same erase opcode

for the hole address space, even for non-uniform layouts. this usually

works fine, but afaics it is not specified in the datasheet what

happens if one uses the subsector erase opcode on a non-subsector *on

devices that actually have subsectors* (the emphasis stems from the

fact that it *is* defined, that the subsector erase command is ignore

by the uniform model: "Any Subsector Erase (SSE) instruction in devices

with uniform architecture (meaning no boot sectors with subsectors) is

rejected without having any effects on the device." (p. 98).

other interesting bits of this chips:

 - bit#5 of the status register "is used in conjunction with the Block

   Protect (BP3, BP2, BP1, BP0) bits to determine if the protected
area

   defined by the Block Protect bits starts from the top or the bottom

   of the memory array"

 - a flag status register that gives more info than the "legacy spi

   status register"

 - a non-volatile configuration register to configure dummy clock

   cycles, output driver strength and other stuff, and a volatile

   register that overrides the nvm settings

the first two points can be somewhat ignored by us, the generic "write
0

to the status register" is good enough to unlock the device.

regarding the ME: are you aware of my layout patches, that enable read,

erase and verify on user-definable address ranges? see the patches from

2011-12-25 at 
http://patchwork.coreboot.org/project/flashrom/list/

-- 

Kind regards/Mit freundlichen Grüßen, Stefan Tauner