how to support 4096+224 page size with plat_nand ?

how to support 4096+224 page size with plat_nand ?

[Brian Foster]

Timothy,

 We have also used 4K + 224 NAND (not sure if the
 same part or not) with ‘plat_nand’ (and also with
 our own driver which uses our chip's ECC engine),
 in a v2.6.36-based Linux kernel.  (The kernel's
 version _may_ be important, since I _think_ some
 later kernels directly support 224 (and 218 and
 maybe 256) OOB sizes;  and/or correctly detecting
 the eraseblock size.)

 We didn't bother using the full 224-byts of OOB,
 but instaed are treating the device as having
 only 128-bytes of OOB.  Works fine, albeit we
 did have to add the part to the nand_flash_ids[]
 table since the eraseblock size wasn't correctly
 detected.

cheers!
	-blf-

-- 
Brian Foster
Principal MTS, Software        |  La Ciotat, France
Maxim Integrated Products      |  Web:  http://www.maxim-ic.com/

Re: how to support 4096+224 page size with plat_nand ?

[Brian Norris]

On Fri, Mar 16, 2012 at 7:05 AM, Brian Foster <brian.foster@maxim-ic.com> wrote:
>  We have also used 4K + 224 NAND (not sure if the
>  same part or not) with ‘plat_nand’ (and also with
>  our own driver which uses our chip's ECC engine),
>  in a v2.6.36-based Linux kernel.  (The kernel's
>  version _may_ be important, since I _think_ some
>  later kernels directly support 224 (and 218 and
>  maybe 256) OOB sizes;  and/or correctly detecting
>  the eraseblock size.)

Timothy's part is an ONFI-compliant device, and I think ONFI support
was added after 2.6.36.

>  We didn't bother using the full 224-byts of OOB,
>  but instaed are treating the device as having
>  only 128-bytes of OOB.  Works fine, albeit we
>  did have to add the part to the nand_flash_ids[]
>  table since the eraseblock size wasn't correctly
>  detected.

In recent kernels, you shouldn't have to modify anything for the
size/eraseblock/etc. to be *detected* properly since ONFI will find
it, but depending on the driver, the OOB size may not be supported.
For instance, since the plat_nand driver uses the nand_base layouts
(as you noticed), you need to at least supply *some* ECC layout that
is valid. Just make sure the ECC strength is high enough for your
device...

Brian

RE: how to support 4096+224 page size with plat_nand ?

[STOTTS Timothy]

Thank you Brian (Norris).

Yes, the chip appears to be correctly detected, including all metrics. I am using kernel 3.0.8-ADI-2011R1.

How can I determine a valid ECC layout for OOB size of 224? A copy-and-paste of a layout found on the Internet resulted in the driver marking all blocks as "bad block" on the NAND Flash. (We have additional chips to work with.) My chip uses software ECC. Does it require BCH?

My datasheet does not specify ECC as number of OOB bytes per 4096 bytes, as such, but rather as a number of bits per a smaller number of bytes. Does that matter?

Timothy

-----Original Message-----
From: Brian Norris [mailto:computersforpeace@gmail.com]
Sent: Friday, March 16, 2012 7:17 PM
To: Brian Foster
Cc: STOTTS Timothy; linux-mtd@lists.infradead.org
Subject: Re: how to support 4096+224 page size with plat_nand ?

On Fri, Mar 16, 2012 at 7:05 AM, Brian Foster <brian.foster@maxim-ic.com> wrote:
>  We have also used 4K + 224 NAND (not sure if the
>  same part or not) with 'plat_nand' (and also with
>  our own driver which uses our chip's ECC engine),
>  in a v2.6.36-based Linux kernel.  (The kernel's
>  version _may_ be important, since I _think_ some
>  later kernels directly support 224 (and 218 and
>  maybe 256) OOB sizes;  and/or correctly detecting
>  the eraseblock size.)

Timothy's part is an ONFI-compliant device, and I think ONFI support
was added after 2.6.36.

>  We didn't bother using the full 224-byts of OOB,
>  but instaed are treating the device as having
>  only 128-bytes of OOB.  Works fine, albeit we
>  did have to add the part to the nand_flash_ids[]
>  table since the eraseblock size wasn't correctly
>  detected.

In recent kernels, you shouldn't have to modify anything for the
size/eraseblock/etc. to be *detected* properly since ONFI will find
it, but depending on the driver, the OOB size may not be supported.
For instance, since the plat_nand driver uses the nand_base layouts
(as you noticed), you need to at least supply *some* ECC layout that
is valid. Just make sure the ECC strength is high enough for your
device...

Brian

________________________________
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.

Re: how to support 4096+224 page size with plat_nand ?

[Brian Norris]

On Mon, Mar 19, 2012 at 7:40 AM, STOTTS Timothy
<timothy.stotts@transport.alstom.com> wrote:
> How can I determine a valid ECC layout for OOB size of 224? A copy-and-paste of a layout found on the Internet resulted in the driver marking all blocks as "bad block" on the NAND Flash. (We have additional chips to work with.) My chip uses software ECC. Does it require BCH?

This depends on your ECC level needed. If you stick with
NAND_ECC_SOFT, then (I think) you get 1-bit (Hamming) ECC. You can
probably just reuse the nand_oob_128 layout for 224. If you need
higher ECC correction, you might need BCH and would switch to
NAND_ECC_SOFT_BCH which I think calculates its own layout.

BTW, BCH is simply an algorithm used for Error Correction. It's
commonly used for anything higher than 1-bit ECC. I'm not very
familiar with software BCH (or software ECC in general).

So you might try just using nand_oob_128 layout by modifying the
`switch (mtd->oobsize) ...' logic. BCH would be a fallback option, or
if you need higher correction.

> My datasheet does not specify ECC as number of OOB bytes per 4096 bytes, as such, but rather as a number of bits per a smaller number of bytes. Does that matter?

That's typical. Usually it's measured across a 512-byte or 1024-byte
sector (sometimes adding OOB, giving odd sizes like 512+16=528, or
512+28=540, etc.).

Brian

how to support 4096+224 page size with plat_nand ?

[STOTTS Timothy]

I am looking to add support for the NAND Flash chip MT29F16G08ABABA to a board implementation of the platform NAND driver plat_nand.c .

I have followed the instructions available for my architecture at:
http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:drivers:bfin_async_nand

The chip has a page size of 4096+224.

According to the manufacturer, all blocks come preset as either 0xFF or 0x00. If 0xFF, the block is erased and good. If 0x00, the block was factory-determined to be bad.

It was necessary to make the following changes to the NAND subsystem for OOB of size 224.
=== modified file 'drivers/mtd/nand/nand_base.c'
--- drivers/mtd/nand/nand_base.c        2011-12-28 19:57:41 +0000
+++ drivers/mtd/nand/nand_base.c        2012-03-15 15:08:23 +0000
@@ -3256,6 +3256,11 @@
                case 128:
                        chip->ecc.layout = &nand_oob_128;
                        break;
+               case 224:
+                       chip->ecc.layout = &nand_oob_128;
+                       break;
                default:
                        printk(KERN_WARNING "No oob scheme defined for "
                               "oobsize %d\n", mtd->oobsize);

All kernel MTD Tests (kernel modules) run without error.
MTD nandtest executable runs without error.

Works as expected: ubiformat /dev/mtd4

Does not work as expected: ubiattach /dev/ubi_ctrl -m 4
root:~> ubiattach /dev/ubi_ctrl -m 4
UBI: attaching mtd4 to ubi0
UBI: physical eraseblock size:   524288 bytes (512 KiB)
UBI: logical eraseblock size:    520192 bytes
UBI: smallest flash I/O unit:    4096
UBI: sub-page size:              1024
UBI: VID header offset:          1024 (aligned 1024)
UBI: data offset:                4096
uncorrectable error :
uncorrectable error :
...
uncorrectable error :
uncorrectable error :
uncorrectable error :
uncorrectable error :
uncorrectable error :
UBI: max. sequence number:       0
UBI: attached mtd4 to ubi0
UBI: MTD device name:            "file system(nand)"
UBI: MTD device size:            2048 MiB
UBI: number of good PEBs:        4096
UBI: number of bad PEBs:         0
UBI: number of corrupted PEBs:   0
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     0
UBI: available PEBs:             4052
UBI: total number of reserved PEBs: 44
UBI: number of PEBs reserved for bad PEB handling: 40
UBI: max/mean erase counter: 0/0
UBI: image sequence number:  760250844
UBI: background thread "ubi_bgt0d" started, PID 482
UBI device number 0, total 4096 LEBs (2130706432 bytes, 2.0 GiB), available 4052 LEBs (2107817984 bytes, 2.0 GiB), LEB size 520192 bytes (508.0 KiB)

I am assuming that the errors are due to an incorrect OOB layout, or the ECC not being written correctly by ubiformat. What can I do to define the correct OOB layout for a chip with OOB size of 224 bytes?

Works as expected: ubimkvol /dev/ubi0 -N nand -m

root:~> ubimkvol /dev/ubi0 -N nand -m
Set volume size to 2107817984
Volume ID 0, size 4052 LEBs (2107817984 bytes, 2.0 GiB), LEB size 520192 bytes (508.0 KiB), dynamic, name "nand", alignment 1

Does not work as expected: mount -t ubifs ubi0:nand /mnt

root:~> mount -t ubifs ubi0:nand /mnt
UBIFS: default file-system created
uncorrectable error :
uncorrectable error :
uncorrectable error :
uncorrectable error :
uncorrectable error :
uncorrectable error :
uncorrectable error :
uncorrectable error :
UBIFS: mounted UBI device 0, volume 0, name "nand"
UBIFS: file system size:   2102616064 bytes (2053336 KiB, 2005 MiB, 4042 LEBs)
UBIFS: journal size:       33292288 bytes (32512 KiB, 31 MiB, 64 LEBs)
UBIFS: media format:       w4/r0 (latest is w4/r0)
UBIFS: default compressor: lzo
UBIFS: reserved for root:  4952683 bytes (4836 KiB)

Regards,
Timothy Stotts


________________________________
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.