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

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