1
2About this document
3===================
4
5Some notes about Marvell's NAND controller available in PXA and Armada 370/XP
6SoC (aka NFCv1 and NFCv2), with an emphasis on the latter.
7
8NFCv2 controller background
9===========================
10
11The controller has a 2176 bytes FIFO buffer. Therefore, in order to support
12larger pages, I/O operations on 4 KiB and 8 KiB pages is done with a set of
13chunked transfers.
14
15For instance, if we choose a 2048 data chunk and set "BCH" ECC (see below)
16we'll have this layout in the pages:
17
18  ------------------------------------------------------------------------------
19  | 2048B data | 32B spare | 30B ECC || 2048B data | 32B spare | 30B ECC | ... |
20  ------------------------------------------------------------------------------
21
22The driver reads the data and spare portions independently and builds an internal
23buffer with this layout (in the 4 KiB page case):
24
25  ------------------------------------------
26  |     4096B data     |     64B spare     |
27  ------------------------------------------
28
29Also, for the READOOB command the driver disables the ECC and reads a 'spare + ECC'
30OOB, one per chunk read.
31
32  -------------------------------------------------------------------
33  |     4096B data     |  32B spare | 30B ECC | 32B spare | 30B ECC |
34  -------------------------------------------------------------------
35
36So, in order to achieve reading (for instance), we issue several READ0 commands
37(with some additional controller-specific magic) and read two chunks of 2080B
38(2048 data + 32 spare) each.
39The driver accommodates this data to expose the NAND core a contiguous buffer
40(4096 data + spare) or (4096 + spare + ECC + spare + ECC).
41
42ECC
43===
44
45The controller has built-in hardware ECC capabilities. In addition it is
46configurable between two modes: 1) Hamming, 2) BCH.
47
48Note that the actual BCH mode: BCH-4 or BCH-8 will depend on the way
49the controller is configured to transfer the data.
50
51In the BCH mode the ECC code will be calculated for each transferred chunk
52and expected to be located (when reading/programming) right after the spare
53bytes as the figure above shows.
54
55So, repeating the above scheme, a 2048B data chunk will be followed by 32B
56spare, and then the ECC controller will read/write the ECC code (30B in
57this case):
58
59  ------------------------------------
60  | 2048B data | 32B spare | 30B ECC |
61  ------------------------------------
62
63If the ECC mode is 'BCH' then the ECC is *always* 30 bytes long.
64If the ECC mode is 'Hamming' the ECC is 6 bytes long, for each 512B block.
65So in Hamming mode, a 2048B page will have a 24B ECC.
66
67Despite all of the above, the controller requires the driver to only read or
68write in multiples of 8-bytes, because the data buffer is 64-bits.
69
70OOB
71===
72
73Because of the above scheme, and because the "spare" OOB is really located in
74the middle of a page, spare OOB cannot be read or write independently of the
75data area. In other words, in order to read the OOB (aka READOOB), the entire
76page (aka READ0) has to be read.
77
78In the same sense, in order to write to the spare OOB the driver has to write
79an *entire* page.
80
81Factory bad blocks handling
82===========================
83
84Given the ECC BCH requires to layout the device's pages in a split
85data/OOB/data/OOB way, the controller has a view of the flash page that's
86different from the specified (aka the manufacturer's) view. In other words,
87
88Factory view:
89
90  -----------------------------------------------
91  |                    Data           |x  OOB   |
92  -----------------------------------------------
93
94Driver's view:
95
96  -----------------------------------------------
97  |      Data      | OOB |      Data   x  | OOB |
98  -----------------------------------------------
99
100It can be seen from the above, that the factory bad block marker must be
101searched within the 'data' region, and not in the usual OOB region.
102
103In addition, this means under regular usage the driver will write such
104position (since it belongs to the data region) and every used block is
105likely to be marked as bad.
106
107For this reason, marking the block as bad in the OOB is explicitly
108disabled by using the NAND_BBT_NO_OOB_BBM option in the driver. The rationale
109for this is that there's no point in marking a block as bad, because good
110blocks are also 'marked as bad' (in the OOB BBM sense) under normal usage.
111
112Instead, the driver relies on the bad block table alone, and should only perform
113the bad block scan on the very first time (when the device hasn't been used).
114