SPRUIE9D May 2017 – May 2024 DRA74P , DRA75P , DRA76P , DRA77P
The initialization routine for NAND consists of three parts: GPMC initialization, device detection with parameter determination, and bad block detection.
The GPMC interface is configured so that it can access NAND. Because NAND memories do not need the address bus, it is released. The data bus width is initially set to 8 bits. If necessary, it is changed to 16 bits after the device parameters are determined. Table 34-39 shows the GPMC configuration used during NAND boot. Table 34-39 is included for debug information.
Parameter | Value (Clock Cycles) | Register Initialization (where i = 0–7) | Reset Value |
---|---|---|---|
Write cycle time | 20 | GPMC_CONFIG5_i[12:8] WRCYCLETIME = 0x14 | 0x11 |
Read cycle time | 20 | GPMC_CONFIG5_i[4:0] RDCYCLETIME = 0x14 | 0x11 |
CS low time | 0 | GPMC_CONFIG2_i[3:0] CSONTIME = 0x0 | 0x1 |
CS low to OE low time | 5 | GPMC_CONFIG4_i[3:0] OEONTIME = 0x5 | 0x6 |
CS low to OE high time | 16 | GPMC_CONFIG4_i[12:8] OEOFFTIME = 0x10 | 0x10 |
CS low to WE low time | 1 | GPMC_CONFIG4_i[19:16] WEONTIME = 0x1 | 0x5 |
CS low to WE high time | 15 | GPMC_CONFIG4_i[28:24] WEOFFTIME = 0xF | 0x10 |
CS low to data latch time | 14 | GPMC_CONFIG5_i[20:16] RDACCESSTIME = 0xE | 0xF |
The ROM code first performs an initial wait for device auto initialization (with a 250-ms time-out) with polling of the ready information. Then, it must identify the NAND type connected to the GPMC interface. The GPMC is initialized using 8 bits, asynchronous mode. The NAND device is reset (command FFh) and its status is polled until ready for operation (with a 100-ms time-out). The ONFI Read ID (command 90h/address 20h) is sent to the NAND device. If it replies with the ONFI signature (4 bytes) then a Read parameters page (command ECh) is sent. The information provided in Table 34-40 is then extracted: page size, spare area size, number of pages per block, and the addressing mode, and ECC. If the CRC of the first parameter page read is not valid, ROM reads subsequent redundant parameter page copies until encountering one with a valid CRC. If ROM fails to read any of the redundant parameter pages without CRC errors, then it will give up attempting to identify the NAND device using the ONFI parameter page data and will fall back to the other NAND identification techniques (table lookup), which might result in NAND boot failing. The remaining data bytes from the parameter page stream are ignored.
Offset | Description | Size (Bytes) |
---|---|---|
6 | Features supported | 2 |
80 | Number of data bytes per page | 4 |
84 | Number of spare bytes per page | 2 |
92 | Number of pages per block | 4 |
101 | Number of address cycles | 1 |
If the ONFI Read ID command fails (it will be the case with any device not supporting ONFI), then the device is reset again with polling for device to be ready (with 100-ms time-out). Then, the standard Read ID (command 90h/address 00h) is sent. If the Device ID (second byte of the ID byte stream) is recognized as being a supported device, then the device parameters are extracted from an internal ROM code table. Table 34-41 lists the supported NAND devices.
Not all NAND geometries are supported – the NAND device datasheet must be compared to Table 34-41 to confirm that the Read ID matches the Geometry specified in Table 34-41.
Capacity | Device ID | Bus Width | Page Size in Bytes |
---|---|---|---|
512 Mibit | F0h | 8 | 2048 |
512 Mibit | C0h | 16 | 2048 |
512 Mibit | A0h | 8 | 2048 |
512 Mibit | B0h | 16 | 2048 |
512 Mibit | F2h | 8 | 2048 |
512 Mibit | C2h | 16 | 2048 |
512 Mibit | A2h | 8 | 2048 |
512 Mibit | B2h | 16 | 2048 |
1 Gibit | F1h | 8 | 2048 |
1 Gibit | C1h | 16 | 2048 |
1 Gibit | A1h | 8 | 2048 |
1 Gibit | B1h | 16 | 2048 |
2 Gibit | DAh | 8 | 2048 |
2 Gibit | CAh | 16 | 2048 |
2 Gibit | AAh | 8 | 2048 |
2 Gibit | BAh | 16 | 2048 |
2 Gibit | 83h | 8 | 2048 |
2 Gibit | 93h | 16 | 2048 |
4 Gibit | DCh | 8 | 2048 |
4 Gibit | CCh | 16 | 2048 |
4 Gibit | ACh | 8 | 2048 (4096) |
4 Gibit | BCh | 16 | 2048 (4096) |
4 Gibit | 84h | 8 | 2048 |
4 Gibit | 94h | 16 | 2048 |
8 Gibit | D3h | 8 | 2048 (4096) |
8 Gibit | C3h | 16 | 2048 (4096) |
8 Gibit | A3h | 8 | 2048 (4096) |
8 Gibit | B3h | 16 | 2048 (4096) |
8 Gibit | 85h | 8 | 2048 |
8 Gibit | 95h | 16 | 2048 |
16 Gibit | D5h | 8 | 2048 (4096) |
16 Gibit | C5h | 16 | 2048 (4096) |
16 Gibit | A5h | 8 | 2048 (4096) |
16 Gibit | B5h | 16 | 2048 (4096) |
16 Gibit | 86h | 8 | 2048 |
16 Gibit | 96h | 16 | 2048 |
32 Gibit | D7h | 8 | 2048 (4096) |
32 Gibit | C7h | 16 | 2048 (4096) |
32 Gibit | A7h | 8 | 2048 (4096) |
32 Gibit | B7h | 16 | 2048 (4096) |
32 Gibit | 87h | 8 | 2048 |
32 Gibit | 97h | 16 | 2048 |
64 Gibit | DEh | 8 | 2048 (4096) |
64 Gibit | CEh | 16 | 2048 (4096) |
64 Gibit | AEh | 8 | 2048 (4096) |
64 Gibit | BEh | 16 | 2048 (4096) |
After retrieving parameters from the table, the page size and block size are updated based on the fourth byte of the NAND ID data. Because of inconsistency among manufacturers, only devices recognized to be at least 2 Gibit have these parameters updated. Therefore, the ROM code supports 4-KiB page devices, but only if their size, according to the table, is at least 2 Gibit. Devices that are smaller than 2 Gibit have the block size parameter set to 128 KiB (when the page size is 2 KiB). Table 34-42 lists the fourth ID data byte encoding used in the ROM code.
Item | Description | I/O Number | |||||||
---|---|---|---|---|---|---|---|---|---|
7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ||
Page size | 512 bytes | 0 | 0 | ||||||
2048 bytes | 0 | 1 | |||||||
4096 bytes | 1 | 0 | |||||||
8192 bytes | 1 | 1 | |||||||
Cell type (1) | 2 levels | 0 | 0 | ||||||
4 levels | 0 | 1 | |||||||
8 levels | 1 | 0 | |||||||
16 levels | 1 | 1 | |||||||
Block size | 64 KiB | 0 | 0 | ||||||
128 KiB | 0 | 1 | |||||||
256 KiB | 1 | 0 | |||||||
512 KiB | 1 | 1 |
Figure 34-17 shows the detection procedure. When the NAND device is successfully detected, the ROM code changes the GPMC to 16-bit bus width, if necessary.
Invalid blocks contain invalid bits whose reliability cannot be ensured by the manufacturer. These bits are identified in the factory or during the programming and reported in the initial invalid block information in the spare area on the first and second page of each block. Because the ROM code looks for an image in the first four blocks, it detects the validity status of these blocks. Blocks detected as invalid are not accessed later. Block validity status is coded in the spare areas of the first two pages of a block (first byte equal to FFh in the first and second pages for an 8-bit device/first word equal to FFFFh in the first and second pages for a 16-bit device).
Figure 34-18 shows the invalid block detection routine. The routine consists in reading spare areas and checking the validity data pattern.