1config BLK
2	bool
3	help
4	  Enable support for block devices, such as SCSI, MMC and USB
5	  flash sticks. These provide a block-level interface which permits
6	  reading, writing and (in some cases) erasing blocks. Block
7	  devices often have a partition table which allows the device to
8	  be partitioned into several areas, called 'partitions' in U-Boot.
9	  A filesystem can be placed in each partition.
10
11config SPL_LEGACY_BLOCK
12	bool # "Enable Legacy Block Device"
13	depends on SPL
14	default y if SPL_MMC || SPL_USB_STORAGE || SCSI || NVME || IDE
15	default y if SPL_AHCI_PCI
16	help
17	  Some devices require block support whether or not DM is enabled. This
18	  is only supported in SPL. With this, the blk uclass is not used, but
19	  instead a legacy implementation of block devices is used, with all
20	  devices consisting of 'struct blk_desc' records.
21
22config SPL_BLK
23	bool "Support block devices in SPL"
24	depends on SPL_DM && BLK
25	default y
26	help
27	  Enable support for block devices, such as SCSI, MMC and USB
28	  flash sticks. These provide a block-level interface which permits
29	  reading, writing and (in some cases) erasing blocks. Block
30	  devices often have a partition table which allows the device to
31	  be partitioned into several areas, called 'partitions' in U-Boot.
32	  A filesystem can be placed in each partition.
33
34config TPL_BLK
35	bool "Support block devices in TPL"
36	depends on TPL_DM && BLK
37	help
38	  Enable support for block devices, such as SCSI, MMC and USB
39	  flash sticks. These provide a block-level interface which permits
40	  reading, writing and (in some cases) erasing blocks. Block
41	  devices often have a partition table which allows the device to
42	  be partitioned into several areas, called 'partitions' in U-Boot.
43	  A filesystem can be placed in each partition.
44
45config VPL_BLK
46	bool "Support block devices in VPL"
47	depends on VPL_DM && BLK
48	default y
49	help
50	  Enable support for block devices, such as SCSI, MMC and USB
51	  flash sticks. These provide a block-level interface which permits
52	  reading, writing and (in some cases) erasing blocks. Block
53	  devices often have a partition table which allows the device to
54	  be partitioned into several areas, called 'partitions' in U-Boot.
55	  A filesystem can be placed in each partition.
56
57config BLOCK_CACHE
58	bool "Use block device cache"
59	depends on BLK
60	default y
61	help
62	  This option enables a disk-block cache for all block devices.
63	  This is most useful when accessing filesystems under U-Boot since
64	  it will prevent repeated reads from directory structures and other
65	  filesystem data structures.
66
67config BLKMAP
68	bool "Composable virtual block devices (blkmap)"
69	depends on BLK
70	help
71 	  Create virtual block devices that are backed by various sources,
72 	  e.g. RAM, or parts of an existing block device. Though much more
73 	  rudimentary, it borrows a lot of ideas from Linux's device mapper
74 	  subsystem.
75
76	  Example use-cases:
77	  - Treat a region of RAM as a block device, i.e. a RAM disk. This let's
78            you extract files from filesystem images stored in RAM (perhaps as a
79            result of a TFTP transfer).
80	  - Create a virtual partition on an existing device. This let's you
81            access filesystems that aren't stored at an exact partition
82            boundary. A common example is a filesystem image embedded in an FIT
83            image.
84
85config SPL_BLOCK_CACHE
86	bool "Use block device cache in SPL"
87	depends on SPL_BLK
88	help
89	  This option enables the disk-block cache in SPL
90
91config TPL_BLOCK_CACHE
92	bool "Use block device cache in TPL"
93	depends on TPL_BLK
94	help
95	  This option enables the disk-block cache in TPL
96
97config EFI_MEDIA
98	bool "Support EFI media drivers"
99	default y if EFI_CLIENT || SANDBOX
100	select BLK
101	help
102	  Enable this to support media devices on top of UEFI. This enables
103	  just the uclass so you also need a specific driver to make this do
104	  anything.
105
106	  For sandbox there is a test driver.
107
108config SPL_BLK_FS
109	bool "Load images from filesystems on block devices"
110	depends on SPL_BLK && SPL_FS_LOADER
111	help
112	  Use generic support to load images from fat/ext filesystems on
113	  different types of block devices such as NVMe.
114
115if EFI_MEDIA
116
117config EFI_MEDIA_SANDBOX
118	bool "Sandbox EFI media driver"
119	depends on SANDBOX
120	default y
121	help
122	  Enables a simple sandbox media driver, used for testing just the
123	  EFI_MEDIA uclass. It does not do anything useful, since sandbox does
124	  not actually support running on top of UEFI.
125
126config EFI_MEDIA_BLK
127	bool "EFI media block driver"
128	depends on EFI_APP
129	default y
130	help
131	  Enables a block driver for providing access to UEFI devices. This
132	  allows use of block devices detected by the underlying UEFI
133	  implementation. With this it is possible to use filesystems on these
134	  devices, for example.
135
136endif  # EFI_MEDIA
137
138config IDE
139	bool "Support IDE controllers"
140	select BLK
141	help
142	  Enables support for IDE (Integrated Drive Electronics) hard drives.
143	  This allows access to raw blocks and filesystems on an IDE drive
144	  from U-Boot. See also CMD_IDE which provides an 'ide' command for
145	  performing various IDE operations.
146
147if IDE
148
149config SYS_IDE_MAXBUS
150	hex "Maximum number of IDE buses"
151	default 2
152	help
153	  This is the number of IDE buses provided by the board. Each one
154	  can have one or two devices. One is designated the master and the
155	  other one the slave. It is not required to have one or both on any
156	  controller.
157
158config SYS_IDE_MAXDEVICE
159	hex "Maximum number of IDE devices"
160	default 2
161	help
162	  This is the number of IDE devices which can be connected to the
163	  board. Normally this is 2 * CONFIG_SYS_IDE_MAXBUS since up to two
164	  devices can be connected to each bus. The number of devices actually
165	  connected is determined by probing.
166
167config SYS_ATA_BASE_ADDR
168	hex "Base address of IDE controller"
169	default 0x0
170	help
171	  This is the address of the IDE controller, from which other addresses
172	  are calculated. Each bus is at a fixed offset from this address,
173	  so it assumed that they are in the same area of the I/O space or
174	  memory.
175
176config SYS_ATA_STRIDE
177	hex "IDE port stride"
178	default 0x1
179	help
180	  This is the distance between each IDE register, in bytes. For an
181	  8-bit controller this is typically 1, meaning that the registers
182	  appear at consecutive bytes. If the value 2 two, that might indicate
183	  a 16-bit register space.
184
185config SYS_ATA_DATA_OFFSET
186	hex "Offset of the data register"
187	default 0x0
188	help
189	  This is the offset of the controller's data register from the base
190	  address of the controller. This is typically 0, but may be something
191	  else if there are some other registers at the start of the
192	  controller space.
193
194config SYS_ATA_REG_OFFSET
195	hex "Offset of the register space"
196	default 0x0
197	help
198	  This is the offset of the controller's 'register' space from the base
199	  address of the controller. The data register (which is typically at
200	  offset 0) has its own CONFIG, to deal with controllers where it is
201	  somewhere else. Register 1 will be at this offset + 1, register 2 at
202	  CONFIG_SYS_ATA_REG_OFFSET + 2, etc.
203
204config SYS_ATA_ALT_OFFSET
205	hex "Offset of the alternative registers"
206	default 0x0
207	help
208	  This is the offset of the controller's 'alternative' space from the
209	  base address of the controller. This allows these registers to be
210	  located separately from the data and register space.
211
212config SYS_ATA_IDE0_OFFSET
213	hex "Offset of bus 0"
214	default 0x1f0
215	help
216	  This is the start offset of bus 0 from the start of the
217	  controller registers. All the other registers are calculated from
218	  this address. using the above options. For x86 hardware this is often
219	  0x1f0.
220
221config SYS_ATA_IDE1_OFFSET
222	hex "Offset of bus 1"
223	default 0x170
224	help
225	  This is the start offset of bus 1 from the start of the
226	  controller registers. All the other registers are calculated from
227	  this address. using the above options. For x86 hardware this is often
228	  0x170.
229
230config ATAPI
231	bool "Enable ATAPI support"
232	help
233	  This enabled Advanced Technology Attachment Packet Interface (ATAPI),
234	  a protocol that allows a greater variety of devices to be connected
235	  to the IDE port than with plain ATA. It allows SCSI commands to be
236	  sent across the bus, e.g. to support optical drives.
237
238config IDE_RESET
239	bool "Support board-specific reset"
240	help
241	  If this is defined, IDE Reset will be performed by calling the
242	  function:
243
244	     ide_set_reset(int reset)
245
246	  where reset is 1 to assert reset and 0 to de-assert it. This function
247	  must be defined in a board-specific file.
248
249endif  # IDE
250
251config LBA48
252	bool "Enable LBA support for disks larger than 137GB"
253	help
254	  Set this to enable support for disks larger than 137GB.
255	  Also look at CONFIG_SYS_64BIT_LBA.  Without both of these, LBA48
256	  support uses 32bit variables and will 'only' support disks up to
257	  2.1TB.
258
259config SYS_64BIT_LBA
260	bool "Enable 64bit number of blocks on a block device"
261	help
262	  Make the block subsystem use 64bit sector addresses, rather than the
263	  default of 32bit.
264
265config RKMTD
266	bool "Rockchip rkmtd virtual block device"
267	select RANDOM_UUID
268	help
269	  Enable "rkmtd" class and driver to create a virtual block device
270	  to transfer Rockchip boot block data to and from NAND with block
271	  orientate tools like "ums" and "rockusb".
272