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
|
config BLK
bool # "Support block devices"
depends on DM
default y if MMC || USB || SCSI || NVME || IDE || AHCI || SATA
default y if EFI_MEDIA || VIRTIO_BLK || PVBLOCK
help
Enable support for block devices, such as SCSI, MMC and USB
flash sticks. These provide a block-level interface which permits
reading, writing and (in some cases) erasing blocks. Block
devices often have a partition table which allows the device to
be partitioned into several areas, called 'partitions' in U-Boot.
A filesystem can be placed in each partition.
config SPL_LEGACY_BLOCK
bool # "Enable Legacy Block Device"
depends on SPL
default y if SPL_MMC || SPL_USB_STORAGE || SCSI || NVME || IDE
default y if SPL_AHCI_PCI
help
Some devices require block support whether or not DM is enabled. This
is only supported in SPL. With this, the blk uclass is not used, but
instead a legacy implementation of block devices is used, with all
devices consisting of 'struct blk_desc' records.
config SPL_BLK
bool "Support block devices in SPL"
depends on SPL_DM && BLK
default y
help
Enable support for block devices, such as SCSI, MMC and USB
flash sticks. These provide a block-level interface which permits
reading, writing and (in some cases) erasing blocks. Block
devices often have a partition table which allows the device to
be partitioned into several areas, called 'partitions' in U-Boot.
A filesystem can be placed in each partition.
config TPL_BLK
bool "Support block devices in TPL"
depends on TPL_DM && BLK
help
Enable support for block devices, such as SCSI, MMC and USB
flash sticks. These provide a block-level interface which permits
reading, writing and (in some cases) erasing blocks. Block
devices often have a partition table which allows the device to
be partitioned into several areas, called 'partitions' in U-Boot.
A filesystem can be placed in each partition.
config VPL_BLK
bool "Support block devices in VPL"
depends on VPL_DM && BLK
default y
help
Enable support for block devices, such as SCSI, MMC and USB
flash sticks. These provide a block-level interface which permits
reading, writing and (in some cases) erasing blocks. Block
devices often have a partition table which allows the device to
be partitioned into several areas, called 'partitions' in U-Boot.
A filesystem can be placed in each partition.
config BLOCK_CACHE
bool "Use block device cache"
depends on BLK
default y
help
This option enables a disk-block cache for all block devices.
This is most useful when accessing filesystems under U-Boot since
it will prevent repeated reads from directory structures and other
filesystem data structures.
config BLKMAP
bool "Composable virtual block devices (blkmap)"
depends on BLK
help
Create virtual block devices that are backed by various sources,
e.g. RAM, or parts of an existing block device. Though much more
rudimentary, it borrows a lot of ideas from Linux's device mapper
subsystem.
Example use-cases:
- Treat a region of RAM as a block device, i.e. a RAM disk. This let's
you extract files from filesystem images stored in RAM (perhaps as a
result of a TFTP transfer).
- Create a virtual partition on an existing device. This let's you
access filesystems that aren't stored at an exact partition
boundary. A common example is a filesystem image embedded in an FIT
image.
config SPL_BLOCK_CACHE
bool "Use block device cache in SPL"
depends on SPL_BLK
help
This option enables the disk-block cache in SPL
config TPL_BLOCK_CACHE
bool "Use block device cache in TPL"
depends on TPL_BLK
help
This option enables the disk-block cache in TPL
config EFI_MEDIA
bool "Support EFI media drivers"
default y if EFI || SANDBOX
help
Enable this to support media devices on top of UEFI. This enables
just the uclass so you also need a specific driver to make this do
anything.
For sandbox there is a test driver.
config SPL_BLK_FS
bool "Load images from filesystems on block devices"
depends on SPL_BLK
help
Use generic support to load images from fat/ext filesystems on
different types of block devices such as NVMe.
if EFI_MEDIA
config EFI_MEDIA_SANDBOX
bool "Sandbox EFI media driver"
depends on SANDBOX
default y
help
Enables a simple sandbox media driver, used for testing just the
EFI_MEDIA uclass. It does not do anything useful, since sandbox does
not actually support running on top of UEFI.
config EFI_MEDIA_BLK
bool "EFI media block driver"
depends on EFI_APP
default y
help
Enables a block driver for providing access to UEFI devices. This
allows use of block devices detected by the underlying UEFI
implementation. With this it is possible to use filesystems on these
devices, for example.
endif # EFI_MEDIA
config IDE
bool "Support IDE controllers"
help
Enables support for IDE (Integrated Drive Electronics) hard drives.
This allows access to raw blocks and filesystems on an IDE drive
from U-Boot. See also CMD_IDE which provides an 'ide' command for
performing various IDE operations.
if IDE
config SYS_IDE_MAXBUS
hex "Maximumm number of IDE buses"
default 2
help
This is the number of IDE buses provided by the board. Each one
can have one or two devices. One is designated the master and the
other one the slave. It is not required to have one or both on any
controller.
config SYS_IDE_MAXDEVICE
hex "Maximum number of IDE devices"
default 2
help
This is the number of IDE devices which can be connected to the
board. Normally this is 2 * CONFIG_SYS_IDE_MAXBUS since up to two
devices can be connected to each bus. The number of devices actually
connected is determined by probing.
config SYS_ATA_BASE_ADDR
hex "Base address of IDE controller"
default 0x0
help
This is the address of the IDE controller, from which other addresses
are calculated. Each bus is at a fixed offset from this address,
so it assumed that they are in the same area of the I/O space or
memory.
config SYS_ATA_STRIDE
hex "IDE port stride"
default 0x1
help
This is the distance between each IDE register, in bytes. For an
8-bit controller this is typically 1, meaning that the registers
appear at consecutive bytes. If the value 2 two, that might indicate
a 16-bit register space.
config SYS_ATA_DATA_OFFSET
hex "Offset of the data register"
default 0x0
help
This is the offset of the controller's data register from the base
address of the controller. This is typically 0, but may be something
else if there are some other registers at the start of the
controller space.
config SYS_ATA_REG_OFFSET
hex "Offset of the register space"
default 0x0
help
This is the offset of the controller's 'register' space from the base
address of the controller. The data register (which is typically at
offset 0) has its own CONFIG, to deal with controllers where it is
somewhere else. Register 1 will be at this offset + 1, register 2 at
CONFIG_SYS_ATA_REG_OFFSET + 2, etc.
config SYS_ATA_ALT_OFFSET
hex "Offset of the alternative registers"
default 0x0
help
This is the offset of the controller's 'alternative' space from the
base address of the controller. This allows these registers to be
located separately from the data and register space.
config SYS_ATA_IDE0_OFFSET
hex "Offset of bus 0"
default 0x1f0
help
This is the start offset of bus 0 from the start of the
controller registers. All the other registers are calculated from
this address. using the above options. For x86 hardware this is often
0x1f0.
config SYS_ATA_IDE1_OFFSET
hex "Offset of bus 1"
default 0x170
help
This is the start offset of bus 1 from the start of the
controller registers. All the other registers are calculated from
this address. using the above options. For x86 hardware this is often
0x170.
config ATAPI
bool "Enable ATAPI support"
help
This enabled Advanced Technology Attachment Packet Interface (ATAPI),
a protocol that allows a greater variety of devices to be connected
to the IDE port than with plain ATA. It allows SCSI commands to be
sent across the bus, e.g. to support optical drives.
config IDE_RESET
bool "Support board-specific reset"
help
If this is defined, IDE Reset will be performed by calling the
function:
ide_set_reset(int reset)
where reset is 1 to assert reset and 0 to de-assert it. This function
must be defined in a board-specific file.
endif # IDE
config LBA48
bool "Enable LBA support for disks larger than 137GB"
help
Set this to enable support for disks larger than 137GB.
Also look at CONFIG_SYS_64BIT_LBA. Without both of these, LBA48
support uses 32bit variables and will 'only' support disks up to
2.1TB.
config SYS_64BIT_LBA
bool "Enable 64bit number of blocks on a block device"
help
Make the block subsystem use 64bit sector addresses, rather than the
default of 32bit.
config RKMTD
bool "Rockchip rkmtd virtual block device"
select RANDOM_UUID
help
Enable "rkmtd" class and driver to create a virtual block device
to transfer Rockchip boot block data to and from NAND with block
orientate tools like "ums" and "rockusb".
|
