Reciva NAND Flash

From Sharpfin
Jump to: navigation, search

Introduction

The Reciva Module has a 16Mb * 8 NAND Flash Device, which is configured into 1024 blocks of 16KBytes. Blocks are sub-divided into 32 pages of 512 bytes, each page has an additional 16 bytes which are used for error correction / detection information.

Nand-map.png

Bad Block Management

Each partition starts at the pre-defined offset of 0000000, 0004000 0100000 0E00000 or 0F00000. The NAND Flash comes from the factory with bad blocks marked (the sixth byte in the extra (Out of Band, or OOB) information of the first two of the 32 pages in the 16K block is non-FF). When writing to the partition, the bad blocks are simply skipped.

Note that the kernel source, nandflash and every program I have seen so far, that deals with NAND flash makes the assumption that oob[5] on the first page indicates a bad block. The datasheet for the NAND device says that it is oob[5] in either the first or second page, so our program checks both!

Error Detection and Correction

There are 15 bytes available in the extra information to store error detection / correction data. The processor uses the first three to provide 24 bits of error correction data (18 bits of row, and 6 bits of column data). This is all defined in the Flash Controller section of the S3C2410 data sheet.

The NAND Flash Controller in the S3C2410 is enabled on the Barracuda module to automatically generate and write these three parity bytes.

The sharpflash program is heavily based on the sjf2410 program, and this accesses the NAND device directly, via the processor's external pins, and does not ask the NAND Flash Controller to read and write the memory. Consequently, the sharpflash program needs to these check bytes pre-calculated. nanddump images include pre-calculated check bytes, so the getpart program performs this calculation to add the missing information when it extracts partitions.

Source Code: The nand_ecc.c source code has been extracted from the kernel nand_ecc.c file, which is capable of generating the 24 bit error codes for 256 byte Toshiba memory. The algorithm for the S3C2410 is almost the same (512 bytes instead of 256, and the last two bits of parity data contain actual data rather than being forced to '11').

Booting

The first block in memory is guaranteed to be error free. The boot process simply copies this block to memory, and then begins execution. The bootloader loads the kernel from the second partition, which then loads the root filesystem.

Flash File Formats

There are two file formats you will see, that are associated with the flash memory. The first is 'nanddump' and the second is 'virtual'

nanddump

This format is used by the 'sharpflash' program, and is also produced by the 'nanddump' and 'getpart' programs. Data is organised into pages, each page contains 512 bytes of disk data, followed by 16 bytes of extra (out of band) data, which contains the error correction codes for the page. 528 bytes makes up a complete page, and 32 pages makes up a block.

When specifying sizes, only worry about the real data, so quoting 04000 will back up 4000(hex) bytes of data, plus 200(hex) bytes of extra data.

virtual

This is the format in which the Reciva firmware updates are stored. Do not be decieved as they are called 'mtd.bin' - they DO NOT CONTAIN ANY EXTRA (OUT OF BAND) DATA. This data must be re-created when partitions are extracted from the image - use 'getpart' to generate partitions.

If you build your own kernel, you will also need to use 'getpart' to generate the 'nanddump' compatible programming file for use by 'sharpflash'.

Useful Resources