* Hints on how to use efi_driver/efi_block_device.c @ 2021-08-12 14:34 Christian Melki 2021-08-12 21:49 ` Simon Glass 2021-08-13 1:21 ` AKASHI Takahiro 0 siblings, 2 replies; 7+ messages in thread From: Christian Melki @ 2021-08-12 14:34 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Hints on how to use efi_driver/efi_block_device.c 2021-08-12 14:34 Hints on how to use efi_driver/efi_block_device.c Christian Melki @ 2021-08-12 21:49 ` Simon Glass 2021-08-13 0:36 ` Heinrich Schuchardt 2021-08-13 1:21 ` AKASHI Takahiro 1 sibling, 1 reply; 7+ messages in thread From: Simon Glass @ 2021-08-12 21:49 UTC (permalink / raw) To: Christian Melki, Heinrich Schuchardt; +Cc: U-Boot Mailing List +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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Hints on how to use efi_driver/efi_block_device.c 2021-08-12 21:49 ` Simon Glass @ 2021-08-13 0:36 ` Heinrich Schuchardt 2021-08-13 7:56 ` Christian Melki 0 siblings, 1 reply; 7+ messages in thread From: Heinrich Schuchardt @ 2021-08-13 0:36 UTC (permalink / raw) To: Christian Melki; +Cc: U-Boot Mailing List, Simon Glass 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Hints on how to use efi_driver/efi_block_device.c 2021-08-13 0:36 ` Heinrich Schuchardt @ 2021-08-13 7:56 ` Christian Melki 2021-08-13 10:02 ` Heinrich Schuchardt 0 siblings, 1 reply; 7+ messages in thread From: Christian Melki @ 2021-08-13 7:56 UTC (permalink / raw) To: Heinrich Schuchardt; +Cc: U-Boot Mailing List, Simon Glass, takahiro.akashi 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Hints on how to use efi_driver/efi_block_device.c 2021-08-13 7:56 ` Christian Melki @ 2021-08-13 10:02 ` Heinrich Schuchardt 2021-09-08 13:30 ` Simon Glass 0 siblings, 1 reply; 7+ messages in thread From: Heinrich Schuchardt @ 2021-08-13 10:02 UTC (permalink / raw) To: Christian Melki; +Cc: U-Boot Mailing List, Simon Glass, takahiro.akashi 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Hints on how to use efi_driver/efi_block_device.c 2021-08-13 10:02 ` Heinrich Schuchardt @ 2021-09-08 13:30 ` Simon Glass 0 siblings, 0 replies; 7+ messages in thread From: Simon Glass @ 2021-09-08 13:30 UTC (permalink / raw) To: Heinrich Schuchardt; +Cc: Christian Melki, U-Boot Mailing List, AKASHI Takahiro 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Hints on how to use efi_driver/efi_block_device.c 2021-08-12 14:34 Hints on how to use efi_driver/efi_block_device.c Christian Melki 2021-08-12 21:49 ` Simon Glass @ 2021-08-13 1:21 ` AKASHI Takahiro 1 sibling, 0 replies; 7+ messages in thread From: AKASHI Takahiro @ 2021-08-13 1:21 UTC (permalink / raw) To: Christian Melki; +Cc: u-boot 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-09-08 13:30 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-08-12 14:34 Hints on how to use efi_driver/efi_block_device.c Christian Melki 2021-08-12 21:49 ` Simon Glass 2021-08-13 0:36 ` Heinrich Schuchardt 2021-08-13 7:56 ` Christian Melki 2021-08-13 10:02 ` Heinrich Schuchardt 2021-09-08 13:30 ` Simon Glass 2021-08-13 1:21 ` AKASHI Takahiro
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.