From 40b9e0dd0505cc505bb31823c11aad59f5abdd43 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Thu, 21 Oct 2021 21:08:50 -0600 Subject: doc: Improve environment documentation further Make various other updates suggested during review of the rST conversion. Signed-off-by: Simon Glass Suggested-by: Heinrich Schuchardt --- doc/develop/environment.rst | 51 +++++++++++++++++++++++++++++++++++++++++++++ doc/develop/index.rst | 1 + 2 files changed, 52 insertions(+) create mode 100644 doc/develop/environment.rst (limited to 'doc/develop') diff --git a/doc/develop/environment.rst b/doc/develop/environment.rst new file mode 100644 index 00000000000..0b86fafbff7 --- /dev/null +++ b/doc/develop/environment.rst @@ -0,0 +1,51 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Environment implementation +========================== + +See :doc:`../usage/environment` for usage information. + +Callback functions for environment variables +-------------------------------------------- + +For some environment variables, the behavior of u-boot needs to change +when their values are changed. This functionality allows functions to +be associated with arbitrary variables. On creation, overwrite, or +deletion, the callback will provide the opportunity for some side +effect to happen or for the change to be rejected. + +The callbacks are named and associated with a function using the +U_BOOT_ENV_CALLBACK macro in your board or driver code. + +These callbacks are associated with variables in one of two ways. The +static list can be added to by defining CONFIG_ENV_CALLBACK_LIST_STATIC +in the board configuration to a string that defines a list of +associations. The list must be in the following format:: + + entry = variable_name[:callback_name] + list = entry[,list] + +If the callback name is not specified, then the callback is deleted. +Spaces are also allowed anywhere in the list. + +Callbacks can also be associated by defining the ".callbacks" variable +with the same list format above. Any association in ".callbacks" will +override any association in the static list. You can define +CONFIG_ENV_CALLBACK_LIST_DEFAULT to a list (string) to define the +".callbacks" environment variable in the default or embedded environment. + +If CONFIG_REGEX is defined, the variable_name above is evaluated as a +regular expression. This allows multiple variables to be connected to +the same callback without explicitly listing them all out. + +The signature of the callback functions is:: + + int callback(const char *name, const char *value, enum env_op op, int flags) + +* name - changed environment variable +* value - new value of the environment variable +* op - operation (create, overwrite, or delete) +* flags - attributes of the environment variable change, see flags H_* in + include/search.h + +The return value is 0 if the variable change is accepted and 1 otherwise. diff --git a/doc/develop/index.rst b/doc/develop/index.rst index b3871b16f35..9592d193fca 100644 --- a/doc/develop/index.rst +++ b/doc/develop/index.rst @@ -16,6 +16,7 @@ Implementation devicetree/index distro driver-model/index + environment global_data logging makefiles -- cgit v1.3.1 From d5b6e91ba2cac6cb0a2f7437fdbbe792d1acb387 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Wed, 3 Nov 2021 21:09:20 -0600 Subject: bloblist: Support allocating the bloblist Typically the bloblist is positioned at a fixed address in memory until relocation. This is convenient when it is set up in SPL or before relocation. But for EFI we want to set it up only when U-Boot proper is running. Add a way to allocate it using malloc() and update the documentation to cover this aspect of bloblist. Note there are no tests of this feature at present, nor any direct testing of bloblist_init(). This can be added, e.g. by making this option controllable at runtime. Signed-off-by: Simon Glass --- common/Kconfig | 15 +++++++++++++-- common/bloblist.c | 16 ++++++++++++++-- common/board_f.c | 8 +++++++- doc/develop/bloblist.rst | 16 ++++++++++++++++ 4 files changed, 50 insertions(+), 5 deletions(-) (limited to 'doc/develop') diff --git a/common/Kconfig b/common/Kconfig index 176fda9449e..50ac4331f5c 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -727,6 +727,8 @@ config TPL_BLOBLIST This enables a bloblist in TPL. The bloblist is set up in TPL and passed to SPL and U-Boot proper. +if BLOBLIST + config BLOBLIST_SIZE hex "Size of bloblist" depends on BLOBLIST @@ -737,17 +739,24 @@ config BLOBLIST_SIZE is set up in the first part of U-Boot to run (TPL, SPL or U-Boot proper), and this sane bloblist is used for subsequent stages. +config BLOBLIST_ALLOC + bool "Allocate bloblist" + help + Allocate the bloblist using malloc(). This avoids the need to + specify a fixed address on systems where this is unknown or can + change at runtime. + config BLOBLIST_ADDR hex "Address of bloblist" - depends on BLOBLIST default 0xc000 if SANDBOX help Sets the address of the bloblist, set up by the first part of U-Boot which runs. Subsequent U-Boot stages typically use the same address. + This is not used if BLOBLIST_ALLOC is selected. + config BLOBLIST_SIZE_RELOC hex "Size of bloblist after relocation" - depends on BLOBLIST default BLOBLIST_SIZE help Sets the size of the bloblist in bytes after relocation. Since U-Boot @@ -755,6 +764,8 @@ config BLOBLIST_SIZE_RELOC size than the one set up by SPL. This bloblist is set up during the relocation process. +endif # BLOBLIST + endmenu source "common/spl/Kconfig" diff --git a/common/bloblist.c b/common/bloblist.c index 1290fff8504..01b04103d91 100644 --- a/common/bloblist.c +++ b/common/bloblist.c @@ -7,6 +7,7 @@ #include #include #include +#include #include #include #include @@ -416,10 +417,21 @@ int bloblist_init(void) ret = bloblist_check(CONFIG_BLOBLIST_ADDR, CONFIG_BLOBLIST_SIZE); if (ret) { + ulong addr; + log(LOGC_BLOBLIST, expected ? LOGL_WARNING : LOGL_DEBUG, "Existing bloblist not found: creating new bloblist\n"); - ret = bloblist_new(CONFIG_BLOBLIST_ADDR, CONFIG_BLOBLIST_SIZE, - 0); + if (IS_ENABLED(CONFIG_BLOBLIST_ALLOC)) { + void *ptr = memalign(BLOBLIST_ALIGN, + CONFIG_BLOBLIST_SIZE); + + if (!ptr) + return log_msg_ret("alloc", -ENOMEM); + addr = map_to_sysmem(ptr); + } else { + addr = CONFIG_BLOBLIST_ADDR; + } + ret = bloblist_new(addr, CONFIG_BLOBLIST_SIZE, 0); } else { log(LOGC_BLOBLIST, LOGL_DEBUG, "Found existing bloblist\n"); } diff --git a/common/board_f.c b/common/board_f.c index f7ea7c7a1e4..dd69c3b6b77 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -655,8 +655,14 @@ static int reloc_bootstage(void) static int reloc_bloblist(void) { #ifdef CONFIG_BLOBLIST - if (gd->flags & GD_FLG_SKIP_RELOC) + /* + * Relocate only if we are supposed to send it + */ + if ((gd->flags & GD_FLG_SKIP_RELOC) && + CONFIG_BLOBLIST_SIZE == CONFIG_BLOBLIST_SIZE_RELOC) { + debug("Not relocating bloblist\n"); return 0; + } if (gd->new_bloblist) { int size = CONFIG_BLOBLIST_SIZE; diff --git a/doc/develop/bloblist.rst b/doc/develop/bloblist.rst index 317ebc4919d..47274cf8e26 100644 --- a/doc/develop/bloblist.rst +++ b/doc/develop/bloblist.rst @@ -59,6 +59,22 @@ Bloblist provides a fairly simple API which allows blobs to be created and found. All access is via the blob's tag. Blob records are zeroed when added. +Placing the bloblist +-------------------- + +The bloblist is typically positioned at a fixed address by TPL, or SPL. This +is controlled by `CONFIG_BLOBLIST_ADDR`. But in some cases it is preferable to +allocate the bloblist in the malloc() space. Use the `CONFIG_BLOBLIST_ALLOC` +option to enable this. + +The bloblist is automatically relocated as part of U-Boot relocation. Sometimes +it is useful to expand the bloblist in U-Boot proper, since it may want to add +information for use by Linux. Note that this does not mean that Linux needs to +know anything about the bloblist format, just that it is convenient to use +bloblist to place things contiguously in memory. Set +`CONFIG_BLOBLIST_SIZE_RELOC` to define the expanded size, if needed. + + Finishing the bloblist ---------------------- -- cgit v1.3.1 From 89050244c40e79fc24b24ee84e4e668a6dfc336d Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Wed, 24 Nov 2021 09:26:39 -0700 Subject: trace: sandbox: Use only the Kconfig options At present there are Kconfig options for tracing, but sandbox uses plain #defines to set them. Correct this and make the tracing command default to enabled so that this is not needed. Signed-off-by: Simon Glass --- cmd/Kconfig | 2 ++ doc/develop/trace.rst | 9 ++------- 2 files changed, 4 insertions(+), 7 deletions(-) (limited to 'doc/develop') diff --git a/cmd/Kconfig b/cmd/Kconfig index 5b30b13e438..fd8f0227c89 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -2350,6 +2350,8 @@ config CMD_LOG config CMD_TRACE bool "trace - Support tracing of function calls and timing" + depends on TRACE + default y help Enables a command to control using of function tracing within U-Boot. This allows recording of call traces including timing diff --git a/doc/develop/trace.rst b/doc/develop/trace.rst index 09f5745a909..b22e068ef9e 100644 --- a/doc/develop/trace.rst +++ b/doc/develop/trace.rst @@ -30,16 +30,11 @@ Sandbox is a build of U-Boot that can run under Linux so it is a convenient way of trying out tracing before you use it on your actual board. To do this, follow these steps: -Add the following to include/configs/sandbox.h (if not already there) +Add the following to config/sandbox_defconfig .. code-block:: c - #define CONFIG_TRACE - #define CONFIG_CMD_TRACE - #define CONFIG_TRACE_BUFFER_SIZE (16 << 20) - #define CONFIG_TRACE_EARLY_SIZE (8 << 20) - #define CONFIG_TRACE_EARLY - #define CONFIG_TRACE_EARLY_ADDR 0x00100000 + CONFIG_TRACE=y Build sandbox U-Boot with tracing enabled: -- cgit v1.3.1 From 6ce2237a4076a323e6dcaa92c6f22a149fef6f28 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Wed, 24 Nov 2021 09:26:45 -0700 Subject: keyboard: Add a migration message A few boards still use the old keyboard mechanism. Set a deadline for them to update to driver model. Signed-off-by: Simon Glass --- Makefile | 1 + doc/develop/driver-model/migration.rst | 8 ++++++++ 2 files changed, 9 insertions(+) (limited to 'doc/develop') diff --git a/Makefile b/Makefile index 1885f364201..ab32efb4d11 100644 --- a/Makefile +++ b/Makefile @@ -1123,6 +1123,7 @@ endif $(CONFIG_WATCHDOG)$(CONFIG_HW_WATCHDOG)) $(call deprecated,CONFIG_DM_ETH,Ethernet drivers,v2020.07,$(CONFIG_NET)) $(call deprecated,CONFIG_DM_I2C,I2C drivers,v2022.04,$(CONFIG_SYS_I2C_LEGACY)) + $(call deprecated,CONFIG_DM_KEYBOARD,Keyboard drivers,v2022.10,$(CONFIG_KEYBOARD)) @# Check that this build does not use CONFIG options that we do not @# know about unless they are in Kconfig. All the existing CONFIG @# options are whitelisted, so new ones should not be added. diff --git a/doc/develop/driver-model/migration.rst b/doc/develop/driver-model/migration.rst index 8bb8601c582..3dbeea6537c 100644 --- a/doc/develop/driver-model/migration.rst +++ b/doc/develop/driver-model/migration.rst @@ -98,3 +98,11 @@ Deadline: 2021.10 The I2C subsystem has supported the driver model since early 2015. Maintainers should submit patches switching over to using CONFIG_DM_I2C and other base driver model options in time for inclusion in the 2021.10 release. + +CONFIG_KEYBOARD +--------------- +Deadline: 2022.10 + +This is a legacy option which has been replaced by driver model. +Maintainers should submit patches switching over to using CONFIG_DM_KEYBOARD and +other base driver model options in time for inclusion in the 2022.10 release. -- cgit v1.3.1 From c3c1614537d4fd2c5b7f1c29887541210bf0b8bd Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Thu, 16 Dec 2021 20:59:09 -0700 Subject: arm: riscv: qemu: Explain how to extract the generated dt QEMU currently generates a devicetree for use with U-Boot. Explain how to obtain it. Also explain how to merge it to produce a devicetree with the U-Boot features included. Signed-off-by: Simon Glass --- doc/board/emulation/qemu-arm.rst | 3 +++ doc/board/emulation/qemu-riscv.rst | 3 +++ doc/develop/devicetree/dt_qemu.rst | 48 ++++++++++++++++++++++++++++++++++++++ doc/develop/devicetree/index.rst | 1 + 4 files changed, 55 insertions(+) create mode 100644 doc/develop/devicetree/dt_qemu.rst (limited to 'doc/develop') diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst index 23abe0964d2..16f66388eb1 100644 --- a/doc/board/emulation/qemu-arm.rst +++ b/doc/board/emulation/qemu-arm.rst @@ -21,6 +21,9 @@ The 'virt' platform provides the following as the basic functionality: Additionally, a number of optional peripherals can be added to the PCI bus. +See :doc:`../../develop/devicetree/dt_qemu` for information on how to see +the devicetree actually generated by QEMU. + Building U-Boot --------------- Set the CROSS_COMPILE environment variable as usual, and run: diff --git a/doc/board/emulation/qemu-riscv.rst b/doc/board/emulation/qemu-riscv.rst index 4b8e104a215..3409fff8117 100644 --- a/doc/board/emulation/qemu-riscv.rst +++ b/doc/board/emulation/qemu-riscv.rst @@ -13,6 +13,9 @@ The QEMU virt machine models a generic RISC-V virtual machine with support for the VirtIO standard networking and block storage devices. It has CLINT, PLIC, 16550A UART devices in addition to VirtIO and it also uses device-tree to pass configuration information to guest software. It implements RISC-V privileged + +See :doc:`../../develop/devicetree/dt_qemu` for information on how to see +the devicetree actually generated by QEMU. architecture spec v1.10. Building U-Boot diff --git a/doc/develop/devicetree/dt_qemu.rst b/doc/develop/devicetree/dt_qemu.rst new file mode 100644 index 00000000000..c25c4fb053d --- /dev/null +++ b/doc/develop/devicetree/dt_qemu.rst @@ -0,0 +1,48 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Devicetree in QEMU +================== + +For QEMU on ARM, RISC-V and one PPC target, the devicetree is created on-the-fly +by QEMU. It is intended for use in Linux but can be used by U-Boot also, so long +as any nodes/properties needed by U-Boot are merged in. + +When `CONFIG_OF_BOARD` is enabled + + +Obtaining the QEMU devicetree +----------------------------- + +Where QEMU generates its own devicetree to pass to U-Boot tou can use +`-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree version. + +To obtain the devicetree that qemu generates, add `-machine dumpdtb=qemu.dtb`, +e.g.:: + + qemu-system-arm -machine virt -machine dumpdtb=qemu.dtb + + qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb + + qemu-system-riscv64 -machine virt -machine dumpdtb=qemu.dtb + + +Merging in U-Boot nodes/properties +---------------------------------- + +Various U-Boot features require nodes and properties in the U-Boot devicetree +and at present QEMU is unaware of these. To use these you must manually merge +in the appropriate pieces. + +One way to do this is with dtc. This command runs dtc on each .dtb file in turn, +to produce a text file. It drops the duplicate header on the qemu one. Then it +joins them up and runs them through dtc to compile the output:: + + qemu-system-arm -machine virt -machine dumpdtb=qemu.dtb + cat <(dtc -I dtb qemu.dtb) <(dtc -I dtb u-boot.dtb |grep -v /dts-v1/) |dtc - -o merged.dtb + +You can then run qemu with the merged devicetree, e.g.:: + + qemu-system-arm -machine virt -nographic -bios u-boot.bin -dtb merged.dtb + +Note that there seems to be a bug in some versions of qemu where the output of +dumpdtb does not quite match what is provided to U-Boot. diff --git a/doc/develop/devicetree/index.rst b/doc/develop/devicetree/index.rst index fa5db3eb76e..2edb69572dd 100644 --- a/doc/develop/devicetree/index.rst +++ b/doc/develop/devicetree/index.rst @@ -11,3 +11,4 @@ build-time and runtime configuration. intro control + dt_qemu -- cgit v1.3.1 From 613cd0c46796cae340382679bc01ef220daf3768 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Wed, 29 Dec 2021 11:57:36 -0700 Subject: efi: Locate all block devices in the app When starting the app, locate all block devices and make them available to U-Boot. This allows listing partitions and accessing files in filesystems. EFI also has the concept of 'disks', meaning boot media. For now, this is not obviously useful in U-Boot, but add code to at least locate these. This can be expanded later as needed. We cannot use printf() in the early stub or app since it is not compiled in Signed-off-by: Simon Glass Reviewed-by: Heinrich Schuchardt --- doc/develop/uefi/u-boot_on_efi.rst | 4 +- include/efi.h | 6 +- include/efi_api.h | 15 +++ lib/efi/efi_app.c | 198 +++++++++++++++++++++++++++++++++++++ 4 files changed, 218 insertions(+), 5 deletions(-) (limited to 'doc/develop') diff --git a/doc/develop/uefi/u-boot_on_efi.rst b/doc/develop/uefi/u-boot_on_efi.rst index 5f2f850f071..8f81b799072 100644 --- a/doc/develop/uefi/u-boot_on_efi.rst +++ b/doc/develop/uefi/u-boot_on_efi.rst @@ -265,9 +265,7 @@ This work could be extended in a number of ways: - Figure out how to solve the interrupt problem -- Add more drivers to the application side (e.g. block devices, USB, - environment access). This would mostly be an academic exercise as a strong - use case is not readily apparent, but it might be fun. +- Add more drivers to the application side (e.g.USB, environment access). - Avoid turning off boot services in the stub. Instead allow U-Boot to make use of boot services in case it wants to. It is unclear what it might want diff --git a/include/efi.h b/include/efi.h index 1432038838a..cd0bdcc717b 100644 --- a/include/efi.h +++ b/include/efi.h @@ -419,10 +419,12 @@ struct efi_priv { * * @handle: handle of the controller on which this driver is installed * @blkio: block io protocol proxied by this driver + * @device_path: EFI path to the device */ struct efi_media_plat { - efi_handle_t handle; - struct efi_block_io *blkio; + efi_handle_t handle; + struct efi_block_io *blkio; + struct efi_device_path *device_path; }; /* Base address of the EFI image */ diff --git a/include/efi_api.h b/include/efi_api.h index 80109f012bc..ec9fa89a935 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -2035,4 +2035,19 @@ struct efi_firmware_management_protocol { const u16 *package_version_name); }; +#define EFI_DISK_IO_PROTOCOL_GUID \ + EFI_GUID(0xce345171, 0xba0b, 0x11d2, 0x8e, 0x4f, \ + 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b) + +struct efi_disk { + u64 revision; + efi_status_t (EFIAPI *read_disk)(struct efi_disk *this, u32 media_id, + u64 offset, efi_uintn_t buffer_size, + void *buffer); + + efi_status_t (EFIAPI *write_disk)(struct efi_disk *this, u32 media_id, + u64 offset, efi_uintn_t buffer_size, + void *buffer); +}; + #endif diff --git a/lib/efi/efi_app.c b/lib/efi/efi_app.c index f61665686c5..4a80633edf1 100644 --- a/lib/efi/efi_app.c +++ b/lib/efi/efi_app.c @@ -21,6 +21,9 @@ #include #include #include +#include +#include +#include DECLARE_GLOBAL_DATA_PTR; @@ -46,6 +49,49 @@ int efi_info_get(enum efi_entry_t type, void **datap, int *sizep) return -ENOSYS; } +/** + * efi_bind_block() - bind a new block device to an EFI device + * + * Binds a new top-level EFI_MEDIA device as well as a child block device so + * that the block device can be accessed in U-Boot. + * + * The device can then be accessed using 'part list efi 0', 'fat ls efi 0:1', + * for example, just like any other interface type. + * + * @handle: handle of the controller on which this driver is installed + * @blkio: block io protocol proxied by this driver + * @device_path: EFI device path structure for this + * @len: Length of @device_path in bytes + * @devp: Returns the bound device + * @return 0 if OK, -ve on error + */ +int efi_bind_block(efi_handle_t handle, struct efi_block_io *blkio, + struct efi_device_path *device_path, int len, + struct udevice **devp) +{ + struct efi_media_plat plat; + struct udevice *dev; + char name[18]; + int ret; + + plat.handle = handle; + plat.blkio = blkio; + plat.device_path = malloc(device_path->length); + if (!plat.device_path) + return log_msg_ret("path", -ENOMEM); + memcpy(plat.device_path, device_path, device_path->length); + ret = device_bind(dm_root(), DM_DRIVER_GET(efi_media), "efi_media", + &plat, ofnode_null(), &dev); + if (ret) + return log_msg_ret("bind", ret); + + snprintf(name, sizeof(name), "efi_media_%x", dev_seq(dev)); + device_set_name(dev, name); + *devp = dev; + + return 0; +} + static efi_status_t setup_memory(struct efi_priv *priv) { struct efi_boot_services *boot = priv->boot; @@ -91,6 +137,14 @@ static efi_status_t setup_memory(struct efi_priv *priv) return 0; } +/** + * free_memory() - Free memory used by the U-Boot app + * + * This frees memory allocated in setup_memory(), in preparation for returning + * to UEFI. It also zeroes the global_data pointer. + * + * @priv: Private EFI data + */ static void free_memory(struct efi_priv *priv) { struct efi_boot_services *boot = priv->boot; @@ -105,6 +159,150 @@ static void free_memory(struct efi_priv *priv) global_data_ptr = NULL; } +/** + * devpath_is_partition() - Figure out if a device path is a partition + * + * Checks if a device path refers to a partition on some media device. This + * works by checking for a valid partition number in a hard-driver media device + * as the final component of the device path. + * + * @path: device path + * Return: true if a partition, false if not + * (e.g. it might be media which contains partitions) + */ +static bool devpath_is_partition(const struct efi_device_path *path) +{ + const struct efi_device_path *p; + bool was_part; + + for (p = path; p->type != DEVICE_PATH_TYPE_END; + p = (void *)p + p->length) { + was_part = false; + if (p->type == DEVICE_PATH_TYPE_MEDIA_DEVICE && + p->sub_type == DEVICE_PATH_SUB_TYPE_HARD_DRIVE_PATH) { + struct efi_device_path_hard_drive_path *hd = + (void *)path; + + if (hd->partition_number) + was_part = true; + } + } + + return was_part; +} + +/** + * setup_block() - Find all block devices and setup EFI devices for them + * + * Partitions are ignored, since U-Boot has partition handling. Errors with + * particular devices produce a warning but execution continues to try to + * find others. + * + * Return: 0 if found, -ENOSYS if there is no boot-services table, -ENOTSUPP + * if a required protocol is not supported + */ +static int setup_block(void) +{ + efi_guid_t efi_blkio_guid = EFI_BLOCK_IO_PROTOCOL_GUID; + efi_guid_t efi_devpath_guid = EFI_DEVICE_PATH_PROTOCOL_GUID; + efi_guid_t efi_pathutil_guid = EFI_DEVICE_PATH_UTILITIES_PROTOCOL_GUID; + efi_guid_t efi_pathtext_guid = EFI_DEVICE_PATH_TO_TEXT_PROTOCOL_GUID; + struct efi_boot_services *boot = efi_get_boot(); + struct efi_device_path_utilities_protocol *util; + struct efi_device_path_to_text_protocol *text; + struct efi_device_path *path; + struct efi_block_io *blkio; + efi_uintn_t num_handles; + efi_handle_t *handle; + int ret, i; + + if (!boot) + return log_msg_ret("sys", -ENOSYS); + + /* Find all devices which support the block I/O protocol */ + ret = boot->locate_handle_buffer(BY_PROTOCOL, &efi_blkio_guid, NULL, + &num_handles, &handle); + if (ret) + return log_msg_ret("loc", -ENOTSUPP); + log_debug("Found %d handles:\n", (int)num_handles); + + /* We need to look up the path size and convert it to text */ + ret = boot->locate_protocol(&efi_pathutil_guid, NULL, (void **)&util); + if (ret) + return log_msg_ret("util", -ENOTSUPP); + ret = boot->locate_protocol(&efi_pathtext_guid, NULL, (void **)&text); + if (ret) + return log_msg_ret("text", -ENOTSUPP); + + for (i = 0; i < num_handles; i++) { + struct udevice *dev; + const u16 *name; + bool is_part; + int len; + + ret = boot->handle_protocol(handle[i], &efi_devpath_guid, + (void **)&path); + if (ret) { + log_warning("- devpath %d failed (ret=%d)\n", i, ret); + continue; + } + + ret = boot->handle_protocol(handle[i], &efi_blkio_guid, + (void **)&blkio); + if (ret) { + log_warning("- blkio %d failed (ret=%d)\n", i, ret); + continue; + } + + name = text->convert_device_path_to_text(path, true, false); + is_part = devpath_is_partition(path); + + if (!is_part) { + len = util->get_device_path_size(path); + ret = efi_bind_block(handle[i], blkio, path, len, &dev); + if (ret) { + log_warning("- blkio bind %d failed (ret=%d)\n", + i, ret); + continue; + } + } else { + dev = NULL; + } + + /* + * Show the device name if we created one. Otherwise indicate + * that it is a partition. + */ + printf("%2d: %-12s %ls\n", i, dev ? dev->name : "", + name); + } + boot->free_pool(handle); + + return 0; +} + +/** + * dm_scan_other() - Scan for UEFI devices that should be available to U-Boot + * + * This sets up block devices within U-Boot for those found in UEFI. With this, + * U-Boot can access those devices + * + * @pre_reloc_only: true to only bind pre-relocation devices (ignored) + * Returns: 0 on success, -ve on error + */ +int dm_scan_other(bool pre_reloc_only) +{ + if (gd->flags & GD_FLG_RELOC) { + int ret; + + ret = setup_block(); + if (ret) + return ret; + } + + return 0; +} + /** * efi_main() - Start an EFI image * -- cgit v1.3.1 From 6e7ad4a45f6e2b036fc56942293b8471ece3341d Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Wed, 29 Dec 2021 11:57:38 -0700 Subject: x86: Allow booting a kernel from the EFI app At present this is disabled, but it should work so long as the kernel does not need EFI services. Enable it and add a note about remaining work. Signed-off-by: Simon Glass --- arch/x86/lib/bootm.c | 11 +++++++---- doc/develop/uefi/u-boot_on_efi.rst | 2 +- 2 files changed, 8 insertions(+), 5 deletions(-) (limited to 'doc/develop') diff --git a/arch/x86/lib/bootm.c b/arch/x86/lib/bootm.c index 667e5e689e3..57cba5c65d3 100644 --- a/arch/x86/lib/bootm.c +++ b/arch/x86/lib/bootm.c @@ -179,10 +179,14 @@ int boot_linux_kernel(ulong setup_base, ulong load_address, bool image_64bit) * U-Boot is setting them up that way for itself in * arch/i386/cpu/cpu.c. * - * Note that we cannot currently boot a kernel while running as - * an EFI application. Please use the payload option for that. + * Note: this is incomplete for EFI kernels! + * + * This can boot a kernel while running as an EFI application, + * but if the kernel requires EFI support then that support needs + * to be enabled first (see EFI_LOADER). Also the EFI information + * must enabled with setup_efi_info(). See setup_zimage() for + * how this is done with the stub. */ -#ifndef CONFIG_EFI_APP __asm__ __volatile__ ( "movl $0, %%ebp\n" "cli\n" @@ -191,7 +195,6 @@ int boot_linux_kernel(ulong setup_base, ulong load_address, bool image_64bit) [boot_params] "S"(setup_base), "b"(0), "D"(0) ); -#endif } /* We can't get to here */ diff --git a/doc/develop/uefi/u-boot_on_efi.rst b/doc/develop/uefi/u-boot_on_efi.rst index 8f81b799072..acad6397e81 100644 --- a/doc/develop/uefi/u-boot_on_efi.rst +++ b/doc/develop/uefi/u-boot_on_efi.rst @@ -269,7 +269,7 @@ This work could be extended in a number of ways: - Avoid turning off boot services in the stub. Instead allow U-Boot to make use of boot services in case it wants to. It is unclear what it might want - though. + though. It is better to use the app. Where is the code? ------------------ -- cgit v1.3.1