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 at 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