Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-12-01 17:10:11 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/drivers/block/Kconfig

209 lines
6.7 KiB
Text
Raw Normal View History

dm: blk: Add a block-device uclass Add a uclass for block devices. These provide block-oriented data access, supporting reading, writing and erasing of whole blocks. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com>
2016-02-29 22:25:55 +00:00
config BLK
bool "Support block devices"
depends on DM
usb: Enforce DM_USB migration for USB_HOST devices. As the deadline for migration to DM_USB, when using a USB host controller has now gone two years past the deadline, enforce migration. This is done by: - Ensuring that all host controller options (other than the very legacy old MUSB ones) now select USB_HOST. USB_HOST now enforces DM_USB and OF_CONTROL. - Remove other parts of Kconfig logic that had platforms pick DM_USB. - To keep Kconfig happy, have some select statements test for USB_HOST as well. - Re-order some Kconfig entries and menus so that we can cleanly pick host or gadget roles. For the various HCD options that have platform glue options, group them together and update dependencies in some cases. - As SPL_DM_USB is not required, on platforms that had not yet enabled it, disable it. Cc: Marek Vasut <marex@denx.de> Cc: Icenowy Zheng <icenowy@aosc.io> Cc: Samuel Holland <samuel@sholland.org> Cc: FUKAUMI Naoki <naobsd@gmail.com> Cc: Andre Przywara <andre.przywara@arm.com> Cc: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2021-07-09 14:11:56 +00:00
default y if DM_MMC || DM_USB
dm: blk: Add a block-device uclass Add a uclass for block devices. These provide block-oriented data access, supporting reading, writing and erasing of whole blocks. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Stephen Warren <swarren@nvidia.com>
2016-02-29 22:25:55 +00:00
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.
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com>
2018-02-06 18:43:56 +00:00
config HAVE_BLOCK_DEVICE
bool "Enable Legacy Block Device"
help
Some devices require block support whether or not DM is enabled
dm: mmc: Allow disabling driver model in SPL At present if U-Boot proper uses driver model for MMC, then SPL has to also. While this is desirable, it places a significant barrier to moving to driver model in some cases. For example, with a space-constrained SPL it may be necessary to enable CONFIG_SPL_OF_PLATDATA which involves adjusting some drivers. Add new SPL versions of the options for DM_MMC, DM_MMC_OPS and BLK. By default these follow their non-SPL versions, but this can be changed by boards which need it. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-07-04 19:31:19 +00:00
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
blk: Support block drivers in TPL At present it is not possible to enable/disable block drivers in TPL. This is needed to provide sandbox support. Add a Kconfig option and adjust the Makefile. Signed-off-by: Simon Glass <sjg@chromium.org>
2018-10-01 18:22:13 +00:00
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
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
dm: mmc: Allow disabling driver model in SPL At present if U-Boot proper uses driver model for MMC, then SPL has to also. While this is desirable, it places a significant barrier to moving to driver model in some cases. For example, with a space-constrained SPL it may be necessary to enable CONFIG_SPL_OF_PLATDATA which involves adjusting some drivers. Add new SPL versions of the options for DM_MMC, DM_MMC_OPS and BLK. By default these follow their non-SPL versions, but this can be changed by boards which need it. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-07-04 19:31:19 +00:00
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.
drivers: block: add block device cache Add a block device cache to speed up repeated reads of block devices by various filesystems. This small amount of cache can dramatically speed up filesystem operations by skipping repeated reads of common areas of a block device (typically directory structures). This has shown to have some benefit on FAT filesystem operations of loading a kernel and RAM disk, but more dramatic benefits on ext4 filesystems when the kernel and/or RAM disk are spread across multiple extent header structures as described in commit fc0fc50. The cache is implemented through a minimal list (block_cache) maintained in most-recently-used order and count of the current number of entries (cache_count). It uses a maximum block count setting to prevent copies of large block reads and an upper bound on the number of cached areas. The maximum number of entries in the cache defaults to 32 and the maximum number of blocks per cache entry has a default of 2, which has shown to produce the best results on testing of ext4 and FAT filesystems. The 'blkcache' command (enabled through CONFIG_CMD_BLOCK_CACHE) allows changing these values and can be used to tune for a particular filesystem layout. Signed-off-by: Eric Nelson <eric@nelint.com>
2016-03-28 17:05:44 +00:00
config BLOCK_CACHE
bool "Use block device cache"
block: Have BLOCK_CACHE default to y in some cases When dealing with filesystems that come from block devices we can get a noticeable performance gain in some use cases from having the block cache enabled. The code paths are valid in other cases when we have BLK set and may provide wins in raw reads in some use cases, so have this be default when BLK is enabled. Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-22 16:24:16 +00:00
depends on BLK
default y
drivers: block: add block device cache Add a block device cache to speed up repeated reads of block devices by various filesystems. This small amount of cache can dramatically speed up filesystem operations by skipping repeated reads of common areas of a block device (typically directory structures). This has shown to have some benefit on FAT filesystem operations of loading a kernel and RAM disk, but more dramatic benefits on ext4 filesystems when the kernel and/or RAM disk are spread across multiple extent header structures as described in commit fc0fc50. The cache is implemented through a minimal list (block_cache) maintained in most-recently-used order and count of the current number of entries (cache_count). It uses a maximum block count setting to prevent copies of large block reads and an upper bound on the number of cached areas. The maximum number of entries in the cache defaults to 32 and the maximum number of blocks per cache entry has a default of 2, which has shown to produce the best results on testing of ext4 and FAT filesystems. The 'blkcache' command (enabled through CONFIG_CMD_BLOCK_CACHE) allows changing these values and can be used to tune for a particular filesystem layout. Signed-off-by: Eric Nelson <eric@nelint.com>
2016-03-28 17:05:44 +00:00
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.
dm: Add support for scsi/sata based devices All sata based drivers are bind and corresponding block device is created. Based on this find_scsi_device() is able to get back block device based on scsi_curr_dev pointer. intr_scsi() is commented now but it can be replaced by calling find_scsi_device() and scsi_scan(). scsi_dev_desc[] is commented out but common/scsi.c heavily depends on it. That's why CONFIG_SYS_SCSI_MAX_DEVICE is hardcoded to 1 and symbol is reassigned to a block description allocated by uclass. There is only one block description by device now but it doesn't need to be correct when more devices are present. scsi_bind() ensures corresponding block device creation. uclass post_probe (scsi_post_probe()) is doing low level init. SCSI/SATA DM based drivers requires to have 64bit base address as the first entry in platform data structure to setup mmio_base. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-09-08 13:06:45 +00:00
block: Add SPL_BLOCK_CACHE and default n When enabling BLOCK_CACHE on devices with limited RAM during SPL, some devices may not boot. This creates an option to enable block caching in SPL by defaults off. It is dependent on SPL_BLK Fixes: 46960ad6d09b ("block: Have BLOCK_CACHE default to y in some cases") Signed-off-by: Adam Ford <aford173@gmail.com>
2018-06-11 22:17:48 +00:00
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
blk: Allow control of the block cache in TPL Generally block devices are not enabled in TPL, but in case they are, add a Kconfig option for the block cache. This allows the setting (default off) to be found with CONFIG_IS_ENABLED(). Signed-off-by: Simon Glass <sjg@chromium.org>
2019-05-18 17:59:53 +00:00
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
efi: Add uclass for devices provided by UEFI firmware UCLASS_EFI_LOADER is used for devices created by applications and drivers loaded by U-Boots UEFI implementation. This patch provides a new uclass (UCLASS_EFI_MEDIA) to be used for devices that provided by a UEFI firmware calling U-Boot as an EFI application. If the two uclasses can be unified, is left to future redesign. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-12-04 15:56:31 +00:00
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.
efi: Add a media/block driver for EFI block devices Add a block driver which handles read/write for EFI block devices. This driver actually already exists ('efi_block') but is not really suitable for use as a real U-Boot driver: - The operations do not provide a udevice - The code is designed for running as part of EFI loader, so uses EFI_PRINT() and EFI_CALL(). - The bind method probes the device, which is not permitted - It uses 'EFI' as its parent device The new driver is more 'normal', just requiring its platform data be set up in advance. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-12-04 15:56:32 +00:00
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.
efi: Add uclass for devices provided by UEFI firmware UCLASS_EFI_LOADER is used for devices created by applications and drivers loaded by U-Boots UEFI implementation. This patch provides a new uclass (UCLASS_EFI_MEDIA) to be used for devices that provided by a UEFI firmware calling U-Boot as an EFI application. If the two uclasses can be unified, is left to future redesign. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-12-04 15:56:31 +00:00
endif # EFI_MEDIA
Kconfig: Add a CONFIG_IDE option At present IDE support is controlled by CONFIG_CMD_IDE. Add a separate CONFIG_IDE option so that IDE support can be enabled without requiring the 'ide' command. Update existing users and move the ide driver into drivers/block since it should not be in common/. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-05-17 09:25:30 +00:00
config IDE
bool "Support IDE controllers"
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com>
2018-02-06 18:43:56 +00:00
select HAVE_BLOCK_DEVICE
Kconfig: Add a CONFIG_IDE option At present IDE support is controlled by CONFIG_CMD_IDE. Add a separate CONFIG_IDE option so that IDE support can be enabled without requiring the 'ide' command. Update existing users and move the ide driver into drivers/block since it should not be in common/. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-05-17 09:25:30 +00:00
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.
Convert CONFIG_SYS_IDE_MAXBUS et al to Kconfig This converts the following to Kconfig: CONFIG_SYS_IDE_MAXBUS CONFIG_SYS_IDE_MAXDEVICE CONFIG_SYS_ATA_BASE_ADDR CONFIG_SYS_ATA_STRIDE CONFIG_SYS_ATA_DATA_OFFSET CONFIG_SYS_ATA_REG_OFFSET CONFIG_SYS_ATA_ALT_OFFSET CONFIG_SYS_ATA_IDE0_OFFSET CONFIG_SYS_ATA_IDE1_OFFSET CONFIG_ATAPI CONFIG_IDE_RESET Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefan Roese <sr@denx.de>
2022-01-22 12:53:24 +00:00
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
Reference in a new issue Copy permalink