Patchwork add Numonyx/Micron N25Q128

login
register
about
Submitter Frederic Temporelli
Date 2012-06-09 12:51:15
Message ID <OF36EFBD57.A02DC692-ONC1257A18.00469C76-C1257A18.00469C7C@bull.net>
Download mbox | patch
Permalink /patch/3652/
State Superseded
Headers show

Comments

Frederic Temporelli - 2012-06-09 12:51:15
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...

=================================================================================
Stefan Tauner - 2012-07-06 05:14:15
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/
Frederic Temporelli - 2012-07-11 14:10:49
Hello Stefan,


Thanks for the comments about N25Q128... (my patch was based on N25Q64)
I'll try to have a look to the layout feature (but currently I'm very 
busy).

the main idea is to unlock the regions from the ME
Document with datails about ME messages for X79/C600 are Intel 
Restricted... :-(
But seems that ME messages (HMRFPO and others) used in Maho Bay and Chief 
River platform are the same,
and "BIOS Writers Guide" for these systems (document 490124) is only 
"Intel Confidential" (and HMRFPO is described in this document...)
I hope that Intel will soon set all these documents available to 
everybody...

note: there are lot of work to do... first, there's only one IOCTL 
developed in mei driver (mei driver may be the best way to interact with 
ME...)



Other topic (may be more related to layout feature): currently, when using 
flashrom for BIOS upgrade, Serial Numbers and some other information in 
DMI are overwritten...
(seen on Supermicro motherboards)
I don't have details, but it may be nice to investigate this issue...


Best regards

--
Fred









De :    Stefan Tauner <stefan.tauner@student.tuwien.ac.at>
A :     frederic.temporelli@bull.net
Cc :    flashrom@flashrom.org
Date :  07/06/2012 08:02 AM
Objet : Re: [flashrom] add Numonyx/Micron N25Q128



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/
Stefan Tauner - 2012-07-16 21:26:48
On Wed, 11 Jul 2012 16:10:49 +0200
frederic.temporelli@bull.net wrote:

Hello Frederic,

> the main idea is to unlock the regions from the ME
> Document with datails about ME messages for X79/C600 are Intel 
> Restricted... :-(

that is/was our main idea too, but since we could not obtain the needed
docs and my REing skills are not as good as needed there was little
progress in that direction. i have documented most of what i could find
out in our documentation, see
http://flashrom.org/trac/flashrom/browser/trunk/Documentation/mysteries_intel.txt#L17
if you can spot any errors or can provide more detail i am happy to
refine (and use) it.

> But seems that ME messages (HMRFPO and others) used in Maho Bay and Chief 
> River platform are the same,
> and "BIOS Writers Guide" for these systems (document 490124) is only 
> "Intel Confidential" (and HMRFPO is described in this document...)
> I hope that Intel will soon set all these documents available to 
> everybody...

hope does not really help... :) do you have any clear indications that
they might open them up?

> note: there are lot of work to do... first, there's only one IOCTL 
> developed in mei driver (mei driver may be the best way to interact with 
> ME...)

i have an almost complete (but unpublished) user-space reimplementation
of the parts of the linux kernel MEI driver that is needed to send the
HMRFPO message from flashrom... if i would know the GUIDs and payloads
to send (and receive on success), there could be ME unlocking support
in a matter of days i think.

> Other topic (may be more related to layout feature): currently, when using 
> flashrom for BIOS upgrade, Serial Numbers and some other information in 
> DMI are overwritten...
> (seen on Supermicro motherboards)
> I don't have details, but it may be nice to investigate this issue...

yes this happens sometimes but flashrom is not the right place to fix
it. flashrom has the goal to read and write images to flash chips. if
the images are not suited for the system the flash chip is used
afterwards then it is per definition not our problem.
one could of course use (lib)flashrom as a backend and create something
that downloads and prepares correct images for all possible systems...
but the person implementing this is not in sight yet ;)

so the most realistic approach for such problems for now is that you
prepare such images by hand or some customized tools/binary diffs,
sorry that there is nothing better than that yet.
Stefan Tauner - 2012-10-15 05:56:12
On Fri, 6 Jul 2012 07:14:15 +0200
Stefan Tauner <stefan.tauner@student.tuwien.ac.at> wrote:

> On Sat, 9 Jun 2012 14:51:15 +0200
> frederic.temporelli@bull.net wrote:
> 
> > 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...
> > […]

> 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.

A patch exists now that adds this functionality, but it is not merged
yet.

> 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).

I missed a bit in the old datasheet (rev. 7 from may 2011) previously:
"subsector erase (SSE) instruction (only available on the 8 boot
sectors at the bottom or top addressable area of a device with a
dedicated part number)" (p. 24). We still don't know what would happen
exactly, but certainly not what we would like to.

And there is a new datasheet (rev. L from June 12 [1]) that does specify
uniform layouts only, but all of them actually *do* include 4 kB
subsectors. Also there is a uniform version with 1.8V VCC now[2].

So we have different options, besides asking micron how we could
differentiate them or get innovative and check available opcodes…:
- disable the 4 kB erasers on all chips to avoid any scary messages
  (down side: 64 kB minimum erase resolution instead of 4 kB;
  advantage: we could merge all three 3V versions into one).
- enable (some of) them and hope no user gets a stroke :)

My current updated (but unpublished) patch disables the 4kB erasers
completely, but keeps all 3 distinct 3V versions as separate entries.

> […]
> regarding the ME: […]

Do you have any news regarding this Frederic?

[1]: http://www.micron.com/~/media/Documents/Products/Data%20Sheet/NOR%20Flash/Serial%20NOR/N25Q/n25q_128mb_3v_65nm.pdf
[2]: http://www.micron.com/~/media/Documents/Products/Data%20Sheet/NOR%20Flash/Serial%20NOR/N25Q/n25q_128mb_1_8v_65nm.pdf

Patch

=================================================================================
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