1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
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
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
|
i.MX NAND Flash Controller Driver Documentation
===============================================
Definitions of Terms
====================
To avoid confusion, let's carefully define some of the terms we'll be using:
"NAND Flash Chip" or "Chip"
A NAND Flash storage array and controller (including a chip select
signal, ready/busy signal, data register, etc.).
"NAND Flash Package" or "Package"
A hardware package containing one or more NAND Flash chips that share
data lines and most control signals, but with separate chip select
and ready/busy signals. Package "boundaries" are unimportant to MTD.
"NAND Flash Medium" or "Medium"
A collection of one or more NAND Flash chips that the system views as
logically contiguous.
"Memory Technology Device" or "MTD"
An abstraction of underlying memory hardware, represented by a single
struct mtd_info.
"NAND Flash MTD"
An abstraction of a NAND Flash medium that is represented by a single
struct nand_chip (the name of this structure is misleading because it
has evolved to represent an entire medium, not just a single chip).
All the physical chips in a NAND Flash MTD medium have answered the
"Read ID" command with the same manufacturer code and device code and
are presumed to have identical characteristics.
"NAND Flash MTD Hardware-independent Layer" or "HIL"
The code that implements an MTD interface and drives all NAND Flash
MTDs.
"NAND Flash MTD Hardware Abstraction Layer" or "HAL"
Code that implements the internal NAND Flash hardware model and
matches it to specific hardware.
"NAND Flash MTD Reference Implementation"
A reference implementation of a HAL "stack."
"Out-of-Band" or "OOB"
An adjective describing information that is not part of the "data" in
a NAND Flash page. NAND Flash pages are generally described in terms
of the amount of data they can hold (e.g., "2K pages" or "4K pages").
The physical page size is actually larger than this and the
additional bytes are called "out-of-band."
The Structure of the MTD NAND Flash System
==========================================
The following figure illustrates how control flows down from the system's
MTD interface into the NAND Flash MTD system and down to the hardware-
specific implementation (this driver):
/ +---------------------------------------+
| | MTD |
| +---------------------------------------+
MTD | |
| | +----------+
| | | |
| v v |
\ ======================================== |
- struct mtd_info |
/ ======================================== |
| | |
| v |
| +---------------------------------------+ |
| | NAND Flash MTD | |
NAND Flash | | Interface Functions | |
Hardware- | +---------------------------------------+ |
Independent | | | |
Layer | | v |
(HIL) | +-------------+ | +-------------+ +-------------+
| | Init | | | Support | | Reference |
| | Functions | | | Functions | |BBT Functions|
| +-------------+ | +-------------+ +-------------+
| | | | ^
| v v v |
\ ======================================== |
- struct nand_chip |
/ ======================================== |
| | ^ | ^ | |
NAND Flash | | | | | | |
Hardware | v | v | | |
Abstraction | +--------------+ +---------------+ | |
Layer | | Hardware- | | Reference | +-----------+
(HAL) | | Specific | | |
| |Implementation| |Implementations|
\ +--------------+ +---------------+
The function pointers and attributes in struct mtd_info embody an abstract
model of memory technology devices.
The struct nand_chip is an aggregation of two categories of function pointers
and attributes:
- Function pointers and attributes used by the HIL. These members embody
an abstract model of NAND Flash media, or a hardware abstraction
layer (HAL).
- Function pointers and attributes used by the reference implementations.
The single most confusing thing about the MTD NAND Flash system is that
struct nand_chip contains all the main HAL members mixed up with all the
members used only by the reference implementation, without any clear
distinction. Recognizing the distinction is critical for understanding the
relationship between the HIL and HAL, and can greatly simplify driver
implementation.
The fundamental operations represented by the function pointers in
struct nand_chip fall into the following categories (from conceptually
"low-level" to "high-level"):
- Signal Control
- Chip Control
- Low-level I/O
- ECC Control
- ECC-aware I/O
- Error Recovery
- High-level I/O
- Bad Block Management
The HIL uses only the following "Replaceable" function pointers in
struct nand_chip:
- Signal Control
- None
- Chip Control
- dev_ready
- select_chip
- cmdfunc
- waitfunc
- Low-level I/O
- read_byte
- ECC Control
- None
- ECC-aware I/O
- ecc.read_page
- ecc.read_page_raw
- Error Recovery
- None
- High-level I/O
- write_page
- ecc.read_oob
- ecc.write_oob
- Bad Block Management
- block_bad
- block_markbad
- scan_bbt
Note that the HIL calls erase_cmd, but this member is marked "Internal."
The HIL uses only the following commands with cmdfunc:
* NAND_CMD_STATUS
- nand_check_wp() - Checks if the current chip is
write-protected.
* NAND_CMD_READID
- nand_get_flash_type() - Gets information about the first chip.
- nand_scan_ident() - Scans for additional chips.
* NAND_CMD_RESET
- nand_do_write_oob() - Clears a bug observed on the
Toshiba TC5832DC and DiskOnChip 2000.
* NAND_CMD_READ0
- nand_do_read_ops() - Used to begin a full page read (both with
and without ECC).
* NAND_CMD_ERASE1
- single_erase_cmd() - Starts a block erase operation.
- multi_erase_cmd() - Starts a block erase operation.
* NAND_CMD_ERASE2
- single_erase_cmd() - Finishes a block erase operation.
- multi_erase_cmd() - Finishes a block erase operation.
Since this is all the HIL uses, this is all a driver needs to implement.
The Structure of the imx_nfc Driver
===================================
This driver supports many different versions of underlying controller, and
also supports higher-level abstractions like interleaving. To facilitate this
versatility, the code is layered as shown in the following diagram:
+--------------------------------------+
| MTD |
+--------------------------------------+
| NAND Flash MTD |
======================================== <-- struct nand_chip
/ | MTD Interface Layer (mil_*) |
| | +----------------------------------+
| | | Medium Abstraction Layer (mal_*) |
imx_nfc | | | |
driver | | | +------------------------+
| | | | NFC Utils (nfc_util_*) |
| ======================================== <-- struct nfc_hal
\ | NFC HAL (nfc_x_y_*) |
======================================== <-- Hardware Interface
| NFC Hardware |
+--------------------------------------+
MTD Interface Layer
-------------------
This layer includes functions that the NAND Flash MTD system calls directly.
In a manner of speaking, this layer "parses" the function calls made by MTD
and translates them into fundamental operations understood by the Medium
Abstraction Layer. Some simple operations don't need any abstraction, so code
in this layer can sometimes use the NFC HAL directly.
Medium Abstraction Layer
------------------------
This layer implements the abstract model of the NAND Flash medium and hides
details that shouldn't concern higher layers (e.g., interleaving).
NFC Utilities
-------------
These functions make it easier to use the NFC HAL. Even though this layer
is shown above the NFC HAL in the diagram, it's actually possible for the
NFC HAL to call some of these functions.
NFC HAL
-------
This layer implements the abstract model of an i.MX NAND Flash controller.
Other Collections of Functions
------------------------------
- System Interface
- imx_nfc_*
- sysfs Interface
- get_module_*
- set_module_*
- show_device_*
- store_device_*
i.MX NAND Flash Controller Versions
===================================
The i.MX NAND Flash controller (NFC) has evolved over time. Both its memory
layout and behaviors have changed. In this driver, we use major and minor
version numbers to label these stages in the NFC's evolution. These version
numbers are very useful, but they are entirely a figment of this driver's
imagination -- you will never find them in Freescale hardware reference
manuals.
When the platform code instantiates an i.MX NFC device, it provides a struct
imx_nfc_platform_data that contains platform-specific information. This
includes the major and minor version numbers for the NFC. This driver uses
the version numbers to select an appopriate NFC HAL structure.
i.MX NFC Memory Map
===================
While many things have changed during the evolution of the NFC, much has
remained the same. All i.MX NFCs have two or three essential memory-mapped
regions: a set of buffers, and one or two sets of registers (one on the AXI
bus and perhaps a second on the IP bus).
The buffer area contains the captive memory to which the NFC writes data
received from the NAND Flash medium. This area is subdivided into several
contiguous "main" buffers that hold 512-byte chunks of data, and several
"spare" buffers that hold varying-size chunks of out-of-band bytes. The
number of main buffers is always the same as the number of spare buffers, but
the exact count and the size of the spare buffers varies across NFC versions.
The register areas contain the NFC's control interface. Some versions have
only one set of registers, and some have two.
The platform-specific resources passed to this driver include the starting
and ending physical addresses of the buffer and register areas. This driver
maps those physical addresses to virtual addresses, and then uses version-
specific offsets and bit masks to operate the NFC.
Matching the NAND Flash MTD Page Model with the i.MX NFC
========================================================
The NAND Flash MTD HAL model views a page as containing two essentially
independent groups of bytes: "data" bytes and "out-of-band" bytes. If the
underlying physical format has data and out-of-band bytes distributed across
the page, they must be reassembled before being delivered to the caller
(e.g., see the function nand_read_page_syndrome(), which is part of the
reference implementation).
The i.MX NFC hardware imposes both a physical page layout and a layout in its
memory buffer that differ from the HAL model. The following figure shows how
all these layouts relate to each other:
i.MX NFC i.MX NFC
Physical Memory NAND Flash
Page Buffers MTD Model
+--------+ +--------+ +--------+
|OOB[N-1]| |OOB[N-1]| |OOB[N-1]|
+--------+ +--------+ +--------+
| | <gap> |OOB[ 1 ]|
| Data | +--------+ +--------+
| [N-1] | |OOB[ 1 ]| |OOB[ 0 ]|
| | +--------+ +--------+
+--------+ <gap>
... +--------+ +--------+
+--------+ |OOB[ 0 ]| | |
|OOB[ 1 ]| +--------+ | Data |
+--------+ | | | [N-1] |
| | | Data | | |
| Data | | [N-1] | +--------+
| [ 1 ] | | | | |
| | +--------+ | Data |
+--------+ ... | [ 1 ] |
|OOB[ 0 ]| +--------+ | |
+--------+ | | +--------+
| | | Data | | |
| Data | | [ 1 ] | | Data |
| [ 0 ] | | | | [ 0 ] |
| | +--------+ | |
+--------+ | | +--------+
| Data |
| [ 0 ] |
| |
+--------+
The NFC memory is *almost* what we want, but not quite. The problems are:
1) There are gaps between the out-of-band fragments.
2) The NFC memory responds only to 16-byte or 32-byte reads and writes.
To resolve these problems, we've encapsulated the NFC memory behind these
functions:
nfc_util_copy_from_the_nfc() - Copies data to main memory from the the NFC.
nfc_util_copy_to_the_nfc() - Copies data from main memory to the NFC.
These functions don't take pointers to locations within the NFC memory - they
take a "column address." These functions know how to skip over the gaps and
handle the NFC memory such that it looks like all the data and out-of-band
bytes are completely contiguous. They also handle copying arbitrary bytes
from/to a memory that only responds to 16- or 32-byte reads/writes. If you're
accessing the NFC memory without these functions, you're *probably* doing
something wrong.
|
