mirror of
https://github.com/AsahiLinux/u-boot
synced 2024-11-14 17:07:38 +00:00
c41e209ea6
blkmaps are loosely modeled on Linux's device mapper subsystem. The basic idea is that you can create virtual block devices whose blocks can be backed by a plethora of sources that are user configurable. This change just adds the basic infrastructure for creating and removing blkmap devices. Subsequent changes will extend this to add support for actual mappings. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Simon Glass <sjg@chromium.org>
257 lines
8.7 KiB
Text
257 lines
8.7 KiB
Text
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 && !DM_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.
|
|
|
|
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 0
|
|
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.
|