Hints on how to use efi_driver/efi_block_device.c
I was hoping that U-boot would detect BLOCK_IO devices provided by UEFI automatically. But I can't see anything attached under lsblk or find some other information about this. For example, Barebox works just fine on both Virtualbox and real hardware in this regard.
Barebox does not have an emmc driver for the real hardware but piggybacks off the UEFI protocol for this.
I'm sure that the idea with this U-boot driver is something like that, but would appreciate some hints on how to use it.
Ie, standard usage. UEFI boots of a drive, posts some handles(?) to a block device and U-boot picks it up, not knowing more about the abstracted hardware.
Best regards, Christian
+Heinrich Schuchardt too
On Thu, 12 Aug 2021 at 08:35, Christian Melki christian.melki@t2data.com wrote:
I was hoping that U-boot would detect BLOCK_IO devices provided by UEFI automatically. But I can't see anything attached under lsblk or find some other information about this. For example, Barebox works just fine on both Virtualbox and real hardware in this regard.
Barebox does not have an emmc driver for the real hardware but piggybacks off the UEFI protocol for this.
I'm sure that the idea with this U-boot driver is something like that, but would appreciate some hints on how to use it.
Ie, standard usage. UEFI boots of a drive, posts some handles(?) to a block device and U-boot picks it up, not knowing more about the abstracted hardware.
Best regards, Christian
On 8/12/21 11:49 PM, Simon Glass wrote:
+Heinrich Schuchardt too
On Thu, 12 Aug 2021 at 08:35, Christian Melki christian.melki@t2data.com wrote:
I was hoping that U-boot would detect BLOCK_IO devices provided by UEFI automatically. But I can't see anything attached under lsblk or find some other information about this. For example, Barebox works just fine on both Virtualbox and real hardware in this regard.
Barebox does not have an emmc driver for the real hardware but piggybacks off the UEFI protocol for this.
Hello Christian,
U-Boot can be used in two scenarios:
1) U-Boot is the firmware providing the UEFI API 2) U-Boot is running as an application consuming the UEFI API.
Barebox only supports scenario 2).
I'm sure that the idea with this U-boot driver is something like that, but would appreciate some hints on how to use it.
efi_driver/efi_block_device.c is used in scenario 1).
When a UEFI payload like iPXE provides an EFI_BLOCK_IO_PROTOCOL on a handle and calls ConnectController() U-Boot will install the EFI_SIMPLE_FILE_PROTOCOL for each partition on the block device.
You can find a detailed description of this use case in:
* https://u-boot.readthedocs.io/en/latest/develop/uefi/iscsi.html * https://archive.fosdem.org/2020/schedule/event/firmware_duwu/
Ie, standard usage. UEFI boots of a drive, posts some handles(?) to a block device and U-boot picks it up, not knowing more about the abstracted hardware.
Here you seem be referring to scenario 2).
For scenario 2) support for UEFI block devices has not been implemented, yet. As operating systems like Linux, BSD, Windows all can be booted via UEFI there has not been any use case driving further development of this scenario.
Please, describe what you want to do with U-Boot.
Best regards
Heinrich
On 8/13/21 2:36 AM, Heinrich Schuchardt wrote:
On 8/12/21 11:49 PM, Simon Glass wrote:
+Heinrich Schuchardt too
On Thu, 12 Aug 2021 at 08:35, Christian Melki christian.melki@t2data.com wrote:
I was hoping that U-boot would detect BLOCK_IO devices provided by UEFI automatically. But I can't see anything attached under lsblk or find some other information about this. For example, Barebox works just fine on both Virtualbox and real hardware in this regard.
Barebox does not have an emmc driver for the real hardware but piggybacks off the UEFI protocol for this.
Hello Christian,
U-Boot can be used in two scenarios:
- U-Boot is the firmware providing the UEFI API
- U-Boot is running as an application consuming the UEFI API.
Barebox only supports scenario 2).
Ok.
I'm sure that the idea with this U-boot driver is something like that, but would appreciate some hints on how to use it.
efi_driver/efi_block_device.c is used in scenario 1).
When a UEFI payload like iPXE provides an EFI_BLOCK_IO_PROTOCOL on a handle and calls ConnectController() U-Boot will install the EFI_SIMPLE_FILE_PROTOCOL for each partition on the block device.
You can find a detailed description of this use case in:
I read the fosdem presentation, but apparently did not understand it correctly, as I thought it could be used for presenting the UEFI block IO protocol.
Ie, standard usage. UEFI boots of a drive, posts some handles(?) to a block device and U-boot picks it up, not knowing more about the abstracted hardware.
Here you seem be referring to scenario 2).
For scenario 2) support for UEFI block devices has not been implemented, yet. As operating systems like Linux, BSD, Windows all can be booted via UEFI there has not been any use case driving further development of this scenario.
Please, describe what you want to do with U-Boot.
I have an x86 board (DFI GHF51, AMD Ryzen R1000) with an ACPI presented eMMC. AMDI0040. U-boot does not seem to recognize this device (Linux works fine. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv...).
So I thought the UEFI block IO protocol could come in handy as a generic abstraction. The device works fine under Barebox with this mechanism. So without a native or an UEFI block IO driver I have no disc access in U-boot.
I know that UEFI can boot a EFI-stubbed kernel directly. But I am more comfortable with the U-boot "ecosystem" than UEFI, also it is easier to merge more platforms under the same (existing) boot mechanism/behavior/environment using U-boot as an intermediate than just UEFI (older ARM/PPC etc).
So definitely an use-case for me.
Thanks in advance, Christian
Best regards
Heinrich
On 8/13/21 9:56 AM, Christian Melki wrote:
On 8/13/21 2:36 AM, Heinrich Schuchardt wrote:
On 8/12/21 11:49 PM, Simon Glass wrote:
+Heinrich Schuchardt too
On Thu, 12 Aug 2021 at 08:35, Christian Melki christian.melki@t2data.com wrote:
I was hoping that U-boot would detect BLOCK_IO devices provided by UEFI automatically. But I can't see anything attached under lsblk or find some other information about this. For example, Barebox works just fine on both Virtualbox and real hardware in this regard.
Barebox does not have an emmc driver for the real hardware but piggybacks off the UEFI protocol for this.
Hello Christian,
U-Boot can be used in two scenarios:
- U-Boot is the firmware providing the UEFI API
- U-Boot is running as an application consuming the UEFI API.
Barebox only supports scenario 2).
Ok.
I'm sure that the idea with this U-boot driver is something like that, but would appreciate some hints on how to use it.
efi_driver/efi_block_device.c is used in scenario 1).
When a UEFI payload like iPXE provides an EFI_BLOCK_IO_PROTOCOL on a handle and calls ConnectController() U-Boot will install the EFI_SIMPLE_FILE_PROTOCOL for each partition on the block device.
You can find a detailed description of this use case in:
I read the fosdem presentation, but apparently did not understand it correctly, as I thought it could be used for presenting the UEFI block IO protocol.
Ie, standard usage. UEFI boots of a drive, posts some handles(?) to a block device and U-boot picks it up, not knowing more about the abstracted hardware.
Here you seem be referring to scenario 2).
For scenario 2) support for UEFI block devices has not been implemented, yet. As operating systems like Linux, BSD, Windows all can be booted via UEFI there has not been any use case driving further development of this scenario.
Please, describe what you want to do with U-Boot.
I have an x86 board (DFI GHF51, AMD Ryzen R1000) with an ACPI presented eMMC. AMDI0040. U-boot does not seem to recognize this device (Linux works fine. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv...).
So I thought the UEFI block IO protocol could come in handy as a generic abstraction. The device works fine under Barebox with this mechanism. So without a native or an UEFI block IO driver I have no disc access in U-boot.
I know that UEFI can boot a EFI-stubbed kernel directly. But I am more comfortable with the U-boot "ecosystem" than UEFI, also it is easier to merge more platforms under the same (existing) boot mechanism/behavior/environment using U-boot as an intermediate than just UEFI (older ARM/PPC etc).
There are two ways U-Boot can run on U-Boot:
CONFIG_EFI_STUB, efi-x86_payload64_defconfig: efi_main() calls ExitBootServices(). After this point U-Boot cannot consume any EFI boot services and protocols but has to rely on its own drivers.
CONFIG_EFI_APP, efi-x86_app_defconfig: U-Boot drivers use the UEFI API. Currently the only drivers implemented in this way are:
- console: drivers/serial/serial_efi.c, "efi,uart" - system reset: lib/efi/efi_app.c, "efi,reset" - video: drivers/video/efi.c, "efi-fb"
drivers/video/efi.c is assuming that you have a VESA compatible graphics card and is bypassing the UEFI API to access the framebuffer. To be portable it would have been preferable to provide a UCLASS_VIDEO_CONSOLE driver based on the graphical output protocol.
setup_memory() is another function that is not portable because it tries to access global_data_ptr directly. This variable only exists on x86_64. On ARM and RISC-V set_gd() should be used.
Best regards
Heinrich
So definitely an use-case for me.
Thanks in advance, Christian
Best regards
Heinrich
Hi Christian,
On Fri, 13 Aug 2021 at 04:02, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 8/13/21 9:56 AM, Christian Melki wrote:
On 8/13/21 2:36 AM, Heinrich Schuchardt wrote:
On 8/12/21 11:49 PM, Simon Glass wrote:
+Heinrich Schuchardt too
On Thu, 12 Aug 2021 at 08:35, Christian Melki christian.melki@t2data.com wrote:
I was hoping that U-boot would detect BLOCK_IO devices provided by UEFI automatically. But I can't see anything attached under lsblk or find some other information about this. For example, Barebox works just fine on both Virtualbox and real hardware in this regard.
Barebox does not have an emmc driver for the real hardware but piggybacks off the UEFI protocol for this.
Hello Christian,
U-Boot can be used in two scenarios:
- U-Boot is the firmware providing the UEFI API
- U-Boot is running as an application consuming the UEFI API.
Barebox only supports scenario 2).
Ok.
I'm sure that the idea with this U-boot driver is something like that, but would appreciate some hints on how to use it.
efi_driver/efi_block_device.c is used in scenario 1).
When a UEFI payload like iPXE provides an EFI_BLOCK_IO_PROTOCOL on a handle and calls ConnectController() U-Boot will install the EFI_SIMPLE_FILE_PROTOCOL for each partition on the block device.
You can find a detailed description of this use case in:
I read the fosdem presentation, but apparently did not understand it correctly, as I thought it could be used for presenting the UEFI block IO protocol.
Ie, standard usage. UEFI boots of a drive, posts some handles(?) to a block device and U-boot picks it up, not knowing more about the abstracted hardware.
Here you seem be referring to scenario 2).
For scenario 2) support for UEFI block devices has not been implemented, yet. As operating systems like Linux, BSD, Windows all can be booted via UEFI there has not been any use case driving further development of this scenario.
Please, describe what you want to do with U-Boot.
I have an x86 board (DFI GHF51, AMD Ryzen R1000) with an ACPI presented eMMC. AMDI0040. U-boot does not seem to recognize this device (Linux works fine. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv...).
So I thought the UEFI block IO protocol could come in handy as a generic abstraction. The device works fine under Barebox with this mechanism. So without a native or an UEFI block IO driver I have no disc access in U-boot.
I know that UEFI can boot a EFI-stubbed kernel directly. But I am more comfortable with the U-boot "ecosystem" than UEFI, also it is easier to merge more platforms under the same (existing) boot mechanism/behavior/environment using U-boot as an intermediate than just UEFI (older ARM/PPC etc).
There are two ways U-Boot can run on U-Boot:
CONFIG_EFI_STUB, efi-x86_payload64_defconfig: efi_main() calls ExitBootServices(). After this point U-Boot cannot consume any EFI boot services and protocols but has to rely on its own drivers.
CONFIG_EFI_APP, efi-x86_app_defconfig: U-Boot drivers use the UEFI API. Currently the only drivers implemented in this way are:
- console: drivers/serial/serial_efi.c, "efi,uart"
- system reset: lib/efi/efi_app.c, "efi,reset"
- video: drivers/video/efi.c, "efi-fb"
drivers/video/efi.c is assuming that you have a VESA compatible graphics card and is bypassing the UEFI API to access the framebuffer. To be portable it would have been preferable to provide a UCLASS_VIDEO_CONSOLE driver based on the graphical output protocol.
setup_memory() is another function that is not portable because it tries to access global_data_ptr directly. This variable only exists on x86_64. On ARM and RISC-V set_gd() should be used.
I have a series which tries to address some of these points, at u-boot-dm/efi-working and hope to send it soon.
Regards, Simon
On Thu, Aug 12, 2021 at 04:34:01PM +0200, Christian Melki wrote:
I was hoping that U-boot would detect BLOCK_IO devices provided by UEFI automatically. But I can't see anything attached under lsblk or find some other information about this.
I'm not sure what you intend to do here, but please try the commands, "efidebug devices" and/or "efidebug dh" to find out what you're looking for.
Please note that you have to enumerate (block) devices in advance with, say, "mmc rescan", "scsi scan" (and probably "virtio scan" as well).
-Takahiro Akashi
For example, Barebox works just fine on both Virtualbox and real hardware in this regard.
Barebox does not have an emmc driver for the real hardware but piggybacks off the UEFI protocol for this.
I'm sure that the idea with this U-boot driver is something like that, but would appreciate some hints on how to use it.
Ie, standard usage. UEFI boots of a drive, posts some handles(?) to a block device and U-boot picks it up, not knowing more about the abstracted hardware.
Best regards, Christian
participants (4)
-
AKASHI Takahiro -
Christian Melki -
Heinrich Schuchardt -
Simon Glass