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
|
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/mtd/nand-controller.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NAND Chip and NAND Controller Generic Binding
maintainers:
- Miquel Raynal <miquel.raynal@bootlin.com>
- Richard Weinberger <richard@nod.at>
description: |
The NAND controller should be represented with its own DT node, and
all NAND chips attached to this controller should be defined as
children nodes of the NAND controller. This representation should be
enforced even for simple controllers supporting only one chip.
The ECC strength and ECC step size properties define the user
desires in terms of correction capability of a controller. Together,
they request the ECC engine to correct {strength} bit errors per
{size} bytes.
The interpretation of these parameters is implementation-defined, so
not all implementations must support all possible
combinations. However, implementations are encouraged to further
specify the value(s) they support.
properties:
$nodename:
pattern: "^nand-controller(@.*)?"
"#address-cells":
const: 1
"#size-cells":
const: 0
ranges: true
cs-gpios:
minItems: 1
maxItems: 8
description:
Array of chip-select available to the controller. The first
entries are a 1:1 mapping of the available chip-select on the
NAND controller (even if they are not used). As many additional
chip-select as needed may follow and should be phandles of GPIO
lines. 'reg' entries of the NAND chip subnodes become indexes of
this array when this property is present.
patternProperties:
"^nand@[a-f0-9]$":
type: object
properties:
reg:
description:
Contains the native Ready/Busy IDs.
nand-ecc-engine:
allOf:
- $ref: /schemas/types.yaml#/definitions/phandle
description: |
A phandle on the hardware ECC engine if any. There are
basically three possibilities:
1/ The ECC engine is part of the NAND controller, in this
case the phandle should reference the parent node.
2/ The ECC engine is part of the NAND part (on-die), in this
case the phandle should reference the node itself.
3/ The ECC engine is external, in this case the phandle should
reference the specific ECC engine node.
nand-use-soft-ecc-engine:
type: boolean
description: Use a software ECC engine.
nand-no-ecc-engine:
type: boolean
description: Do not use any ECC correction.
nand-ecc-placement:
allOf:
- $ref: /schemas/types.yaml#/definitions/string
- enum: [ oob, interleaved ]
description:
Location of the ECC bytes. This location is unknown by default
but can be explicitly set to "oob", if all ECC bytes are
known to be stored in the OOB area, or "interleaved" if ECC
bytes will be interleaved with regular data in the main area.
nand-ecc-algo:
description:
Desired ECC algorithm.
$ref: /schemas/types.yaml#/definitions/string
enum: [hamming, bch, rs]
nand-bus-width:
description:
Bus width to the NAND chip
$ref: /schemas/types.yaml#/definitions/uint32
enum: [8, 16]
default: 8
nand-on-flash-bbt:
$ref: /schemas/types.yaml#/definitions/flag
description:
With this property, the OS will search the device for a Bad
Block Table (BBT). If not found, it will create one, reserve
a few blocks at the end of the device to store it and update
it as the device ages. Otherwise, the out-of-band area of a
few pages of all the blocks will be scanned at boot time to
find Bad Block Markers (BBM). These markers will help to
build a volatile BBT in RAM.
nand-ecc-strength:
description:
Maximum number of bits that can be corrected per ECC step.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
nand-ecc-step-size:
description:
Number of data bytes covered by a single ECC step.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
nand-ecc-maximize:
$ref: /schemas/types.yaml#/definitions/flag
description:
Whether or not the ECC strength should be maximized. The
maximum ECC strength is both controller and chip
dependent. The ECC engine has to select the ECC config
providing the best strength and taking the OOB area size
constraint into account. This is particularly useful when
only the in-band area is used by the upper layers, and you
want to make your NAND as reliable as possible.
nand-is-boot-medium:
$ref: /schemas/types.yaml#/definitions/flag
description:
Whether or not the NAND chip is a boot medium. Drivers might
use this information to select ECC algorithms supported by
the boot ROM or similar restrictions.
nand-rb:
$ref: /schemas/types.yaml#/definitions/uint32-array
description:
Contains the native Ready/Busy IDs.
rb-gpios:
description:
Contains one or more GPIO descriptor (the numper of descriptor
depends on the number of R/B pins exposed by the flash) for the
Ready/Busy pins. Active state refers to the NAND ready state and
should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted.
secure-regions:
$ref: /schemas/types.yaml#/definitions/uint64-matrix
description:
Regions in the NAND chip which are protected using a secure element
like Trustzone. This property contains the start address and size of
the secure regions present.
required:
- reg
required:
- "#address-cells"
- "#size-cells"
additionalProperties: true
examples:
- |
nand-controller {
#address-cells = <1>;
#size-cells = <0>;
cs-gpios = <0>, <&gpioA 1>; /* A single native CS is available */
/* controller specific properties */
nand@0 {
reg = <0>; /* Native CS */
nand-use-soft-ecc-engine;
nand-ecc-algo = "bch";
/* controller specific properties */
};
nand@1 {
reg = <1>; /* GPIO CS */
};
};
|
