Hints on how to use efi_driver/efi_block_device.c

Hints on how to use efi_driver/efi_block_device.c

[Christian Melki]

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

Re: Hints on how to use efi_driver/efi_block_device.c

[Simon Glass]

+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

Re: Hints on how to use efi_driver/efi_block_device.c

[Heinrich Schuchardt]

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

Re: Hints on how to use efi_driver/efi_block_device.c

[AKASHI Takahiro]

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

Re: Hints on how to use efi_driver/efi_block_device.c

[Christian Melki]

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:
> 
> 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).
> 

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:
> 
> * https://u-boot.readthedocs.io/en/latest/develop/uefi/iscsi.html
> * https://archive.fosdem.org/2020/schedule/event/firmware_duwu/
> 

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/drivers/mmc/host/sdhci-acpi.c). 

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

Re: Hints on how to use efi_driver/efi_block_device.c

[Heinrich Schuchardt]

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:
>>
>> 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).
>>
>
> 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:
>>
>> * https://u-boot.readthedocs.io/en/latest/develop/uefi/iscsi.html
>> * https://archive.fosdem.org/2020/schedule/event/firmware_duwu/
>>
>
> 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/drivers/mmc/host/sdhci-acpi.c).
>
> 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

Re: Hints on how to use efi_driver/efi_block_device.c

[Simon Glass]

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:
> >>
> >> 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).
> >>
> >
> > 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:
> >>
> >> * https://u-boot.readthedocs.io/en/latest/develop/uefi/iscsi.html
> >> * https://archive.fosdem.org/2020/schedule/event/firmware_duwu/
> >>
> >
> > 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/drivers/mmc/host/sdhci-acpi.c).
> >
> > 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