All of lore.kernel.org
 help / color / mirror / Atom feed
* NAND dump questions
@ 2016-02-18  8:22 Gary Thomas
  2016-02-18  9:27 ` Richard Weinberger
  0 siblings, 1 reply; 4+ messages in thread
From: Gary Thomas @ 2016-02-18  8:22 UTC (permalink / raw)
  To: linux-mtd

I'm trying to use 'nanddump' to help me duplicate a NAND device.
The idea is to provide a production lab with raw dumps, including
OOB data for every page.  They have a programming machine which can
take these dumps and program the device.  This process is interesting
because we need to make thousands of identical devices and programming
the NAND manually takes a lot of time & manpower.

My target hardware is a Freescale/NXP i.MX6 which uses the gpmi-nand
driver in the Linux kernel.  I have a device layout like this:
   0x000000000000-0x000000780000 : "U-Boot"
   0x000000780000-0x000000800000 : "U-Boot env"
   0x000000800000-0x000004800000 : "Linux kernel"
   0x000004800000-0x000080000000 : "File system"

I generated a hex dump for each partition using
   $ nanddump -c -o -f out.mtdX /dev/mtdX
These files were then sent to the programming lab for duplication.

The results are mixed.  The board boots fine from NAND, so the
first partition was copied as expected.  None of the other
partitions are working, neither in U-Boot nor Linux.  However,
when I look at them using nand dump tools, they contain the
data I provided, i.e. what was in my master device.  I'm truly
baffled as bits should be bits I would think.

Here are more details from mtd1.  My original dump contained
   0x00000000: 55 a8 dd 0f 62 61 75 64 72 61 74 65 3d 31 31 35  |U...baudrate=115|
   0x00000010: 32 30 30 00 62 6f 6f 74 63 6d 64 3d 72 75 6e 20  |200.bootcmd=run |
   0x00000020: 6e 61 6e 64 62 6f 6f 74 3b 00 62 6f 6f 74 64 65  |nandboot;.bootde|
       ...
   0x00000ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
     OOB Data: ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
     OOB Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
     OOB Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
     OOB Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
     OOB Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
     OOB Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
     OOB Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
     OOB Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
     OOB Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
     OOB Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
     OOB Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
     OOB Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
     OOB Data: 9b af dc 75 5f 24 d8 95 ba 51 16 e5 f3 5d 8d a8  |...u_$...Q...]..|
     OOB Data: 37 66 08 44 f1 63 ac 5d e8 49 00 00 00 00 00 00  |7f.D.c.].I......|
This all looks good and matches what I get from U-Boot nand dump
    > nand dump 0x780000
    Page 00780000 dump:
	55 a8 dd 0f 62 61 75 64  72 61 74 65 3d 31 31 35
	32 30 30 00 62 6f 6f 74  63 6d 64 3d 72 75 6e 20
	6e 61 6e 64 62 6f 6f 74  3b 00 62 6f 6f 74 64 65
	6c 61 79 3d 35 00 62 6f  6f 74 6d 6d 63 3d 73 65
             ...
	00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
   OOB:
	ff 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	00 00 00 00 00 00 00 00
	9b af dc 75 5f 24 d8 95
	ba 51 16 e5 f3 5d 8d a8
	37 66 08 44 f1 63 ac 5d
	e8 49 00 00 00 00 00 00
I also get the same dump running nanddump on Linux reading the duplicated
device - 100% identical.  But I get errors when reading the device :-(
Note that none of these issues are related to bad block handling (as there
were none in the blocks I'm talking about here), but I think I know how to
handle that if we can just get the basic duplication process working.

Any ideas what's going on here?  What else can I look at to diagnose the issue?

Note: I've actually done this process on another system which is
TI/OMAP Davinci based.  On that device (a different NAND chip and
a different production lab), the duplication worked perfectly.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

^ permalink raw reply	[flat|nested] 4+ messages in thread
* Re: NAND dump questions
  2016-02-18  8:22 NAND dump questions Gary Thomas
@ 2016-02-18  9:27 ` Richard Weinberger
  2016-02-18 11:45   ` Gary Thomas
  0 siblings, 1 reply; 4+ messages in thread
From: Richard Weinberger @ 2016-02-18  9:27 UTC (permalink / raw)
  To: Gary Thomas; +Cc: linux-mtd

Hi!

On Thu, Feb 18, 2016 at 9:22 AM, Gary Thomas <gary@mlbassoc.com> wrote:
> I'm trying to use 'nanddump' to help me duplicate a NAND device.
> The idea is to provide a production lab with raw dumps, including
> OOB data for every page.  They have a programming machine which can
> take these dumps and program the device.  This process is interesting
> because we need to make thousands of identical devices and programming
> the NAND manually takes a lot of time & manpower.

[...]

> Any ideas what's going on here?  What else can I look at to diagnose the
> issue?
>
> Note: I've actually done this process on another system which is
> TI/OMAP Davinci based.  On that device (a different NAND chip and
> a different production lab), the duplication worked perfectly.

I read your mail and the first thing that alarmed me was, why OOB?
Can you please retry without OOB and which read errors do you get?
I bet uncorrectable ECC errors...

-- 
Thanks,
//richard

^ permalink raw reply	[flat|nested] 4+ messages in thread
* Re: NAND dump questions
  2016-02-18  9:27 ` Richard Weinberger
