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

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