Hi Christian, On Fri, 13 Aug 2021 at 04:02, Heinrich Schuchardt <xypron.g...@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.me...@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