@ 2016-02-18 11:45   ` Gary Thomas
  2016-02-18 15:24     ` Han Xu
  0 siblings, 1 reply; 4+ messages in thread
From: Gary Thomas @ 2016-02-18 11:45 UTC (permalink / raw)
  To: Richard Weinberger; +Cc: linux-mtd

On 2016-02-18 10:27, Richard Weinberger wrote:
> Hi!
>
> On Thu, Feb 18, 2016 at 9:22 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>> I'm trying to use 'nanddump' to help me duplicate a NAND device.
>> The idea is to provide a production lab with raw dumps, including
>> OOB data for every page.  They have a programming machine which can
>> take these dumps and program the device.  This process is interesting
>> because we need to make thousands of identical devices and programming
>> the NAND manually takes a lot of time & manpower.
>
> [...]
>
>> Any ideas what's going on here?  What else can I look at to diagnose the
>> issue?
>>
>> Note: I've actually done this process on another system which is
>> TI/OMAP Davinci based.  On that device (a different NAND chip and
>> a different production lab), the duplication worked perfectly.
>
> I read your mail and the first thing that alarmed me was, why OOB?
> Can you please retry without OOB and which read errors do you get?
> I bet uncorrectable ECC errors...
>

The reason for the OOB is that the production lab doesn't have the
ability to generate that info itself - they only know how to push
raw bits (all of them) into the device.  Maybe there are better ways
to mass duplicate NAND devices - does anyone know?

I think that the driver or device is not reporting the correct OOB data.
If I look at another i.MX6 board I have which is fitted with a different
NAND device, the OOB is vastly different.  Using U-Boot to dump some OOB

On the failing board with this NAND device:
   nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x48
   nand: Micron MT29F16G08ABACAWP
   nand: 2048MiB, SLC, page size: 4096, OOB size: 224

Page 00780000 dump:
OOB:
         ff 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00
         9b af dc 75 5f 24 d8 95
         ba 51 16 e5 f3 5d 8d a8
         37 66 08 44 f1 63 ac 5d
         e8 49 00 00 00 00 00 00

On the other board with this NAND device
   nand: device found, Manufacturer ID: 0x01, Chip ID: 0xdc
   nand: AMD/Spansion S34ML04G2
   nand: 512MiB, SLC, page size: 2048, OOB size: 128

Page 003e0000 dump:
OOB:
         ff 5b 4f 1b de 98 99 18
         8c 0e 59 99 5d 0f db 18
         19 cb 10 53 50 50 cb 95
         d5 51 10 4b 9a 59 8f d4
         91 90 0c 0d c8 d8 9b db
         dc 1b 5b 99 18 5b 98 db
         5a 0f 0c 88 5d 1a 59 d9
         5b 4f 1b de 98 99 58 8c
         ce 9b 99 19 88 5d 1a 59
         d9 5b 4f 1b de 98 99 98
         8c ce 9b 99 19 88 5d 1a
         59 d9 5b 4f 1b de 98 99
         d8 4c 07 03 98 ab 17 1c
         cc 1e fa 21 6f 43 d4 3b
         bc 8d 56 0b 20 77 0d de
         09 1a 2c ef 7b 82 a8 00

Different NAND devices, same kernel rev & SOC (i.MX6).  Look how
different - how many non-zero bits are in the AMD device.  Is
this significant at all?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

