Re: [U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command
On 26.12.15 19:55, Leif Lindholm wrote: > On Fri, Dec 25, 2015 at 10:25:22AM +0100, Andreas Färber wrote: >> Am 25.12.2015 um 10:02 schrieb Alexander Graf: >> [snip] >>> The reason I implemented "bootefi" was really because it's the natural >>> fit into how U-Boot handles all other formats today. I don't think this >>> is going to be the last patch set around EFI support. >> >> I think what Matwey was suggesting is integrating your "bootefi" into >> the standard "distro" boot sequence environment, so that it probes each >> device for an EFI binary and if it finds one runs load and bootefi, >> without the need for any boot.scr. >> >> That would be a follow-up patch. >> >> It however conflicts with your idea of having some potentially >> board-specific code mess with "fdt addr" command before running "bootefi". > > This could however be resolved by moving to a model where the > device-tree was considered a component of the firmware (which is how > we treat it in UEFI). If U-Boot had an awareness (if it does not > already) of an FDT being something it should have and know about, then > this could trivially be passed onto bootefi. > This could means a "default_fdt" environment variable which is loaded > automatically before bootcmd is executed. That part is already the case in my patches :). The difficult bit is what to do when it doesn't work, because the kernel guys consider a dtb to be a "Linux configuration" framework rather than the "hardware description" framework it's supposed to be. Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command
On Fri, Dec 25, 2015 at 10:25:22AM +0100, Andreas Färber wrote: > Am 25.12.2015 um 10:02 schrieb Alexander Graf: > [snip] > > The reason I implemented "bootefi" was really because it's the natural > > fit into how U-Boot handles all other formats today. I don't think this > > is going to be the last patch set around EFI support. > > I think what Matwey was suggesting is integrating your "bootefi" into > the standard "distro" boot sequence environment, so that it probes each > device for an EFI binary and if it finds one runs load and bootefi, > without the need for any boot.scr. > > That would be a follow-up patch. > > It however conflicts with your idea of having some potentially > board-specific code mess with "fdt addr" command before running "bootefi". This could however be resolved by moving to a model where the device-tree was considered a component of the firmware (which is how we treat it in UEFI). If U-Boot had an awareness (if it does not already) of an FDT being something it should have and know about, then this could trivially be passed onto bootefi. This could means a "default_fdt" environment variable which is loaded automatically before bootcmd is executed. > My solution would be to give boot.scr preference over *.efi, so that the > user has a way to load dtb and run "bootefi" on his own, and otherwise > fall back to just "bootefi" which'll spit a warning about lack of fdt if > I read that correctly. An explicit bootscript should always override a fallback boot option. And booting the "removable boot path" is a fallback boot option. Regards, Leif ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command
On Fri, Dec 25, 2015 at 10:02:44AM +0100, Alexander Graf wrote:
> On 24.12.15 12:15, Matwey V. Kornilov wrote:
> > Why just not to implement standard EFI behaviour when EFI looks for
> > boot-efi partition and proceed?
>
> Well, what is "standard EFI behavior"?
>
> There are 2 standard ways I'm aware of:
>
> 1) NVRAM
>
> The default case for 99.9% of the boots on normal EFI systems is based
> on variables in NVRAM that tell EFI which boot device to boot from.
> Since we don't implement EFI variables today, we can't really make use
> of this feature. And because you want to change the default boot device
> at runtime, we'd have to have runtime services be able to modify them
> after exiting boot services.
>
> 2) Removable Media
>
> There is another way implemented for "Removable Media" - mostly intended
> for USB sticks and the likes. Here EFI searches for a defined file name
> (EFI/boot/boot{arm,a64,x64}.efi) on the ESP partition and boots it.
>
> Part 1 is very difficult to do without major rework of a few U-Boot
> components. If EFI becomes the de-facto standard way of booting with
> U-Boot, I think we'll walk down that road, but it's nothing I want to
> have to deal with in the initial enablement discussion.
>
> Part 2 is easy to do. But then again it's also easy to do it using a
> boot script. Or a compiled in bootcmd. If it's really desired.
Sure, I've seen a lot more complicated boot operations than that
shipped in the default environment of many platforms.
> Which brings me to the next idea. What if we just implement exlinux.conf
> support for EFI binaries? Then all you need to do is have an
> extlinux.conf available on your generic EFI media that tells U-Boot
> where to load the grub binary from.
The problem with this is that you're adding things unrelated to UEFI
into a UEFI boot scenario. Now, depending on what you're looking for,
this may be fine - but it will not leave you with the ability to rely
on being able to "just work" with the UEFI support provided by
UEFI-aware operating systems and their installation media.
Basically, it comes down to preference - is this about:
- Leveraging the benefits of UEFI while staying with the U-Boot
codebase.
or
- Leveraging some of the benefits of UEFI in order to give distros a
more device-independent way of supporting U-Boot platforms.
> That way we wouldn't bend U-Boot completely away from its heritage, make
> use of its flexibility and all distributions that actually care about
> booting from U-Boot would easily be able to just put such a file in an
> rpm an install it always.
You would also need a way to distinguish whether booting with UEFI or
U-Boot efiload.
Sure, compared to stuff like flash-kernel, this is hardly rocket
science, but would be worth standardising early and hard.
> > If ARM board developers will enable EFI support in the future, we can
> > have single one JeOS having all possible dtb in KIWI image.
> > BeagleBone Black has its own u-boot on eMMC, and the user need to push
> > S2 button to force hardware to use our openSUSE u-boot from SD card.
> > Maybe something like that is for other boards. If the single one
> > required u-boot feature is to run EFI grub, then we can even don't
> > touch preinstalled bootloader, that is not possible now, because we
> > need our openSUSE boot scripts.
>
> There are more things we need to solve before we can truly get to a
> universal booting solution. But one step at a time :).
>
> The reason I implemented "bootefi" was really because it's the natural
> fit into how U-Boot handles all other formats today. I don't think this
> is going to be the last patch set around EFI support.
>
>
> Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command
On 24.12.15 12:15, Matwey V. Kornilov wrote:
> Why just not to implement standard EFI behaviour when EFI looks for
> boot-efi partition and proceed?
Well, what is "standard EFI behavior"?
There are 2 standard ways I'm aware of:
1) NVRAM
The default case for 99.9% of the boots on normal EFI systems is based
on variables in NVRAM that tell EFI which boot device to boot from.
Since we don't implement EFI variables today, we can't really make use
of this feature. And because you want to change the default boot device
at runtime, we'd have to have runtime services be able to modify them
after exiting boot services.
2) Removable Media
There is another way implemented for "Removable Media" - mostly intended
for USB sticks and the likes. Here EFI searches for a defined file name
(EFI/boot/boot{arm,a64,x64}.efi) on the ESP partition and boots it.
Part 1 is very difficult to do without major rework of a few U-Boot
components. If EFI becomes the de-facto standard way of booting with
U-Boot, I think we'll walk down that road, but it's nothing I want to
have to deal with in the initial enablement discussion.
Part 2 is easy to do. But then again it's also easy to do it using a
boot script. Or a compiled in bootcmd. If it's really desired.
Which brings me to the next idea. What if we just implement exlinux.conf
support for EFI binaries? Then all you need to do is have an
extlinux.conf available on your generic EFI media that tells U-Boot
where to load the grub binary from.
That way we wouldn't bend U-Boot completely away from its heritage, make
use of its flexibility and all distributions that actually care about
booting from U-Boot would easily be able to just put such a file in an
rpm an install it always.
> If ARM board developers will enable EFI support in the future, we can
> have single one JeOS having all possible dtb in KIWI image.
> BeagleBone Black has its own u-boot on eMMC, and the user need to push
> S2 button to force hardware to use our openSUSE u-boot from SD card.
> Maybe something like that is for other boards. If the single one
> required u-boot feature is to run EFI grub, then we can even don't
> touch preinstalled bootloader, that is not possible now, because we
> need our openSUSE boot scripts.
There are more things we need to solve before we can truly get to a
universal booting solution. But one step at a time :).
The reason I implemented "bootefi" was really because it's the natural
fit into how U-Boot handles all other formats today. I don't think this
is going to be the last patch set around EFI support.
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command
On Fri, Dec 25, 2015 at 12:40:25PM +0300, Matwey V. Kornilov wrote:
> 2015-12-25 12:25 GMT+03:00 Andreas Färber :
> > Am 25.12.2015 um 10:02 schrieb Alexander Graf:
> > [snip]
> >> The reason I implemented "bootefi" was really because it's the natural
> >> fit into how U-Boot handles all other formats today. I don't think this
> >> is going to be the last patch set around EFI support.
> >
> > I think what Matwey was suggesting is integrating your "bootefi" into
> > the standard "distro" boot sequence environment, so that it probes each
> > device for an EFI binary and if it finds one runs load and bootefi,
> > without the need for any boot.scr.
>
> I have no problem if boot{arm,a64,x64}.efi search is implemented via
> standard bootscript.
> But I like idea about extlinux.conf too.
>
> >
> > That would be a follow-up patch.
> >
> > It however conflicts with your idea of having some potentially
> > board-specific code mess with "fdt addr" command before running "bootefi".
> >
> > My solution would be to give boot.scr preference over *.efi, so that the
> > user has a way to load dtb and run "bootefi" on his own, and otherwise
> > fall back to just "bootefi" which'll spit a warning about lack of fdt if
> > I read that correctly.
> >
>
> Yeah, dtb should be anyhow controlled by the user to make workarounds
> possible.
> Funny story about how u-boot detects dtb:
> http://lists.denx.de/pipermail/u-boot/2015-December/237604.html
Yeah. And frankly that's about how it's supposed to work too. That's a
very "funny" Beaglbone Black clone you found there (they neither
verbatim copied the EEPROM contents nor followed the guidelines on how
to get their own name in there). :)
But, in the end it's all a solvable set of problems, after the initial
work is in.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command
On Thu, Dec 24, 2015 at 02:15:52PM +0300, Matwey V. Kornilov wrote: > Why just not to implement standard EFI behaviour when EFI looks for > boot-efi partition and proceed? > > If ARM board developers will enable EFI support in the future, we can > have single one JeOS having all possible dtb in KIWI image. > BeagleBone Black has its own u-boot on eMMC, and the user need to push > S2 button to force hardware to use our openSUSE u-boot from SD card. > Maybe something like that is for other boards. If the single one > required u-boot feature is to run EFI grub, then we can even don't > touch preinstalled bootloader, that is not possible now, because we > need our openSUSE boot scripts. AFAICT once we have the general support in we can simply extend the current generic distro framework to have an iteration on "does the device have the expected EFI boot stuff?" and if so, boot it. Nothing we need to do in C code here. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command
2015-12-25 12:25 GMT+03:00 Andreas Färber :
> Am 25.12.2015 um 10:02 schrieb Alexander Graf:
> [snip]
>> The reason I implemented "bootefi" was really because it's the natural
>> fit into how U-Boot handles all other formats today. I don't think this
>> is going to be the last patch set around EFI support.
>
> I think what Matwey was suggesting is integrating your "bootefi" into
> the standard "distro" boot sequence environment, so that it probes each
> device for an EFI binary and if it finds one runs load and bootefi,
> without the need for any boot.scr.
I have no problem if boot{arm,a64,x64}.efi search is implemented via
standard bootscript.
But I like idea about extlinux.conf too.
>
> That would be a follow-up patch.
>
> It however conflicts with your idea of having some potentially
> board-specific code mess with "fdt addr" command before running "bootefi".
>
> My solution would be to give boot.scr preference over *.efi, so that the
> user has a way to load dtb and run "bootefi" on his own, and otherwise
> fall back to just "bootefi" which'll spit a warning about lack of fdt if
> I read that correctly.
>
Yeah, dtb should be anyhow controlled by the user to make workarounds possible.
Funny story about how u-boot detects dtb:
http://lists.denx.de/pipermail/u-boot/2015-December/237604.html
> Cheers,
> Andreas
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)
--
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2...@jabber.ru
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command
Am 25.12.2015 um 10:02 schrieb Alexander Graf: [snip] > The reason I implemented "bootefi" was really because it's the natural > fit into how U-Boot handles all other formats today. I don't think this > is going to be the last patch set around EFI support. I think what Matwey was suggesting is integrating your "bootefi" into the standard "distro" boot sequence environment, so that it probes each device for an EFI binary and if it finds one runs load and bootefi, without the need for any boot.scr. That would be a follow-up patch. It however conflicts with your idea of having some potentially board-specific code mess with "fdt addr" command before running "bootefi". My solution would be to give boot.scr preference over *.efi, so that the user has a way to load dtb and run "bootefi" on his own, and otherwise fall back to just "bootefi" which'll spit a warning about lack of fdt if I read that correctly. Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command
Why just not to implement standard EFI behaviour when EFI looks for
boot-efi partition and proceed?
If ARM board developers will enable EFI support in the future, we can
have single one JeOS having all possible dtb in KIWI image.
BeagleBone Black has its own u-boot on eMMC, and the user need to push
S2 button to force hardware to use our openSUSE u-boot from SD card.
Maybe something like that is for other boards. If the single one
required u-boot feature is to run EFI grub, then we can even don't
touch preinstalled bootloader, that is not possible now, because we
need our openSUSE boot scripts.
2015-12-22 16:57 GMT+03:00 Alexander Graf :
> In order to execute an EFI application, we need to bridge the gap between
> U-Boot's notion of executing images and EFI's notion of doing the same.
>
> The best path forward IMHO here is to stick completely to the way U-Boot
> deals with payloads. You manually load them using whatever method to RAM
> and then have a simple boot command to execute them. So in our case, you
> would do
>
> # load mmc 0:1 $loadaddr grub.efi
> # bootefi $loadaddr
>
> which then gets you into a grub shell. Fdt information known to U-boot
> via the fdt addr command is also passed to the EFI payload.
>
> Signed-off-by: Alexander Graf
> ---
> common/Makefile | 1 +
> common/cmd_bootefi.c | 168
> +++
> 2 files changed, 169 insertions(+)
> create mode 100644 common/cmd_bootefi.c
>
> diff --git a/common/Makefile b/common/Makefile
> index 2a1d9f8..a7a728a 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -67,6 +67,7 @@ obj-$(CONFIG_CMD_SOURCE) += cmd_source.o
> obj-$(CONFIG_CMD_BDI) += cmd_bdinfo.o
> obj-$(CONFIG_CMD_BEDBUG) += bedbug.o cmd_bedbug.o
> obj-$(CONFIG_CMD_BMP) += cmd_bmp.o
> +obj-$(CONFIG_EFI_LOADER) += cmd_bootefi.o
> obj-$(CONFIG_CMD_BOOTMENU) += cmd_bootmenu.o
> obj-$(CONFIG_CMD_BOOTLDR) += cmd_bootldr.o
> obj-$(CONFIG_CMD_BOOTSTAGE) += cmd_bootstage.o
> diff --git a/common/cmd_bootefi.c b/common/cmd_bootefi.c
> new file mode 100644
> index 000..8d872d0
> --- /dev/null
> +++ b/common/cmd_bootefi.c
> @@ -0,0 +1,168 @@
> +/*
> + * EFI application loader
> + *
> + * Copyright (c) 2015 Alexander Graf
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
> + *
> + * SPDX-License-Identifier: LGPL-2.1+
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +/* This list contains all the EFI objects our payload has access to */
> +LIST_HEAD(efi_obj_list);
> +
> +/*
> + * When booting using the "bootefi" command, we don't know which
> + * physical device the file came from. So we create a pseudo-device
> + * called "bootefi" with the device path /bootefi.
> + *
> + * In addition to the originating device we also declare the file path
> + * of "bootefi" based loads to be /bootefi.
> + */
> +static struct efi_device_path_file_path bootefi_dummy_path[] = {
> + {
> + .dp.type = DEVICE_PATH_TYPE_MEDIA_DEVICE,
> + .dp.sub_type = DEVICE_PATH_SUB_TYPE_FILE_PATH,
> + .dp.length = sizeof(bootefi_dummy_path[0]),
> + .str = { 'b','o','o','t','e','f','i' },
> + }, {
> + .dp.type = DEVICE_PATH_TYPE_END,
> + .dp.sub_type = DEVICE_PATH_SUB_TYPE_END,
> + .dp.length = sizeof(bootefi_dummy_path[0]),
> + }
> +};
> +
> +static efi_status_t bootefi_open_dp(void *handle, efi_guid_t *protocol,
> + void **protocol_interface, void *agent_handle,
> + void *controller_handle, uint32_t attributes)
> +{
> + *protocol_interface = bootefi_dummy_path;
> + return EFI_SUCCESS;
> +}
> +
> +/* The EFI loaded_image interface for the image executed via "bootefi" */
> +static struct efi_loaded_image loaded_image_info = {
> + .device_handle = bootefi_dummy_path,
> + .file_path = bootefi_dummy_path,
> +};
> +
> +/* The EFI object struct for the image executed via "bootefi" */
> +static struct efi_object loaded_image_info_obj = {
> + .handle = &loaded_image_info,
> + .protocols = {
> + {
> + /* When asking for the loaded_image interface, just
> +* return h
[U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command
In order to execute an EFI application, we need to bridge the gap between
U-Boot's notion of executing images and EFI's notion of doing the same.
The best path forward IMHO here is to stick completely to the way U-Boot
deals with payloads. You manually load them using whatever method to RAM
and then have a simple boot command to execute them. So in our case, you
would do
# load mmc 0:1 $loadaddr grub.efi
# bootefi $loadaddr
which then gets you into a grub shell. Fdt information known to U-boot
via the fdt addr command is also passed to the EFI payload.
Signed-off-by: Alexander Graf
---
common/Makefile | 1 +
common/cmd_bootefi.c | 168 +++
2 files changed, 169 insertions(+)
create mode 100644 common/cmd_bootefi.c
diff --git a/common/Makefile b/common/Makefile
index 2a1d9f8..a7a728a 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_CMD_SOURCE) += cmd_source.o
obj-$(CONFIG_CMD_BDI) += cmd_bdinfo.o
obj-$(CONFIG_CMD_BEDBUG) += bedbug.o cmd_bedbug.o
obj-$(CONFIG_CMD_BMP) += cmd_bmp.o
+obj-$(CONFIG_EFI_LOADER) += cmd_bootefi.o
obj-$(CONFIG_CMD_BOOTMENU) += cmd_bootmenu.o
obj-$(CONFIG_CMD_BOOTLDR) += cmd_bootldr.o
obj-$(CONFIG_CMD_BOOTSTAGE) += cmd_bootstage.o
diff --git a/common/cmd_bootefi.c b/common/cmd_bootefi.c
new file mode 100644
index 000..8d872d0
--- /dev/null
+++ b/common/cmd_bootefi.c
@@ -0,0 +1,168 @@
+/*
+ * EFI application loader
+ *
+ * Copyright (c) 2015 Alexander Graf
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
+ *
+ * SPDX-License-Identifier: LGPL-2.1+
+ */
+
+#include
+#include
+#include
+#include
+
+/* This list contains all the EFI objects our payload has access to */
+LIST_HEAD(efi_obj_list);
+
+/*
+ * When booting using the "bootefi" command, we don't know which
+ * physical device the file came from. So we create a pseudo-device
+ * called "bootefi" with the device path /bootefi.
+ *
+ * In addition to the originating device we also declare the file path
+ * of "bootefi" based loads to be /bootefi.
+ */
+static struct efi_device_path_file_path bootefi_dummy_path[] = {
+ {
+ .dp.type = DEVICE_PATH_TYPE_MEDIA_DEVICE,
+ .dp.sub_type = DEVICE_PATH_SUB_TYPE_FILE_PATH,
+ .dp.length = sizeof(bootefi_dummy_path[0]),
+ .str = { 'b','o','o','t','e','f','i' },
+ }, {
+ .dp.type = DEVICE_PATH_TYPE_END,
+ .dp.sub_type = DEVICE_PATH_SUB_TYPE_END,
+ .dp.length = sizeof(bootefi_dummy_path[0]),
+ }
+};
+
+static efi_status_t bootefi_open_dp(void *handle, efi_guid_t *protocol,
+ void **protocol_interface, void *agent_handle,
+ void *controller_handle, uint32_t attributes)
+{
+ *protocol_interface = bootefi_dummy_path;
+ return EFI_SUCCESS;
+}
+
+/* The EFI loaded_image interface for the image executed via "bootefi" */
+static struct efi_loaded_image loaded_image_info = {
+ .device_handle = bootefi_dummy_path,
+ .file_path = bootefi_dummy_path,
+};
+
+/* The EFI object struct for the image executed via "bootefi" */
+static struct efi_object loaded_image_info_obj = {
+ .handle = &loaded_image_info,
+ .protocols = {
+ {
+ /* When asking for the loaded_image interface, just
+* return handle which points to loaded_image_info */
+ .guid = &efi_guid_loaded_image,
+ .open = &efi_return_handle,
+ },
+ {
+ /* When asking for the device path interface, return
+* bootefi_dummy_path */
+ .guid = &efi_guid_device_path,
+ .open = &bootefi_open_dp,
+ },
+ },
+};
+
+/* The EFI object struct for the device the "bootefi" image was loaded from */
+static struct efi_object bootefi_device_obj = {
+ .handle = bootefi_dummy_path,
+ .protocols = {
+ {
+ /* When asking for the device path interface, return
+* bootefi_dummy_path */
+ .guid = &efi_guid_device_path,
+
