Uboot NAND 2 GB fix

Nand_init in drivers/Nand
For example
# Define pai_nand_base (0x70200010)
Which is
Nand_init_chip
Nand-> io_addr_r = NAND-> io_addr_w = (void _ iomem * base_addr;
Retrieve the address and then proceed,
Board_nand_init

 

4 K is correct. It seems that the value of 8g needs to be changed. The value of M is also 4 K.

K9g8g08 (1 piece = 128 page = 256 K), started normally on 1 gb mlc Nand

Device 0: NAND 2gib, 3 V 8-bit, sector size 512 kib
Nand: MAF. ID = 0xec
Device. ID = 0xd5

 

Nand_init in drivers/Nand
For example
# Define pai_nand_base (0x70200010)
Which is
Nand_init_chip
Nand-> io_addr_r = NAND-> io_addr_w = (void _ iomem * base_addr;
Retrieve the address and then proceed,
Board_nand_init

 

Uboot print information:

Nand: MAF. ID = 0xec
Device. ID = 0xd5
NAND Flash name is NAND 2gib 3, 3 V 8-bit
Nand type MLC
Pagesize = 0x1000
Oobsize = 0x80
Blocksize = 0x80000
Busw = 0x0
2048 MB

 

/Write is a page, and wipe is a block
Programe size 4224-byte page (= 4096 + 128, so OOB is also 128)
Erase size 512 K + 16 K byte Block
512k-----80000
Indicates that the first block is a bad block.
Device 0 bad blocks:
00000000
00080000

 

K9gag08u

G: MLC normal

AG: 16 GB

08: X8

U: 2.7 ~ 3.6

0: normal

M: 1st generation

P

C

B

0

 

16 GB is bit
So it's AG.

 

From the NAND bad command entry in uboot, we can see how uboot breaks down blocks separately.

It verifies the colomn address 4096 of last page in the block in the datasheet of NAND Flash below.

The specific process is as follows:

Device 0 bad blocks:
[Do_nand]: Off = 00000000.
[Nand_block_isbad]: 1 00000000
[Nand_block_isbad]: 2 00000000
[Nand_block_isbad]: MTD-> erasesize = 0x80000, MTD-> writesize = 0x1000
[Nand_block_isbad]: 3 00000000
[Nand_block_checkbad]: 00000000
[Nand_block_checkbad]: MTD-> erasesize = 0x80000, MTD-> writesize = 0x1000
[Nand_block_bad]: 1 OFS = 0x00000000
[Nand_block_bad]: 2 OFS = 0x7f000
MTD-> erasesize = 0x80000, MTD-> writesize = 0x1000, and Chip-> page_shift = 0xc
Page = 0x7f, chipnr = 0x0
[Nand_command_lp]: column = 0x1000
Find a bad block, and result = 0x0
00000000

Print

Printf ("[nand_block_bad]: 1 OFS = 0x % 08x/N", (ulong) OFS );
Ulong must be added. Because OFS is loff_t, that is, long.

 

The first thought was that OOB should also be an address, but in fact it is.

Increment by erase_block (Block), move to the last page of the current block each time, calculate the number of the page as the page number, and then change the column address to pagesize, in sequence, read the CMD, page, and column in the address is transmitted to NAND Flash, and then the value of this address can be read from the 6410 NAND Flash data address register.

 

Check whether the hardware is correct, such as the address line.

Note that if you use the nand read command on movinand uboot, the error of ECC uncorrectable is normal. Because there is no bbt at this time.

 

And then use the NAND scrub command in uboot to forcibly remove the bad block flag. After that, you can write 0th pieces of data, which will not be lost after restart.

 

There is no error in the hardware address line, including the configuration for starting from NAND, because the irom-NAND startup mode is known from datasheet, Which is used on our own board. I still cannot use this method on the idea board.

Specific Method: Enable the macro of config_nand_bl1_8bit_ecc in uboot. Because NAND and irom are used in different ways, it is certainly better to use the first module based on NAND, there is certainly no problem with carrying 8kb BL1, while irom uses 8bit ECC to ensure that what is obtained is correct (maybe not required ?).

 

Check the distribution of Bad blocks with nand bad before writing.

 

/**
* Struct nand_flash_dev-NAND flash device ID Structure
* @ Name: Identify the device type
* @ ID: device ID code
* @ Pagesize: pagesize in bytes. Either 256 or 512 or 0
* If the pagesize is 0, then the real pagesize
* And the eraseize are determined from
* Extended ID bytes in the chip
* @ Erasesize: size of an erase block in the flash device.
* @ Chipsize: Total chipsize in mega bytes
* @ Options: bitfield to store chip relevant options
*/
Struct nand_flash_dev {
Char * Name;
Int ID;
Unsigned long pagesize; // 0 mean not fixed
Unsigned long chipsize;
Unsigned long erasesize; // 0 mean not fixed
Unsigned long options;
};

 

 

Bad Block table (bbt)

Since the usual bad block marker in the OOB area does not allow us to distinguish between factory-bad and worn-out-Bad blocks, we need to store this information elsewhere. this place is called Bad-block table (bbt) and is stored as a bitmapIn the last two good blocks at the end of NAND. To increase security,A backup of those two blocks is kept in the two preceding Good blocks as well.

The bbt location itself is identified by special markers (bbt0/bbt1) in the OOB area of the first page of the respective erase blocks.

The bbt consistsTwo bitsPer block which distinguish the three conditions (factory-bad/worn-out/good ).

Both U-boot and Linux implement the same bbt layout and thus interoperate quite well.

Bbt Creation

The bbt is created once a bbt-implementing U-boot is started for the first time. The bbt scanning Code assumes that the NAND isCompletely erased, I. e. Only contains 0xff as content. Any block that contains bytes! = 0xff In the OOB is marked as "factory bad" block.

 

It is said that the 4 kb pagesize corresponds to the 8-bit ECC. In addition, a large nand_ecclayout (128?) is required ?).

 

Since NAND Controller supports ecc_hw, should ecc_hw be enabled?

 

Understanding memory technology devices in Embedded Linux

From book: Essential Linux Device Drivers

About Nand

Nand chip drivers

Nand technology users such as USB pen drives, DOMs, compact flash memory, and SD/MMC cards emulate Standard Storage interfaces such as SCSI or IDE over NAND flash, so you don't need to develop NAND drivers to communicate with them.5 on-board NAND Flash chips need special drivers, however, and are the topic of this section.

As you learned previusly in this chapter, NAND Flash chips, unlike their nor counterparts, are not connected to the CPU via data and address lines. They interface to the CPU through special electronics calledNAND Flash ControllerThat is part of your embedded processors. to read data from NAND Flash, the CPU issues an appropriateReadCommand to the NAND controller. The controller transfers data from the requested flash location to an internal RAM memory, also part of the controller. The data transfer is done in units of the flash chip'sPage size(For example, 2kb). In general, the denser the flash chip, the larger is its page size. Note that the page size is different from the flash chip'sBlock Size, Which is the minimum erasable flash memory unit (for example, 16 KB ). after the transfer operation completes, the CPU reads the requested NAND contents from the internal RAM. writes to NAND Flash are done similarly, thanks t that the controller transfers data from the internal RAM to flash. the connection digoal of nand flash memory on an embedded device is shown in figure 17.3.

 

Figure 17.3 NAND Flash connection.

Because of this unconventional mode of addressing, you need special drivers to work with nand storage. MTD provides such drivers to manage NAND-resident data. if you are using a supported chip, you have to enable only the appropriate low-level mtd nand driver. if you are writing a NAND Flash Driver, however, you need to need e two datasheets: The NAND Flash Controller and the NAND flash chip.

NAND Flash chips do not support automatic configuration using protocols such as CFI. You have to manually inform MTD about the properties of your NAND chip by adding an entry toNand_flash_ids []Table defined inDrivers/MTD/NAND/nand_ids.c. Each entry in the table consists of an identifier name, the device ID, page size, erase block size, chip size, and options such as the bus width.

There is another characteristic that goes hand in hand with nand memory. NAND Flash chips, unlike nor chips, are not faultless. it's normal to have some problem bits and Bad blocks scattered loss ss nand Flash regions. to handle this, Nand devices associateSpare AreaWith each flash page (for example, 64 bytes of spare area for each 2kb data page). The spare area containsOut-of-band(OOB) Information to help perform bad block management and error correction. The OOB area has desError Correcting Codes(ECCS) to implement error correction and detection. ECC algorithms correct single-bit errors and detect Multibit errors.Nand_ecclayoutStructure defined inInclude/MTD/mtd-abi.hSpecifies the layout of the OOB spare area:

struct nand_ecclayout {
  uint 32_t eccbytes;
  uint32_t  eccpos[64];
  uint32_t  oobavail;
  struct    nand_oobfree oobfree[MTD_MAX_OOBFREE_ENTRIES];
};

In this structure,EccbytesHolds the number of OOB bytes that store ECC data, andEccposIs an array of offsets into the OOB area that contains the ECC data.OobfreeRecords the unused bytes in the OOB area available to flash filesystems for storing flags suchClean markersThat signal successful completion of erase operations.

Individual NAND drivers initialize theirNand_ecclayoutAccording to the chip's properties. figure 17.4 analyze strates the layout of a NAND flash chip having a page size of 2kb. the OOB semantics used by the figure is the default for 2kb page-sized chips as defined in the generic NAND driver,Drivers/MTD/NAND/nand_base.c.

  Fig 17.4 In the PIC: 2-39 for file system, 40-63, OOB

Figure 17.4 layout of a NAND flash chip.

Often, the NAND controller performs error correction and detection in hardware by operating on the ECC fields in the OOB area. if your NAND controller does not support error management, however, you will need to get MTD to do that for you in software. the MTDNand_eccDriver (Drivers/MTD/NAND/nand_ecc.c) Implements software ECC.

Figure 17.4 also shows OOB memory bytes that contain bad block markers. These markers are used to flag faulty flash blocks and areUsually present in the OOB region belonging to the first page of each block.The position of the marker inside the OOB area depends on the properties of the chip.Bad Block markers are either set at

(In 2g flash according to this to judge bad block)

Factory during manufacture, or by software when it detects wear in a block. MTD implements bad block management inDrivers/MTD/NAND/nand_bbt.c.

TheMtd_partitionStructure Used in listing 17.1 For the nor flash in Figure 17.2 works for NAND memory, too. After you MTD-Enable your NAND Flash, you can access the constituent partitions using standard device nodes such/Dev/MTD/xAnd/Dev/mtdblock/x. If you have a mix of nor and NAND memories on your hardware,XCan be either a nor or a NAND partition. If you have a total of more than 32 flash partitions, accordingly change the valueMax_mtd_devicesInInclude/Linux/MTD. h.

To upgrade tively make use of NAND storage, you need to use a filesystem tuned for NAND access, such as jffs2 or yaffs2, in tandem with the low-level NAND driver. we discuss these filesystems in the next section.

 

/* Zhangq add this to support OOB 128 */
Struct nand_ecclayout nand_oob_128 = {
. Eccbytes = 48,
. Eccpos = {
80, 81, 82, 83, 84, 85, 86, 87,
88, 89, 90, 91, 92, 93, 94, 95,
96, 97, 98, 99,100,101,102,103,
104,105,106,107,108,109,110,111,
112,113,114,115,116,117,118,119,
120,121,122,123,124,125,126,127 },
. Oobfree = {
{. Offset = 2,
. Length = 78 }}
};

 

Nand-> ECC. size = 128;
// NAND-> ECC. bytes = 8;/* really 7 bytes */
Nand-> ECC. bytes = 48;/* really 7 bytes */

ECC. size = ECC. bytes + lenth + offset 128 = 78 + 2 + 48

 

 

 

Nand-> ECC. size = 512;
Nand-> ECC. bytes = 8;/* really 7 bytes */

Here there are only eight rows, and the total size of the eight bytes can be verified is equal to size.

Chip-> ECC. Steps = MTD-> writesize/chip-> ECC. size;
Step: it takes several times to complete ECC verification.

Chip-> ECC. Total = chip-> ECC. Steps * chip-> ECC. bytes;

That is, the total number of ECC bytes required for verification.

 

 

 

Nand_nce select the chip by setting nce to low

Nand_cle select the command latch by setting CLE to high

Nand_ale select the address latch by setting ale to high