^ permalink raw reply	[flat|nested] 4+ messages in thread
* Re: NAND dump questions
  2016-02-18 11:45   ` Gary Thomas
@ 2016-02-18 15:24     ` Han Xu
  0 siblings, 0 replies; 4+ messages in thread
From: Han Xu @ 2016-02-18 15:24 UTC (permalink / raw)
  To: Gary Thomas; +Cc: Richard Weinberger, linux-mtd

On Thu, Feb 18, 2016 at 5:45 AM, Gary Thomas <gary@mlbassoc.com> wrote:
> On 2016-02-18 10:27, Richard Weinberger wrote:
>>
>> Hi!
>>
>> On Thu, Feb 18, 2016 at 9:22 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>
>>> I'm trying to use 'nanddump' to help me duplicate a NAND device.
>>> The idea is to provide a production lab with raw dumps, including
>>> OOB data for every page.  They have a programming machine which can
>>> take these dumps and program the device.  This process is interesting
>>> because we need to make thousands of identical devices and programming
>>> the NAND manually takes a lot of time & manpower.
>>
>>
>> [...]
>>
>>> Any ideas what's going on here?  What else can I look at to diagnose the
>>> issue?
>>>
>>> Note: I've actually done this process on another system which is
>>> TI/OMAP Davinci based.  On that device (a different NAND chip and
>>> a different production lab), the duplication worked perfectly.
>>
>>
>> I read your mail and the first thing that alarmed me was, why OOB?
>> Can you please retry without OOB and which read errors do you get?
>> I bet uncorrectable ECC errors...
>>

What kind of error?

>
> The reason for the OOB is that the production lab doesn't have the
> ability to generate that info itself - they only know how to push
> raw bits (all of them) into the device.  Maybe there are better ways
> to mass duplicate NAND devices - does anyone know?
>
> I think that the driver or device is not reporting the correct OOB data.
> If I look at another i.MX6 board I have which is fitted with a different
> NAND device, the OOB is vastly different.  Using U-Boot to dump some OOB
>
> On the failing board with this NAND device:
>   nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x48
>   nand: Micron MT29F16G08ABACAWP
>   nand: 2048MiB, SLC, page size: 4096, OOB size: 224
>
> Page 00780000 dump:
>
> OOB:
>         ff 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         00 00 00 00 00 00 00 00
>         9b af dc 75 5f 24 d8 95
>         ba 51 16 e5 f3 5d 8d a8
>         37 66 08 44 f1 63 ac 5d
>         e8 49 00 00 00 00 00 00
>
> On the other board with this NAND device
>   nand: device found, Manufacturer ID: 0x01, Chip ID: 0xdc
>   nand: AMD/Spansion S34ML04G2
>   nand: 512MiB, SLC, page size: 2048, OOB size: 128
>
> Page 003e0000 dump:
> OOB:
>         ff 5b 4f 1b de 98 99 18
>         8c 0e 59 99 5d 0f db 18
>         19 cb 10 53 50 50 cb 95
>         d5 51 10 4b 9a 59 8f d4
>         91 90 0c 0d c8 d8 9b db
>         dc 1b 5b 99 18 5b 98 db
>         5a 0f 0c 88 5d 1a 59 d9
>         5b 4f 1b de 98 99 58 8c
>         ce 9b 99 19 88 5d 1a 59
>         d9 5b 4f 1b de 98 99 98
>         8c ce 9b 99 19 88 5d 1a
>         59 d9 5b 4f 1b de 98 99
>         d8 4c 07 03 98 ab 17 1c
>         cc 1e fa 21 6f 43 d4 3b
>         bc 8d 56 0b 20 77 0d de
>         09 1a 2c ef 7b 82 a8 00
>
> Different NAND devices, same kernel rev & SOC (i.MX6).  Look how
> different - how many non-zero bits are in the AMD device.  Is
> this significant at all?

I don't quite understand the meaning of this comparison. Why comparing
OOB data in different pages of different NAND chips( 4K+224 vs
2K+128)?

BTW, Freescale/NXP provides mfgtool for manufacturing purpose, please
check if the tool helps.

>
> --
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-02-18 15:24 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-18  8:22 NAND dump questions Gary Thomas
2016-02-18  9:27 ` Richard Weinberger
2016-02-18 11:45   ` Gary Thomas
2016-02-18 15:24     ` Han Xu

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.