* [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-10-20 23:34 ` Heinrich Schuchardt
2021-09-25 0:30 ` [PATCH v2 02/39] efi: Add a separate maintainer entry for the app Simon Glass
` (37 subsequent siblings)
38 siblings, 1 reply; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
This code should never have been added as it builds a new feature on top
of legacy code. This has already been improved with the dependency on BLK.
Add a dependency on DM_ETH also, to avoid needing to deal with this old
code.
Boards which want EFI_LOADER should migrate to driver model first.
Note this patch is included to resolve the following build error:
lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
undeclared (first use in this function); did you mean
‘CONFIG_SYS_SRAM_BASE’?
680 | ulong base = CONFIG_SYS_TEXT_BASE;
| ^~~~~~~~~~~~~~~~~~~~
| CONFIG_SYS_SRAM_BASE
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Mention why this patch is included in this series
- Put this patch first so that it is separated from the rest of the series
lib/efi_driver/Makefile | 2 +-
lib/efi_loader/Kconfig | 1 +
lib/efi_loader/efi_device_path.c | 96 +++++++-------------------------
lib/efi_loader/efi_disk.c | 48 ----------------
4 files changed, 23 insertions(+), 124 deletions(-)
diff --git a/lib/efi_driver/Makefile b/lib/efi_driver/Makefile
index 83baa1c9a49..f2b6c05cc24 100644
--- a/lib/efi_driver/Makefile
+++ b/lib/efi_driver/Makefile
@@ -6,6 +6,6 @@
# object inclusion implicitly depends on it
obj-y += efi_uclass.o
-ifeq ($(CONFIG_BLK)$(CONFIG_PARTITIONS),yy)
+ifeq ($(CONFIG_PARTITIONS),y)
obj-y += efi_block_device.o
endif
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 14bf5f7e92e..4d0d2a0e0b7 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -11,6 +11,7 @@ config EFI_LOADER
# We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB
depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT
depends on BLK
+ depends on DM_ETH || !NET
default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8
select LIB_UUID
select PARTITION_UUIDS
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index cbdb466da41..a09090a32e4 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -46,7 +46,7 @@ static const struct efi_device_path_vendor ROOT = {
.guid = U_BOOT_GUID,
};
-#if defined(CONFIG_DM_MMC) && defined(CONFIG_MMC)
+#if defined(CONFIG_MMC)
/*
* Determine if an MMC device is an SD card.
*
@@ -486,7 +486,6 @@ bool efi_dp_is_multi_instance(const struct efi_device_path *dp)
return p->sub_type == DEVICE_PATH_SUB_TYPE_INSTANCE_END;
}
-#ifdef CONFIG_DM
/* size of device-path not including END node for device and all parents
* up to the root device.
*/
@@ -503,7 +502,6 @@ __maybe_unused static unsigned int dp_size(struct udevice *dev)
case UCLASS_ETH:
return dp_size(dev->parent) +
sizeof(struct efi_device_path_mac_addr);
-#ifdef CONFIG_BLK
case UCLASS_BLK:
switch (dev->parent->uclass->uc_drv->id) {
#ifdef CONFIG_IDE
@@ -511,12 +509,12 @@ __maybe_unused static unsigned int dp_size(struct udevice *dev)
return dp_size(dev->parent) +
sizeof(struct efi_device_path_atapi);
#endif
-#if defined(CONFIG_SCSI) && defined(CONFIG_DM_SCSI)
+#if defined(CONFIG_SCSI)
case UCLASS_SCSI:
return dp_size(dev->parent) +
sizeof(struct efi_device_path_scsi);
#endif
-#if defined(CONFIG_DM_MMC) && defined(CONFIG_MMC)
+#if defined(CONFIG_MMC)
case UCLASS_MMC:
return dp_size(dev->parent) +
sizeof(struct efi_device_path_sd_mmc_path);
@@ -554,8 +552,7 @@ __maybe_unused static unsigned int dp_size(struct udevice *dev)
default:
return dp_size(dev->parent);
}
-#endif
-#if defined(CONFIG_DM_MMC) && defined(CONFIG_MMC)
+#if defined(CONFIG_MMC)
case UCLASS_MMC:
return dp_size(dev->parent) +
sizeof(struct efi_device_path_sd_mmc_path);
@@ -590,7 +587,7 @@ __maybe_unused static void *dp_fill(void *buf, struct udevice *dev)
*vdp = ROOT;
return &vdp[1];
}
-#ifdef CONFIG_DM_ETH
+#ifdef CONFIG_NET
case UCLASS_ETH: {
struct efi_device_path_mac_addr *dp =
dp_fill(buf, dev->parent);
@@ -607,7 +604,6 @@ __maybe_unused static void *dp_fill(void *buf, struct udevice *dev)
return &dp[1];
}
#endif
-#ifdef CONFIG_BLK
case UCLASS_BLK:
switch (dev->parent->uclass->uc_drv->id) {
#ifdef CONFIG_SANDBOX
@@ -662,7 +658,7 @@ __maybe_unused static void *dp_fill(void *buf, struct udevice *dev)
return &dp[1];
}
#endif
-#if defined(CONFIG_SCSI) && defined(CONFIG_DM_SCSI)
+#if defined(CONFIG_SCSI)
case UCLASS_SCSI: {
struct efi_device_path_scsi *dp =
dp_fill(buf, dev->parent);
@@ -676,7 +672,7 @@ __maybe_unused static void *dp_fill(void *buf, struct udevice *dev)
return &dp[1];
}
#endif
-#if defined(CONFIG_DM_MMC) && defined(CONFIG_MMC)
+#if defined(CONFIG_MMC)
case UCLASS_MMC: {
struct efi_device_path_sd_mmc_path *sddp =
dp_fill(buf, dev->parent);
@@ -727,8 +723,7 @@ __maybe_unused static void *dp_fill(void *buf, struct udevice *dev)
dev->name, dev->parent->uclass->uc_drv->id);
return dp_fill(buf, dev->parent);
}
-#endif
-#if defined(CONFIG_DM_MMC) && defined(CONFIG_MMC)
+#if defined(CONFIG_MMC)
case UCLASS_MMC: {
struct efi_device_path_sd_mmc_path *sddp =
dp_fill(buf, dev->parent);
@@ -770,24 +765,18 @@ __maybe_unused static void *dp_fill(void *buf, struct udevice *dev)
return dp_fill(buf, dev->parent);
}
}
-#endif
static unsigned dp_part_size(struct blk_desc *desc, int part)
{
unsigned dpsize;
+ struct udevice *dev;
+ int ret;
-#ifdef CONFIG_BLK
- {
- struct udevice *dev;
- int ret = blk_find_device(desc->if_type, desc->devnum, &dev);
+ ret = blk_find_device(desc->if_type, desc->devnum, &dev);
- if (ret)
- dev = desc->bdev->parent;
- dpsize = dp_size(dev);
- }
-#else
- dpsize = sizeof(ROOT) + sizeof(struct efi_device_path_usb);
-#endif
+ if (ret)
+ dev = desc->bdev->parent;
+ dpsize = dp_size(dev);
if (part == 0) /* the actual disk, not a partition */
return dpsize;
@@ -877,36 +866,14 @@ static void *dp_part_node(void *buf, struct blk_desc *desc, int part)
*/
static void *dp_part_fill(void *buf, struct blk_desc *desc, int part)
{
-#ifdef CONFIG_BLK
- {
- struct udevice *dev;
- int ret = blk_find_device(desc->if_type, desc->devnum, &dev);
+ struct udevice *dev;
+ int ret;
- if (ret)
- dev = desc->bdev->parent;
- buf = dp_fill(buf, dev);
- }
-#else
- /*
- * We *could* make a more accurate path, by looking at if_type
- * and handling all the different cases like we do for non-
- * legacy (i.e. CONFIG_BLK=y) case. But most important thing
- * is just to have a unique device-path for if_type+devnum.
- * So map things to a fictitious USB device.
- */
- struct efi_device_path_usb *udp;
-
- memcpy(buf, &ROOT, sizeof(ROOT));
- buf += sizeof(ROOT);
-
- udp = buf;
- udp->dp.type = DEVICE_PATH_TYPE_MESSAGING_DEVICE;
- udp->dp.sub_type = DEVICE_PATH_SUB_TYPE_MSG_USB;
- udp->dp.length = sizeof(*udp);
- udp->parent_port_number = desc->if_type;
- udp->usb_interface = desc->devnum;
- buf = &udp[1];
-#endif
+ ret = blk_find_device(desc->if_type, desc->devnum, &dev);
+
+ if (ret)
+ dev = desc->bdev->parent;
+ buf = dp_fill(buf, dev);
if (part == 0) /* the actual disk, not a partition */
return buf;
@@ -1051,39 +1018,18 @@ struct efi_device_path *efi_dp_from_uart(void)
#ifdef CONFIG_NET
struct efi_device_path *efi_dp_from_eth(void)
{
-#ifndef CONFIG_DM_ETH
- struct efi_device_path_mac_addr *ndp;
-#endif
void *buf, *start;
unsigned dpsize = 0;
assert(eth_get_dev());
-#ifdef CONFIG_DM_ETH
dpsize += dp_size(eth_get_dev());
-#else
- dpsize += sizeof(ROOT);
- dpsize += sizeof(*ndp);
-#endif
start = buf = dp_alloc(dpsize + sizeof(END));
if (!buf)
return NULL;
-#ifdef CONFIG_DM_ETH
buf = dp_fill(buf, eth_get_dev());
-#else
- memcpy(buf, &ROOT, sizeof(ROOT));
- buf += sizeof(ROOT);
-
- ndp = buf;
- ndp->dp.type = DEVICE_PATH_TYPE_MESSAGING_DEVICE;
- ndp->dp.sub_type = DEVICE_PATH_SUB_TYPE_MSG_MAC_ADDR;
- ndp->dp.length = sizeof(*ndp);
- ndp->if_type = 1; /* Ethernet */
- memcpy(ndp->mac.addr, eth_get_ethaddr(), ARP_HLEN);
- buf = &ndp[1];
-#endif
*((struct efi_device_path *)buf) = END;
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 988907ecb91..ef8b5c88ff9 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -555,7 +555,6 @@ efi_status_t efi_disk_register(void)
struct efi_disk_obj *disk;
int disks = 0;
efi_status_t ret;
-#ifdef CONFIG_BLK
struct udevice *dev;
for (uclass_first_device_check(UCLASS_BLK, &dev); dev;
@@ -583,54 +582,7 @@ efi_status_t efi_disk_register(void)
&disk->header, desc, if_typename,
desc->devnum, dev->name);
}
-#else
- int i, if_type;
- /* Search for all available disk devices */
- for (if_type = 0; if_type < IF_TYPE_COUNT; if_type++) {
- const struct blk_driver *cur_drvr;
- const char *if_typename;
-
- cur_drvr = blk_driver_lookup_type(if_type);
- if (!cur_drvr)
- continue;
-
- if_typename = cur_drvr->if_typename;
- log_info("Scanning disks on %s...\n", if_typename);
- for (i = 0; i < 4; i++) {
- struct blk_desc *desc;
- char devname[32] = { 0 }; /* dp->str is u16[32] long */
-
- desc = blk_get_devnum_by_type(if_type, i);
- if (!desc)
- continue;
- if (desc->type == DEV_TYPE_UNKNOWN)
- continue;
-
- snprintf(devname, sizeof(devname), "%s%d",
- if_typename, i);
-
- /* Add block device for the full device */
- ret = efi_disk_add_dev(NULL, NULL, if_typename, desc,
- i, NULL, 0, &disk);
- if (ret == EFI_NOT_READY) {
- log_notice("Disk %s not ready\n", devname);
- continue;
- }
- if (ret) {
- log_err("ERROR: failure to add disk device %s, r = %lu\n",
- devname, ret & ~EFI_ERROR_MASK);
- return ret;
- }
- disks++;
-
- /* Partitions show up as block devices in EFI */
- disks += efi_disk_create_partitions
- (&disk->header, desc,
- if_typename, i, devname);
- }
- }
-#endif
log_info("Found %d disks\n", disks);
return EFI_SUCCESS;
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model
2021-09-25 0:30 ` [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model Simon Glass
@ 2021-10-20 23:34 ` Heinrich Schuchardt
2022-10-14 11:51 ` Jan Kiszka
0 siblings, 1 reply; 74+ messages in thread
From: Heinrich Schuchardt @ 2021-10-20 23:34 UTC (permalink / raw)
To: Simon Glass
Cc: Bin Meng, Christian Melki, Tom Rini, Ilias Apalodimas,
U-Boot Mailing List, Alexander Graf
On 9/25/21 2:30 AM, Simon Glass wrote:
> This code should never have been added as it builds a new feature on top
> of legacy code. This has already been improved with the dependency on BLK.
>
> Add a dependency on DM_ETH also, to avoid needing to deal with this old
> code.
>
> Boards which want EFI_LOADER should migrate to driver model first.
>
> Note this patch is included to resolve the following build error:
>
> lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
> undeclared (first use in this function); did you mean
> ‘CONFIG_SYS_SRAM_BASE’?
> 680 | ulong base = CONFIG_SYS_TEXT_BASE;
> | ^~~~~~~~~~~~~~~~~~~~
> | CONFIG_SYS_SRAM_BASE
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model
2021-10-20 23:34 ` Heinrich Schuchardt
@ 2022-10-14 11:51 ` Jan Kiszka
2022-10-14 13:13 ` Tom Rini
2022-10-14 15:10 ` Heinrich Schuchardt
0 siblings, 2 replies; 74+ messages in thread
From: Jan Kiszka @ 2022-10-14 11:51 UTC (permalink / raw)
To: Heinrich Schuchardt, Simon Glass
Cc: Bin Meng, Christian Melki, Tom Rini, Ilias Apalodimas,
U-Boot Mailing List, Alexander Graf
On 21.10.21 01:34, Heinrich Schuchardt wrote:
> On 9/25/21 2:30 AM, Simon Glass wrote:
>> This code should never have been added as it builds a new feature on top
>> of legacy code. This has already been improved with the dependency on
>> BLK.
>>
>> Add a dependency on DM_ETH also, to avoid needing to deal with this old
>> code.
>>
>> Boards which want EFI_LOADER should migrate to driver model first.
>>
>> Note this patch is included to resolve the following build error:
>>
>> lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
>> undeclared (first use in this function); did you mean
>> ‘CONFIG_SYS_SRAM_BASE’?
>> 680 | ulong base = CONFIG_SYS_TEXT_BASE;
>> | ^~~~~~~~~~~~~~~~~~~~
>> | CONFIG_SYS_SRAM_BASE
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>
> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>
How to deal with boards that need CONFIG_NET but do not actually
implement any driver (yet)? This now broke UEFI for the IOT2050 which
needs NET for network-related device tree setup (see also [1]) and
enforces a local hack for us.
Jan
[1]
https://lore.kernel.org/u-boot/66758c37842d0524d89715b03f05898c2136abef.1664958832.git.jan.kiszka@siemens.com/
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model
2022-10-14 11:51 ` Jan Kiszka
@ 2022-10-14 13:13 ` Tom Rini
2022-10-14 15:33 ` Simon Glass
2022-10-14 15:10 ` Heinrich Schuchardt
1 sibling, 1 reply; 74+ messages in thread
From: Tom Rini @ 2022-10-14 13:13 UTC (permalink / raw)
To: Jan Kiszka, Simon Glass
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Ilias Apalodimas,
U-Boot Mailing List, Alexander Graf
[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]
On Fri, Oct 14, 2022 at 01:51:54PM +0200, Jan Kiszka wrote:
> On 21.10.21 01:34, Heinrich Schuchardt wrote:
> > On 9/25/21 2:30 AM, Simon Glass wrote:
> >> This code should never have been added as it builds a new feature on top
> >> of legacy code. This has already been improved with the dependency on
> >> BLK.
> >>
> >> Add a dependency on DM_ETH also, to avoid needing to deal with this old
> >> code.
> >>
> >> Boards which want EFI_LOADER should migrate to driver model first.
> >>
> >> Note this patch is included to resolve the following build error:
> >>
> >> lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
> >> undeclared (first use in this function); did you mean
> >> ‘CONFIG_SYS_SRAM_BASE’?
> >> 680 | ulong base = CONFIG_SYS_TEXT_BASE;
> >> | ^~~~~~~~~~~~~~~~~~~~
> >> | CONFIG_SYS_SRAM_BASE
> >>
> >> Signed-off-by: Simon Glass <sjg@chromium.org>
> >
> > Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >
>
> How to deal with boards that need CONFIG_NET but do not actually
> implement any driver (yet)? This now broke UEFI for the IOT2050 which
> needs NET for network-related device tree setup (see also [1]) and
> enforces a local hack for us.
Yes, looking at the patch, this should probably use NETDEVICES and not
NET as the test? Would that fix your problem, Jan?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model
2022-10-14 13:13 ` Tom Rini
@ 2022-10-14 15:33 ` Simon Glass
2022-10-14 15:34 ` Jan Kiszka
0 siblings, 1 reply; 74+ messages in thread
From: Simon Glass @ 2022-10-14 15:33 UTC (permalink / raw)
To: Tom Rini
Cc: Jan Kiszka, Heinrich Schuchardt, Bin Meng, Christian Melki,
Ilias Apalodimas, U-Boot Mailing List, Alexander Graf
Hi Tom,
On Fri, 14 Oct 2022 at 07:13, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Oct 14, 2022 at 01:51:54PM +0200, Jan Kiszka wrote:
> > On 21.10.21 01:34, Heinrich Schuchardt wrote:
> > > On 9/25/21 2:30 AM, Simon Glass wrote:
> > >> This code should never have been added as it builds a new feature on top
> > >> of legacy code. This has already been improved with the dependency on
> > >> BLK.
> > >>
> > >> Add a dependency on DM_ETH also, to avoid needing to deal with this old
> > >> code.
> > >>
> > >> Boards which want EFI_LOADER should migrate to driver model first.
> > >>
> > >> Note this patch is included to resolve the following build error:
> > >>
> > >> lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
> > >> undeclared (first use in this function); did you mean
> > >> ‘CONFIG_SYS_SRAM_BASE’?
> > >> 680 | ulong base = CONFIG_SYS_TEXT_BASE;
> > >> | ^~~~~~~~~~~~~~~~~~~~
> > >> | CONFIG_SYS_SRAM_BASE
> > >>
> > >> Signed-off-by: Simon Glass <sjg@chromium.org>
> > >
> > > Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > >
> >
> > How to deal with boards that need CONFIG_NET but do not actually
> > implement any driver (yet)? This now broke UEFI for the IOT2050 which
> > needs NET for network-related device tree setup (see also [1]) and
> > enforces a local hack for us.
>
> Yes, looking at the patch, this should probably use NETDEVICES and not
> NET as the test? Would that fix your problem, Jan?
But that selects DM_ETH. You can still enable DM_ETH when there are no
devices, so I'm not sure what the problem is. Can you post an error?
Things should be migrated to DM_ETH by now (end of 2020).
Regards,
Simon
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model
2022-10-14 15:33 ` Simon Glass
@ 2022-10-14 15:34 ` Jan Kiszka
2022-10-14 15:36 ` Simon Glass
0 siblings, 1 reply; 74+ messages in thread
From: Jan Kiszka @ 2022-10-14 15:34 UTC (permalink / raw)
To: Simon Glass, Tom Rini
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Ilias Apalodimas,
U-Boot Mailing List, Alexander Graf
On 14.10.22 17:33, Simon Glass wrote:
> Hi Tom,
>
> On Fri, 14 Oct 2022 at 07:13, Tom Rini <trini@konsulko.com> wrote:
>>
>> On Fri, Oct 14, 2022 at 01:51:54PM +0200, Jan Kiszka wrote:
>>> On 21.10.21 01:34, Heinrich Schuchardt wrote:
>>>> On 9/25/21 2:30 AM, Simon Glass wrote:
>>>>> This code should never have been added as it builds a new feature on top
>>>>> of legacy code. This has already been improved with the dependency on
>>>>> BLK.
>>>>>
>>>>> Add a dependency on DM_ETH also, to avoid needing to deal with this old
>>>>> code.
>>>>>
>>>>> Boards which want EFI_LOADER should migrate to driver model first.
>>>>>
>>>>> Note this patch is included to resolve the following build error:
>>>>>
>>>>> lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
>>>>> undeclared (first use in this function); did you mean
>>>>> ‘CONFIG_SYS_SRAM_BASE’?
>>>>> 680 | ulong base = CONFIG_SYS_TEXT_BASE;
>>>>> | ^~~~~~~~~~~~~~~~~~~~
>>>>> | CONFIG_SYS_SRAM_BASE
>>>>>
>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>
>>>> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>
>>>
>>> How to deal with boards that need CONFIG_NET but do not actually
>>> implement any driver (yet)? This now broke UEFI for the IOT2050 which
>>> needs NET for network-related device tree setup (see also [1]) and
>>> enforces a local hack for us.
>>
>> Yes, looking at the patch, this should probably use NETDEVICES and not
>> NET as the test? Would that fix your problem, Jan?
>
> But that selects DM_ETH. You can still enable DM_ETH when there are no
> devices, so I'm not sure what the problem is. Can you post an error?
>
> Things should be migrated to DM_ETH by now (end of 2020).
>
I am enable DM_ETH now at board-level, just to make EFI_LOADER happy,
but that feels wrong.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model
2022-10-14 15:34 ` Jan Kiszka
@ 2022-10-14 15:36 ` Simon Glass
2022-10-14 15:39 ` Tom Rini
0 siblings, 1 reply; 74+ messages in thread
From: Simon Glass @ 2022-10-14 15:36 UTC (permalink / raw)
To: Jan Kiszka
Cc: Tom Rini, Heinrich Schuchardt, Bin Meng, Christian Melki,
Ilias Apalodimas, U-Boot Mailing List, Alexander Graf
Hi Jan,
On Fri, 14 Oct 2022 at 09:35, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 14.10.22 17:33, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 14 Oct 2022 at 07:13, Tom Rini <trini@konsulko.com> wrote:
> >>
> >> On Fri, Oct 14, 2022 at 01:51:54PM +0200, Jan Kiszka wrote:
> >>> On 21.10.21 01:34, Heinrich Schuchardt wrote:
> >>>> On 9/25/21 2:30 AM, Simon Glass wrote:
> >>>>> This code should never have been added as it builds a new feature on top
> >>>>> of legacy code. This has already been improved with the dependency on
> >>>>> BLK.
> >>>>>
> >>>>> Add a dependency on DM_ETH also, to avoid needing to deal with this old
> >>>>> code.
> >>>>>
> >>>>> Boards which want EFI_LOADER should migrate to driver model first.
> >>>>>
> >>>>> Note this patch is included to resolve the following build error:
> >>>>>
> >>>>> lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
> >>>>> undeclared (first use in this function); did you mean
> >>>>> ‘CONFIG_SYS_SRAM_BASE’?
> >>>>> 680 | ulong base = CONFIG_SYS_TEXT_BASE;
> >>>>> | ^~~~~~~~~~~~~~~~~~~~
> >>>>> | CONFIG_SYS_SRAM_BASE
> >>>>>
> >>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
> >>>>
> >>>> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >>>>
> >>>
> >>> How to deal with boards that need CONFIG_NET but do not actually
> >>> implement any driver (yet)? This now broke UEFI for the IOT2050 which
> >>> needs NET for network-related device tree setup (see also [1]) and
> >>> enforces a local hack for us.
> >>
> >> Yes, looking at the patch, this should probably use NETDEVICES and not
> >> NET as the test? Would that fix your problem, Jan?
> >
> > But that selects DM_ETH. You can still enable DM_ETH when there are no
> > devices, so I'm not sure what the problem is. Can you post an error?
> >
> > Things should be migrated to DM_ETH by now (end of 2020).
> >
>
> I am enable DM_ETH now at board-level, just to make EFI_LOADER happy,
> but that feels wrong.
I agree, but I wonder if this might need some code refactoring.
Perhaps EFI_LOADER_NET needs to be created, net functionality can be
disabled?
Regards,
Simon
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model
2022-10-14 15:36 ` Simon Glass
@ 2022-10-14 15:39 ` Tom Rini
2022-10-14 15:47 ` Jan Kiszka
0 siblings, 1 reply; 74+ messages in thread
From: Tom Rini @ 2022-10-14 15:39 UTC (permalink / raw)
To: Simon Glass
Cc: Jan Kiszka, Heinrich Schuchardt, Bin Meng, Christian Melki,
Ilias Apalodimas, U-Boot Mailing List, Alexander Graf
[-- Attachment #1: Type: text/plain, Size: 2606 bytes --]
On Fri, Oct 14, 2022 at 09:36:46AM -0600, Simon Glass wrote:
> Hi Jan,
>
> On Fri, 14 Oct 2022 at 09:35, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >
> > On 14.10.22 17:33, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 14 Oct 2022 at 07:13, Tom Rini <trini@konsulko.com> wrote:
> > >>
> > >> On Fri, Oct 14, 2022 at 01:51:54PM +0200, Jan Kiszka wrote:
> > >>> On 21.10.21 01:34, Heinrich Schuchardt wrote:
> > >>>> On 9/25/21 2:30 AM, Simon Glass wrote:
> > >>>>> This code should never have been added as it builds a new feature on top
> > >>>>> of legacy code. This has already been improved with the dependency on
> > >>>>> BLK.
> > >>>>>
> > >>>>> Add a dependency on DM_ETH also, to avoid needing to deal with this old
> > >>>>> code.
> > >>>>>
> > >>>>> Boards which want EFI_LOADER should migrate to driver model first.
> > >>>>>
> > >>>>> Note this patch is included to resolve the following build error:
> > >>>>>
> > >>>>> lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
> > >>>>> undeclared (first use in this function); did you mean
> > >>>>> ‘CONFIG_SYS_SRAM_BASE’?
> > >>>>> 680 | ulong base = CONFIG_SYS_TEXT_BASE;
> > >>>>> | ^~~~~~~~~~~~~~~~~~~~
> > >>>>> | CONFIG_SYS_SRAM_BASE
> > >>>>>
> > >>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
> > >>>>
> > >>>> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > >>>>
> > >>>
> > >>> How to deal with boards that need CONFIG_NET but do not actually
> > >>> implement any driver (yet)? This now broke UEFI for the IOT2050 which
> > >>> needs NET for network-related device tree setup (see also [1]) and
> > >>> enforces a local hack for us.
> > >>
> > >> Yes, looking at the patch, this should probably use NETDEVICES and not
> > >> NET as the test? Would that fix your problem, Jan?
> > >
> > > But that selects DM_ETH. You can still enable DM_ETH when there are no
> > > devices, so I'm not sure what the problem is. Can you post an error?
> > >
> > > Things should be migrated to DM_ETH by now (end of 2020).
> > >
> >
> > I am enable DM_ETH now at board-level, just to make EFI_LOADER happy,
> > but that feels wrong.
>
> I agree, but I wonder if this might need some code refactoring.
> Perhaps EFI_LOADER_NET needs to be created, net functionality can be
> disabled?
I think we should be able to leverage existing flags already for this
and not need a new one. The issue is that CONFIG_NET does not mean "we
have network devices" but CONFIG_NETDEVICES does.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model
2022-10-14 15:39 ` Tom Rini
@ 2022-10-14 15:47 ` Jan Kiszka
2022-10-14 15:58 ` Tom Rini
0 siblings, 1 reply; 74+ messages in thread
From: Jan Kiszka @ 2022-10-14 15:47 UTC (permalink / raw)
To: Tom Rini, Simon Glass
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Ilias Apalodimas,
U-Boot Mailing List, Alexander Graf
On 14.10.22 17:39, Tom Rini wrote:
> On Fri, Oct 14, 2022 at 09:36:46AM -0600, Simon Glass wrote:
>> Hi Jan,
>>
>> On Fri, 14 Oct 2022 at 09:35, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>
>>> On 14.10.22 17:33, Simon Glass wrote:
>>>> Hi Tom,
>>>>
>>>> On Fri, 14 Oct 2022 at 07:13, Tom Rini <trini@konsulko.com> wrote:
>>>>>
>>>>> On Fri, Oct 14, 2022 at 01:51:54PM +0200, Jan Kiszka wrote:
>>>>>> On 21.10.21 01:34, Heinrich Schuchardt wrote:
>>>>>>> On 9/25/21 2:30 AM, Simon Glass wrote:
>>>>>>>> This code should never have been added as it builds a new feature on top
>>>>>>>> of legacy code. This has already been improved with the dependency on
>>>>>>>> BLK.
>>>>>>>>
>>>>>>>> Add a dependency on DM_ETH also, to avoid needing to deal with this old
>>>>>>>> code.
>>>>>>>>
>>>>>>>> Boards which want EFI_LOADER should migrate to driver model first.
>>>>>>>>
>>>>>>>> Note this patch is included to resolve the following build error:
>>>>>>>>
>>>>>>>> lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
>>>>>>>> undeclared (first use in this function); did you mean
>>>>>>>> ‘CONFIG_SYS_SRAM_BASE’?
>>>>>>>> 680 | ulong base = CONFIG_SYS_TEXT_BASE;
>>>>>>>> | ^~~~~~~~~~~~~~~~~~~~
>>>>>>>> | CONFIG_SYS_SRAM_BASE
>>>>>>>>
>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>>>
>>>>>>> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>>>>
>>>>>>
>>>>>> How to deal with boards that need CONFIG_NET but do not actually
>>>>>> implement any driver (yet)? This now broke UEFI for the IOT2050 which
>>>>>> needs NET for network-related device tree setup (see also [1]) and
>>>>>> enforces a local hack for us.
>>>>>
>>>>> Yes, looking at the patch, this should probably use NETDEVICES and not
>>>>> NET as the test? Would that fix your problem, Jan?
>>>>
>>>> But that selects DM_ETH. You can still enable DM_ETH when there are no
>>>> devices, so I'm not sure what the problem is. Can you post an error?
>>>>
>>>> Things should be migrated to DM_ETH by now (end of 2020).
>>>>
>>>
>>> I am enable DM_ETH now at board-level, just to make EFI_LOADER happy,
>>> but that feels wrong.
>>
>> I agree, but I wonder if this might need some code refactoring.
>> Perhaps EFI_LOADER_NET needs to be created, net functionality can be
>> disabled?
>
> I think we should be able to leverage existing flags already for this
> and not need a new one. The issue is that CONFIG_NET does not mean "we
> have network devices" but CONFIG_NETDEVICES does.
>
So, you mean fixing up the efi-loader code to use CONFIG_NETDEVICES,
rather than CONFIG_NET? Then we could drop that Kconfig check.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model
2022-10-14 15:47 ` Jan Kiszka
@ 2022-10-14 15:58 ` Tom Rini
0 siblings, 0 replies; 74+ messages in thread
From: Tom Rini @ 2022-10-14 15:58 UTC (permalink / raw)
To: Jan Kiszka
Cc: Simon Glass, Heinrich Schuchardt, Bin Meng, Christian Melki,
Ilias Apalodimas, U-Boot Mailing List, Alexander Graf
[-- Attachment #1: Type: text/plain, Size: 2947 bytes --]
On Fri, Oct 14, 2022 at 05:47:55PM +0200, Jan Kiszka wrote:
> On 14.10.22 17:39, Tom Rini wrote:
> > On Fri, Oct 14, 2022 at 09:36:46AM -0600, Simon Glass wrote:
> >> Hi Jan,
> >>
> >> On Fri, 14 Oct 2022 at 09:35, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>
> >>> On 14.10.22 17:33, Simon Glass wrote:
> >>>> Hi Tom,
> >>>>
> >>>> On Fri, 14 Oct 2022 at 07:13, Tom Rini <trini@konsulko.com> wrote:
> >>>>>
> >>>>> On Fri, Oct 14, 2022 at 01:51:54PM +0200, Jan Kiszka wrote:
> >>>>>> On 21.10.21 01:34, Heinrich Schuchardt wrote:
> >>>>>>> On 9/25/21 2:30 AM, Simon Glass wrote:
> >>>>>>>> This code should never have been added as it builds a new feature on top
> >>>>>>>> of legacy code. This has already been improved with the dependency on
> >>>>>>>> BLK.
> >>>>>>>>
> >>>>>>>> Add a dependency on DM_ETH also, to avoid needing to deal with this old
> >>>>>>>> code.
> >>>>>>>>
> >>>>>>>> Boards which want EFI_LOADER should migrate to driver model first.
> >>>>>>>>
> >>>>>>>> Note this patch is included to resolve the following build error:
> >>>>>>>>
> >>>>>>>> lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
> >>>>>>>> undeclared (first use in this function); did you mean
> >>>>>>>> ‘CONFIG_SYS_SRAM_BASE’?
> >>>>>>>> 680 | ulong base = CONFIG_SYS_TEXT_BASE;
> >>>>>>>> | ^~~~~~~~~~~~~~~~~~~~
> >>>>>>>> | CONFIG_SYS_SRAM_BASE
> >>>>>>>>
> >>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
> >>>>>>>
> >>>>>>> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >>>>>>>
> >>>>>>
> >>>>>> How to deal with boards that need CONFIG_NET but do not actually
> >>>>>> implement any driver (yet)? This now broke UEFI for the IOT2050 which
> >>>>>> needs NET for network-related device tree setup (see also [1]) and
> >>>>>> enforces a local hack for us.
> >>>>>
> >>>>> Yes, looking at the patch, this should probably use NETDEVICES and not
> >>>>> NET as the test? Would that fix your problem, Jan?
> >>>>
> >>>> But that selects DM_ETH. You can still enable DM_ETH when there are no
> >>>> devices, so I'm not sure what the problem is. Can you post an error?
> >>>>
> >>>> Things should be migrated to DM_ETH by now (end of 2020).
> >>>>
> >>>
> >>> I am enable DM_ETH now at board-level, just to make EFI_LOADER happy,
> >>> but that feels wrong.
> >>
> >> I agree, but I wonder if this might need some code refactoring.
> >> Perhaps EFI_LOADER_NET needs to be created, net functionality can be
> >> disabled?
> >
> > I think we should be able to leverage existing flags already for this
> > and not need a new one. The issue is that CONFIG_NET does not mean "we
> > have network devices" but CONFIG_NETDEVICES does.
>
> So, you mean fixing up the efi-loader code to use CONFIG_NETDEVICES,
> rather than CONFIG_NET? Then we could drop that Kconfig check.
Yes.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model
2022-10-14 11:51 ` Jan Kiszka
2022-10-14 13:13 ` Tom Rini
@ 2022-10-14 15:10 ` Heinrich Schuchardt
2022-10-14 15:20 ` Tom Rini
2022-10-14 15:25 ` Jan Kiszka
1 sibling, 2 replies; 74+ messages in thread
From: Heinrich Schuchardt @ 2022-10-14 15:10 UTC (permalink / raw)
To: Jan Kiszka
Cc: Bin Meng, Christian Melki, Tom Rini, Ilias Apalodimas,
U-Boot Mailing List, Alexander Graf, Simon Glass
On 10/14/22 13:51, Jan Kiszka wrote:
> On 21.10.21 01:34, Heinrich Schuchardt wrote:
>> On 9/25/21 2:30 AM, Simon Glass wrote:
>>> This code should never have been added as it builds a new feature on top
>>> of legacy code. This has already been improved with the dependency on
>>> BLK.
>>>
>>> Add a dependency on DM_ETH also, to avoid needing to deal with this old
>>> code.
>>>
>>> Boards which want EFI_LOADER should migrate to driver model first.
>>>
>>> Note this patch is included to resolve the following build error:
>>>
>>> lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
>>> undeclared (first use in this function); did you mean
>>> ‘CONFIG_SYS_SRAM_BASE’?
>>> 680 | ulong base = CONFIG_SYS_TEXT_BASE;
>>> | ^~~~~~~~~~~~~~~~~~~~
>>> | CONFIG_SYS_SRAM_BASE
>>>
>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>
>> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>
>
> How to deal with boards that need CONFIG_NET but do not actually
> implement any driver (yet)? This now broke UEFI for the IOT2050 which
> needs NET for network-related device tree setup (see also [1]) and
> enforces a local hack for us.
UEFI will not provide network without a DM driver.
The migration period ended 2020.07.
make iot2050_defconfig set EFI_LOADER=y.
What does not work in UEFI?
Are you missing a way to call eth_get_dev() to trigger aforementioned
devicetree setup?
Adding 'net list' to CONFIG_PREBOOT might do the trick.
Best regards
Heinrich
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model
2022-10-14 15:10 ` Heinrich Schuchardt
@ 2022-10-14 15:20 ` Tom Rini
2022-10-14 15:27 ` Jan Kiszka
2022-10-14 15:25 ` Jan Kiszka
1 sibling, 1 reply; 74+ messages in thread
From: Tom Rini @ 2022-10-14 15:20 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Jan Kiszka, Bin Meng, Christian Melki, Ilias Apalodimas,
U-Boot Mailing List, Alexander Graf, Simon Glass
[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]
On Fri, Oct 14, 2022 at 05:10:55PM +0200, Heinrich Schuchardt wrote:
> On 10/14/22 13:51, Jan Kiszka wrote:
> > On 21.10.21 01:34, Heinrich Schuchardt wrote:
> > > On 9/25/21 2:30 AM, Simon Glass wrote:
> > > > This code should never have been added as it builds a new feature on top
> > > > of legacy code. This has already been improved with the dependency on
> > > > BLK.
> > > >
> > > > Add a dependency on DM_ETH also, to avoid needing to deal with this old
> > > > code.
> > > >
> > > > Boards which want EFI_LOADER should migrate to driver model first.
> > > >
> > > > Note this patch is included to resolve the following build error:
> > > >
> > > > lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
> > > > undeclared (first use in this function); did you mean
> > > > ‘CONFIG_SYS_SRAM_BASE’?
> > > > 680 | ulong base = CONFIG_SYS_TEXT_BASE;
> > > > | ^~~~~~~~~~~~~~~~~~~~
> > > > | CONFIG_SYS_SRAM_BASE
> > > >
> > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > >
> > > Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > >
> >
> > How to deal with boards that need CONFIG_NET but do not actually
> > implement any driver (yet)? This now broke UEFI for the IOT2050 which
> > needs NET for network-related device tree setup (see also [1]) and
> > enforces a local hack for us.
>
> UEFI will not provide network without a DM driver.
> The migration period ended 2020.07.
>
> make iot2050_defconfig set EFI_LOADER=y.
> What does not work in UEFI?
>
> Are you missing a way to call eth_get_dev() to trigger aforementioned
> devicetree setup?
>
> Adding 'net list' to CONFIG_PREBOOT might do the trick.
I think, and this is why I suggested NETDEVICES, the issue is that there
is no network driver in U-Boot, but we need to have networking support
enabled in general, in order to perform device tree fixups for Linux
where there is the network driver.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model
2022-10-14 15:20 ` Tom Rini
@ 2022-10-14 15:27 ` Jan Kiszka
2022-10-14 15:34 ` Tom Rini
0 siblings, 1 reply; 74+ messages in thread
From: Jan Kiszka @ 2022-10-14 15:27 UTC (permalink / raw)
To: Tom Rini, Heinrich Schuchardt
Cc: Bin Meng, Christian Melki, Ilias Apalodimas, U-Boot Mailing List,
Alexander Graf, Simon Glass
On 14.10.22 17:20, Tom Rini wrote:
> On Fri, Oct 14, 2022 at 05:10:55PM +0200, Heinrich Schuchardt wrote:
>> On 10/14/22 13:51, Jan Kiszka wrote:
>>> On 21.10.21 01:34, Heinrich Schuchardt wrote:
>>>> On 9/25/21 2:30 AM, Simon Glass wrote:
>>>>> This code should never have been added as it builds a new feature on top
>>>>> of legacy code. This has already been improved with the dependency on
>>>>> BLK.
>>>>>
>>>>> Add a dependency on DM_ETH also, to avoid needing to deal with this old
>>>>> code.
>>>>>
>>>>> Boards which want EFI_LOADER should migrate to driver model first.
>>>>>
>>>>> Note this patch is included to resolve the following build error:
>>>>>
>>>>> lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
>>>>> undeclared (first use in this function); did you mean
>>>>> ‘CONFIG_SYS_SRAM_BASE’?
>>>>> 680 | ulong base = CONFIG_SYS_TEXT_BASE;
>>>>> | ^~~~~~~~~~~~~~~~~~~~
>>>>> | CONFIG_SYS_SRAM_BASE
>>>>>
>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>
>>>> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>
>>>
>>> How to deal with boards that need CONFIG_NET but do not actually
>>> implement any driver (yet)? This now broke UEFI for the IOT2050 which
>>> needs NET for network-related device tree setup (see also [1]) and
>>> enforces a local hack for us.
>>
>> UEFI will not provide network without a DM driver.
>> The migration period ended 2020.07.
>>
>> make iot2050_defconfig set EFI_LOADER=y.
>> What does not work in UEFI?
>>
>> Are you missing a way to call eth_get_dev() to trigger aforementioned
>> devicetree setup?
>>
>> Adding 'net list' to CONFIG_PREBOOT might do the trick.
>
> I think, and this is why I suggested NETDEVICES, the issue is that there
> is no network driver in U-Boot, but we need to have networking support
> enabled in general, in order to perform device tree fixups for Linux
> where there is the network driver.
>
Exactly.
Unfortunately, NETDEVICES does not do the trick because it selects
DM_ETH anyway, thus you don't detect legacy network drivers this way.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model
2022-10-14 15:27 ` Jan Kiszka
@ 2022-10-14 15:34 ` Tom Rini
2022-10-14 15:35 ` Jan Kiszka
0 siblings, 1 reply; 74+ messages in thread
From: Tom Rini @ 2022-10-14 15:34 UTC (permalink / raw)
To: Jan Kiszka
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Ilias Apalodimas,
U-Boot Mailing List, Alexander Graf, Simon Glass
[-- Attachment #1: Type: text/plain, Size: 2557 bytes --]
On Fri, Oct 14, 2022 at 05:27:39PM +0200, Jan Kiszka wrote:
> On 14.10.22 17:20, Tom Rini wrote:
> > On Fri, Oct 14, 2022 at 05:10:55PM +0200, Heinrich Schuchardt wrote:
> >> On 10/14/22 13:51, Jan Kiszka wrote:
> >>> On 21.10.21 01:34, Heinrich Schuchardt wrote:
> >>>> On 9/25/21 2:30 AM, Simon Glass wrote:
> >>>>> This code should never have been added as it builds a new feature on top
> >>>>> of legacy code. This has already been improved with the dependency on
> >>>>> BLK.
> >>>>>
> >>>>> Add a dependency on DM_ETH also, to avoid needing to deal with this old
> >>>>> code.
> >>>>>
> >>>>> Boards which want EFI_LOADER should migrate to driver model first.
> >>>>>
> >>>>> Note this patch is included to resolve the following build error:
> >>>>>
> >>>>> lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
> >>>>> undeclared (first use in this function); did you mean
> >>>>> ‘CONFIG_SYS_SRAM_BASE’?
> >>>>> 680 | ulong base = CONFIG_SYS_TEXT_BASE;
> >>>>> | ^~~~~~~~~~~~~~~~~~~~
> >>>>> | CONFIG_SYS_SRAM_BASE
> >>>>>
> >>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
> >>>>
> >>>> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >>>>
> >>>
> >>> How to deal with boards that need CONFIG_NET but do not actually
> >>> implement any driver (yet)? This now broke UEFI for the IOT2050 which
> >>> needs NET for network-related device tree setup (see also [1]) and
> >>> enforces a local hack for us.
> >>
> >> UEFI will not provide network without a DM driver.
> >> The migration period ended 2020.07.
> >>
> >> make iot2050_defconfig set EFI_LOADER=y.
> >> What does not work in UEFI?
> >>
> >> Are you missing a way to call eth_get_dev() to trigger aforementioned
> >> devicetree setup?
> >>
> >> Adding 'net list' to CONFIG_PREBOOT might do the trick.
> >
> > I think, and this is why I suggested NETDEVICES, the issue is that there
> > is no network driver in U-Boot, but we need to have networking support
> > enabled in general, in order to perform device tree fixups for Linux
> > where there is the network driver.
> >
>
> Exactly.
>
> Unfortunately, NETDEVICES does not do the trick because it selects
> DM_ETH anyway, thus you don't detect legacy network drivers this way.
Right, but does your platform enable NETDEVICES? It sounds like it
shouldn't be since you don't have devices in U-Boot? Or something else?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model
2022-10-14 15:34 ` Tom Rini
@ 2022-10-14 15:35 ` Jan Kiszka
2022-10-14 15:38 ` Tom Rini
0 siblings, 1 reply; 74+ messages in thread
From: Jan Kiszka @ 2022-10-14 15:35 UTC (permalink / raw)
To: Tom Rini
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Ilias Apalodimas,
U-Boot Mailing List, Alexander Graf, Simon Glass
On 14.10.22 17:34, Tom Rini wrote:
> On Fri, Oct 14, 2022 at 05:27:39PM +0200, Jan Kiszka wrote:
>> On 14.10.22 17:20, Tom Rini wrote:
>>> On Fri, Oct 14, 2022 at 05:10:55PM +0200, Heinrich Schuchardt wrote:
>>>> On 10/14/22 13:51, Jan Kiszka wrote:
>>>>> On 21.10.21 01:34, Heinrich Schuchardt wrote:
>>>>>> On 9/25/21 2:30 AM, Simon Glass wrote:
>>>>>>> This code should never have been added as it builds a new feature on top
>>>>>>> of legacy code. This has already been improved with the dependency on
>>>>>>> BLK.
>>>>>>>
>>>>>>> Add a dependency on DM_ETH also, to avoid needing to deal with this old
>>>>>>> code.
>>>>>>>
>>>>>>> Boards which want EFI_LOADER should migrate to driver model first.
>>>>>>>
>>>>>>> Note this patch is included to resolve the following build error:
>>>>>>>
>>>>>>> lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
>>>>>>> undeclared (first use in this function); did you mean
>>>>>>> ‘CONFIG_SYS_SRAM_BASE’?
>>>>>>> 680 | ulong base = CONFIG_SYS_TEXT_BASE;
>>>>>>> | ^~~~~~~~~~~~~~~~~~~~
>>>>>>> | CONFIG_SYS_SRAM_BASE
>>>>>>>
>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>>
>>>>>> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>>>
>>>>>
>>>>> How to deal with boards that need CONFIG_NET but do not actually
>>>>> implement any driver (yet)? This now broke UEFI for the IOT2050 which
>>>>> needs NET for network-related device tree setup (see also [1]) and
>>>>> enforces a local hack for us.
>>>>
>>>> UEFI will not provide network without a DM driver.
>>>> The migration period ended 2020.07.
>>>>
>>>> make iot2050_defconfig set EFI_LOADER=y.
>>>> What does not work in UEFI?
>>>>
>>>> Are you missing a way to call eth_get_dev() to trigger aforementioned
>>>> devicetree setup?
>>>>
>>>> Adding 'net list' to CONFIG_PREBOOT might do the trick.
>>>
>>> I think, and this is why I suggested NETDEVICES, the issue is that there
>>> is no network driver in U-Boot, but we need to have networking support
>>> enabled in general, in order to perform device tree fixups for Linux
>>> where there is the network driver.
>>>
>>
>> Exactly.
>>
>> Unfortunately, NETDEVICES does not do the trick because it selects
>> DM_ETH anyway, thus you don't detect legacy network drivers this way.
>
> Right, but does your platform enable NETDEVICES? It sounds like it
> shouldn't be since you don't have devices in U-Boot? Or something else?
>
NETDEVICES is off, obviously.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model
2022-10-14 15:35 ` Jan Kiszka
@ 2022-10-14 15:38 ` Tom Rini
0 siblings, 0 replies; 74+ messages in thread
From: Tom Rini @ 2022-10-14 15:38 UTC (permalink / raw)
To: Jan Kiszka
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Ilias Apalodimas,
U-Boot Mailing List, Alexander Graf, Simon Glass
[-- Attachment #1: Type: text/plain, Size: 2984 bytes --]
On Fri, Oct 14, 2022 at 05:35:43PM +0200, Jan Kiszka wrote:
> On 14.10.22 17:34, Tom Rini wrote:
> > On Fri, Oct 14, 2022 at 05:27:39PM +0200, Jan Kiszka wrote:
> >> On 14.10.22 17:20, Tom Rini wrote:
> >>> On Fri, Oct 14, 2022 at 05:10:55PM +0200, Heinrich Schuchardt wrote:
> >>>> On 10/14/22 13:51, Jan Kiszka wrote:
> >>>>> On 21.10.21 01:34, Heinrich Schuchardt wrote:
> >>>>>> On 9/25/21 2:30 AM, Simon Glass wrote:
> >>>>>>> This code should never have been added as it builds a new feature on top
> >>>>>>> of legacy code. This has already been improved with the dependency on
> >>>>>>> BLK.
> >>>>>>>
> >>>>>>> Add a dependency on DM_ETH also, to avoid needing to deal with this old
> >>>>>>> code.
> >>>>>>>
> >>>>>>> Boards which want EFI_LOADER should migrate to driver model first.
> >>>>>>>
> >>>>>>> Note this patch is included to resolve the following build error:
> >>>>>>>
> >>>>>>> lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
> >>>>>>> undeclared (first use in this function); did you mean
> >>>>>>> ‘CONFIG_SYS_SRAM_BASE’?
> >>>>>>> 680 | ulong base = CONFIG_SYS_TEXT_BASE;
> >>>>>>> | ^~~~~~~~~~~~~~~~~~~~
> >>>>>>> | CONFIG_SYS_SRAM_BASE
> >>>>>>>
> >>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
> >>>>>>
> >>>>>> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >>>>>>
> >>>>>
> >>>>> How to deal with boards that need CONFIG_NET but do not actually
> >>>>> implement any driver (yet)? This now broke UEFI for the IOT2050 which
> >>>>> needs NET for network-related device tree setup (see also [1]) and
> >>>>> enforces a local hack for us.
> >>>>
> >>>> UEFI will not provide network without a DM driver.
> >>>> The migration period ended 2020.07.
> >>>>
> >>>> make iot2050_defconfig set EFI_LOADER=y.
> >>>> What does not work in UEFI?
> >>>>
> >>>> Are you missing a way to call eth_get_dev() to trigger aforementioned
> >>>> devicetree setup?
> >>>>
> >>>> Adding 'net list' to CONFIG_PREBOOT might do the trick.
> >>>
> >>> I think, and this is why I suggested NETDEVICES, the issue is that there
> >>> is no network driver in U-Boot, but we need to have networking support
> >>> enabled in general, in order to perform device tree fixups for Linux
> >>> where there is the network driver.
> >>>
> >>
> >> Exactly.
> >>
> >> Unfortunately, NETDEVICES does not do the trick because it selects
> >> DM_ETH anyway, thus you don't detect legacy network drivers this way.
> >
> > Right, but does your platform enable NETDEVICES? It sounds like it
> > shouldn't be since you don't have devices in U-Boot? Or something else?
> >
>
> NETDEVICES is off, obviously.
Right, so, this patch should make the EFI code test for NETDEVICES and
not NET, and then you wouldn't need to hack in something on your
platform I think.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model
2022-10-14 15:10 ` Heinrich Schuchardt
2022-10-14 15:20 ` Tom Rini
@ 2022-10-14 15:25 ` Jan Kiszka
1 sibling, 0 replies; 74+ messages in thread
From: Jan Kiszka @ 2022-10-14 15:25 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Bin Meng, Christian Melki, Tom Rini, Ilias Apalodimas,
U-Boot Mailing List, Alexander Graf, Simon Glass
On 14.10.22 17:10, Heinrich Schuchardt wrote:
> On 10/14/22 13:51, Jan Kiszka wrote:
>> On 21.10.21 01:34, Heinrich Schuchardt wrote:
>>> On 9/25/21 2:30 AM, Simon Glass wrote:
>>>> This code should never have been added as it builds a new feature on
>>>> top
>>>> of legacy code. This has already been improved with the dependency on
>>>> BLK.
>>>>
>>>> Add a dependency on DM_ETH also, to avoid needing to deal with this old
>>>> code.
>>>>
>>>> Boards which want EFI_LOADER should migrate to driver model first.
>>>>
>>>> Note this patch is included to resolve the following build error:
>>>>
>>>> lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
>>>> undeclared (first use in this function); did you mean
>>>> ‘CONFIG_SYS_SRAM_BASE’?
>>>> 680 | ulong base = CONFIG_SYS_TEXT_BASE;
>>>> | ^~~~~~~~~~~~~~~~~~~~
>>>> | CONFIG_SYS_SRAM_BASE
>>>>
>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>
>>> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>
>>
>> How to deal with boards that need CONFIG_NET but do not actually
>> implement any driver (yet)? This now broke UEFI for the IOT2050 which
>> needs NET for network-related device tree setup (see also [1]) and
>> enforces a local hack for us.
>
> UEFI will not provide network without a DM driver.
> The migration period ended 2020.07.
We are not interested in networking in UEFI so far. We need other
features from CONFIG_NET, namely mac address transfer into the DT.
>
> make iot2050_defconfig set EFI_LOADER=y.
> What does not work in UEFI?
This is a hack, just like my "select DM_ETH" in our board kconfig now.
We want users to be able to configure this via kconfig as well.
>
> Are you missing a way to call eth_get_dev() to trigger aforementioned
> devicetree setup?
Nope, eth_env_set_enetaddr_by_index, and also some networking var flags
for setting CONFIG_ENV_FLAGS_LIST_STATIC. That's what my cited patch
takes care of.
>
> Adding 'net list' to CONFIG_PREBOOT might do the trick.
We don't enable CONFIG_CMD_NET - because there is no network to
configure with it.
Thanks,
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH v2 02/39] efi: Add a separate maintainer entry for the app
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
2021-09-25 0:30 ` [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-10-18 16:36 ` Heinrich Schuchardt
2021-09-25 0:30 ` [PATCH v2 03/39] x86: Keep symbol information in u-boot ELF file Simon Glass
` (36 subsequent siblings)
38 siblings, 1 reply; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
Separate this out slightly from the payload, with a new entry.
We might consider renaming EFI PAYLOAD to EFI LOADER, but that would
require quite a lot of file changes.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Add new patch with maintainer entry
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 687c72dcd83..019c87592c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -700,6 +700,13 @@ F: drivers/core/
F: include/dm/
F: test/dm/
+EFI APP
+M: Simon Glass <sjg@chromium.org>
+M: Heinrich Schuchardt <xypron.glpk@gmx.de>
+S: Maintained
+W: https://u-boot.readthedocs.io/en/latest/develop/uefi/u-boot_on_efi.html
+F: lib/efi/efi_app.c
+
EFI PAYLOAD
M: Heinrich Schuchardt <xypron.glpk@gmx.de>
R: Alexander Graf <agraf@csgraf.de>
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [PATCH v2 02/39] efi: Add a separate maintainer entry for the app
2021-09-25 0:30 ` [PATCH v2 02/39] efi: Add a separate maintainer entry for the app Simon Glass
@ 2021-10-18 16:36 ` Heinrich Schuchardt
0 siblings, 0 replies; 74+ messages in thread
From: Heinrich Schuchardt @ 2021-10-18 16:36 UTC (permalink / raw)
To: Simon Glass, U-Boot Mailing List
Cc: Bin Meng, Christian Melki, Tom Rini, Ilias Apalodimas, Alexander Graf
On 9/25/21 2:30 AM, Simon Glass wrote:
> Separate this out slightly from the payload, with a new entry.
>
> We might consider renaming EFI PAYLOAD to EFI LOADER, but that would
> require quite a lot of file changes.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> ---
>
> Changes in v2:
> - Add new patch with maintainer entry
>
> MAINTAINERS | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 687c72dcd83..019c87592c5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -700,6 +700,13 @@ F: drivers/core/
> F: include/dm/
> F: test/dm/
>
> +EFI APP
> +M: Simon Glass <sjg@chromium.org>
> +M: Heinrich Schuchardt <xypron.glpk@gmx.de>
> +S: Maintained
> +W: https://u-boot.readthedocs.io/en/latest/develop/uefi/u-boot_on_efi.html
> +F: lib/efi/efi_app.c
> +
> EFI PAYLOAD
> M: Heinrich Schuchardt <xypron.glpk@gmx.de>
> R: Alexander Graf <agraf@csgraf.de>
>
^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH v2 03/39] x86: Keep symbol information in u-boot ELF file
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
2021-09-25 0:30 ` [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model Simon Glass
2021-09-25 0:30 ` [PATCH v2 02/39] efi: Add a separate maintainer entry for the app Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 04/39] x86: Create a new header for EFI Simon Glass
` (35 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass
At present this information is stripped when linking. It is useful to keep
it around. Strip it from the .efi files instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/x86/config.mk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/config.mk b/arch/x86/config.mk
index 7a8242562db..589f2aed2bc 100644
--- a/arch/x86/config.mk
+++ b/arch/x86/config.mk
@@ -37,7 +37,7 @@ KBUILD_LDFLAGS += -m $(if $(IS_32BIT),elf_i386,elf_x86_64)
LDFLAGS_EFI_PAYLOAD := -Bsymbolic -Bsymbolic-functions -shared --no-undefined -s
OBJCOPYFLAGS_EFI := -j .text -j .sdata -j .data -j .dynamic -j .dynsym \
- -j .rel -j .rela -j .reloc
+ -j .rel -j .rela -j .reloc --strip-all
# Compiler flags to be added when building UEFI applications
CFLAGS_EFI := -fpic -fshort-wchar
@@ -65,7 +65,7 @@ CPPFLAGS_crt0-efi-$(EFIARCH).o += $(CFLAGS_EFI)
ifeq ($(CONFIG_EFI_APP),y)
PLATFORM_CPPFLAGS += $(CFLAGS_EFI)
-LDFLAGS_FINAL += -znocombreloc -shared -s
+LDFLAGS_FINAL += -znocombreloc -shared
LDSCRIPT := $(LDSCRIPT_EFI)
else
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 04/39] x86: Create a new header for EFI
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (2 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 03/39] x86: Keep symbol information in u-boot ELF file Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-10-18 17:00 ` Heinrich Schuchardt
2021-09-25 0:30 ` [PATCH v2 05/39] x86: Show some EFI info with the bdinfo command Simon Glass
` (34 subsequent siblings)
38 siblings, 1 reply; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass
The setup routines are called from zimage but don't really belong in the
zimage header. Add a new EFI header to house these. Add comments so it is
clear what the functions do.
Note that these functions are x86-specific. The zimage business is not
used on other architectures.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Update commit message to mention that these function are x86-specific
arch/x86/include/asm/efi.h | 32 ++++++++++++++++++++++++++++++++
arch/x86/include/asm/zimage.h | 3 ---
arch/x86/lib/zimage.c | 1 +
3 files changed, 33 insertions(+), 3 deletions(-)
create mode 100644 arch/x86/include/asm/efi.h
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
new file mode 100644
index 00000000000..c1735e4dc5f
--- /dev/null
+++ b/arch/x86/include/asm/efi.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright Google LLC
+ */
+
+#ifndef _ASM_EFI_H_
+#define _ASM_EFI_H_
+
+struct efi_info;
+struct screen_info;
+
+/**
+ * setup_video() - Set up the screen info in the x86 setup
+ *
+ * This is needed so Linux can use the display (when U-Boot is an EFI payload)
+ *
+ * @efi_info: Pointer to place to put the screen info in the x86 setup base
+ */
+void setup_video(struct screen_info *screen_info);
+
+/**
+ * setup_efi_info() - Set up the EFI info needed by Linux to boot
+ *
+ * This writes a suitable signature, table pointers, memory-map pointer, etc.
+ * These are needed for Linux to boot from U-Boot (when U-Boot is an EFI
+ * payload).
+ *
+ * @efi_info: Pointer to place to put the EFI info in the x86 setup base
+ */
+void setup_efi_info(struct efi_info *efi_info);
+
+#endif
diff --git a/arch/x86/include/asm/zimage.h b/arch/x86/include/asm/zimage.h
index 6679767d16b..fa6e7f76e05 100644
--- a/arch/x86/include/asm/zimage.h
+++ b/arch/x86/include/asm/zimage.h
@@ -72,7 +72,4 @@ int setup_zimage(struct boot_params *setup_base, char *cmd_line, int auto_boot,
*/
void zimage_dump(struct boot_params *base_ptr);
-void setup_video(struct screen_info *screen_info);
-void setup_efi_info(struct efi_info *efi_info);
-
#endif
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index 9938c80a42b..7ce02226ef9 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -29,6 +29,7 @@
#include <asm/byteorder.h>
#include <asm/bootm.h>
#include <asm/bootparam.h>
+#include <asm/efi.h>
#include <asm/global_data.h>
#ifdef CONFIG_SYS_COREBOOT
#include <asm/arch/timestamp.h>
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [PATCH v2 04/39] x86: Create a new header for EFI
2021-09-25 0:30 ` [PATCH v2 04/39] x86: Create a new header for EFI Simon Glass
@ 2021-10-18 17:00 ` Heinrich Schuchardt
0 siblings, 0 replies; 74+ messages in thread
From: Heinrich Schuchardt @ 2021-10-18 17:00 UTC (permalink / raw)
To: Simon Glass, U-Boot Mailing List
Cc: Bin Meng, Christian Melki, Tom Rini, Ilias Apalodimas
On 9/25/21 2:30 AM, Simon Glass wrote:
> The setup routines are called from zimage but don't really belong in the
> zimage header. Add a new EFI header to house these. Add comments so it is
> clear what the functions do.
>
> Note that these functions are x86-specific. The zimage business is not
> used on other architectures.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> ---
>
> Changes in v2:
> - Update commit message to mention that these function are x86-specific
>
> arch/x86/include/asm/efi.h | 32 ++++++++++++++++++++++++++++++++
> arch/x86/include/asm/zimage.h | 3 ---
> arch/x86/lib/zimage.c | 1 +
> 3 files changed, 33 insertions(+), 3 deletions(-)
> create mode 100644 arch/x86/include/asm/efi.h
>
> diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
> new file mode 100644
> index 00000000000..c1735e4dc5f
> --- /dev/null
> +++ b/arch/x86/include/asm/efi.h
> @@ -0,0 +1,32 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright Google LLC
> + */
> +
> +#ifndef _ASM_EFI_H_
> +#define _ASM_EFI_H_
> +
> +struct efi_info;
> +struct screen_info;
> +
> +/**
> + * setup_video() - Set up the screen info in the x86 setup
> + *
> + * This is needed so Linux can use the display (when U-Boot is an EFI payload)
> + *
> + * @efi_info: Pointer to place to put the screen info in the x86 setup base
> + */
> +void setup_video(struct screen_info *screen_info);
> +
> +/**
> + * setup_efi_info() - Set up the EFI info needed by Linux to boot
> + *
> + * This writes a suitable signature, table pointers, memory-map pointer, etc.
> + * These are needed for Linux to boot from U-Boot (when U-Boot is an EFI
> + * payload).
> + *
> + * @efi_info: Pointer to place to put the EFI info in the x86 setup base
> + */
> +void setup_efi_info(struct efi_info *efi_info);
> +
> +#endif
> diff --git a/arch/x86/include/asm/zimage.h b/arch/x86/include/asm/zimage.h
> index 6679767d16b..fa6e7f76e05 100644
> --- a/arch/x86/include/asm/zimage.h
> +++ b/arch/x86/include/asm/zimage.h
> @@ -72,7 +72,4 @@ int setup_zimage(struct boot_params *setup_base, char *cmd_line, int auto_boot,
> */
> void zimage_dump(struct boot_params *base_ptr);
>
> -void setup_video(struct screen_info *screen_info);
> -void setup_efi_info(struct efi_info *efi_info);
> -
> #endif
> diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
> index 9938c80a42b..7ce02226ef9 100644
> --- a/arch/x86/lib/zimage.c
> +++ b/arch/x86/lib/zimage.c
> @@ -29,6 +29,7 @@
> #include <asm/byteorder.h>
> #include <asm/bootm.h>
> #include <asm/bootparam.h>
> +#include <asm/efi.h>
> #include <asm/global_data.h>
> #ifdef CONFIG_SYS_COREBOOT
> #include <asm/arch/timestamp.h>
>
^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH v2 05/39] x86: Show some EFI info with the bdinfo command
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (3 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 04/39] x86: Create a new header for EFI Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-10-18 17:10 ` Heinrich Schuchardt
2021-09-25 0:30 ` [PATCH v2 06/39] x86: Tidy up global_data pointer for 64-bit Simon Glass
` (33 subsequent siblings)
38 siblings, 1 reply; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass
It is useful to see some basic EFI info with the command as it forms part
of the information about a board.
Add a hook for this and show the table address as a start.
While here, fix an invalid cast in setup_efi_info(). Note that this
function is using a data structure defined by Linux so we cannot change
it. Also note that ulong is used since this is the standard in U-Boot
(>6k uses), despite there being quite a bit of the more verbose uintptr_t
(930 uses).
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Update commit message to mention why the data structure is like it is
- Update commit message to mention why ulong is used
arch/x86/cpu/efi/payload.c | 13 +++++++++++--
arch/x86/include/asm/efi.h | 7 +++++++
arch/x86/lib/Makefile | 1 +
arch/x86/lib/bdinfo.c | 22 ++++++++++++++++++++++
4 files changed, 41 insertions(+), 2 deletions(-)
create mode 100644 arch/x86/lib/bdinfo.c
diff --git a/arch/x86/cpu/efi/payload.c b/arch/x86/cpu/efi/payload.c
index 9a73b768e9b..3a9f7d72868 100644
--- a/arch/x86/cpu/efi/payload.c
+++ b/arch/x86/cpu/efi/payload.c
@@ -280,15 +280,24 @@ void setup_efi_info(struct efi_info *efi_info)
}
efi_info->efi_memdesc_size = map->desc_size;
efi_info->efi_memdesc_version = map->version;
- efi_info->efi_memmap = (u32)(map->desc);
+ efi_info->efi_memmap = (ulong)(map->desc);
efi_info->efi_memmap_size = size - sizeof(struct efi_entry_memmap);
#ifdef CONFIG_EFI_STUB_64BIT
efi_info->efi_systab_hi = table->sys_table >> 32;
- efi_info->efi_memmap_hi = (u64)(u32)(map->desc) >> 32;
+ efi_info->efi_memmap_hi = (u64)(ulong)map->desc >> 32;
signature = EFI64_LOADER_SIGNATURE;
#else
signature = EFI32_LOADER_SIGNATURE;
#endif
memcpy(&efi_info->efi_loader_signature, signature, 4);
}
+
+void efi_show_bdinfo(void)
+{
+ struct efi_entry_systable *table = NULL;
+ int size, ret;
+
+ ret = efi_info_get(EFIET_SYS_TABLE, (void **)&table, &size);
+ bdinfo_print_num_l("efi_table", (ulong)table);
+}
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index c1735e4dc5f..dfd858b78ba 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -29,4 +29,11 @@ void setup_video(struct screen_info *screen_info);
*/
void setup_efi_info(struct efi_info *efi_info);
+/**
+ * efi_show_bdinfo() - Show information about EFI for the 'bdinfo' command
+ *
+ * This looks up the EFI table pointer and shows related info
+ */
+void efi_show_bdinfo(void);
+
#endif
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 65d9b3bd6a3..18757b29aa9 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -3,6 +3,7 @@
# (C) Copyright 2002-2006
# Wolfgang Denk, DENX Software Engineering, wd@denx.de.
+obj-y += bdinfo.o
ifndef CONFIG_X86_64
ifndef CONFIG_TPL_BUILD
obj-y += bios.o
diff --git a/arch/x86/lib/bdinfo.c b/arch/x86/lib/bdinfo.c
new file mode 100644
index 00000000000..0cb79b01bd3
--- /dev/null
+++ b/arch/x86/lib/bdinfo.c
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * x86-specific information for the 'bd' command
+ *
+ * Copyright 2021 Google LLC
+ */
+
+#include <common.h>
+#include <efi.h>
+#include <init.h>
+#include <asm/efi.h>
+#include <asm/global_data.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+void arch_print_bdinfo(void)
+{
+ bdinfo_print_num_l("prev table", gd->arch.table);
+
+ if (IS_ENABLED(CONFIG_EFI_STUB))
+ efi_show_bdinfo();
+}
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [PATCH v2 05/39] x86: Show some EFI info with the bdinfo command
2021-09-25 0:30 ` [PATCH v2 05/39] x86: Show some EFI info with the bdinfo command Simon Glass
@ 2021-10-18 17:10 ` Heinrich Schuchardt
2021-10-26 3:29 ` Simon Glass
0 siblings, 1 reply; 74+ messages in thread
From: Heinrich Schuchardt @ 2021-10-18 17:10 UTC (permalink / raw)
To: Simon Glass, U-Boot Mailing List
Cc: Bin Meng, Christian Melki, Tom Rini, Ilias Apalodimas
On 9/25/21 2:30 AM, Simon Glass wrote:
> It is useful to see some basic EFI info with the command as it forms part
> of the information about a board.
>
> Add a hook for this and show the table address as a start.
>
> While here, fix an invalid cast in setup_efi_info(). Note that this
> function is using a data structure defined by Linux so we cannot change
> it. Also note that ulong is used since this is the standard in U-Boot
> (>6k uses), despite there being quite a bit of the more verbose uintptr_t
> (930 uses).
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2:
> - Update commit message to mention why the data structure is like it is
> - Update commit message to mention why ulong is used
>
> arch/x86/cpu/efi/payload.c | 13 +++++++++++--
> arch/x86/include/asm/efi.h | 7 +++++++
> arch/x86/lib/Makefile | 1 +
> arch/x86/lib/bdinfo.c | 22 ++++++++++++++++++++++
> 4 files changed, 41 insertions(+), 2 deletions(-)
> create mode 100644 arch/x86/lib/bdinfo.c
>
> diff --git a/arch/x86/cpu/efi/payload.c b/arch/x86/cpu/efi/payload.c
> index 9a73b768e9b..3a9f7d72868 100644
> --- a/arch/x86/cpu/efi/payload.c
> +++ b/arch/x86/cpu/efi/payload.c
> @@ -280,15 +280,24 @@ void setup_efi_info(struct efi_info *efi_info)
> }
> efi_info->efi_memdesc_size = map->desc_size;
> efi_info->efi_memdesc_version = map->version;
> - efi_info->efi_memmap = (u32)(map->desc);
> + efi_info->efi_memmap = (ulong)(map->desc);
> efi_info->efi_memmap_size = size - sizeof(struct efi_entry_memmap);
>
> #ifdef CONFIG_EFI_STUB_64BIT
> efi_info->efi_systab_hi = table->sys_table >> 32;
> - efi_info->efi_memmap_hi = (u64)(u32)(map->desc) >> 32;
> + efi_info->efi_memmap_hi = (u64)(ulong)map->desc >> 32;
> signature = EFI64_LOADER_SIGNATURE;
> #else
> signature = EFI32_LOADER_SIGNATURE;
> #endif
> memcpy(&efi_info->efi_loader_signature, signature, 4);
> }
> +
> +void efi_show_bdinfo(void)
> +{
> + struct efi_entry_systable *table = NULL;
> + int size, ret;
> +
> + ret = efi_info_get(EFIET_SYS_TABLE, (void **)&table, &size);
> + bdinfo_print_num_l("efi_table", (ulong)table);
Some properties of the UEFI API depend on the UEFI API version
(EFI_SYSTEM_TABLE.FirmwareRevision)
The revision of the EFI_FILE_PROTOCOL may also be relevant for U-Boot.
Maybe you want to add this information in a later patch.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> +}
> diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
> index c1735e4dc5f..dfd858b78ba 100644
> --- a/arch/x86/include/asm/efi.h
> +++ b/arch/x86/include/asm/efi.h
> @@ -29,4 +29,11 @@ void setup_video(struct screen_info *screen_info);
> */
> void setup_efi_info(struct efi_info *efi_info);
>
> +/**
> + * efi_show_bdinfo() - Show information about EFI for the 'bdinfo' command
> + *
> + * This looks up the EFI table pointer and shows related info
> + */
> +void efi_show_bdinfo(void);
> +
> #endif
> diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
> index 65d9b3bd6a3..18757b29aa9 100644
> --- a/arch/x86/lib/Makefile
> +++ b/arch/x86/lib/Makefile
> @@ -3,6 +3,7 @@
> # (C) Copyright 2002-2006
> # Wolfgang Denk, DENX Software Engineering, wd@denx.de.
>
> +obj-y += bdinfo.o
> ifndef CONFIG_X86_64
> ifndef CONFIG_TPL_BUILD
> obj-y += bios.o
> diff --git a/arch/x86/lib/bdinfo.c b/arch/x86/lib/bdinfo.c
> new file mode 100644
> index 00000000000..0cb79b01bd3
> --- /dev/null
> +++ b/arch/x86/lib/bdinfo.c
> @@ -0,0 +1,22 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * x86-specific information for the 'bd' command
> + *
> + * Copyright 2021 Google LLC
> + */
> +
> +#include <common.h>
> +#include <efi.h>
> +#include <init.h>
> +#include <asm/efi.h>
> +#include <asm/global_data.h>
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +void arch_print_bdinfo(void)
> +{
> + bdinfo_print_num_l("prev table", gd->arch.table);
> +
> + if (IS_ENABLED(CONFIG_EFI_STUB))
> + efi_show_bdinfo();
> +}
>
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [PATCH v2 05/39] x86: Show some EFI info with the bdinfo command
2021-10-18 17:10 ` Heinrich Schuchardt
@ 2021-10-26 3:29 ` Simon Glass
0 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-10-26 3:29 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: U-Boot Mailing List, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas
Hi Heinrich,
On Mon, 18 Oct 2021 at 11:15, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 9/25/21 2:30 AM, Simon Glass wrote:
> > It is useful to see some basic EFI info with the command as it forms part
> > of the information about a board.
> >
> > Add a hook for this and show the table address as a start.
> >
> > While here, fix an invalid cast in setup_efi_info(). Note that this
> > function is using a data structure defined by Linux so we cannot change
> > it. Also note that ulong is used since this is the standard in U-Boot
> > (>6k uses), despite there being quite a bit of the more verbose uintptr_t
> > (930 uses).
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > Changes in v2:
> > - Update commit message to mention why the data structure is like it is
> > - Update commit message to mention why ulong is used
> >
> > arch/x86/cpu/efi/payload.c | 13 +++++++++++--
> > arch/x86/include/asm/efi.h | 7 +++++++
> > arch/x86/lib/Makefile | 1 +
> > arch/x86/lib/bdinfo.c | 22 ++++++++++++++++++++++
> > 4 files changed, 41 insertions(+), 2 deletions(-)
> > create mode 100644 arch/x86/lib/bdinfo.c
> >
> > diff --git a/arch/x86/cpu/efi/payload.c b/arch/x86/cpu/efi/payload.c
> > index 9a73b768e9b..3a9f7d72868 100644
> > --- a/arch/x86/cpu/efi/payload.c
> > +++ b/arch/x86/cpu/efi/payload.c
> > @@ -280,15 +280,24 @@ void setup_efi_info(struct efi_info *efi_info)
> > }
> > efi_info->efi_memdesc_size = map->desc_size;
> > efi_info->efi_memdesc_version = map->version;
> > - efi_info->efi_memmap = (u32)(map->desc);
> > + efi_info->efi_memmap = (ulong)(map->desc);
> > efi_info->efi_memmap_size = size - sizeof(struct efi_entry_memmap);
> >
> > #ifdef CONFIG_EFI_STUB_64BIT
> > efi_info->efi_systab_hi = table->sys_table >> 32;
> > - efi_info->efi_memmap_hi = (u64)(u32)(map->desc) >> 32;
> > + efi_info->efi_memmap_hi = (u64)(ulong)map->desc >> 32;
> > signature = EFI64_LOADER_SIGNATURE;
> > #else
> > signature = EFI32_LOADER_SIGNATURE;
> > #endif
> > memcpy(&efi_info->efi_loader_signature, signature, 4);
> > }
> > +
> > +void efi_show_bdinfo(void)
> > +{
> > + struct efi_entry_systable *table = NULL;
> > + int size, ret;
> > +
> > + ret = efi_info_get(EFIET_SYS_TABLE, (void **)&table, &size);
> > + bdinfo_print_num_l("efi_table", (ulong)table);
>
> Some properties of the UEFI API depend on the UEFI API version
> (EFI_SYSTEM_TABLE.FirmwareRevision)
OK I will add a patch.
>
> The revision of the EFI_FILE_PROTOCOL may also be relevant for U-Boot.
>
> Maybe you want to add this information in a later patch.
This is tricky because the protocol version is no-longer available
once the payload has loaded.
[..]
Regards,
Simon
^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH v2 06/39] x86: Tidy up global_data pointer for 64-bit
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (4 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 05/39] x86: Show some EFI info with the bdinfo command Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-10-18 17:15 ` Heinrich Schuchardt
2021-09-25 0:30 ` [PATCH v2 07/39] efi: Add a script for building and testing U-Boot on UEFI Simon Glass
` (32 subsequent siblings)
38 siblings, 1 reply; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass
Add an extern declaration so that it is possible to use this macro in
files other than the one that defines it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
(no changes since v1)
arch/x86/cpu/x86_64/cpu.c | 3 +++
arch/x86/include/asm/global_data.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/arch/x86/cpu/x86_64/cpu.c b/arch/x86/cpu/x86_64/cpu.c
index 90a766c3c57..e090b1b478a 100644
--- a/arch/x86/cpu/x86_64/cpu.c
+++ b/arch/x86/cpu/x86_64/cpu.c
@@ -8,6 +8,9 @@
#include <cpu_func.h>
#include <debug_uart.h>
#include <init.h>
+#include <asm/global_data.h>
+
+DECLARE_GLOBAL_DATA_PTR;
/*
* Global declaration of gd.
diff --git a/arch/x86/include/asm/global_data.h b/arch/x86/include/asm/global_data.h
index 3e4044593c8..f95fb5a1931 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -133,6 +133,8 @@ struct arch_global_data {
#ifndef __ASSEMBLY__
# if defined(CONFIG_EFI_APP) || CONFIG_IS_ENABLED(X86_64)
+extern struct global_data *global_data_ptr;
+
/* TODO(sjg@chromium.org): Consider using a fixed register for gd on x86_64 */
#define gd global_data_ptr
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [PATCH v2 06/39] x86: Tidy up global_data pointer for 64-bit
2021-09-25 0:30 ` [PATCH v2 06/39] x86: Tidy up global_data pointer for 64-bit Simon Glass
@ 2021-10-18 17:15 ` Heinrich Schuchardt
2021-10-26 3:29 ` Simon Glass
0 siblings, 1 reply; 74+ messages in thread
From: Heinrich Schuchardt @ 2021-10-18 17:15 UTC (permalink / raw)
To: Simon Glass
Cc: Bin Meng, Christian Melki, Tom Rini, Ilias Apalodimas,
U-Boot Mailing List
On 9/25/21 2:30 AM, Simon Glass wrote:
> Add an extern declaration so that it is possible to use this macro in
> files other than the one that defines it.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> ---
>
> (no changes since v1)
>
> arch/x86/cpu/x86_64/cpu.c | 3 +++
> arch/x86/include/asm/global_data.h | 2 ++
> 2 files changed, 5 insertions(+)
>
> diff --git a/arch/x86/cpu/x86_64/cpu.c b/arch/x86/cpu/x86_64/cpu.c
> index 90a766c3c57..e090b1b478a 100644
> --- a/arch/x86/cpu/x86_64/cpu.c
> +++ b/arch/x86/cpu/x86_64/cpu.c
> @@ -8,6 +8,9 @@
> #include <cpu_func.h>
> #include <debug_uart.h>
> #include <init.h>
> +#include <asm/global_data.h>
> +
> +DECLARE_GLOBAL_DATA_PTR;
>
> /*
> * Global declaration of gd.
> diff --git a/arch/x86/include/asm/global_data.h b/arch/x86/include/asm/global_data.h
> index 3e4044593c8..f95fb5a1931 100644
> --- a/arch/x86/include/asm/global_data.h
> +++ b/arch/x86/include/asm/global_data.h
> @@ -133,6 +133,8 @@ struct arch_global_data {
> #ifndef __ASSEMBLY__
> # if defined(CONFIG_EFI_APP) || CONFIG_IS_ENABLED(X86_64)
>
> +extern struct global_data *global_data_ptr;
You already have:
arch/x86/include/asm/global_data.h:139:
#define DECLARE_GLOBAL_DATA_PTR extern struct global_data *global_data_ptr
Why don't you use DECLARE_GLOBAL_DATA_PTR where needed?
Best regards
Heinrich
> +
> /* TODO(sjg@chromium.org): Consider using a fixed register for gd on x86_64 */
> #define gd global_data_ptr
>
>
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [PATCH v2 06/39] x86: Tidy up global_data pointer for 64-bit
2021-10-18 17:15 ` Heinrich Schuchardt
@ 2021-10-26 3:29 ` Simon Glass
0 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-10-26 3:29 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Bin Meng, Christian Melki, Tom Rini, Ilias Apalodimas,
U-Boot Mailing List
Hi Heinrich,
On Mon, 18 Oct 2021 at 11:15, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 9/25/21 2:30 AM, Simon Glass wrote:
> > Add an extern declaration so that it is possible to use this macro in
> > files other than the one that defines it.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > ---
> >
> > (no changes since v1)
> >
> > arch/x86/cpu/x86_64/cpu.c | 3 +++
> > arch/x86/include/asm/global_data.h | 2 ++
> > 2 files changed, 5 insertions(+)
> >
> > diff --git a/arch/x86/cpu/x86_64/cpu.c b/arch/x86/cpu/x86_64/cpu.c
> > index 90a766c3c57..e090b1b478a 100644
> > --- a/arch/x86/cpu/x86_64/cpu.c
> > +++ b/arch/x86/cpu/x86_64/cpu.c
> > @@ -8,6 +8,9 @@
> > #include <cpu_func.h>
> > #include <debug_uart.h>
> > #include <init.h>
> > +#include <asm/global_data.h>
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> >
> > /*
> > * Global declaration of gd.
> > diff --git a/arch/x86/include/asm/global_data.h b/arch/x86/include/asm/global_data.h
> > index 3e4044593c8..f95fb5a1931 100644
> > --- a/arch/x86/include/asm/global_data.h
> > +++ b/arch/x86/include/asm/global_data.h
> > @@ -133,6 +133,8 @@ struct arch_global_data {
> > #ifndef __ASSEMBLY__
> > # if defined(CONFIG_EFI_APP) || CONFIG_IS_ENABLED(X86_64)
> >
> > +extern struct global_data *global_data_ptr;
>
> You already have:
> arch/x86/include/asm/global_data.h:139:
> #define DECLARE_GLOBAL_DATA_PTR extern struct global_data *global_data_ptr
>
> Why don't you use DECLARE_GLOBAL_DATA_PTR where needed?
I have no idea what I was thinking or how I got into this state. But
anyway, I don't think we need this patch. Thanks for catching it.
Regards,
Simon
^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH v2 07/39] efi: Add a script for building and testing U-Boot on UEFI
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (5 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 06/39] x86: Tidy up global_data pointer for 64-bit Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-10-18 17:30 ` Heinrich Schuchardt
2021-10-25 19:35 ` Heinrich Schuchardt
2021-09-25 0:30 ` [PATCH v2 08/39] efi: Enable DM_ETH for the app Simon Glass
` (31 subsequent siblings)
38 siblings, 2 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
It is quite complicating to run U-Boot on qemu since we have four
different builds and they must use different versions of qemu and the
UEFI binaries.
Add a script to help.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Add MAINTAINERS entry
- Add support for creating a partition table with a filesystem inside
- Add support for running qemu with just a serial console (no display)
MAINTAINERS | 1 +
doc/develop/uefi/u-boot_on_efi.rst | 62 ++++++++++
scripts/build-efi.sh | 188 +++++++++++++++++++++++++++++
3 files changed, 251 insertions(+)
create mode 100755 scripts/build-efi.sh
diff --git a/MAINTAINERS b/MAINTAINERS
index 019c87592c5..84750be81a9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -706,6 +706,7 @@ M: Heinrich Schuchardt <xypron.glpk@gmx.de>
S: Maintained
W: https://u-boot.readthedocs.io/en/latest/develop/uefi/u-boot_on_efi.html
F: lib/efi/efi_app.c
+F: scripts/build-efi.sh
EFI PAYLOAD
M: Heinrich Schuchardt <xypron.glpk@gmx.de>
diff --git a/doc/develop/uefi/u-boot_on_efi.rst b/doc/develop/uefi/u-boot_on_efi.rst
index c9a41bc919f..4b2a733076d 100644
--- a/doc/develop/uefi/u-boot_on_efi.rst
+++ b/doc/develop/uefi/u-boot_on_efi.rst
@@ -96,6 +96,11 @@ that EFI does not support booting a 64-bit application from a 32-bit
EFI (or vice versa). Also it will often fail to print an error message if
you get this wrong.
+You may find the script `scripts/build-efi.sh` helpful for building and testing
+U-Boot on UEFI on QEMU. It also includes links to UEFI binaries dating from
+2021.
+
+See `Example run`_ for an example run.
Inner workings
--------------
@@ -191,6 +196,63 @@ of code is built this way (see the extra- line in lib/efi/Makefile).
Everything else is built as a normal U-Boot, so is always 32-bit on x86 at
present.
+Example run
+-----------
+
+This shows running with serial enabled (see `include/configs/efi-x86_app.h`)::
+
+ $ scripts/build-efi.sh -wsPr
+ Packaging efi-x86_app32
+ Running qemu-system-i386
+
+ BdsDxe: failed to load Boot0001 "UEFI QEMU HARDDISK QM00005 " from PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0xFFFF,0x0): Not Found
+ BdsDxe: loading Boot0002 "EFI Internal Shell" from Fv(7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1)/FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1)
+ BdsDxe: starting Boot0002 "EFI Internal Shell" from Fv(7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1)/FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1)
+
+ UEFI Interactive Shell v2.2
+ EDK II
+ UEFI v2.70 (EDK II, 0x00010000)
+ Mapping table
+ FS0: Alias(s):HD0a65535a1:;BLK1:
+ PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0xFFFF,0x0)/HD(1,GPT,0FFD5E61-3B0C-4326-8049-BDCDC910AF72,0x800,0xB000)
+ BLK0: Alias(s):
+ PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0xFFFF,0x0)
+
+ Press ESC in 5 seconds to skip startup.nsh or any other key to continue.
+ Shell> fs0:u-boot-app.efi
+ U-Boot EFI App (using allocated RAM address 47d4000) key=8d4, image=06a6f610
+ starting
+
+
+ U-Boot 2022.01-rc4 (Sep 19 2021 - 14:03:20 -0600)
+
+ CPU: x86, vendor Intel, device 663h
+ DRAM: 32 MiB
+ 0: efi_media_0 PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0xFFFF,0x0)
+ 1: <partition> PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0xFFFF,0x0)/HD(1,GPT,0FFD5E61-3B0C-4326-8049-BDCDC910AF72,0x800,0xB000)
+ Loading Environment from nowhere... OK
+ Model: EFI x86 Application
+ Hit any key to stop autoboot: 0
+
+ Partition Map for EFI device 0 -- Partition Type: EFI
+
+ Part Start LBA End LBA Name
+ Attributes
+ Type GUID
+ Partition GUID
+ 1 0x00000800 0x0000b7ff "boot"
+ attrs: 0x0000000000000000
+ type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
+ guid: 0ffd5e61-3b0c-4326-8049-bdcdc910af72
+ 19 startup.nsh
+ 528384 u-boot-app.efi
+ 10181 NvVars
+
+ 3 file(s), 0 dir(s)
+
+ => QEMU: Terminated
+
+
Future work
-----------
This work could be extended in a number of ways:
diff --git a/scripts/build-efi.sh b/scripts/build-efi.sh
new file mode 100755
index 00000000000..e6c035a7495
--- /dev/null
+++ b/scripts/build-efi.sh
@@ -0,0 +1,188 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Script to build an EFI thing suitable for booting with qemu, possibly running
+# it also.
+
+# This just an example. It assumes that
+
+# - you build U-Boot in /tmp/b/<name> where <name> is the U-Boot board config
+# - /mnt/x is a directory used for mounting
+# - you have access to the 'pure UEFI' builds for qemu
+#
+# UEFI binaries for QEMU used for testing this script:
+#
+# OVMF-pure-efi.i386.fd at
+# https://drive.google.com/file/d/1jWzOAZfQqMmS2_dAK2G518GhIgj9r2RY/view?usp=sharing
+
+# OVMF-pure-efi.x64.fd at
+# https://drive.google.com/file/d/1c39YI9QtpByGQ4V0UNNQtGqttEzS-eFV/view?usp=sharing
+
+set -e
+
+usage() {
+ echo "Usage: $0 [-a | -p] [other opts]" 1>&2
+ echo 1>&2
+ echo " -a - Package up the app" 1>&2
+ echo " -o - Use old EFI app build (before 32/64 split)" 1>&2
+ echo " -p - Package up the payload" 1>&2
+ echo " -P - Create a partition table" 1>&2
+ echo " -r - Run qemu with the image" 1>&2
+ echo " -s - Run qemu with serial only (no display)" 1>&2
+ echo " -w - Use word version (32-bit)" 1>&2
+ exit 1
+}
+
+# 32- or 64-bit EFI
+bitness=64
+
+# app or payload ?
+type=app
+
+# create a partition table and put the filesystem in that (otherwise put the
+# filesystem in the raw device)
+part=
+
+# run the image with qemu
+run=
+
+# run qemu without a display (U-Boot must be set to stdout=serial)
+serial=
+
+# before the 32/64 split of the app
+old=
+
+while getopts "aopPrsw" opt; do
+ case "${opt}" in
+ a)
+ type=app
+ ;;
+ p)
+ type=payload
+ ;;
+ r)
+ run=1
+ ;;
+ s)
+ serial=1
+ ;;
+ w)
+ bitness=32
+ ;;
+ o)
+ old=1
+ ;;
+ P)
+ part=1
+ ;;
+ *)
+ usage
+ ;;
+ esac
+done
+
+run_qemu() {
+ extra=
+ if [[ "${bitness}" = "64" ]]; then
+ qemu=qemu-system-x86_64
+ bios=OVMF-pure-efi.x64.fd
+ else
+ qemu=qemu-system-i386
+ bios=OVMF-pure-efi.i386.fd
+ fi
+ if [[ -n "${serial}" ]]; then
+ extra="-display none -serial mon:stdio"
+ fi
+ echo "Running ${qemu}"
+ "${qemu}" -bios "${bios}" \
+ -drive id=disk,file="${IMG}",if=none,format=raw \
+ -nic none -device ahci,id=ahci \
+ -device ide-hd,drive=disk,bus=ahci.0 ${extra}
+}
+
+# Put files in /tmp/b/${BUILD}
+setup_files() {
+ echo "Packaging ${BUILD}"
+ mkdir -p $TMP
+ cat >$TMP/startup.nsh <<EOF
+fs0:u-boot-${type}.efi
+EOF
+ sudo cp /tmp/b/$BUILD/u-boot-${type}.efi $TMP
+
+ # Can copy in other files here:
+ #sudo cp /tmp/b/$BUILD/image.bin $TMP/chromeos.rom
+ #sudo cp /boot/vmlinuz-5.4.0-77-generic $TMP/vmlinuz
+}
+
+# Copy files into the filesystem
+copy_files() {
+ sudo cp $TMP/* $MNT
+}
+
+# Create a filesystem on a raw device and copy in the files
+setup_raw() {
+ mkfs.vfat "${IMG}" >/dev/null
+ sudo mount -o loop "${IMG}" $MNT
+ copy_files
+ sudo umount $MNT
+}
+
+# Create a partition table and put the filesystem in the first partition
+# then copy in the files
+setup_part() {
+ # Create a gpt partition table with one parittion
+ parted "${IMG}" mklabel gpt 2>/dev/null
+
+ # This doesn't work correctly. It creates:
+ # Number Start End Size File system Name Flags
+ # 1 1049kB 24.1MB 23.1MB boot msftdata
+ # Odd if the same is entered interactively it does set the FS type
+ parted -s -a optimal -- "${IMG}" mkpart boot fat32 1MiB 23MiB
+
+ # Map this partition to a loop device
+ kp="$(sudo kpartx -av ${IMG})"
+ read boot_dev<<<$(grep -o 'loop.*p.' <<< "${kp}")
+ test "${boot_dev}"
+ dev="/dev/mapper/${boot_dev}"
+
+ mkfs.vfat "${dev}" >/dev/null
+
+ sudo mount -o loop "${dev}" $MNT
+
+ copy_files
+
+ # Sync here since this makes kpartx more likely to work the first time
+ sync
+ sudo umount $MNT
+
+ # For some reason this needs a sleep or it sometimes fails, if it was
+ # run recently (in the last few seconds)
+ if ! sudo kpartx -d "${IMG}" > /dev/null; then
+ sleep .5
+ sudo kpartx -d "${IMG}" > /dev/null || \
+ echo "Failed to remove ${boot_dev}, use: sudo kpartx -d ${IMG}"
+ fi
+}
+
+TMP="/tmp/efi${bitness}${type}"
+MNT=/mnt/x
+BUILD="efi-x86_${type}${bitness}"
+IMG=try.img
+
+if [[ -n "${old}" && "${bitness}" = "32" ]]; then
+ BUILD="efi-x86_${type}"
+fi
+
+setup_files
+
+qemu-img create "${IMG}" 24M >/dev/null
+
+if [[ -n "${part}" ]]; then
+ setup_part
+else
+ setup_raw
+fi
+
+if [[ -n "${run}" ]]; then
+ run_qemu
+fi
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [PATCH v2 07/39] efi: Add a script for building and testing U-Boot on UEFI
2021-09-25 0:30 ` [PATCH v2 07/39] efi: Add a script for building and testing U-Boot on UEFI Simon Glass
@ 2021-10-18 17:30 ` Heinrich Schuchardt
2021-10-18 18:12 ` Simon Glass
2021-10-25 19:35 ` Heinrich Schuchardt
1 sibling, 1 reply; 74+ messages in thread
From: Heinrich Schuchardt @ 2021-10-18 17:30 UTC (permalink / raw)
To: Simon Glass
Cc: Bin Meng, Christian Melki, Tom Rini, Ilias Apalodimas,
Alexander Graf, U-Boot Mailing List
On 9/25/21 2:30 AM, Simon Glass wrote:
> It is quite complicating to run U-Boot on qemu since we have four
Nits:
%s/complicating/complicated/ %/qemu/QEMU/
> different builds and they must use different versions of qemu and the
QEMU
> UEFI binaries.
>
> Add a script to help.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2:
> - Add MAINTAINERS entry
> - Add support for creating a partition table with a filesystem inside
> - Add support for running qemu with just a serial console (no display)
>
> MAINTAINERS | 1 +
> doc/develop/uefi/u-boot_on_efi.rst | 62 ++++++++++
> scripts/build-efi.sh | 188 +++++++++++++++++++++++++++++
> 3 files changed, 251 insertions(+)
> create mode 100755 scripts/build-efi.sh
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 019c87592c5..84750be81a9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -706,6 +706,7 @@ M: Heinrich Schuchardt <xypron.glpk@gmx.de>
> S: Maintained
> W: https://u-boot.readthedocs.io/en/latest/develop/uefi/u-boot_on_efi.html
> F: lib/efi/efi_app.c
> +F: scripts/build-efi.sh
>
> EFI PAYLOAD
> M: Heinrich Schuchardt <xypron.glpk@gmx.de>
> diff --git a/doc/develop/uefi/u-boot_on_efi.rst b/doc/develop/uefi/u-boot_on_efi.rst
> index c9a41bc919f..4b2a733076d 100644
> --- a/doc/develop/uefi/u-boot_on_efi.rst
> +++ b/doc/develop/uefi/u-boot_on_efi.rst
> @@ -96,6 +96,11 @@ that EFI does not support booting a 64-bit application from a 32-bit
> EFI (or vice versa). Also it will often fail to print an error message if
> you get this wrong.
>
> +You may find the script `scripts/build-efi.sh` helpful for building and testing
> +U-Boot on UEFI on QEMU. It also includes links to UEFI binaries dating from
> +2021.
> +
> +See `Example run`_ for an example run.
>
> Inner workings
> --------------
> @@ -191,6 +196,63 @@ of code is built this way (see the extra- line in lib/efi/Makefile).
> Everything else is built as a normal U-Boot, so is always 32-bit on x86 at
> present.
>
> +Example run
> +-----------
> +
> +This shows running with serial enabled (see `include/configs/efi-x86_app.h`)::
> +
> + $ scripts/build-efi.sh -wsPr
> + Packaging efi-x86_app32
> + Running qemu-system-i386
> +
> + BdsDxe: failed to load Boot0001 "UEFI QEMU HARDDISK QM00005 " from PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0xFFFF,0x0): Not Found
> + BdsDxe: loading Boot0002 "EFI Internal Shell" from Fv(7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1)/FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1)
> + BdsDxe: starting Boot0002 "EFI Internal Shell" from Fv(7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1)/FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1)
> +
> + UEFI Interactive Shell v2.2
> + EDK II
> + UEFI v2.70 (EDK II, 0x00010000)
> + Mapping table
> + FS0: Alias(s):HD0a65535a1:;BLK1:
> + PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0xFFFF,0x0)/HD(1,GPT,0FFD5E61-3B0C-4326-8049-BDCDC910AF72,0x800,0xB000)
> + BLK0: Alias(s):
> + PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0xFFFF,0x0)
> +
> + Press ESC in 5 seconds to skip startup.nsh or any other key to continue.
> + Shell> fs0:u-boot-app.efi
> + U-Boot EFI App (using allocated RAM address 47d4000) key=8d4, image=06a6f610
> + starting
> +
> +
> + U-Boot 2022.01-rc4 (Sep 19 2021 - 14:03:20 -0600)
> +
> + CPU: x86, vendor Intel, device 663h
> + DRAM: 32 MiB
> + 0: efi_media_0 PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0xFFFF,0x0)
> + 1: <partition> PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0xFFFF,0x0)/HD(1,GPT,0FFD5E61-3B0C-4326-8049-BDCDC910AF72,0x800,0xB000)
> + Loading Environment from nowhere... OK
> + Model: EFI x86 Application
> + Hit any key to stop autoboot: 0
> +
> + Partition Map for EFI device 0 -- Partition Type: EFI
> +
> + Part Start LBA End LBA Name
> + Attributes
> + Type GUID
> + Partition GUID
> + 1 0x00000800 0x0000b7ff "boot"
> + attrs: 0x0000000000000000
> + type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
> + guid: 0ffd5e61-3b0c-4326-8049-bdcdc910af72
> + 19 startup.nsh
> + 528384 u-boot-app.efi
> + 10181 NvVars
> +
> + 3 file(s), 0 dir(s)
> +
> + => QEMU: Terminated
> +
> +
> Future work
> -----------
> This work could be extended in a number of ways:
> diff --git a/scripts/build-efi.sh b/scripts/build-efi.sh
> new file mode 100755
> index 00000000000..e6c035a7495
> --- /dev/null
> +++ b/scripts/build-efi.sh
> @@ -0,0 +1,188 @@
> +#!/bin/bash
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Script to build an EFI thing suitable for booting with qemu, possibly running
> +# it also.
> +
> +# This just an example. It assumes that
> +
> +# - you build U-Boot in /tmp/b/<name> where <name> is the U-Boot board config
> +# - /mnt/x is a directory used for mounting
> +# - you have access to the 'pure UEFI' builds for qemu
> +#
> +# UEFI binaries for QEMU used for testing this script:
> +#
> +# OVMF-pure-efi.i386.fd at
> +# https://drive.google.com/file/d/1jWzOAZfQqMmS2_dAK2G518GhIgj9r2RY/view?usp=sharing
> +
> +# OVMF-pure-efi.x64.fd at
> +# https://drive.google.com/file/d/1c39YI9QtpByGQ4V0UNNQtGqttEzS-eFV/view?usp=sharing
> +
> +set -e
> +
> +usage() {
> + echo "Usage: $0 [-a | -p] [other opts]" 1>&2
> + echo 1>&2
> + echo " -a - Package up the app" 1>&2
> + echo " -o - Use old EFI app build (before 32/64 split)" 1>&2
Why is this option needed?
> + echo " -p - Package up the payload" 1>&2
> + echo " -P - Create a partition table" 1>&2
> + echo " -r - Run qemu with the image" 1>&2
QEMU
> + echo " -s - Run qemu with serial only (no display)" 1>&2
QEMU
Best regards
Heinrich
> + echo " -w - Use word version (32-bit)" 1>&2
> + exit 1
> +}
> +
> +# 32- or 64-bit EFI
> +bitness=64
> +
> +# app or payload ?
> +type=app
> +
> +# create a partition table and put the filesystem in that (otherwise put the
> +# filesystem in the raw device)
> +part=
> +
> +# run the image with qemu
> +run=
> +
> +# run qemu without a display (U-Boot must be set to stdout=serial)
> +serial=
> +
> +# before the 32/64 split of the app
> +old=
> +
> +while getopts "aopPrsw" opt; do
> + case "${opt}" in
> + a)
> + type=app
> + ;;
> + p)
> + type=payload
> + ;;
> + r)
> + run=1
> + ;;
> + s)
> + serial=1
> + ;;
> + w)
> + bitness=32
> + ;;
> + o)
> + old=1
> + ;;
> + P)
> + part=1
> + ;;
> + *)
> + usage
> + ;;
> + esac
> +done
> +
> +run_qemu() {
> + extra=
> + if [[ "${bitness}" = "64" ]]; then
> + qemu=qemu-system-x86_64
> + bios=OVMF-pure-efi.x64.fd
> + else
> + qemu=qemu-system-i386
> + bios=OVMF-pure-efi.i386.fd
> + fi
> + if [[ -n "${serial}" ]]; then
> + extra="-display none -serial mon:stdio"
> + fi
> + echo "Running ${qemu}"
> + "${qemu}" -bios "${bios}" \
> + -drive id=disk,file="${IMG}",if=none,format=raw \
> + -nic none -device ahci,id=ahci \
> + -device ide-hd,drive=disk,bus=ahci.0 ${extra}
> +}
> +
> +# Put files in /tmp/b/${BUILD}
> +setup_files() {
> + echo "Packaging ${BUILD}"
> + mkdir -p $TMP
> + cat >$TMP/startup.nsh <<EOF
> +fs0:u-boot-${type}.efi
> +EOF
> + sudo cp /tmp/b/$BUILD/u-boot-${type}.efi $TMP
> +
> + # Can copy in other files here:
> + #sudo cp /tmp/b/$BUILD/image.bin $TMP/chromeos.rom
> + #sudo cp /boot/vmlinuz-5.4.0-77-generic $TMP/vmlinuz
> +}
> +
> +# Copy files into the filesystem
> +copy_files() {
> + sudo cp $TMP/* $MNT
> +}
> +
> +# Create a filesystem on a raw device and copy in the files
> +setup_raw() {
> + mkfs.vfat "${IMG}" >/dev/null
> + sudo mount -o loop "${IMG}" $MNT
> + copy_files
> + sudo umount $MNT
> +}
> +
> +# Create a partition table and put the filesystem in the first partition
> +# then copy in the files
> +setup_part() {
> + # Create a gpt partition table with one parittion
> + parted "${IMG}" mklabel gpt 2>/dev/null
> +
> + # This doesn't work correctly. It creates:
> + # Number Start End Size File system Name Flags
> + # 1 1049kB 24.1MB 23.1MB boot msftdata
> + # Odd if the same is entered interactively it does set the FS type
> + parted -s -a optimal -- "${IMG}" mkpart boot fat32 1MiB 23MiB
> +
> + # Map this partition to a loop device
> + kp="$(sudo kpartx -av ${IMG})"
> + read boot_dev<<<$(grep -o 'loop.*p.' <<< "${kp}")
> + test "${boot_dev}"
> + dev="/dev/mapper/${boot_dev}"
> +
> + mkfs.vfat "${dev}" >/dev/null
> +
> + sudo mount -o loop "${dev}" $MNT
> +
> + copy_files
> +
> + # Sync here since this makes kpartx more likely to work the first time
> + sync
> + sudo umount $MNT
> +
> + # For some reason this needs a sleep or it sometimes fails, if it was
> + # run recently (in the last few seconds)
> + if ! sudo kpartx -d "${IMG}" > /dev/null; then
> + sleep .5
> + sudo kpartx -d "${IMG}" > /dev/null || \
> + echo "Failed to remove ${boot_dev}, use: sudo kpartx -d ${IMG}"
> + fi
> +}
> +
> +TMP="/tmp/efi${bitness}${type}"
> +MNT=/mnt/x
> +BUILD="efi-x86_${type}${bitness}"
> +IMG=try.img
> +
> +if [[ -n "${old}" && "${bitness}" = "32" ]]; then
> + BUILD="efi-x86_${type}"
> +fi
> +
> +setup_files
> +
> +qemu-img create "${IMG}" 24M >/dev/null
> +
> +if [[ -n "${part}" ]]; then
> + setup_part
> +else
> + setup_raw
> +fi
> +
> +if [[ -n "${run}" ]]; then
> + run_qemu
> +fi
>
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [PATCH v2 07/39] efi: Add a script for building and testing U-Boot on UEFI
2021-10-18 17:30 ` Heinrich Schuchardt
@ 2021-10-18 18:12 ` Simon Glass
0 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-10-18 18:12 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Bin Meng, Christian Melki, Tom Rini, Ilias Apalodimas,
Alexander Graf, U-Boot Mailing List
Hi Heinrich,
On Mon, 18 Oct 2021 at 11:35, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 9/25/21 2:30 AM, Simon Glass wrote:
> > It is quite complicating to run U-Boot on qemu since we have four
>
> Nits:
> %s/complicating/complicated/ %/qemu/QEMU/
>
> > different builds and they must use different versions of qemu and the
>
> QEMU
>
> > UEFI binaries.
> >
> > Add a script to help.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > Changes in v2:
> > - Add MAINTAINERS entry
> > - Add support for creating a partition table with a filesystem inside
> > - Add support for running qemu with just a serial console (no display)
> >
> > MAINTAINERS | 1 +
> > doc/develop/uefi/u-boot_on_efi.rst | 62 ++++++++++
> > scripts/build-efi.sh | 188 +++++++++++++++++++++++++++++
> > 3 files changed, 251 insertions(+)
> > create mode 100755 scripts/build-efi.sh
[..]
> > diff --git a/scripts/build-efi.sh b/scripts/build-efi.sh
> > new file mode 100755
> > index 00000000000..e6c035a7495
> > --- /dev/null
> > +++ b/scripts/build-efi.sh
> > @@ -0,0 +1,188 @@
> > +#!/bin/bash
> > +# SPDX-License-Identifier: GPL-2.0+
> > +#
> > +# Script to build an EFI thing suitable for booting with qemu, possibly running
> > +# it also.
> > +
> > +# This just an example. It assumes that
> > +
> > +# - you build U-Boot in /tmp/b/<name> where <name> is the U-Boot board config
> > +# - /mnt/x is a directory used for mounting
> > +# - you have access to the 'pure UEFI' builds for qemu
> > +#
> > +# UEFI binaries for QEMU used for testing this script:
> > +#
> > +# OVMF-pure-efi.i386.fd at
> > +# https://drive.google.com/file/d/1jWzOAZfQqMmS2_dAK2G518GhIgj9r2RY/view?usp=sharing
> > +
> > +# OVMF-pure-efi.x64.fd at
> > +# https://drive.google.com/file/d/1c39YI9QtpByGQ4V0UNNQtGqttEzS-eFV/view?usp=sharing
> > +
> > +set -e
> > +
> > +usage() {
> > + echo "Usage: $0 [-a | -p] [other opts]" 1>&2
> > + echo 1>&2
> > + echo " -a - Package up the app" 1>&2
> > + echo " -o - Use old EFI app build (before 32/64 split)" 1>&2
>
> Why is this option needed?
I think it is wise for now, in case we hit regressions. This allows
comparing the 'old' build with the new one. I have used it quite a few
times. We can drop this option once everything is settled.
[..]
Regards,
Simon
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v2 07/39] efi: Add a script for building and testing U-Boot on UEFI
2021-09-25 0:30 ` [PATCH v2 07/39] efi: Add a script for building and testing U-Boot on UEFI Simon Glass
2021-10-18 17:30 ` Heinrich Schuchardt
@ 2021-10-25 19:35 ` Heinrich Schuchardt
2021-10-26 3:29 ` Simon Glass
1 sibling, 1 reply; 74+ messages in thread
From: Heinrich Schuchardt @ 2021-10-25 19:35 UTC (permalink / raw)
To: Simon Glass
Cc: Bin Meng, Christian Melki, Tom Rini, Ilias Apalodimas,
Alexander Graf, U-Boot Mailing List
On 9/25/21 02:30, Simon Glass wrote:
> It is quite complicating to run U-Boot on qemu since we have four
> different builds and they must use different versions of qemu and the
> UEFI binaries.
>
> Add a script to help.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
This patch seems not to work:
$ scripts/build-efi.sh -wsPr
Packaging efi-x86_app32
cp: cannot stat '/tmp/b/efi-x86_app32/u-boot-app.efi': No such file or
director
The scripts lacks a step to build the EFI binary.
If you expect the user to build it, you will find it in the current
directory and not in some arbitrary subdirectory of /tmp.
Temporary directories should be created with 'mktemp -d'. Using fixed
paths (e.g. /tmp/b/) may lead to conflicts.
Best regards
Heinrich
> ---
>
> Changes in v2:
> - Add MAINTAINERS entry
> - Add support for creating a partition table with a filesystem inside
> - Add support for running qemu with just a serial console (no display)
>
> MAINTAINERS | 1 +
> doc/develop/uefi/u-boot_on_efi.rst | 62 ++++++++++
> scripts/build-efi.sh | 188 +++++++++++++++++++++++++++++
> 3 files changed, 251 insertions(+)
> create mode 100755 scripts/build-efi.sh
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 019c87592c5..84750be81a9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -706,6 +706,7 @@ M: Heinrich Schuchardt <xypron.glpk@gmx.de>
> S: Maintained
> W: https://u-boot.readthedocs.io/en/latest/develop/uefi/u-boot_on_efi.html
> F: lib/efi/efi_app.c
> +F: scripts/build-efi.sh
>
> EFI PAYLOAD
> M: Heinrich Schuchardt <xypron.glpk@gmx.de>
> diff --git a/doc/develop/uefi/u-boot_on_efi.rst b/doc/develop/uefi/u-boot_on_efi.rst
> index c9a41bc919f..4b2a733076d 100644
> --- a/doc/develop/uefi/u-boot_on_efi.rst
> +++ b/doc/develop/uefi/u-boot_on_efi.rst
> @@ -96,6 +96,11 @@ that EFI does not support booting a 64-bit application from a 32-bit
> EFI (or vice versa). Also it will often fail to print an error message if
> you get this wrong.
>
> +You may find the script `scripts/build-efi.sh` helpful for building and testing
> +U-Boot on UEFI on QEMU. It also includes links to UEFI binaries dating from
> +2021.
> +
> +See `Example run`_ for an example run.
>
> Inner workings
> --------------
> @@ -191,6 +196,63 @@ of code is built this way (see the extra- line in lib/efi/Makefile).
> Everything else is built as a normal U-Boot, so is always 32-bit on x86 at
> present.
>
> +Example run
> +-----------
> +
> +This shows running with serial enabled (see `include/configs/efi-x86_app.h`)::
> +
> + $ scripts/build-efi.sh -wsPr
> + Packaging efi-x86_app32
> + Running qemu-system-i386
> +
> + BdsDxe: failed to load Boot0001 "UEFI QEMU HARDDISK QM00005 " from PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0xFFFF,0x0): Not Found
> + BdsDxe: loading Boot0002 "EFI Internal Shell" from Fv(7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1)/FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1)
> + BdsDxe: starting Boot0002 "EFI Internal Shell" from Fv(7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1)/FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1)
> +
> + UEFI Interactive Shell v2.2
> + EDK II
> + UEFI v2.70 (EDK II, 0x00010000)
> + Mapping table
> + FS0: Alias(s):HD0a65535a1:;BLK1:
> + PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0xFFFF,0x0)/HD(1,GPT,0FFD5E61-3B0C-4326-8049-BDCDC910AF72,0x800,0xB000)
> + BLK0: Alias(s):
> + PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0xFFFF,0x0)
> +
> + Press ESC in 5 seconds to skip startup.nsh or any other key to continue.
> + Shell> fs0:u-boot-app.efi
> + U-Boot EFI App (using allocated RAM address 47d4000) key=8d4, image=06a6f610
> + starting
> +
> +
> + U-Boot 2022.01-rc4 (Sep 19 2021 - 14:03:20 -0600)
> +
> + CPU: x86, vendor Intel, device 663h
> + DRAM: 32 MiB
> + 0: efi_media_0 PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0xFFFF,0x0)
> + 1: <partition> PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0xFFFF,0x0)/HD(1,GPT,0FFD5E61-3B0C-4326-8049-BDCDC910AF72,0x800,0xB000)
> + Loading Environment from nowhere... OK
> + Model: EFI x86 Application
> + Hit any key to stop autoboot: 0
> +
> + Partition Map for EFI device 0 -- Partition Type: EFI
> +
> + Part Start LBA End LBA Name
> + Attributes
> + Type GUID
> + Partition GUID
> + 1 0x00000800 0x0000b7ff "boot"
> + attrs: 0x0000000000000000
> + type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
> + guid: 0ffd5e61-3b0c-4326-8049-bdcdc910af72
> + 19 startup.nsh
> + 528384 u-boot-app.efi
> + 10181 NvVars
> +
> + 3 file(s), 0 dir(s)
> +
> + => QEMU: Terminated
> +
> +
> Future work
> -----------
> This work could be extended in a number of ways:
> diff --git a/scripts/build-efi.sh b/scripts/build-efi.sh
> new file mode 100755
> index 00000000000..e6c035a7495
> --- /dev/null
> +++ b/scripts/build-efi.sh
> @@ -0,0 +1,188 @@
> +#!/bin/bash
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Script to build an EFI thing suitable for booting with qemu, possibly running
> +# it also.
> +
> +# This just an example. It assumes that
> +
> +# - you build U-Boot in /tmp/b/<name> where <name> is the U-Boot board config
> +# - /mnt/x is a directory used for mounting
> +# - you have access to the 'pure UEFI' builds for qemu
> +#
> +# UEFI binaries for QEMU used for testing this script:
> +#
> +# OVMF-pure-efi.i386.fd at
> +# https://drive.google.com/file/d/1jWzOAZfQqMmS2_dAK2G518GhIgj9r2RY/view?usp=sharing
> +
> +# OVMF-pure-efi.x64.fd at
> +# https://drive.google.com/file/d/1c39YI9QtpByGQ4V0UNNQtGqttEzS-eFV/view?usp=sharing
> +
> +set -e
> +
> +usage() {
> + echo "Usage: $0 [-a | -p] [other opts]" 1>&2
> + echo 1>&2
> + echo " -a - Package up the app" 1>&2
> + echo " -o - Use old EFI app build (before 32/64 split)" 1>&2
> + echo " -p - Package up the payload" 1>&2
> + echo " -P - Create a partition table" 1>&2
> + echo " -r - Run qemu with the image" 1>&2
> + echo " -s - Run qemu with serial only (no display)" 1>&2
> + echo " -w - Use word version (32-bit)" 1>&2
> + exit 1
> +}
> +
> +# 32- or 64-bit EFI
> +bitness=64
> +
> +# app or payload ?
> +type=app
> +
> +# create a partition table and put the filesystem in that (otherwise put the
> +# filesystem in the raw device)
> +part=
> +
> +# run the image with qemu
> +run=
> +
> +# run qemu without a display (U-Boot must be set to stdout=serial)
> +serial=
> +
> +# before the 32/64 split of the app
> +old=
> +
> +while getopts "aopPrsw" opt; do
> + case "${opt}" in
> + a)
> + type=app
> + ;;
> + p)
> + type=payload
> + ;;
> + r)
> + run=1
> + ;;
> + s)
> + serial=1
> + ;;
> + w)
> + bitness=32
> + ;;
> + o)
> + old=1
> + ;;
> + P)
> + part=1
> + ;;
> + *)
> + usage
> + ;;
> + esac
> +done
> +
> +run_qemu() {
> + extra=
> + if [[ "${bitness}" = "64" ]]; then
> + qemu=qemu-system-x86_64
> + bios=OVMF-pure-efi.x64.fd
> + else
> + qemu=qemu-system-i386
> + bios=OVMF-pure-efi.i386.fd
> + fi
> + if [[ -n "${serial}" ]]; then
> + extra="-display none -serial mon:stdio"
> + fi
> + echo "Running ${qemu}"
> + "${qemu}" -bios "${bios}" \
> + -drive id=disk,file="${IMG}",if=none,format=raw \
> + -nic none -device ahci,id=ahci \
> + -device ide-hd,drive=disk,bus=ahci.0 ${extra}
> +}
> +
> +# Put files in /tmp/b/${BUILD}
> +setup_files() {
> + echo "Packaging ${BUILD}"
> + mkdir -p $TMP
> + cat >$TMP/startup.nsh <<EOF
> +fs0:u-boot-${type}.efi
> +EOF
> + sudo cp /tmp/b/$BUILD/u-boot-${type}.efi $TMP
> +
> + # Can copy in other files here:
> + #sudo cp /tmp/b/$BUILD/image.bin $TMP/chromeos.rom
> + #sudo cp /boot/vmlinuz-5.4.0-77-generic $TMP/vmlinuz
> +}
> +
> +# Copy files into the filesystem
> +copy_files() {
> + sudo cp $TMP/* $MNT
> +}
> +
> +# Create a filesystem on a raw device and copy in the files
> +setup_raw() {
> + mkfs.vfat "${IMG}" >/dev/null
> + sudo mount -o loop "${IMG}" $MNT
> + copy_files
> + sudo umount $MNT
> +}
> +
> +# Create a partition table and put the filesystem in the first partition
> +# then copy in the files
> +setup_part() {
> + # Create a gpt partition table with one parittion
> + parted "${IMG}" mklabel gpt 2>/dev/null
> +
> + # This doesn't work correctly. It creates:
> + # Number Start End Size File system Name Flags
> + # 1 1049kB 24.1MB 23.1MB boot msftdata
> + # Odd if the same is entered interactively it does set the FS type
> + parted -s -a optimal -- "${IMG}" mkpart boot fat32 1MiB 23MiB
> +
> + # Map this partition to a loop device
> + kp="$(sudo kpartx -av ${IMG})"
> + read boot_dev<<<$(grep -o 'loop.*p.' <<< "${kp}")
> + test "${boot_dev}"
> + dev="/dev/mapper/${boot_dev}"
> +
> + mkfs.vfat "${dev}" >/dev/null
> +
> + sudo mount -o loop "${dev}" $MNT
> +
> + copy_files
> +
> + # Sync here since this makes kpartx more likely to work the first time
> + sync
> + sudo umount $MNT
> +
> + # For some reason this needs a sleep or it sometimes fails, if it was
> + # run recently (in the last few seconds)
> + if ! sudo kpartx -d "${IMG}" > /dev/null; then
> + sleep .5
> + sudo kpartx -d "${IMG}" > /dev/null || \
> + echo "Failed to remove ${boot_dev}, use: sudo kpartx -d ${IMG}"
> + fi
> +}
> +
> +TMP="/tmp/efi${bitness}${type}"
> +MNT=/mnt/x
> +BUILD="efi-x86_${type}${bitness}"
> +IMG=try.img
> +
> +if [[ -n "${old}" && "${bitness}" = "32" ]]; then
> + BUILD="efi-x86_${type}"
> +fi
> +
> +setup_files
> +
> +qemu-img create "${IMG}" 24M >/dev/null
> +
> +if [[ -n "${part}" ]]; then
> + setup_part
> +else
> + setup_raw
> +fi
> +
> +if [[ -n "${run}" ]]; then
> + run_qemu
> +fi
>
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [PATCH v2 07/39] efi: Add a script for building and testing U-Boot on UEFI
2021-10-25 19:35 ` Heinrich Schuchardt
@ 2021-10-26 3:29 ` Simon Glass
0 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-10-26 3:29 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Bin Meng, Christian Melki, Tom Rini, Ilias Apalodimas,
Alexander Graf, U-Boot Mailing List
Hi Heinrich,
On Mon, 25 Oct 2021 at 13:40, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
>
>
> On 9/25/21 02:30, Simon Glass wrote:
> > It is quite complicating to run U-Boot on qemu since we have four
> > different builds and they must use different versions of qemu and the
> > UEFI binaries.
> >
> > Add a script to help.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
>
> This patch seems not to work:
>
> $ scripts/build-efi.sh -wsPr
> Packaging efi-x86_app32
> cp: cannot stat '/tmp/b/efi-x86_app32/u-boot-app.efi': No such file or
> director
>
> The scripts lacks a step to build the EFI binary.
>
> If you expect the user to build it, you will find it in the current
> directory and not in some arbitrary subdirectory of /tmp.
Did you read the top of the script? It does not do the build, just the
package/run bit
>
> Temporary directories should be created with 'mktemp -d'. Using fixed
> paths (e.g. /tmp/b/) may lead to conflicts.
I'll make it a variable in v3. But we cannot use mktemp-d as the build
needs to stay around for multiple runs of this script.
Regards,
Simon
^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH v2 08/39] efi: Enable DM_ETH for the app
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (6 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 07/39] efi: Add a script for building and testing U-Boot on UEFI Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 09/39] efi: Drop the OF_EMBED warning for EFI Simon Glass
` (30 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
There is no need to avoid driver model for networking. Drop this.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Add new patch to enable DM_ETH for the app
configs/efi-x86_app_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/configs/efi-x86_app_defconfig b/configs/efi-x86_app_defconfig
index e9ee66250cf..3f7c9ba9008 100644
--- a/configs/efi-x86_app_defconfig
+++ b/configs/efi-x86_app_defconfig
@@ -32,7 +32,6 @@ CONFIG_ENV_OVERWRITE=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_REGMAP=y
CONFIG_SYSCON=y
-# CONFIG_DM_ETH is not set
# CONFIG_REGEX is not set
# CONFIG_GZIP is not set
CONFIG_EFI=y
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 09/39] efi: Drop the OF_EMBED warning for EFI
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (7 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 08/39] efi: Enable DM_ETH for the app Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-10-23 11:37 ` Heinrich Schuchardt
2021-09-25 0:30 ` [PATCH v2 10/39] x86: Create a 32/64-bit selection for the app Simon Glass
` (29 subsequent siblings)
38 siblings, 1 reply; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
For the EFI app, we must embed the devicetree in the ELF file since that
is the only thing that is run by UEFI. Drop the warning to avoid
confusion.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Add new patch to drop the OF_EMBED warning for EFI
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index a09f48f84b2..784efd4ef6e 100644
--- a/Makefile
+++ b/Makefile
@@ -1087,7 +1087,7 @@ endif
ifeq ($(CONFIG_DEPRECATED),y)
$(warning "You have deprecated configuration options enabled in your .config! Please check your configuration.")
endif
-ifeq ($(CONFIG_OF_EMBED),y)
+ifeq ($(CONFIG_OF_EMBED)$(CONFIG_EFI_APP),y)
@echo >&2 "===================== WARNING ======================"
@echo >&2 "CONFIG_OF_EMBED is enabled. This option should only"
@echo >&2 "be used for debugging purposes. Please use"
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [PATCH v2 09/39] efi: Drop the OF_EMBED warning for EFI
2021-09-25 0:30 ` [PATCH v2 09/39] efi: Drop the OF_EMBED warning for EFI Simon Glass
@ 2021-10-23 11:37 ` Heinrich Schuchardt
2021-10-26 3:29 ` Simon Glass
0 siblings, 1 reply; 74+ messages in thread
From: Heinrich Schuchardt @ 2021-10-23 11:37 UTC (permalink / raw)
To: Simon Glass, U-Boot Mailing List
Cc: Bin Meng, Christian Melki, Tom Rini, Ilias Apalodimas, Alexander Graf
On 9/25/21 02:30, Simon Glass wrote:
> For the EFI app, we must embed the devicetree in the ELF file since that
> is the only thing that is run by UEFI. Drop the warning to avoid
> confusion.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2:
> - Add new patch to drop the OF_EMBED warning for EFI
>
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index a09f48f84b2..784efd4ef6e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1087,7 +1087,7 @@ endif
> ifeq ($(CONFIG_DEPRECATED),y)
> $(warning "You have deprecated configuration options enabled in your .config! Please check your configuration.")
> endif
> -ifeq ($(CONFIG_OF_EMBED),y)
> +ifeq ($(CONFIG_OF_EMBED)$(CONFIG_EFI_APP),y)
> @echo >&2 "===================== WARNING ======================"
> @echo >&2 "CONFIG_OF_EMBED is enabled. This option should only"
> @echo >&2 "be used for debugging purposes. Please use"
There are 47 defconfigs and 5 include/configs/*.h using CONFIG_OF_EMBED.
doc/board/intel/slimbootloader.rst and doc/board/coreboot/coreboot.rst
require to use it for building U-Boot.
Is there a migration requirement and plan?
Best regards
Heinrich
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v2 09/39] efi: Drop the OF_EMBED warning for EFI
2021-10-23 11:37 ` Heinrich Schuchardt
@ 2021-10-26 3:29 ` Simon Glass
0 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-10-26 3:29 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: U-Boot Mailing List, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Alexander Graf
Hi Heinrich,
On Sat, 23 Oct 2021 at 05:42, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
>
>
> On 9/25/21 02:30, Simon Glass wrote:
> > For the EFI app, we must embed the devicetree in the ELF file since that
> > is the only thing that is run by UEFI. Drop the warning to avoid
> > confusion.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > Changes in v2:
> > - Add new patch to drop the OF_EMBED warning for EFI
> >
> > Makefile | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Makefile b/Makefile
> > index a09f48f84b2..784efd4ef6e 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1087,7 +1087,7 @@ endif
> > ifeq ($(CONFIG_DEPRECATED),y)
> > $(warning "You have deprecated configuration options enabled in your .config! Please check your configuration.")
> > endif
> > -ifeq ($(CONFIG_OF_EMBED),y)
> > +ifeq ($(CONFIG_OF_EMBED)$(CONFIG_EFI_APP),y)
> > @echo >&2 "===================== WARNING ======================"
> > @echo >&2 "CONFIG_OF_EMBED is enabled. This option should only"
> > @echo >&2 "be used for debugging purposes. Please use"
>
> There are 47 defconfigs and 5 include/configs/*.h using CONFIG_OF_EMBED.
> doc/board/intel/slimbootloader.rst and doc/board/coreboot/coreboot.rst
> require to use it for building U-Boot.
>
> Is there a migration requirement and plan?
Actually people were never supposed to use it.
I sent a series today which cleans this up quite a bit, so that I
think many of the boards using OF_EMBED can drop it. TBD though.
Regards,
Simon
^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH v2 10/39] x86: Create a 32/64-bit selection for the app
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (8 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 09/39] efi: Drop the OF_EMBED warning for EFI Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-10-23 11:41 ` Heinrich Schuchardt
2021-09-25 0:30 ` [PATCH v2 11/39] efi: Create a 64-bit app Simon Glass
` (28 subsequent siblings)
38 siblings, 1 reply; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass
Most EFI implementations use 64-bit but U-Boot only supports running as
a 32-bit app at present. While efi-x86_payload64 does boot from 64-bit
UEFI it immediately changes back to 32-bit before starting U-Boot.
In order to support a 64-bit U-Boot app, update the Kconfig to add an
option for 32/64 bit. Update the prompt for the existing option so it is
clear it relates to the stub. Move both up to just under the choice that
controls them, since this looks better and the menu.
Use CONFIG_EFI_APP in the Makefile instead of CONFIG_TARGET_EFI_APP,
since the latter is specific to a single target and we will have two.
Memory size is set to 32MB for now so that it can run on qemu without
increasing the default memory size. We may need to increase the default
later.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Expand the commit message to make things clearer
arch/x86/cpu/intel_common/Makefile | 2 +-
lib/efi/Kconfig | 34 +++++++++++++++++++++++-------
2 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/arch/x86/cpu/intel_common/Makefile b/arch/x86/cpu/intel_common/Makefile
index 8b9a810f66d..1dc17b45879 100644
--- a/arch/x86/cpu/intel_common/Makefile
+++ b/arch/x86/cpu/intel_common/Makefile
@@ -27,7 +27,7 @@ obj-y += fast_spi.o
obj-y += lpc.o
obj-y += lpss.o
obj-$(CONFIG_$(SPL_)INTEL_GENERIC_WIFI) += generic_wifi.o
-ifndef CONFIG_TARGET_EFI_APP
+ifndef CONFIG_EFI_APP
obj-$(CONFIG_$(SPL_TPL_)X86_32BIT_INIT) += microcode.o
ifndef CONFIG_$(SPL_)X86_64
obj-y += microcode.o
diff --git a/lib/efi/Kconfig b/lib/efi/Kconfig
index 93b85644920..e818cef0d15 100644
--- a/lib/efi/Kconfig
+++ b/lib/efi/Kconfig
@@ -26,18 +26,26 @@ config EFI_STUB
endchoice
-config EFI_RAM_SIZE
- hex "Amount of EFI RAM for U-Boot"
+choice
+ prompt "EFI app 32/64-bit selection"
depends on EFI_APP
- default 0x2000000
help
- Set the amount of EFI RAM which is claimed by U-Boot for its own
- use. U-Boot allocates this from EFI on start-up (along with a few
- other smaller amounts) and it can never be increased after that.
- It is used as the RAM size in with U-Boot.
+ EFI does not support mixing 32-bit and 64-bit modes. This is a
+ significant problem because it means that you must build a stub with
+ the correct type for EFI to load it correctly. If you are using
+ 32-bit EFI, select 32-bit here, else select 64-bit. Failure to do
+ this may produce no error message - it just won't start!
+
+config EFI_APP_32BIT
+ bool "Produce an app for running with 32-bit EFI"
+
+config EFI_APP_64BIT
+ bool "Produce an app for running with 64-bit EFI"
+
+endchoice
choice
- prompt "EFI 32/64-bit selection"
+ prompt "EFI stub 32/64-bit selection"
depends on EFI_STUB
help
EFI does not support mixing 32-bit and 64-bit modes. This is a
@@ -53,3 +61,13 @@ config EFI_STUB_64BIT
bool "Produce a stub for running with 64-bit EFI"
endchoice
+
+config EFI_RAM_SIZE
+ hex "Amount of EFI RAM for U-Boot"
+ depends on EFI_APP
+ default 0x2000000
+ help
+ Set the amount of EFI RAM which is claimed by U-Boot for its own
+ use. U-Boot allocates this from EFI on start-up (along with a few
+ other smaller amounts) and it can never be increased after that.
+ It is used as the RAM size in with U-Boot.
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [PATCH v2 10/39] x86: Create a 32/64-bit selection for the app
2021-09-25 0:30 ` [PATCH v2 10/39] x86: Create a 32/64-bit selection for the app Simon Glass
@ 2021-10-23 11:41 ` Heinrich Schuchardt
0 siblings, 0 replies; 74+ messages in thread
From: Heinrich Schuchardt @ 2021-10-23 11:41 UTC (permalink / raw)
To: Simon Glass, U-Boot Mailing List
Cc: Bin Meng, Christian Melki, Tom Rini, Ilias Apalodimas
On 9/25/21 02:30, Simon Glass wrote:
> Most EFI implementations use 64-bit but U-Boot only supports running as
> a 32-bit app at present. While efi-x86_payload64 does boot from 64-bit
> UEFI it immediately changes back to 32-bit before starting U-Boot.
>
> In order to support a 64-bit U-Boot app, update the Kconfig to add an
> option for 32/64 bit. Update the prompt for the existing option so it is
> clear it relates to the stub. Move both up to just under the choice that
> controls them, since this looks better and the menu.
>
> Use CONFIG_EFI_APP in the Makefile instead of CONFIG_TARGET_EFI_APP,
> since the latter is specific to a single target and we will have two.
>
> Memory size is set to 32MB for now so that it can run on qemu without
> increasing the default memory size. We may need to increase the default
> later.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2:
> - Expand the commit message to make things clearer
>
> arch/x86/cpu/intel_common/Makefile | 2 +-
> lib/efi/Kconfig | 34 +++++++++++++++++++++++-------
> 2 files changed, 27 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/cpu/intel_common/Makefile b/arch/x86/cpu/intel_common/Makefile
> index 8b9a810f66d..1dc17b45879 100644
> --- a/arch/x86/cpu/intel_common/Makefile
> +++ b/arch/x86/cpu/intel_common/Makefile
> @@ -27,7 +27,7 @@ obj-y += fast_spi.o
> obj-y += lpc.o
> obj-y += lpss.o
> obj-$(CONFIG_$(SPL_)INTEL_GENERIC_WIFI) += generic_wifi.o
> -ifndef CONFIG_TARGET_EFI_APP
> +ifndef CONFIG_EFI_APP
> obj-$(CONFIG_$(SPL_TPL_)X86_32BIT_INIT) += microcode.o
> ifndef CONFIG_$(SPL_)X86_64
> obj-y += microcode.o
> diff --git a/lib/efi/Kconfig b/lib/efi/Kconfig
> index 93b85644920..e818cef0d15 100644
> --- a/lib/efi/Kconfig
> +++ b/lib/efi/Kconfig
> @@ -26,18 +26,26 @@ config EFI_STUB
>
> endchoice
>
> -config EFI_RAM_SIZE
> - hex "Amount of EFI RAM for U-Boot"
> +choice
> + prompt "EFI app 32/64-bit selection"
> depends on EFI_APP
> - default 0x2000000
> help
> - Set the amount of EFI RAM which is claimed by U-Boot for its own
> - use. U-Boot allocates this from EFI on start-up (along with a few
> - other smaller amounts) and it can never be increased after that.
> - It is used as the RAM size in with U-Boot.
> + EFI does not support mixing 32-bit and 64-bit modes. This is a
> + significant problem because it means that you must build a stub with
> + the correct type for EFI to load it correctly. If you are using
> + 32-bit EFI, select 32-bit here, else select 64-bit. Failure to do
> + this may produce no error message - it just won't start!
> +
> +config EFI_APP_32BIT
> + bool "Produce an app for running with 32-bit EFI"
> +
> +config EFI_APP_64BIT
> + bool "Produce an app for running with 64-bit EFI"
> +
> +endchoice
>
> choice
> - prompt "EFI 32/64-bit selection"
> + prompt "EFI stub 32/64-bit selection"
> depends on EFI_STUB
> help
> EFI does not support mixing 32-bit and 64-bit modes. This is a
> @@ -53,3 +61,13 @@ config EFI_STUB_64BIT
> bool "Produce a stub for running with 64-bit EFI"
>
> endchoice
> +
> +config EFI_RAM_SIZE
> + hex "Amount of EFI RAM for U-Boot"
> + depends on EFI_APP
> + default 0x2000000
This will be too small for loading the kernel and the initrd in some
cases. 256 MiB seems reasonable.
Best regards
Heinrich
> + help
> + Set the amount of EFI RAM which is claimed by U-Boot for its own
> + use. U-Boot allocates this from EFI on start-up (along with a few
> + other smaller amounts) and it can never be increased after that.
> + It is used as the RAM size in with U-Boot.
>
^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH v2 11/39] efi: Create a 64-bit app
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (9 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 10/39] x86: Create a 32/64-bit selection for the app Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 12/39] x86: Don't duplicate global_ptr in 64-bit EFI app Simon Glass
` (27 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
Most modern platforms use 64-bit EFI so it is useful to have a U-Boot app
that runs under that. Add a (non-functional) build for this.
Note that --whole-archive causes the gcc 9.2 linker to crash, so disable
this for now. Once this is resolved, things should work.
For now, avoid mentioning the documentation for the 64-bit app, since it
does not work.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Add MAINTAINERS entry
- Add a work-around to avoid a toolchain crash
MAINTAINERS | 3 ++
Makefile | 8 +++-
arch/x86/cpu/u-boot-64.lds | 2 +
arch/x86/cpu/x86_64/Makefile | 4 ++
arch/x86/cpu/x86_64/cpu.c | 17 --------
arch/x86/cpu/x86_64/misc.c | 25 ++++++++++++
board/efi/Kconfig | 15 ++++++-
board/efi/efi-x86_app/Kconfig | 2 +-
board/efi/efi-x86_app/MAINTAINERS | 11 +++++-
..._app_defconfig => efi-x86_app32_defconfig} | 2 +-
configs/efi-x86_app64_defconfig | 39 +++++++++++++++++++
doc/develop/uefi/u-boot_on_efi.rst | 6 +--
12 files changed, 106 insertions(+), 28 deletions(-)
create mode 100644 arch/x86/cpu/x86_64/misc.c
rename configs/{efi-x86_app_defconfig => efi-x86_app32_defconfig} (97%)
create mode 100644 configs/efi-x86_app64_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS
index 84750be81a9..a254b705e73 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -705,6 +705,9 @@ M: Simon Glass <sjg@chromium.org>
M: Heinrich Schuchardt <xypron.glpk@gmx.de>
S: Maintained
W: https://u-boot.readthedocs.io/en/latest/develop/uefi/u-boot_on_efi.html
+F: board/efi/efi-x86_app
+F: configs/efi-x86_app*
+F: doc/develop/uefi/u-boot_on_efi.rst
F: lib/efi/efi_app.c
F: scripts/build-efi.sh
diff --git a/Makefile b/Makefile
index 784efd4ef6e..8720b50b517 100644
--- a/Makefile
+++ b/Makefile
@@ -1755,12 +1755,16 @@ quiet_cmd_u-boot__ ?= LTO $@
-Wl,-Map,u-boot.map; \
$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
else
+# Note: Linking efi-x86_app64 causes a segfault in the linker at present
+# when using x86_64-linux-gnu-ld.bfd
+# For now, disable --whole-archive which makes things link, although not
+# correctly
quiet_cmd_u-boot__ ?= LD $@
cmd_u-boot__ ?= $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_u-boot) -o $@ \
-T u-boot.lds $(u-boot-init) \
- --whole-archive \
+ $(if $(CONFIG_EFI_APP_64BIT),,--whole-archive) \
$(u-boot-main) \
- --no-whole-archive \
+ $(if $(CONFIG_EFI_APP_64BIT),,--no-whole-archive) \
$(PLATFORM_LIBS) -Map u-boot.map; \
$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
endif
diff --git a/arch/x86/cpu/u-boot-64.lds b/arch/x86/cpu/u-boot-64.lds
index ee0812aefbc..92a30c2a387 100644
--- a/arch/x86/cpu/u-boot-64.lds
+++ b/arch/x86/cpu/u-boot-64.lds
@@ -15,7 +15,9 @@ SECTIONS
/DISCARD/ : { *(.u_boot_list_2_cmd_*) }
#endif
+#ifdef CONFIG_SYS_TEXT_BASE
. = CONFIG_SYS_TEXT_BASE; /* Location of bootcode in flash */
+#endif
__text_start = .;
.text.start : { *(.text.start); }
diff --git a/arch/x86/cpu/x86_64/Makefile b/arch/x86/cpu/x86_64/Makefile
index 400f0ffe397..e929563b2c1 100644
--- a/arch/x86/cpu/x86_64/Makefile
+++ b/arch/x86/cpu/x86_64/Makefile
@@ -4,3 +4,7 @@
#
obj-y += cpu.o interrupts.o setjmp.o
+
+ifndef CONFIG_EFI
+obj-y += misc.o
+endif
diff --git a/arch/x86/cpu/x86_64/cpu.c b/arch/x86/cpu/x86_64/cpu.c
index e090b1b478a..fb501218e25 100644
--- a/arch/x86/cpu/x86_64/cpu.c
+++ b/arch/x86/cpu/x86_64/cpu.c
@@ -52,23 +52,6 @@ int x86_mp_init(void)
return 0;
}
-int misc_init_r(void)
-{
- return 0;
-}
-
-#ifndef CONFIG_SYS_COREBOOT
-int checkcpu(void)
-{
- return 0;
-}
-
-int print_cpuinfo(void)
-{
- return 0;
-}
-#endif
-
int x86_cpu_reinit_f(void)
{
return 0;
diff --git a/arch/x86/cpu/x86_64/misc.c b/arch/x86/cpu/x86_64/misc.c
new file mode 100644
index 00000000000..02587ff0c50
--- /dev/null
+++ b/arch/x86/cpu/x86_64/misc.c
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2016 Google, Inc
+ * Written by Simon Glass <sjg@chromium.org>
+ */
+
+#include <common.h>
+#include <init.h>
+
+int misc_init_r(void)
+{
+ return 0;
+}
+
+#ifndef CONFIG_SYS_COREBOOT
+int checkcpu(void)
+{
+ return 0;
+}
+
+int print_cpuinfo(void)
+{
+ return 0;
+}
+#endif
diff --git a/board/efi/Kconfig b/board/efi/Kconfig
index 291bd2ca154..3df6e31c8ba 100644
--- a/board/efi/Kconfig
+++ b/board/efi/Kconfig
@@ -4,14 +4,25 @@ choice
prompt "Mainboard model"
optional
-config TARGET_EFI_APP
- bool "efi application"
+config TARGET_EFI_APP32
+ bool "32-bit efi application"
+ select EFI_APP
help
This target is used for running U-Boot on top of EFI. In
this case EFI does the early initialisation, and U-Boot
takes over once the RAM, video and CPU are fully running.
U-Boot is loaded as an application from EFI.
+config TARGET_EFI_APP64
+ bool "64-bit efi application"
+ select EFI_APP
+ select X86_64
+ help
+ This target is used for running U-Boot on top of EFI in 64-bit mode.
+ In this case EFI does the early initialisation, and U-Boot
+ takes over once the RAM, video and CPU are fully running.
+ U-Boot is loaded as an application from EFI.
+
config TARGET_EFI_PAYLOAD
bool "efi payload"
help
diff --git a/board/efi/efi-x86_app/Kconfig b/board/efi/efi-x86_app/Kconfig
index ae87bf34d37..e412702eed7 100644
--- a/board/efi/efi-x86_app/Kconfig
+++ b/board/efi/efi-x86_app/Kconfig
@@ -1,4 +1,4 @@
-if TARGET_EFI_APP
+if EFI_APP
config SYS_BOARD
default "efi-x86_app"
diff --git a/board/efi/efi-x86_app/MAINTAINERS b/board/efi/efi-x86_app/MAINTAINERS
index fb8a6b1c2fa..b292811a8f0 100644
--- a/board/efi/efi-x86_app/MAINTAINERS
+++ b/board/efi/efi-x86_app/MAINTAINERS
@@ -1,6 +1,13 @@
-EFI-X86_APP BOARD
+EFI-X86_APP32 BOARD
M: Simon Glass <sjg@chromium.org>
S: Maintained
F: board/efi/efi-x86_app/
F: include/configs/efi-x86_app.h
-F: configs/efi-x86_app_defconfig
+F: configs/efi-x86_app32_defconfig
+
+EFI-X86_APP64 BOARD
+M: Simon Glass <sjg@chromium.org>
+S: Maintained
+F: board/efi/efi-x86_app/
+F: include/configs/efi-x86_app.h
+F: configs/efi-x86_app64_defconfig
diff --git a/configs/efi-x86_app_defconfig b/configs/efi-x86_app32_defconfig
similarity index 97%
rename from configs/efi-x86_app_defconfig
rename to configs/efi-x86_app32_defconfig
index 3f7c9ba9008..b22a86090a1 100644
--- a/configs/efi-x86_app_defconfig
+++ b/configs/efi-x86_app32_defconfig
@@ -5,7 +5,7 @@ CONFIG_DEFAULT_DEVICE_TREE="efi-x86_app"
CONFIG_DEBUG_UART_BASE=0
CONFIG_DEBUG_UART_CLOCK=0
CONFIG_VENDOR_EFI=y
-CONFIG_TARGET_EFI_APP=y
+CONFIG_TARGET_EFI_APP32=y
CONFIG_DEBUG_UART=y
CONFIG_FIT=y
CONFIG_SHOW_BOOT_PROGRESS=y
diff --git a/configs/efi-x86_app64_defconfig b/configs/efi-x86_app64_defconfig
new file mode 100644
index 00000000000..99fa43387f2
--- /dev/null
+++ b/configs/efi-x86_app64_defconfig
@@ -0,0 +1,39 @@
+CONFIG_X86=y
+CONFIG_NR_DRAM_BANKS=8
+CONFIG_ENV_SIZE=0x1000
+CONFIG_DEFAULT_DEVICE_TREE="efi-x86_app"
+CONFIG_DEBUG_UART_BASE=0
+CONFIG_DEBUG_UART_CLOCK=0
+CONFIG_VENDOR_EFI=y
+CONFIG_TARGET_EFI_APP64=y
+CONFIG_DEBUG_UART=y
+CONFIG_FIT=y
+CONFIG_SHOW_BOOT_PROGRESS=y
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro"
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_LAST_STAGE_INIT=y
+CONFIG_HUSH_PARSER=y
+# CONFIG_CMD_BOOTM is not set
+CONFIG_CMD_PART=y
+# CONFIG_CMD_NET is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_MAC_PARTITION=y
+CONFIG_ISO_PARTITION=y
+CONFIG_EFI_PARTITION=y
+CONFIG_OF_EMBED=y
+CONFIG_ENV_OVERWRITE=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
+# CONFIG_REGEX is not set
+# CONFIG_GZIP is not set
+CONFIG_EFI=y
+CONFIG_EFI_APP_64BIT=y
+# CONFIG_EFI_LOADER is not set
diff --git a/doc/develop/uefi/u-boot_on_efi.rst b/doc/develop/uefi/u-boot_on_efi.rst
index 4b2a733076d..d049f429fdc 100644
--- a/doc/develop/uefi/u-boot_on_efi.rst
+++ b/doc/develop/uefi/u-boot_on_efi.rst
@@ -48,10 +48,10 @@ for that board. It will be either 32-bit or 64-bit. Alternatively, you can
opt for using QEMU [1] and the OVMF [2], as detailed below.
To build U-Boot as an EFI application (32-bit EFI required), enable CONFIG_EFI
-and CONFIG_EFI_APP. The efi-x86_app config (efi-x86_app_defconfig) is set up
+and CONFIG_EFI_APP. The efi-x86_app config (efi-x86_app32_defconfig) is set up
for this. Just build U-Boot as normal, e.g.::
- make efi-x86_app_defconfig
+ make efi-x86_app32_defconfig
make
To build U-Boot as an EFI payload (32-bit or 64-bit EFI can be used), enable
@@ -259,7 +259,7 @@ This work could be extended in a number of ways:
- Add ARM support
-- Add 64-bit application support
+- Add 64-bit application support (in progress)
- Figure out how to solve the interrupt problem
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 12/39] x86: Don't duplicate global_ptr in 64-bit EFI app
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (10 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 11/39] efi: Create a 64-bit app Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 13/39] efi: Add a way to obtain boot services in the app Simon Glass
` (26 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass
This variable is already defined by the EFI code. Drop the duplicate
definition when building a 64-bit EFI app.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/x86/cpu/x86_64/cpu.c | 16 ----------------
arch/x86/cpu/x86_64/misc.c | 16 ++++++++++++++++
lib/efi/efi.c | 9 +++++++++
3 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/arch/x86/cpu/x86_64/cpu.c b/arch/x86/cpu/x86_64/cpu.c
index fb501218e25..a3674e8e29a 100644
--- a/arch/x86/cpu/x86_64/cpu.c
+++ b/arch/x86/cpu/x86_64/cpu.c
@@ -10,22 +10,6 @@
#include <init.h>
#include <asm/global_data.h>
-DECLARE_GLOBAL_DATA_PTR;
-
-/*
- * Global declaration of gd.
- *
- * As we write to it before relocation we have to make sure it is not put into
- * a .bss section which may overlap a .rela section. Initialization forces it
- * into a .data section which cannot overlap any .rela section.
- */
-struct global_data *global_data_ptr = (struct global_data *)~0;
-
-void arch_setup_gd(gd_t *new_gd)
-{
- global_data_ptr = new_gd;
-}
-
int cpu_has_64bit(void)
{
return true;
diff --git a/arch/x86/cpu/x86_64/misc.c b/arch/x86/cpu/x86_64/misc.c
index 02587ff0c50..691b67ff68a 100644
--- a/arch/x86/cpu/x86_64/misc.c
+++ b/arch/x86/cpu/x86_64/misc.c
@@ -7,6 +7,22 @@
#include <common.h>
#include <init.h>
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * Global declaration of gd.
+ *
+ * As we write to it before relocation we have to make sure it is not put into
+ * a .bss section which may overlap a .rela section. Initialization forces it
+ * into a .data section which cannot overlap any .rela section.
+ */
+struct global_data *global_data_ptr = (struct global_data *)~0;
+
+void arch_setup_gd(gd_t *new_gd)
+{
+ global_data_ptr = new_gd;
+}
+
int misc_init_r(void)
{
return 0;
diff --git a/lib/efi/efi.c b/lib/efi/efi.c
index 0c16a5fdd38..69e52e45748 100644
--- a/lib/efi/efi.c
+++ b/lib/efi/efi.c
@@ -17,6 +17,15 @@
#include <efi.h>
#include <efi_api.h>
+/*
+ * Global declaration of gd.
+ *
+ * As we write to it before relocation we have to make sure it is not put into
+ * a .bss section which may overlap a .rela section. Initialization forces it
+ * into a .data section which cannot overlap any .rela section.
+ */
+struct global_data *global_data_ptr = (struct global_data *)~0;
+
/*
* Unfortunately we cannot access any code outside what is built especially
* for the stub. lib/string.c is already being built for the U-Boot payload
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 13/39] efi: Add a way to obtain boot services in the app
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (11 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 12/39] x86: Don't duplicate global_ptr in 64-bit EFI app Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 14/39] efi: Add video support to " Simon Glass
` (25 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
Add a function to return this information along with a stub for the
efi_info_get() function, since calling it otherwise hangs U-Boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
include/efi.h | 8 +++++++-
lib/efi/efi_app.c | 10 ++++++++++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/efi.h b/include/efi.h
index 18c13e0370a..b5835422b95 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -444,9 +444,15 @@ extern char _binary_u_boot_bin_start[], _binary_u_boot_bin_end[];
*
* @return pointer to EFI system table
*/
-
struct efi_system_table *efi_get_sys_table(void);
+/**
+ * efi_get_boot() - Get access to the EFI boot services table
+ *
+ * @return pointer to EFI boot services table
+ */
+struct efi_boot_services *efi_get_boot(void);
+
/**
* efi_get_ram_base() - Find the base of RAM
*
diff --git a/lib/efi/efi_app.c b/lib/efi/efi_app.c
index 907bacd716a..f61665686c5 100644
--- a/lib/efi/efi_app.c
+++ b/lib/efi/efi_app.c
@@ -31,11 +31,21 @@ struct efi_system_table *efi_get_sys_table(void)
return global_priv->sys_table;
}
+struct efi_boot_services *efi_get_boot(void)
+{
+ return global_priv->boot;
+}
+
unsigned long efi_get_ram_base(void)
{
return global_priv->ram_base;
}
+int efi_info_get(enum efi_entry_t type, void **datap, int *sizep)
+{
+ return -ENOSYS;
+}
+
static efi_status_t setup_memory(struct efi_priv *priv)
{
struct efi_boot_services *boot = priv->boot;
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 14/39] efi: Add video support to the app
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (12 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 13/39] efi: Add a way to obtain boot services in the app Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 15/39] efi: Add EFI uclass for media Simon Glass
` (24 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
The current EFI video driver only works when running in the stub. In that
case the stub calls boot services (before jumping to U-Boot proper) and
copies the graphics info over to the efi table. This is necessary because
the stub exits boot services before jumping to U-Boot.
The app maintains access to boot services throughout its life, so does not
need to do this. Update the driver to support calling boot services
directly.
Enable video output for the app. Note that this uses the
EFI_GRAPHICS_OUTPUT_PROTOCOL protocol, even though it mentions vesa.
A sample qemu command-line for this case is:
qemu-system-x86_64 -bios /usr/share/edk2.git/ovmf-ia32/OVMF-pure-efi.fd
-drive id=disk,file=try.img,if=none,format=raw -nic none
-device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Add a note that EFI_GRAPHICS_OUTPUT_PROTOCOL is used
- Update documentation
arch/x86/dts/efi-x86_app.dts | 4 +++
board/efi/efi-x86_app/Kconfig | 4 +++
doc/develop/uefi/u-boot_on_efi.rst | 2 +-
drivers/video/Kconfig | 2 +-
drivers/video/efi.c | 45 ++++++++++++++++++++++++------
include/configs/efi-x86_app.h | 6 ++--
6 files changed, 50 insertions(+), 13 deletions(-)
diff --git a/arch/x86/dts/efi-x86_app.dts b/arch/x86/dts/efi-x86_app.dts
index 04e044a07a8..a5316e2a1a7 100644
--- a/arch/x86/dts/efi-x86_app.dts
+++ b/arch/x86/dts/efi-x86_app.dts
@@ -25,4 +25,8 @@
compatible = "efi,reset";
u-boot,dm-pre-reloc;
};
+ efi-fb {
+ compatible = "efi-fb";
+ };
+
};
diff --git a/board/efi/efi-x86_app/Kconfig b/board/efi/efi-x86_app/Kconfig
index e412702eed7..ecd08d73146 100644
--- a/board/efi/efi-x86_app/Kconfig
+++ b/board/efi/efi-x86_app/Kconfig
@@ -12,4 +12,8 @@ config SYS_SOC
config SYS_CONFIG_NAME
default "efi-x86_app"
+config BOARD_SPECIFIC_OPTIONS # dummy
+ def_bool y
+ imply VIDEO_EFI
+
endif
diff --git a/doc/develop/uefi/u-boot_on_efi.rst b/doc/develop/uefi/u-boot_on_efi.rst
index d049f429fdc..83de9309816 100644
--- a/doc/develop/uefi/u-boot_on_efi.rst
+++ b/doc/develop/uefi/u-boot_on_efi.rst
@@ -263,7 +263,7 @@ This work could be extended in a number of ways:
- Figure out how to solve the interrupt problem
-- Add more drivers to the application side (e.g. video, block devices, USB,
+- Add more drivers to the application side (e.g. block devices, USB,
environment access). This would mostly be an academic exercise as a strong
use case is not readily apparent, but it might be fun.
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index b1f8a9c1e62..9c789b7588d 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -250,7 +250,7 @@ config VIDEO_COREBOOT
config VIDEO_EFI
bool "Enable EFI framebuffer driver support"
- depends on EFI_STUB
+ depends on EFI_STUB || EFI_APP
help
Turn on this option to enable a framebuffeer driver when U-Boot is
loaded as a payload (see README.u-boot_on_efi) by an EFI BIOS where
diff --git a/drivers/video/efi.c b/drivers/video/efi.c
index c248bd352a7..4e13a3efcb1 100644
--- a/drivers/video/efi.c
+++ b/drivers/video/efi.c
@@ -50,6 +50,28 @@ static void efi_find_pixel_bits(u32 mask, u8 *pos, u8 *size)
*size = len;
}
+static int get_mode_info(struct vesa_mode_info *vesa)
+{
+ efi_guid_t efi_gop_guid = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;
+ struct efi_boot_services *boot = efi_get_boot();
+ struct efi_gop_mode *mode;
+ struct efi_gop *gop;
+ int ret;
+
+ if (!boot)
+ return log_msg_ret("sys", -ENOSYS);
+ ret = boot->locate_protocol(&efi_gop_guid, NULL, (void **)&gop);
+ if (ret)
+ return log_msg_ret("prot", -ENOTSUPP);
+
+ mode = gop->mode;
+ vesa->phys_base_ptr = mode->fb_base;
+ vesa->x_resolution = mode->info->width;
+ vesa->y_resolution = mode->info->height;
+
+ return 0;
+}
+
static int save_vesa_mode(struct vesa_mode_info *vesa)
{
struct efi_entry_gopmode *mode;
@@ -57,16 +79,23 @@ static int save_vesa_mode(struct vesa_mode_info *vesa)
int size;
int ret;
- ret = efi_info_get(EFIET_GOP_MODE, (void **)&mode, &size);
- if (ret == -ENOENT) {
- debug("efi graphics output protocol mode not found\n");
- return -ENXIO;
+ if (IS_ENABLED(CONFIG_EFI_APP)) {
+ ret = get_mode_info(vesa);
+ if (ret) {
+ printf("efi graphics output protocol not found\n");
+ return -ENXIO;
+ }
+ } else {
+ ret = efi_info_get(EFIET_GOP_MODE, (void **)&mode, &size);
+ if (ret == -ENOENT) {
+ printf("efi graphics output protocol mode not found\n");
+ return -ENXIO;
+ }
+ vesa->phys_base_ptr = mode->fb_base;
+ vesa->x_resolution = mode->info->width;
+ vesa->y_resolution = mode->info->height;
}
- vesa->phys_base_ptr = mode->fb_base;
- vesa->x_resolution = mode->info->width;
- vesa->y_resolution = mode->info->height;
-
if (mode->info->pixel_format < EFI_GOT_BITMASK) {
fbinfo = &efi_framebuffer_format_map[mode->info->pixel_format];
vesa->red_mask_size = fbinfo->red.size;
diff --git a/include/configs/efi-x86_app.h b/include/configs/efi-x86_app.h
index 33418cfbec4..6061a6db0a4 100644
--- a/include/configs/efi-x86_app.h
+++ b/include/configs/efi-x86_app.h
@@ -10,8 +10,8 @@
#undef CONFIG_TPM_TIS_BASE_ADDRESS
-#define CONFIG_STD_DEVICES_SETTINGS "stdin=usbkbd,vga,serial\0" \
- "stdout=vga,serial\0" \
- "stderr=vga,serial\0"
+#define CONFIG_STD_DEVICES_SETTINGS "stdin=serial\0" \
+ "stdout=vidconsole\0" \
+ "stderr=vidconsole\0"
#endif
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 15/39] efi: Add EFI uclass for media
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (13 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 14/39] efi: Add video support to " Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-10-23 12:26 ` Heinrich Schuchardt
2021-09-25 0:30 ` [PATCH v2 16/39] efi: Add a media/block driver for EFI block devices Simon Glass
` (23 subsequent siblings)
38 siblings, 1 reply; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
At present UCLASS_EFI is used to represent an EFI filesystem among other
things. The description of this uclass is "EFI managed devices" which is
pretty vague. The only driver that uses this uclass is in fact not a real
U-Boot driver, since its operations do not include a struct udevice.
Rather than mess with this, create a new UCLASS_EFI_MEDIA uclass to handle
EFI media such as disks. Make this the uclass to use for EFI media so that
it can be used with 'part list', for example.
The existing implementation using UCLASS_EFI remains as is, for
discussion.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Add MAINTAINERS entry
- Show the correct interface type with 'part list'
- Update the commit message to explain things better
MAINTAINERS | 3 +++
arch/sandbox/dts/test.dts | 4 ++++
disk/part.c | 5 ++++-
drivers/block/Kconfig | 23 +++++++++++++++++++++++
drivers/block/Makefile | 3 +++
drivers/block/blk-uclass.c | 2 +-
drivers/block/efi-media-uclass.c | 15 +++++++++++++++
drivers/block/sb_efi_media.c | 20 ++++++++++++++++++++
include/dm/uclass-id.h | 1 +
test/dm/Makefile | 1 +
test/dm/efi_media.c | 24 ++++++++++++++++++++++++
11 files changed, 99 insertions(+), 2 deletions(-)
create mode 100644 drivers/block/efi-media-uclass.c
create mode 100644 drivers/block/sb_efi_media.c
create mode 100644 test/dm/efi_media.c
diff --git a/MAINTAINERS b/MAINTAINERS
index a254b705e73..0c1cbff7d01 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -708,8 +708,11 @@ W: https://u-boot.readthedocs.io/en/latest/develop/uefi/u-boot_on_efi.html
F: board/efi/efi-x86_app
F: configs/efi-x86_app*
F: doc/develop/uefi/u-boot_on_efi.rst
+F: drivers/block/efi-media-uclass.c
+F: drivers/block/sb_efi_media.c
F: lib/efi/efi_app.c
F: scripts/build-efi.sh
+F: test/dm/efi_media.c
EFI PAYLOAD
M: Heinrich Schuchardt <xypron.glpk@gmx.de>
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index b36447c4a79..23b8435a92a 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -495,6 +495,10 @@
compatible = "sandbox,clk-ccf";
};
+ efi-media {
+ compatible = "sandbox,efi-media";
+ };
+
eth@10002000 {
compatible = "sandbox,eth";
reg = <0x10002000 0x1000>;
diff --git a/disk/part.c b/disk/part.c
index a6a8f7052bd..2560f6a50bc 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -296,8 +296,11 @@ static void print_part_header(const char *type, struct blk_desc *dev_desc)
case IF_TYPE_VIRTIO:
puts("VirtIO");
break;
+ case IF_TYPE_EFI:
+ puts("EFI");
+ break;
default:
- puts ("UNKNOWN");
+ puts("UNKNOWN");
break;
}
printf (" device %d -- Partition Type: %s\n\n",
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 56a4eec05ac..755fdccb574 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -61,6 +61,29 @@ config TPL_BLOCK_CACHE
help
This option enables the disk-block cache in TPL
+config EFI_MEDIA
+ bool "Support EFI media drivers"
+ default y if EFI || SANDBOX
+ help
+ Enable this to support media devices on top of UEFI. This enables
+ just the uclass so you also need a specific driver to make this do
+ anything.
+
+ For sandbox there is a test driver.
+
+if EFI_MEDIA
+
+config EFI_MEDIA_SANDBOX
+ bool "Sandbox EFI media driver"
+ depends on SANDBOX
+ default y
+ help
+ Enables a simple sandbox media driver, used for testing just the
+ EFI_MEDIA uclass. It does not do anything useful, since sandbox does
+ not actually support running on top of UEFI.
+
+endif # EFI_MEDIA
+
config IDE
bool "Support IDE controllers"
select HAVE_BLOCK_DEVICE
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index 94ab5c6f906..3778633da1d 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -14,3 +14,6 @@ obj-$(CONFIG_IDE) += ide.o
endif
obj-$(CONFIG_SANDBOX) += sandbox.o
obj-$(CONFIG_$(SPL_TPL_)BLOCK_CACHE) += blkcache.o
+
+obj-$(CONFIG_EFI_MEDIA) += efi-media-uclass.o
+obj-$(CONFIG_EFI_MEDIA_SANDBOX) += sb_efi_media.o
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index 83682dcc181..2db7ce5de20 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -44,7 +44,7 @@ static enum uclass_id if_type_uclass_id[IF_TYPE_COUNT] = {
[IF_TYPE_SATA] = UCLASS_AHCI,
[IF_TYPE_HOST] = UCLASS_ROOT,
[IF_TYPE_NVME] = UCLASS_NVME,
- [IF_TYPE_EFI] = UCLASS_EFI,
+ [IF_TYPE_EFI] = UCLASS_EFI_MEDIA,
[IF_TYPE_VIRTIO] = UCLASS_VIRTIO,
[IF_TYPE_PVBLOCK] = UCLASS_PVBLOCK,
};
diff --git a/drivers/block/efi-media-uclass.c b/drivers/block/efi-media-uclass.c
new file mode 100644
index 00000000000..e012f6f2f4c
--- /dev/null
+++ b/drivers/block/efi-media-uclass.c
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Uclass for EFI media devices
+ *
+ * Copyright 2021 Google LLC
+ */
+
+#include <common.h>
+#include <dm.h>
+
+UCLASS_DRIVER(efi_media) = {
+ .id = UCLASS_EFI_MEDIA,
+ .name = "efi_media",
+ .flags = DM_UC_FLAG_SEQ_ALIAS,
+};
diff --git a/drivers/block/sb_efi_media.c b/drivers/block/sb_efi_media.c
new file mode 100644
index 00000000000..52af155a600
--- /dev/null
+++ b/drivers/block/sb_efi_media.c
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * EFI_MEDIA driver for sandbox
+ *
+ * Copyright 2021 Google LLC
+ */
+
+#include <common.h>
+#include <dm.h>
+
+static const struct udevice_id sandbox_efi_media_ids[] = {
+ { .compatible = "sandbox,efi-media" },
+ { }
+};
+
+U_BOOT_DRIVER(sandbox_efi_media) = {
+ .name = "sandbox_efi_media",
+ .id = UCLASS_EFI_MEDIA,
+ .of_match = sandbox_efi_media_ids,
+};
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index 3768432b680..34f5e6689d3 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -49,6 +49,7 @@ enum uclass_id {
UCLASS_DSA, /* Distributed (Ethernet) Switch Architecture */
UCLASS_ECDSA, /* Elliptic curve cryptographic device */
UCLASS_EFI, /* EFI managed devices */
+ UCLASS_EFI_MEDIA, /* EFI media (e.g. a disk) */
UCLASS_ETH, /* Ethernet device */
UCLASS_ETH_PHY, /* Ethernet PHY device */
UCLASS_FIRMWARE, /* Firmware */
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 55162e9499d..e24679eb640 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_DMA) += dma.o
obj-$(CONFIG_VIDEO_MIPI_DSI) += dsi_host.o
obj-$(CONFIG_DM_DSA) += dsa.o
obj-$(CONFIG_ECDSA_VERIFY) += ecdsa.o
+obj-$(CONFIG_EFI_MEDIA_SANDBOX) += efi_media.o
obj-$(CONFIG_DM_ETH) += eth.o
ifneq ($(CONFIG_EFI_PARTITION),)
obj-$(CONFIG_FASTBOOT_FLASH_MMC) += fastboot.o
diff --git a/test/dm/efi_media.c b/test/dm/efi_media.c
new file mode 100644
index 00000000000..e343a0e9c85
--- /dev/null
+++ b/test/dm/efi_media.c
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Test for EFI_MEDIA uclass
+ *
+ * Copyright 2021 Google LLC
+ */
+
+#include <common.h>
+#include <dm.h>
+#include <asm/test.h>
+#include <dm/test.h>
+#include <test/test.h>
+#include <test/ut.h>
+
+/* Test that we can use the EFI_MEDIA uclass */
+static int dm_test_efi_media(struct unit_test_state *uts)
+{
+ struct udevice *dev;
+
+ ut_assertok(uclass_first_device_err(UCLASS_EFI_MEDIA, &dev));
+
+ return 0;
+}
+DM_TEST(dm_test_efi_media, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [PATCH v2 15/39] efi: Add EFI uclass for media
2021-09-25 0:30 ` [PATCH v2 15/39] efi: Add EFI uclass for media Simon Glass
@ 2021-10-23 12:26 ` Heinrich Schuchardt
2021-10-26 3:29 ` Simon Glass
0 siblings, 1 reply; 74+ messages in thread
From: Heinrich Schuchardt @ 2021-10-23 12:26 UTC (permalink / raw)
To: Simon Glass
Cc: Bin Meng, Christian Melki, Tom Rini, Ilias Apalodimas,
Alexander Graf, U-Boot Mailing List
On 9/25/21 02:30, Simon Glass wrote:
> At present UCLASS_EFI is used to represent an EFI filesystem among other
UCLASS_EFI is for UEFI drivers that provide the driver binding protocol.
Your new UCLASS seems to be for U-Boot drivers consuming the
EFI_BLOCK_IO_PROTOCOL.
I agree that lib/efi_driver/efi_block_device.c is to much intertwined
with the UEFI subsystem to easily merge it with your requirement. But it
at least can serve as a template.
> things. The description of this uclass is "EFI managed devices" which is
> pretty vague. The only driver that uses this uclass is in fact not a real
> U-Boot driver, since its operations do not include a struct udevice.
>
> Rather than mess with this, create a new UCLASS_EFI_MEDIA uclass to handle
> EFI media such as disks. Make this the uclass to use for EFI media so that
In UEFI speak MEDIA relates to:
* block devices
* firmware files
* Bluetooth
* REST services
* etc
Do you only mean block devices?
Why can't you use UCLASS_BLK for your new driver?
Best regards
Heinrich
> it can be used with 'part list', for example.
>
> The existing implementation using UCLASS_EFI remains as is, for
> discussion.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2:
> - Add MAINTAINERS entry
> - Show the correct interface type with 'part list'
> - Update the commit message to explain things better
>
> MAINTAINERS | 3 +++
> arch/sandbox/dts/test.dts | 4 ++++
> disk/part.c | 5 ++++-
> drivers/block/Kconfig | 23 +++++++++++++++++++++++
> drivers/block/Makefile | 3 +++
> drivers/block/blk-uclass.c | 2 +-
> drivers/block/efi-media-uclass.c | 15 +++++++++++++++
> drivers/block/sb_efi_media.c | 20 ++++++++++++++++++++
> include/dm/uclass-id.h | 1 +
> test/dm/Makefile | 1 +
> test/dm/efi_media.c | 24 ++++++++++++++++++++++++
> 11 files changed, 99 insertions(+), 2 deletions(-)
> create mode 100644 drivers/block/efi-media-uclass.c
> create mode 100644 drivers/block/sb_efi_media.c
> create mode 100644 test/dm/efi_media.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a254b705e73..0c1cbff7d01 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -708,8 +708,11 @@ W: https://u-boot.readthedocs.io/en/latest/develop/uefi/u-boot_on_efi.html
> F: board/efi/efi-x86_app
> F: configs/efi-x86_app*
> F: doc/develop/uefi/u-boot_on_efi.rst
> +F: drivers/block/efi-media-uclass.c
> +F: drivers/block/sb_efi_media.c
> F: lib/efi/efi_app.c
> F: scripts/build-efi.sh
> +F: test/dm/efi_media.c
>
> EFI PAYLOAD
> M: Heinrich Schuchardt <xypron.glpk@gmx.de>
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index b36447c4a79..23b8435a92a 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -495,6 +495,10 @@
> compatible = "sandbox,clk-ccf";
> };
>
> + efi-media {
> + compatible = "sandbox,efi-media";
> + };
> +
> eth@10002000 {
> compatible = "sandbox,eth";
> reg = <0x10002000 0x1000>;
> diff --git a/disk/part.c b/disk/part.c
> index a6a8f7052bd..2560f6a50bc 100644
> --- a/disk/part.c
> +++ b/disk/part.c
> @@ -296,8 +296,11 @@ static void print_part_header(const char *type, struct blk_desc *dev_desc)
> case IF_TYPE_VIRTIO:
> puts("VirtIO");
> break;
> + case IF_TYPE_EFI:
> + puts("EFI");
> + break;
> default:
> - puts ("UNKNOWN");
> + puts("UNKNOWN");
> break;
> }
> printf (" device %d -- Partition Type: %s\n\n",
> diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
> index 56a4eec05ac..755fdccb574 100644
> --- a/drivers/block/Kconfig
> +++ b/drivers/block/Kconfig
> @@ -61,6 +61,29 @@ config TPL_BLOCK_CACHE
> help
> This option enables the disk-block cache in TPL
>
> +config EFI_MEDIA
> + bool "Support EFI media drivers"
> + default y if EFI || SANDBOX
> + help
> + Enable this to support media devices on top of UEFI. This enables
> + just the uclass so you also need a specific driver to make this do
> + anything.
> +
> + For sandbox there is a test driver.
> +
> +if EFI_MEDIA
> +
> +config EFI_MEDIA_SANDBOX
> + bool "Sandbox EFI media driver"
> + depends on SANDBOX
> + default y
> + help
> + Enables a simple sandbox media driver, used for testing just the
> + EFI_MEDIA uclass. It does not do anything useful, since sandbox does
> + not actually support running on top of UEFI.
> +
> +endif # EFI_MEDIA
> +
> config IDE
> bool "Support IDE controllers"
> select HAVE_BLOCK_DEVICE
> diff --git a/drivers/block/Makefile b/drivers/block/Makefile
> index 94ab5c6f906..3778633da1d 100644
> --- a/drivers/block/Makefile
> +++ b/drivers/block/Makefile
> @@ -14,3 +14,6 @@ obj-$(CONFIG_IDE) += ide.o
> endif
> obj-$(CONFIG_SANDBOX) += sandbox.o
> obj-$(CONFIG_$(SPL_TPL_)BLOCK_CACHE) += blkcache.o
> +
> +obj-$(CONFIG_EFI_MEDIA) += efi-media-uclass.o
> +obj-$(CONFIG_EFI_MEDIA_SANDBOX) += sb_efi_media.o
> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
> index 83682dcc181..2db7ce5de20 100644
> --- a/drivers/block/blk-uclass.c
> +++ b/drivers/block/blk-uclass.c
> @@ -44,7 +44,7 @@ static enum uclass_id if_type_uclass_id[IF_TYPE_COUNT] = {
> [IF_TYPE_SATA] = UCLASS_AHCI,
> [IF_TYPE_HOST] = UCLASS_ROOT,
> [IF_TYPE_NVME] = UCLASS_NVME,
> - [IF_TYPE_EFI] = UCLASS_EFI,
UCLASS_EFI_MEDIA is only relevant for the EFI app and should not be
compiled into normal U-Boot. This change is bound to break the UEFI
sub-system.
Why don't you define a new if_type for your use case?
blk_get_devnum_by_typename() uses if_type to check if the corresponding
uclass exists. Why is this check needed? If we remove it, we can drop
if_type_uclass_id[] completely. This would be my preferred solution.
Best regards
Heinrich
> + [IF_TYPE_EFI] = UCLASS_EFI_MEDIA,
> [IF_TYPE_VIRTIO] = UCLASS_VIRTIO,
> [IF_TYPE_PVBLOCK] = UCLASS_PVBLOCK,
> };
> diff --git a/drivers/block/efi-media-uclass.c b/drivers/block/efi-media-uclass.c
> new file mode 100644
> index 00000000000..e012f6f2f4c
> --- /dev/null
> +++ b/drivers/block/efi-media-uclass.c
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Uclass for EFI media devices
> + *
> + * Copyright 2021 Google LLC
> + */
> +
> +#include <common.h>
> +#include <dm.h>
> +
> +UCLASS_DRIVER(efi_media) = {
> + .id = UCLASS_EFI_MEDIA,
> + .name = "efi_media",
> + .flags = DM_UC_FLAG_SEQ_ALIAS,
> +};
> diff --git a/drivers/block/sb_efi_media.c b/drivers/block/sb_efi_media.c
> new file mode 100644
> index 00000000000..52af155a600
> --- /dev/null
> +++ b/drivers/block/sb_efi_media.c
> @@ -0,0 +1,20 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * EFI_MEDIA driver for sandbox
> + *
> + * Copyright 2021 Google LLC
> + */
> +
> +#include <common.h>
> +#include <dm.h>
> +
> +static const struct udevice_id sandbox_efi_media_ids[] = {
> + { .compatible = "sandbox,efi-media" },
> + { }
> +};
> +
> +U_BOOT_DRIVER(sandbox_efi_media) = {
> + .name = "sandbox_efi_media",
> + .id = UCLASS_EFI_MEDIA,
> + .of_match = sandbox_efi_media_ids,
> +};
> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
> index 3768432b680..34f5e6689d3 100644
> --- a/include/dm/uclass-id.h
> +++ b/include/dm/uclass-id.h
> @@ -49,6 +49,7 @@ enum uclass_id {
> UCLASS_DSA, /* Distributed (Ethernet) Switch Architecture */
> UCLASS_ECDSA, /* Elliptic curve cryptographic device */
> UCLASS_EFI, /* EFI managed devices */
> + UCLASS_EFI_MEDIA, /* EFI media (e.g. a disk) */
> UCLASS_ETH, /* Ethernet device */
> UCLASS_ETH_PHY, /* Ethernet PHY device */
> UCLASS_FIRMWARE, /* Firmware */
> diff --git a/test/dm/Makefile b/test/dm/Makefile
> index 55162e9499d..e24679eb640 100644
> --- a/test/dm/Makefile
> +++ b/test/dm/Makefile
> @@ -37,6 +37,7 @@ obj-$(CONFIG_DMA) += dma.o
> obj-$(CONFIG_VIDEO_MIPI_DSI) += dsi_host.o
> obj-$(CONFIG_DM_DSA) += dsa.o
> obj-$(CONFIG_ECDSA_VERIFY) += ecdsa.o
> +obj-$(CONFIG_EFI_MEDIA_SANDBOX) += efi_media.o
> obj-$(CONFIG_DM_ETH) += eth.o
> ifneq ($(CONFIG_EFI_PARTITION),)
> obj-$(CONFIG_FASTBOOT_FLASH_MMC) += fastboot.o
> diff --git a/test/dm/efi_media.c b/test/dm/efi_media.c
> new file mode 100644
> index 00000000000..e343a0e9c85
> --- /dev/null
> +++ b/test/dm/efi_media.c
> @@ -0,0 +1,24 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Test for EFI_MEDIA uclass
> + *
> + * Copyright 2021 Google LLC
> + */
> +
> +#include <common.h>
> +#include <dm.h>
> +#include <asm/test.h>
> +#include <dm/test.h>
> +#include <test/test.h>
> +#include <test/ut.h>
> +
> +/* Test that we can use the EFI_MEDIA uclass */
> +static int dm_test_efi_media(struct unit_test_state *uts)
> +{
> + struct udevice *dev;
> +
> + ut_assertok(uclass_first_device_err(UCLASS_EFI_MEDIA, &dev));
> +
> + return 0;
> +}
> +DM_TEST(dm_test_efi_media, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
>
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [PATCH v2 15/39] efi: Add EFI uclass for media
2021-10-23 12:26 ` Heinrich Schuchardt
@ 2021-10-26 3:29 ` Simon Glass
0 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-10-26 3:29 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Bin Meng, Christian Melki, Tom Rini, Ilias Apalodimas,
Alexander Graf, U-Boot Mailing List
Hi Heinrich,
On Sat, 23 Oct 2021 at 06:31, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
>
>
> On 9/25/21 02:30, Simon Glass wrote:
> > At present UCLASS_EFI is used to represent an EFI filesystem among other
>
> UCLASS_EFI is for UEFI drivers that provide the driver binding protocol.
>
> Your new UCLASS seems to be for U-Boot drivers consuming the
> EFI_BLOCK_IO_PROTOCOL.
>
> I agree that lib/efi_driver/efi_block_device.c is to much intertwined
> with the UEFI subsystem to easily merge it with your requirement. But it
> at least can serve as a template.
It did.
>
> > things. The description of this uclass is "EFI managed devices" which is
> > pretty vague. The only driver that uses this uclass is in fact not a real
> > U-Boot driver, since its operations do not include a struct udevice.
> >
> > Rather than mess with this, create a new UCLASS_EFI_MEDIA uclass to handle
> > EFI media such as disks. Make this the uclass to use for EFI media so that
>
> In UEFI speak MEDIA relates to:
>
> * block devices
> * firmware files
> * Bluetooth
> * REST services
> * etc
>
> Do you only mean block devices?
Sort of...it is a parent of a block device, like MMC or SCSI.
> Why can't you use UCLASS_BLK for your new driver?
That is the child. I need something to be the parent so that it actually works.
Regards,
Simon
^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH v2 16/39] efi: Add a media/block driver for EFI block devices
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (14 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 15/39] efi: Add EFI uclass for media Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 17/39] efi: Locate all block devices in the app Simon Glass
` (22 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
Add a block driver which handles read/write for EFI block devices. This
driver actually already exists ('efi_block') but is not really suitable
for use as a real U-Boot driver:
- The operations do not provide a udevice
- The code is designed for running as part of EFI loader, so uses
EFI_PRINT() and EFI_CALL().
- The bind method probes the device, which is not permitted
- It uses 'EFI' as its parent device
The new driver is more 'normal', just requiring its platform data be set
up in advance.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Drop mention of partitions from the commit message
drivers/block/Kconfig | 10 ++++
drivers/block/Makefile | 1 +
drivers/block/efi_blk.c | 115 ++++++++++++++++++++++++++++++++++++++++
include/efi.h | 11 ++++
4 files changed, 137 insertions(+)
create mode 100644 drivers/block/efi_blk.c
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 755fdccb574..8235430497d 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -82,6 +82,16 @@ config EFI_MEDIA_SANDBOX
EFI_MEDIA uclass. It does not do anything useful, since sandbox does
not actually support running on top of UEFI.
+config EFI_MEDIA_BLK
+ bool "EFI media block driver"
+ depends on EFI_APP
+ default y
+ help
+ Enables a block driver for providing access to UEFI devices. This
+ allows use of block devices detected by the underlying UEFI
+ implementation. With this it is possible to use filesystems on these
+ devices, for example.
+
endif # EFI_MEDIA
config IDE
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index 3778633da1d..b221a7c6eea 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_$(SPL_TPL_)BLOCK_CACHE) += blkcache.o
obj-$(CONFIG_EFI_MEDIA) += efi-media-uclass.o
obj-$(CONFIG_EFI_MEDIA_SANDBOX) += sb_efi_media.o
+obj-$(CONFIG_EFI_MEDIA_BLK) += efi_blk.o
diff --git a/drivers/block/efi_blk.c b/drivers/block/efi_blk.c
new file mode 100644
index 00000000000..c00b0cc0b1c
--- /dev/null
+++ b/drivers/block/efi_blk.c
@@ -0,0 +1,115 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Block driver for EFI devices
+ * This supports a media driver of UCLASS_EFI with a child UCLASS_BLK
+ * It allows block-level access to EFI devices made available via EFI boot
+ * services
+ *
+ * Copyright 2021 Google LLC
+ */
+
+#include <common.h>
+#include <blk.h>
+#include <dm.h>
+#include <efi.h>
+#include <efi_api.h>
+
+struct efi_block_plat {
+ struct efi_block_io *blkio;
+};
+
+/**
+ * Read from block device
+ *
+ * @dev: device
+ * @blknr: first block to be read
+ * @blkcnt: number of blocks to read
+ * @buffer: output buffer
+ * Return: number of blocks transferred
+ */
+static ulong efi_bl_read(struct udevice *dev, lbaint_t blknr, lbaint_t blkcnt,
+ void *buffer)
+{
+ struct efi_block_plat *plat = dev_get_plat(dev);
+ struct efi_block_io *io = plat->blkio;
+ efi_status_t ret;
+
+ log_debug("read buf=%p, block=%lx, count=%lx: ", buffer, (ulong)blknr,
+ (ulong)blkcnt);
+ ret = io->read_blocks(io, io->media->media_id, blknr,
+ blkcnt * io->media->block_size, buffer);
+ log_debug("ret=%lx (dec %ld)\n", ret & ~EFI_ERROR_MASK,
+ ret & ~EFI_ERROR_MASK);
+ if (ret)
+ return 0;
+
+ return blkcnt;
+}
+
+/**
+ * Write to block device
+ *
+ * @dev: device
+ * @blknr: first block to be write
+ * @blkcnt: number of blocks to write
+ * @buffer: input buffer
+ * Return: number of blocks transferred
+ */
+static ulong efi_bl_write(struct udevice *dev, lbaint_t blknr, lbaint_t blkcnt,
+ const void *buffer)
+{
+ struct efi_block_plat *plat = dev_get_plat(dev);
+ struct efi_block_io *io = plat->blkio;
+ efi_status_t ret;
+
+ log_debug("write buf=%p, block=%lx, count=%lx: ", buffer, (ulong)blknr,
+ (ulong)blkcnt);
+ ret = io->write_blocks(io, io->media->media_id, blknr,
+ blkcnt * io->media->block_size, (void *)buffer);
+ log_debug("ret=%lx (dec %ld)\n", ret & ~EFI_ERROR_MASK,
+ ret & ~EFI_ERROR_MASK);
+ if (ret)
+ return 0;
+
+ return blkcnt;
+}
+
+/* Block device driver operators */
+static const struct blk_ops efi_blk_ops = {
+ .read = efi_bl_read,
+ .write = efi_bl_write,
+};
+
+U_BOOT_DRIVER(efi_block) = {
+ .name = "efi_block",
+ .id = UCLASS_BLK,
+ .ops = &efi_blk_ops,
+ .plat_auto = sizeof(struct efi_block_plat),
+};
+
+static int efi_media_bind(struct udevice *dev)
+{
+ struct efi_media_plat *plat = dev_get_plat(dev);
+ struct efi_block_plat *blk_plat;
+ struct udevice *blk;
+ int ret;
+
+ ret = blk_create_devicef(dev, "efi_block", "blk", IF_TYPE_EFI,
+ dev_seq(dev), plat->blkio->media->block_size,
+ plat->blkio->media->last_block, &blk);
+ if (ret) {
+ debug("Cannot create block device\n");
+ return ret;
+ }
+ blk_plat = dev_get_plat(blk);
+ blk_plat->blkio = plat->blkio;
+
+ return 0;
+}
+
+U_BOOT_DRIVER(efi_media) = {
+ .name = "efi_media",
+ .id = UCLASS_EFI_MEDIA,
+ .bind = efi_media_bind,
+ .plat_auto = sizeof(struct efi_media_plat),
+};
diff --git a/include/efi.h b/include/efi.h
index b5835422b95..0ec5913ddd1 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -414,6 +414,17 @@ struct efi_priv {
void *next_hdr;
};
+/*
+ * EFI attributes of the udevice handled by efi_media driver
+ *
+ * @handle: handle of the controller on which this driver is installed
+ * @blkio: block io protocol proxied by this driver
+ */
+struct efi_media_plat {
+ efi_handle_t handle;
+ struct efi_block_io *blkio;
+};
+
/* Base address of the EFI image */
extern char image_base[];
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 17/39] efi: Locate all block devices in the app
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (15 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 16/39] efi: Add a media/block driver for EFI block devices Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 18/39] patman: Use a ValueError exception if tools.Run() fails Simon Glass
` (21 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
When starting the app, locate all block devices and make them available
to U-Boot. This allows listing partitions and accessing files in
filesystems.
EFI also has the concept of 'disks', meaning boot media. For now, this
is not obviously useful in U-Boot, but add code to at least locate these.
This can be expanded later as needed.
Series-changes; 2
- Store device path in struct efi_media_plat
- Don't export efi_bind_block()
- Only bind devices for media devices, not for partitions
- Show devices that are processed
- Update documentation
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
doc/develop/uefi/u-boot_on_efi.rst | 4 +-
include/efi.h | 6 +-
include/efi_api.h | 15 ++
lib/efi/efi_app.c | 223 +++++++++++++++++++++++++++++
4 files changed, 243 insertions(+), 5 deletions(-)
diff --git a/doc/develop/uefi/u-boot_on_efi.rst b/doc/develop/uefi/u-boot_on_efi.rst
index 83de9309816..f39be4a1ed9 100644
--- a/doc/develop/uefi/u-boot_on_efi.rst
+++ b/doc/develop/uefi/u-boot_on_efi.rst
@@ -263,9 +263,7 @@ This work could be extended in a number of ways:
- Figure out how to solve the interrupt problem
-- Add more drivers to the application side (e.g. block devices, USB,
- environment access). This would mostly be an academic exercise as a strong
- use case is not readily apparent, but it might be fun.
+- Add more drivers to the application side (e.g.USB, environment access).
- Avoid turning off boot services in the stub. Instead allow U-Boot to make
use of boot services in case it wants to. It is unclear what it might want
diff --git a/include/efi.h b/include/efi.h
index 0ec5913ddd1..908c5dc6ebd 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -419,10 +419,12 @@ struct efi_priv {
*
* @handle: handle of the controller on which this driver is installed
* @blkio: block io protocol proxied by this driver
+ * @device_path: EFI path to the device
*/
struct efi_media_plat {
- efi_handle_t handle;
- struct efi_block_io *blkio;
+ efi_handle_t handle;
+ struct efi_block_io *blkio;
+ struct efi_device_path *device_path;
};
/* Base address of the EFI image */
diff --git a/include/efi_api.h b/include/efi_api.h
index c8f959bb720..0e88b3e5dbe 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -1994,4 +1994,19 @@ struct efi_firmware_management_protocol {
const u16 *package_version_name);
};
+#define EFI_DISK_IO_PROTOCOL_GUID \
+ EFI_GUID(0xce345171, 0xba0b, 0x11d2, 0x8e, 0x4f, \
+ 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
+
+struct efi_disk {
+ u64 revision;
+ efi_status_t (EFIAPI *read_disk)(struct efi_disk *this, u32 media_id,
+ u64 offset, efi_uintn_t buffer_size,
+ void *buffer);
+
+ efi_status_t (EFIAPI *write_disk)(struct efi_disk *this, u32 media_id,
+ u64 offset, efi_uintn_t buffer_size,
+ void *buffer);
+};
+
#endif
diff --git a/lib/efi/efi_app.c b/lib/efi/efi_app.c
index f61665686c5..e38d46b15db 100644
--- a/lib/efi/efi_app.c
+++ b/lib/efi/efi_app.c
@@ -21,6 +21,9 @@
#include <efi.h>
#include <efi_api.h>
#include <sysreset.h>
+#include <dm/device-internal.h>
+#include <dm/lists.h>
+#include <dm/root.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -46,6 +49,64 @@ int efi_info_get(enum efi_entry_t type, void **datap, int *sizep)
return -ENOSYS;
}
+/**
+ * efi_print_str() - Print a UFT-16 string to the U-Boot console
+ *
+ * @str: String to print
+ */
+static void efi_print_str(const u16 *str)
+{
+ while (*str) {
+ int ch = *str++;
+
+ if (ch > ' ' && ch < 127)
+ putc(ch);
+ }
+}
+
+/**
+ * efi_bind_block() - bind a new block device to an EFI device
+ *
+ * Binds a new top-level EFI_MEDIA device as well as a child block device so
+ * that the block device can be accessed in U-Boot.
+ *
+ * The device can then be accessed using 'part list efi 0', 'fat ls efi 0:1',
+ * for example, just like any other interface type.
+ *
+ * @handle: handle of the controller on which this driver is installed
+ * @blkio: block io protocol proxied by this driver
+ * @device_path: EFI device path structure for this
+ * @len: Length of @device_path in bytes
+ * @devp: Returns the bound device
+ * @return 0 if OK, -ve on error
+ */
+int efi_bind_block(efi_handle_t handle, struct efi_block_io *blkio,
+ struct efi_device_path *device_path, int len,
+ struct udevice **devp)
+{
+ struct efi_media_plat plat;
+ struct udevice *dev;
+ char name[18];
+ int ret;
+
+ plat.handle = handle;
+ plat.blkio = blkio;
+ plat.device_path = malloc(device_path->length);
+ if (!plat.device_path)
+ return log_msg_ret("path", -ENOMEM);
+ memcpy(plat.device_path, device_path, device_path->length);
+ ret = device_bind(dm_root(), DM_DRIVER_GET(efi_media), "efi_media",
+ &plat, ofnode_null(), &dev);
+ if (ret)
+ return log_msg_ret("bind", ret);
+
+ snprintf(name, sizeof(name), "efi_media_%x", dev_seq(dev));
+ device_set_name(dev, name);
+ *devp = dev;
+
+ return 0;
+}
+
static efi_status_t setup_memory(struct efi_priv *priv)
{
struct efi_boot_services *boot = priv->boot;
@@ -105,6 +166,168 @@ static void free_memory(struct efi_priv *priv)
global_data_ptr = NULL;
}
+static int setup_disks(void)
+{
+ /* This is not fully implemented yet */
+ return 0;
+
+ efi_guid_t efi_disk_guid = EFI_DISK_IO_PROTOCOL_GUID;
+ struct efi_boot_services *boot = efi_get_boot();
+ struct efi_disk *disk;
+ int ret;
+
+ if (!boot)
+ return log_msg_ret("sys", -ENOSYS);
+ ret = boot->locate_protocol(&efi_disk_guid, NULL, (void **)&disk);
+ if (ret)
+ return log_msg_ret("prot", -ENOTSUPP);
+
+ return 0;
+}
+
+/**
+ * devpath_is_partition() - Figure out if a device path is a partition
+ *
+ * Checks if a device path refers to a partition on some media device. This
+ * works by checking for a valid partition number in a hard-driver media device
+ * as the final component of the device path.
+ *
+ * @return true if a partition, false if not (e.g. it might be media which
+ * contains partitions)
+ */
+static bool devpath_is_partition(const struct efi_device_path *path)
+{
+ const struct efi_device_path *p;
+ bool was_part;
+
+ for (p = path; p->type != DEVICE_PATH_TYPE_END;
+ p = (void *)p + p->length) {
+ was_part = false;
+ if (p->type == DEVICE_PATH_TYPE_MEDIA_DEVICE &&
+ p->sub_type == DEVICE_PATH_SUB_TYPE_HARD_DRIVE_PATH) {
+ struct efi_device_path_hard_drive_path *hd =
+ (void *)path;
+
+ if (hd->partition_number)
+ was_part = true;
+ }
+ }
+
+ return was_part;
+}
+
+/**
+ * setup_block() - Find all block devices and setup EFI devices for them
+ *
+ * Partitions are ignored, since U-Boot has partition handling. Errors with
+ * particular devices produce a warning but execution continues to try to
+ * find others.
+ *
+ * @return 0 if found, -ENOSYS if there is no boot-services table, -ENOTSUPP
+ * if a required protocol is not supported
+ */
+static int setup_block(void)
+{
+ efi_guid_t efi_blkio_guid = EFI_BLOCK_IO_PROTOCOL_GUID;
+ efi_guid_t efi_devpath_guid = EFI_DEVICE_PATH_PROTOCOL_GUID;
+ efi_guid_t efi_pathutil_guid = EFI_DEVICE_PATH_UTILITIES_PROTOCOL_GUID;
+ efi_guid_t efi_pathtext_guid = EFI_DEVICE_PATH_TO_TEXT_PROTOCOL_GUID;
+ struct efi_boot_services *boot = efi_get_boot();
+ struct efi_device_path_utilities_protocol *util;
+ struct efi_device_path_to_text_protocol *text;
+ struct efi_device_path *path;
+ struct efi_block_io *blkio;
+ efi_uintn_t num_handles;
+ efi_handle_t *handle;
+ int ret, i;
+
+ if (!boot)
+ return log_msg_ret("sys", -ENOSYS);
+
+ /* Find all devices which support the block I/O protocol */
+ ret = boot->locate_handle_buffer(BY_PROTOCOL, &efi_blkio_guid, NULL,
+ &num_handles, &handle);
+ if (ret)
+ return log_msg_ret("loc", -ENOTSUPP);
+ log_debug("Found %d handles:\n", (int)num_handles);
+
+ /* We need to look up the path size and convert it to text */
+ ret = boot->locate_protocol(&efi_pathutil_guid, NULL, (void **)&util);
+ if (ret)
+ return log_msg_ret("util", -ENOTSUPP);
+ ret = boot->locate_protocol(&efi_pathtext_guid, NULL, (void **)&text);
+ if (ret)
+ return log_msg_ret("text", -ENOTSUPP);
+
+ for (i = 0; i < num_handles; i++) {
+ struct udevice *dev;
+ const u16 *name;
+ bool is_part;
+ int len;
+
+ ret = boot->handle_protocol(handle[i], &efi_devpath_guid,
+ (void **)&path);
+ if (ret) {
+ log_warning("- devpath %d failed (ret=%d)\n", i, ret);
+ continue;
+ }
+
+ ret = boot->handle_protocol(handle[i], &efi_blkio_guid,
+ (void **)&blkio);
+ if (ret) {
+ log_warning("- blkio %d failed (ret=%d)\n", i, ret);
+ continue;
+ }
+
+ name = text->convert_device_path_to_text(path, true, false);
+ is_part = devpath_is_partition(path);
+
+ if (!is_part) {
+ len = util->get_device_path_size(path);
+ ret = efi_bind_block(handle[i], blkio, path, len, &dev);
+ if (ret) {
+ log_warning("- blkio bind %d failed (ret=%d)\n",
+ i, ret);
+ continue;
+ }
+ } else {
+ dev = NULL;
+ }
+
+ /*
+ * Show the device name if we created one. Otherwise indicate
+ * that it is a partition.
+ *
+ * We don't seem to have have a way to print unicode on the
+ * U-Boot console at present, so use our own function.
+ */
+ printf("%2d: %-12s ", i, dev ? dev->name : "<partition>");
+ efi_print_str(name);
+ printf("\n");
+ }
+ boot->free_pool(handle);
+
+ return 0;
+}
+
+int dm_scan_other(bool pre_reloc_only)
+{
+ if (gd->flags & GD_FLG_RELOC) {
+ int ret;
+
+ ret = setup_block();
+ if (ret)
+ return ret;
+
+ /* Not needed at present, but could be useful one day? */
+ ret = setup_disks();
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
/**
* efi_main() - Start an EFI image
*
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 18/39] patman: Use a ValueError exception if tools.Run() fails
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (16 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 17/39] efi: Locate all block devices in the app Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 19/39] binman: Report an error if test files fail to compile Simon Glass
` (20 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass
The Exception base class is a very vague and could be confusing to the
test system. Use the more specific ValueError exception instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
tools/patman/tools.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/patman/tools.py b/tools/patman/tools.py
index 877e37cd8da..23ddb124804 100644
--- a/tools/patman/tools.py
+++ b/tools/patman/tools.py
@@ -348,7 +348,7 @@ def Run(name, *args, **kwargs):
result = command.RunPipe([all_args], capture=True, capture_stderr=True,
env=env, raise_on_error=False, binary=binary)
if result.return_code:
- raise Exception("Error %d running '%s': %s" %
+ raise ValueError("Error %d running '%s': %s" %
(result.return_code,' '.join(all_args),
result.stderr))
return result.stdout
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 19/39] binman: Report an error if test files fail to compile
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (17 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 18/39] patman: Use a ValueError exception if tools.Run() fails Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 20/39] binman: Support reading the offset of an ELF-file symbol Simon Glass
` (19 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass
At present any error from the 'make' command is silently swallowed by the
test system. Fix this by showing it when detected.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
tools/binman/elf_test.py | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/binman/elf_test.py b/tools/binman/elf_test.py
index 7a128018d9f..bcccd78c0a1 100644
--- a/tools/binman/elf_test.py
+++ b/tools/binman/elf_test.py
@@ -70,8 +70,12 @@ def BuildElfTestFiles(target_dir):
# correctly. So drop any make flags here.
if 'MAKEFLAGS' in os.environ:
del os.environ['MAKEFLAGS']
- tools.Run('make', '-C', target_dir, '-f',
- os.path.join(testdir, 'Makefile'), 'SRC=%s/' % testdir)
+ try:
+ tools.Run('make', '-C', target_dir, '-f',
+ os.path.join(testdir, 'Makefile'), 'SRC=%s/' % testdir)
+ except ValueError as e:
+ # The test system seems to suppress this in a strange way
+ print(e)
class TestElf(unittest.TestCase):
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 20/39] binman: Support reading the offset of an ELF-file symbol
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (18 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 19/39] binman: Report an error if test files fail to compile Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 21/39] binman: Allow timeout to occur in the image or its section Simon Glass
` (18 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass
Binman needs to be able to update the contents of an ELF file after it has
been build. To support this, add a function to locate the position of a
symbol's contents within the file.
Fix the comments on bss_data.c and Symbol while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
tools/binman/elf.py | 53 ++++++++++++++++++++++++++++++--
tools/binman/elf_test.py | 37 ++++++++++++++++++++++
tools/binman/test/Makefile | 5 ++-
tools/binman/test/bss_data.c | 2 +-
tools/binman/test/embed_data.c | 16 ++++++++++
tools/binman/test/embed_data.lds | 23 ++++++++++++++
6 files changed, 131 insertions(+), 5 deletions(-)
create mode 100644 tools/binman/test/embed_data.c
create mode 100644 tools/binman/test/embed_data.lds
diff --git a/tools/binman/elf.py b/tools/binman/elf.py
index 03b49d7163c..4aca4f847ce 100644
--- a/tools/binman/elf.py
+++ b/tools/binman/elf.py
@@ -24,7 +24,14 @@ try:
except: # pragma: no cover
ELF_TOOLS = False
-Symbol = namedtuple('Symbol', ['section', 'address', 'size', 'weak'])
+# Information about an EFL symbol:
+# section (str): Name of the section containing this symbol
+# address (int): Address of the symbol (its value)
+# size (int): Size of the symbol in bytes
+# weak (bool): True if the symbol is weak
+# offset (int or None): Offset of the symbol's data in the ELF file, or None if
+# not known
+Symbol = namedtuple('Symbol', ['section', 'address', 'size', 'weak', 'offset'])
# Information about an ELF file:
# data: Extracted program contents of ELF file (this would be loaded by an
@@ -71,8 +78,48 @@ def GetSymbols(fname, patterns):
section, size = parts[:2]
if len(parts) > 2:
name = parts[2] if parts[2] != '.hidden' else parts[3]
- syms[name] = Symbol(section, int(value, 16), int(size,16),
- flags[1] == 'w')
+ syms[name] = Symbol(section, int(value, 16), int(size, 16),
+ flags[1] == 'w', None)
+
+ # Sort dict by address
+ return OrderedDict(sorted(syms.items(), key=lambda x: x[1].address))
+
+def GetSymbolFileOffset(fname, patterns):
+ """Get the symbols from an ELF file
+
+ Args:
+ fname: Filename of the ELF file to read
+ patterns: List of regex patterns to search for, each a string
+
+ Returns:
+ None, if the file does not exist, or Dict:
+ key: Name of symbol
+ value: Hex value of symbol
+ """
+ def _GetFileOffset(elf, addr):
+ for seg in elf.iter_segments():
+ seg_end = seg['p_vaddr'] + seg['p_filesz']
+ if seg.header['p_type'] == 'PT_LOAD':
+ if addr >= seg['p_vaddr'] and addr < seg_end:
+ return addr - seg['p_vaddr'] + seg['p_offset']
+
+ if not ELF_TOOLS:
+ raise ValueError('Python elftools package is not available')
+
+ syms = {}
+ with open(fname, 'rb') as fd:
+ elf = ELFFile(fd)
+
+ re_syms = re.compile('|'.join(patterns))
+ for section in elf.iter_sections():
+ if isinstance(section, SymbolTableSection):
+ for symbol in section.iter_symbols():
+ if not re_syms or re_syms.search(symbol.name):
+ addr = symbol.entry['st_value']
+ syms[symbol.name] = Symbol(
+ section.name, addr, symbol.entry['st_size'],
+ symbol.entry['st_info']['bind'] == 'STB_WEAK',
+ _GetFileOffset(elf, addr))
# Sort dict by address
return OrderedDict(sorted(syms.items(), key=lambda x: x[1].address))
diff --git a/tools/binman/elf_test.py b/tools/binman/elf_test.py
index bcccd78c0a1..ac69a95b654 100644
--- a/tools/binman/elf_test.py
+++ b/tools/binman/elf_test.py
@@ -6,6 +6,7 @@
import os
import shutil
+import struct
import sys
import tempfile
import unittest
@@ -221,6 +222,42 @@ class TestElf(unittest.TestCase):
elf.DecodeElf(data, load + 2))
shutil.rmtree(outdir)
+ def testEmbedData(self):
+ """Test for the GetSymbolFileOffset() function"""
+ if not elf.ELF_TOOLS:
+ self.skipTest('Python elftools not available')
+
+ fname = self.ElfTestFile('embed_data')
+ offset = elf.GetSymbolFileOffset(fname, ['embed_start', 'embed_end'])
+ start = offset['embed_start'].offset
+ end = offset['embed_end'].offset
+ data = tools.ReadFile(fname)
+ embed_data = data[start:end]
+ expect = struct.pack('<III', 0x1234, 0x5678, 0)
+ self.assertEqual(expect, embed_data)
+
+ def testEmbedFail(self):
+ """Test calling GetSymbolFileOffset() without elftools"""
+ try:
+ old_val = elf.ELF_TOOLS
+ elf.ELF_TOOLS = False
+ fname = self.ElfTestFile('embed_data')
+ with self.assertRaises(ValueError) as e:
+ elf.GetSymbolFileOffset(fname, ['embed_start', 'embed_end'])
+ self.assertIn('Python elftools package is not available',
+ str(e.exception))
+ finally:
+ elf.ELF_TOOLS = old_val
+
+ def testEmbedDataNoSym(self):
+ """Test for GetSymbolFileOffset() getting no symbols"""
+ if not elf.ELF_TOOLS:
+ self.skipTest('Python elftools not available')
+
+ fname = self.ElfTestFile('embed_data')
+ offset = elf.GetSymbolFileOffset(fname, ['missing_sym'])
+ self.assertEqual({}, offset)
+
if __name__ == '__main__':
unittest.main()
diff --git a/tools/binman/test/Makefile b/tools/binman/test/Makefile
index 0b19b7d9935..6e6cc6de491 100644
--- a/tools/binman/test/Makefile
+++ b/tools/binman/test/Makefile
@@ -31,7 +31,7 @@ LDS_BINMAN_X86 := -T $(SRC)u_boot_binman_syms_x86.lds
TARGETS = u_boot_ucode_ptr u_boot_no_ucode_ptr bss_data \
u_boot_binman_syms u_boot_binman_syms.bin u_boot_binman_syms_bad \
- u_boot_binman_syms_size u_boot_binman_syms_x86
+ u_boot_binman_syms_size u_boot_binman_syms_x86 embed_data
all: $(TARGETS)
@@ -44,6 +44,9 @@ u_boot_ucode_ptr: u_boot_ucode_ptr.c
bss_data: CFLAGS += $(SRC)bss_data.lds
bss_data: bss_data.c
+embed_data: CFLAGS += $(SRC)embed_data.lds
+embed_data: embed_data.c
+
u_boot_binman_syms.bin: u_boot_binman_syms
$(OBJCOPY) -O binary $< -R .note.gnu.build-id $@
diff --git a/tools/binman/test/bss_data.c b/tools/binman/test/bss_data.c
index 79537c31b65..4f9b64cef9e 100644
--- a/tools/binman/test/bss_data.c
+++ b/tools/binman/test/bss_data.c
@@ -2,7 +2,7 @@
/*
* Copyright (c) 2016 Google, Inc
*
- * Simple program to create a _dt_ucode_base_size symbol which can be read
+ * Simple program to create a bss_data region so the symbol can be read
* by binutils. This is used by binman tests.
*/
diff --git a/tools/binman/test/embed_data.c b/tools/binman/test/embed_data.c
new file mode 100644
index 00000000000..47d8c38248c
--- /dev/null
+++ b/tools/binman/test/embed_data.c
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 Google LLC
+ *
+ * Simple program including some embedded data that can be accessed by binman.
+ * This is used by binman tests.
+ */
+
+int first[10] = {1};
+int embed[3] __attribute__((section(".embed"))) = {0x1234, 0x5678};
+int second[10] = {1};
+
+int main(void)
+{
+ return 0;
+}
diff --git a/tools/binman/test/embed_data.lds b/tools/binman/test/embed_data.lds
new file mode 100644
index 00000000000..908bf66c294
--- /dev/null
+++ b/tools/binman/test/embed_data.lds
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 Google LLC
+ */
+
+OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
+OUTPUT_ARCH(i386)
+ENTRY(_start)
+
+SECTIONS
+{
+ _start = .;
+ __data_start = .;
+ .data :
+ {
+ . = ALIGN(32);
+ embed_start = .;
+ *(.embed*)
+ embed_end = .;
+ . = ALIGN(32);
+ *(.data*)
+ }
+}
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 21/39] binman: Allow timeout to occur in the image or its section
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (19 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 20/39] binman: Support reading the offset of an ELF-file symbol Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 22/39] binman: Tidy up comments on _DoTestFile() Simon Glass
` (17 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass
At present testThreadTimeout() assumes that the expected timeout happens
first when building the section, but it can just as easily happen at the
top-level image. Update the test to cope with both.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
tools/binman/ftest.py | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index cea3ebf2b9f..8199a4fc7e0 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -4565,8 +4565,7 @@ class TestFunctional(unittest.TestCase):
with self.assertRaises(ValueError) as e:
self._DoTestFile('202_section_timeout.dts',
test_section_timeout=True)
- self.assertIn("Node '/binman/section@0': Timed out obtaining contents",
- str(e.exception))
+ self.assertIn("Timed out obtaining contents", str(e.exception))
def testTiming(self):
"""Test output of timing information"""
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 22/39] binman: Tidy up comments on _DoTestFile()
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (20 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 21/39] binman: Allow timeout to occur in the image or its section Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 23/39] binman: Support updating the dtb in an ELF file Simon Glass
` (16 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass
The comment for this function is missing an argument and the return value.
Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
tools/binman/ftest.py | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 8199a4fc7e0..39a4b94cd0b 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -334,6 +334,11 @@ class TestFunctional(unittest.TestCase):
extra_indirs: Extra input directories to add using -I
threads: Number of threads to use (None for default, 0 for
single-threaded)
+ test_section_timeout: True to force the first time to timeout, as
+ used in testThreadTimeout()
+
+ Returns:
+ int return code, 0 on success
"""
args = []
if debug:
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 23/39] binman: Support updating the dtb in an ELF file
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (21 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 22/39] binman: Tidy up comments on _DoTestFile() Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 24/39] efi: serial: Support arrow keys Simon Glass
` (15 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass
WIth EFI we must embed the devicetree in an ELF image so that it is loaded
as part of the executable file. We want it to include the binman
definition in there also, which in some cases cannot be created until the
ELF (u-boot) is built. Add an option to binman to support writing the
updated dtb to the ELF file u-boot.out
This is useful with the EFI app, which is always packaged as an ELF file.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
tools/binman/binman.rst | 36 ++++++++++
tools/binman/cmdline.py | 2 +
tools/binman/control.py | 11 +++
tools/binman/elf.py | 21 ++++++
tools/binman/ftest.py | 83 +++++++++++++++++++++-
tools/binman/test/Makefile | 10 ++-
tools/binman/test/u_boot_binman_embed.c | 13 ++++
tools/binman/test/u_boot_binman_embed.lds | 29 ++++++++
tools/binman/test/u_boot_binman_embed_sm.c | 13 ++++
9 files changed, 216 insertions(+), 2 deletions(-)
create mode 100644 tools/binman/test/u_boot_binman_embed.c
create mode 100644 tools/binman/test/u_boot_binman_embed.lds
create mode 100644 tools/binman/test/u_boot_binman_embed_sm.c
diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
index 09e7b571982..e2c7083722d 100644
--- a/tools/binman/binman.rst
+++ b/tools/binman/binman.rst
@@ -822,6 +822,42 @@ the 'warning' line in scripts/Makefile.lib to see what it has found::
# u_boot_dtsi_options_debug = $(u_boot_dtsi_options_raw)
+Updating an ELF file
+====================
+
+For the EFI app, where U-Boot is loaded from UEFI and runs as an app, there is
+no way to update the devicetree after U-Boot is built. Normally this works by
+creating a new u-boot.dtb.out with he updated devicetree, which is automatically
+built into the output image. With ELF this is not possible since the ELF is
+not part of an image, just a stand-along file. We must create an updated ELF
+file with the new devicetree.
+
+This is handled by the --update-fdt-in-elf option. It takes four arguments,
+separated by comma:
+
+ infile - filename of input ELF file, e.g. 'u-boot's
+ outfile - filename of output ELF file, e.g. 'u-boot.out'
+ begin_sym - symbol at the start of the embedded devicetree, e.g.
+ '__dtb_dt_begin'
+ end_sym - symbol at the start of the embedded devicetree, e.g.
+ '__dtb_dt_end'
+
+When this flag is used, U-Boot does all the normal packaging, but as an
+additional step, it creates a new ELF file with the new devicetree embedded in
+it.
+
+If logging is enabled you will see a message like this::
+
+ Updating file 'u-boot' with data length 0x400a (16394) between symbols
+ '__dtb_dt_begin' and '__dtb_dt_end'
+
+There must be enough space for the updated devicetree. If not, an error like
+the following is produced::
+
+ ValueError: Not enough space in 'u-boot' for data length 0x400a (16394);
+ size is 0x1744 (5956)
+
+
Entry Documentation
===================
diff --git a/tools/binman/cmdline.py b/tools/binman/cmdline.py
index d6156df408b..23729f16dcc 100644
--- a/tools/binman/cmdline.py
+++ b/tools/binman/cmdline.py
@@ -71,6 +71,8 @@ controlled by a description in the board device tree.'''
'given')
build_parser.add_argument('-u', '--update-fdt', action='store_true',
default=False, help='Update the binman node with offset/size info')
+ build_parser.add_argument('--update-fdt-in-elf', type=str,
+ help='Update an ELF file with the output dtb: infile,outfile,begin_sym,end_sym')
entry_parser = subparsers.add_parser('entry-docs',
help='Write out entry documentation (see entries.rst)')
diff --git a/tools/binman/control.py b/tools/binman/control.py
index dcba02ff7f8..e73bc55252c 100644
--- a/tools/binman/control.py
+++ b/tools/binman/control.py
@@ -598,6 +598,13 @@ def Binman(args):
tools.FinaliseOutputDir()
return 0
+ elf_params = None
+ if args.update_fdt_in_elf:
+ elf_params = args.update_fdt_in_elf.split(',')
+ if len(elf_params) != 4:
+ raise ValueError('Invalid args %s to --update-fdt-in-elf: expected infile,outfile,begin_sym,end_sym' %
+ elf_params)
+
# Try to figure out which device tree contains our image description
if args.dt:
dtb_fname = args.dt
@@ -644,6 +651,10 @@ def Binman(args):
for dtb_item in state.GetAllFdts():
tools.WriteFile(dtb_item._fname, dtb_item.GetContents())
+ if elf_params:
+ data = state.GetFdtForEtype('u-boot-dtb').GetContents()
+ elf.UpdateFile(*elf_params, data)
+
if missing:
tout.Warning("\nSome images are invalid")
diff --git a/tools/binman/elf.py b/tools/binman/elf.py
index 4aca4f847ce..de2bb4651fa 100644
--- a/tools/binman/elf.py
+++ b/tools/binman/elf.py
@@ -348,3 +348,24 @@ def DecodeElf(data, location):
segment.data()[offset:])
return ElfInfo(output, data_start, elf.header['e_entry'] + virt_to_phys,
mem_end - data_start)
+
+def UpdateFile(infile, outfile, start_sym, end_sym, insert):
+ tout.Notice("Creating file '%s' with data length %#x (%d) between symbols '%s' and '%s'" %
+ (outfile, len(insert), len(insert), start_sym, end_sym))
+ syms = GetSymbolFileOffset(infile, [start_sym, end_sym])
+ if len(syms) != 2:
+ raise ValueError("Expected two symbols '%s' and '%s': got %d: %s" %
+ (start_sym, end_sym, len(syms),
+ ','.join(syms.keys())))
+
+ size = syms[end_sym].offset - syms[start_sym].offset
+ if len(insert) > size:
+ raise ValueError("Not enough space in '%s' for data length %#x (%d); size is %#x (%d)" %
+ (infile, len(insert), len(insert), size, size))
+
+ data = tools.ReadFile(infile)
+ newdata = data[:syms[start_sym].offset]
+ newdata += insert + tools.GetBytes(0, size - len(insert))
+ newdata += data[syms[end_sym].offset:]
+ tools.WriteFile(outfile, newdata)
+ tout.Info('Written to offset %#x' % syms[start_sym].offset)
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 39a4b94cd0b..6be003786e8 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -309,7 +309,7 @@ class TestFunctional(unittest.TestCase):
entry_args=None, images=None, use_real_dtb=False,
use_expanded=False, verbosity=None, allow_missing=False,
extra_indirs=None, threads=None,
- test_section_timeout=False):
+ test_section_timeout=False, update_fdt_in_elf=None):
"""Run binman with a given test file
Args:
@@ -336,6 +336,7 @@ class TestFunctional(unittest.TestCase):
single-threaded)
test_section_timeout: True to force the first time to timeout, as
used in testThreadTimeout()
+ update_fdt_in_elf: Value to pass with --update-fdt-in-elf=xxx
Returns:
int return code, 0 on success
@@ -368,6 +369,8 @@ class TestFunctional(unittest.TestCase):
args.append('-a%s=%s' % (arg, value))
if allow_missing:
args.append('-M')
+ if update_fdt_in_elf:
+ args += ['--update-fdt-in-elf', update_fdt_in_elf]
if images:
for image in images:
args += ['-i', image]
@@ -4580,6 +4583,84 @@ class TestFunctional(unittest.TestCase):
self.assertIn('read:', stdout.getvalue())
self.assertIn('compress:', stdout.getvalue())
+ def testUpdateFdtInElf(self):
+ """Test that we can update the devicetree in an ELF file"""
+ infile = elf_fname = self.ElfTestFile('u_boot_binman_embed')
+ outfile = os.path.join(self._indir, 'u-boot.out')
+ begin_sym = 'dtb_embed_begin'
+ end_sym = 'dtb_embed_end'
+ retcode = self._DoTestFile(
+ '060_fdt_update.dts', update_dtb=True,
+ update_fdt_in_elf=','.join([infile,outfile,begin_sym,end_sym]))
+ self.assertEqual(0, retcode)
+
+ # Check that the output file does in fact contact a dtb with the binman
+ # definition in the correct place
+ syms = elf.GetSymbolFileOffset(infile,
+ ['dtb_embed_begin', 'dtb_embed_end'])
+ data = tools.ReadFile(outfile)
+ dtb_data = data[syms['dtb_embed_begin'].offset:
+ syms['dtb_embed_end'].offset]
+
+ dtb = fdt.Fdt.FromData(dtb_data)
+ dtb.Scan()
+ props = self._GetPropTree(dtb, BASE_DTB_PROPS + REPACK_DTB_PROPS)
+ self.assertEqual({
+ 'image-pos': 0,
+ 'offset': 0,
+ '_testing:offset': 32,
+ '_testing:size': 2,
+ '_testing:image-pos': 32,
+ 'section@0/u-boot:offset': 0,
+ 'section@0/u-boot:size': len(U_BOOT_DATA),
+ 'section@0/u-boot:image-pos': 0,
+ 'section@0:offset': 0,
+ 'section@0:size': 16,
+ 'section@0:image-pos': 0,
+
+ 'section@1/u-boot:offset': 0,
+ 'section@1/u-boot:size': len(U_BOOT_DATA),
+ 'section@1/u-boot:image-pos': 16,
+ 'section@1:offset': 16,
+ 'section@1:size': 16,
+ 'section@1:image-pos': 16,
+ 'size': 40
+ }, props)
+
+ def testUpdateFdtInElfInvalid(self):
+ """Test that invalid args are detected with --update-fdt-in-elf"""
+ with self.assertRaises(ValueError) as e:
+ self._DoTestFile('060_fdt_update.dts', update_fdt_in_elf='fred')
+ self.assertIn("Invalid args ['fred'] to --update-fdt-in-elf",
+ str(e.exception))
+
+ def testUpdateFdtInElfNoSyms(self):
+ """Test that missing symbols are detected with --update-fdt-in-elf"""
+ infile = elf_fname = self.ElfTestFile('u_boot_binman_embed')
+ outfile = ''
+ begin_sym = 'wrong_begin'
+ end_sym = 'wrong_end'
+ with self.assertRaises(ValueError) as e:
+ self._DoTestFile(
+ '060_fdt_update.dts',
+ update_fdt_in_elf=','.join([infile,outfile,begin_sym,end_sym]))
+ self.assertIn("Expected two symbols 'wrong_begin' and 'wrong_end': got 0:",
+ str(e.exception))
+
+ def testUpdateFdtInElfTooSmall(self):
+ """Test that an over-large dtb is detected with --update-fdt-in-elf"""
+ infile = elf_fname = self.ElfTestFile('u_boot_binman_embed_sm')
+ outfile = os.path.join(self._indir, 'u-boot.out')
+ begin_sym = 'dtb_embed_begin'
+ end_sym = 'dtb_embed_end'
+ with self.assertRaises(ValueError) as e:
+ self._DoTestFile(
+ '060_fdt_update.dts', update_dtb=True,
+ update_fdt_in_elf=','.join([infile,outfile,begin_sym,end_sym]))
+ self.assertRegex(
+ str(e.exception),
+ "Not enough space in '.*u_boot_binman_embed_sm' for data length.*")
+
if __name__ == "__main__":
unittest.main()
diff --git a/tools/binman/test/Makefile b/tools/binman/test/Makefile
index 6e6cc6de491..387ba163353 100644
--- a/tools/binman/test/Makefile
+++ b/tools/binman/test/Makefile
@@ -28,10 +28,12 @@ LDS_UCODE := -T $(SRC)u_boot_ucode_ptr.lds
LDS_BINMAN := -T $(SRC)u_boot_binman_syms.lds
LDS_BINMAN_BAD := -T $(SRC)u_boot_binman_syms_bad.lds
LDS_BINMAN_X86 := -T $(SRC)u_boot_binman_syms_x86.lds
+LDS_BINMAN_EMBED := -T $(SRC)u_boot_binman_embed.lds
TARGETS = u_boot_ucode_ptr u_boot_no_ucode_ptr bss_data \
u_boot_binman_syms u_boot_binman_syms.bin u_boot_binman_syms_bad \
- u_boot_binman_syms_size u_boot_binman_syms_x86 embed_data
+ u_boot_binman_syms_size u_boot_binman_syms_x86 embed_data \
+ u_boot_binman_embed u_boot_binman_embed_sm
all: $(TARGETS)
@@ -62,6 +64,12 @@ u_boot_binman_syms_bad: u_boot_binman_syms_bad.c
u_boot_binman_syms_size: CFLAGS += $(LDS_BINMAN)
u_boot_binman_syms_size: u_boot_binman_syms_size.c
+u_boot_binman_embed: CFLAGS += $(LDS_BINMAN_EMBED)
+u_boot_binman_embed: u_boot_binman_embed.c
+
+u_boot_binman_embed_sm: CFLAGS += $(LDS_BINMAN_EMBED)
+u_boot_binman_embed_sm: u_boot_binman_embed_sm.c
+
clean:
rm -f $(TARGETS)
diff --git a/tools/binman/test/u_boot_binman_embed.c b/tools/binman/test/u_boot_binman_embed.c
new file mode 100644
index 00000000000..75874bb6e23
--- /dev/null
+++ b/tools/binman/test/u_boot_binman_embed.c
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 Google LLC
+ *
+ * Simple program to embed a devicetree. This is used by binman tests.
+ */
+
+int __attribute__((section(".mydtb"))) dtb_data[4096];
+
+int main(void)
+{
+ return 0;
+}
diff --git a/tools/binman/test/u_boot_binman_embed.lds b/tools/binman/test/u_boot_binman_embed.lds
new file mode 100644
index 00000000000..e213fa8a84c
--- /dev/null
+++ b/tools/binman/test/u_boot_binman_embed.lds
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2016 Google, Inc
+ */
+
+OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
+OUTPUT_ARCH(i386)
+ENTRY(_start)
+
+SECTIONS
+{
+ . = 0x00000000;
+ _start = .;
+
+ . = ALIGN(4);
+ .text :
+ {
+ *(.text*)
+ }
+
+ . = ALIGN(4);
+ .data : {
+ dtb_embed_begin = .;
+ KEEP(*(.mydtb));
+ dtb_embed_end = .;
+ }
+ .interp : { *(.interp*) }
+
+}
diff --git a/tools/binman/test/u_boot_binman_embed_sm.c b/tools/binman/test/u_boot_binman_embed_sm.c
new file mode 100644
index 00000000000..ae245d78a6a
--- /dev/null
+++ b/tools/binman/test/u_boot_binman_embed_sm.c
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 Google LLC
+ *
+ * Simple program to embed a devicetree. This is used by binman tests.
+ */
+
+int __attribute__((section(".mydtb"))) dtb_data[16];
+
+int main(void)
+{
+ return 0;
+}
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 24/39] efi: serial: Support arrow keys
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (22 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 23/39] binman: Support updating the dtb in an ELF file Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-10-18 16:55 ` Heinrich Schuchardt
2021-09-25 0:30 ` [PATCH v2 25/39] bloblist: Support allocating the bloblist Simon Glass
` (14 subsequent siblings)
38 siblings, 1 reply; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
At present only the backspace key is supported in U-Boot, when running as
an EFI app. Add support for arrows, home and end as well, to make the CLI
more friendly.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
drivers/serial/serial_efi.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/serial_efi.c b/drivers/serial/serial_efi.c
index 33ddbd6080c..0067576389d 100644
--- a/drivers/serial/serial_efi.c
+++ b/drivers/serial/serial_efi.c
@@ -24,6 +24,9 @@ struct serial_efi_priv {
bool have_key;
};
+/* Convert a lower-case character to its ctrl-char equivalent */
+#define CTL_CH(c) ((c) - 'a' + 1)
+
int serial_efi_setbrg(struct udevice *dev, int baudrate)
{
return 0;
@@ -49,6 +52,7 @@ static int serial_efi_get_key(struct serial_efi_priv *priv)
static int serial_efi_getc(struct udevice *dev)
{
struct serial_efi_priv *priv = dev_get_priv(dev);
+ char conv_scan[10] = {0, 'p', 'n', 'f', 'b', 'a', 'e', 0, 8};
int ret, ch;
ret = serial_efi_get_key(priv);
@@ -63,8 +67,11 @@ static int serial_efi_getc(struct udevice *dev)
* key scan code of 8. Handle this so that backspace works correctly
* in the U-Boot command line.
*/
- if (!ch && priv->key.scan_code == 8)
- ch = 8;
+ if (!ch && priv->key.scan_code < sizeof(conv_scan)) {
+ ch = conv_scan[priv->key.scan_code];
+ if (ch >= 'a')
+ ch -= 'a' - 1;
+ }
debug(" [%x %x %x] ", ch, priv->key.unicode_char, priv->key.scan_code);
return ch;
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [PATCH v2 24/39] efi: serial: Support arrow keys
2021-09-25 0:30 ` [PATCH v2 24/39] efi: serial: Support arrow keys Simon Glass
@ 2021-10-18 16:55 ` Heinrich Schuchardt
2021-10-26 3:29 ` Simon Glass
0 siblings, 1 reply; 74+ messages in thread
From: Heinrich Schuchardt @ 2021-10-18 16:55 UTC (permalink / raw)
To: Simon Glass, U-Boot Mailing List
Cc: Bin Meng, Christian Melki, Tom Rini, Ilias Apalodimas, Alexander Graf
On 9/25/21 2:30 AM, Simon Glass wrote:
> At present only the backspace key is supported in U-Boot, when running as
> an EFI app. Add support for arrows, home and end as well, to make the CLI
> more friendly.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> (no changes since v1)
>
> drivers/serial/serial_efi.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/serial/serial_efi.c b/drivers/serial/serial_efi.c
> index 33ddbd6080c..0067576389d 100644
> --- a/drivers/serial/serial_efi.c
> +++ b/drivers/serial/serial_efi.c
> @@ -24,6 +24,9 @@ struct serial_efi_priv {
> bool have_key;
> };
>
> +/* Convert a lower-case character to its ctrl-char equivalent */
> +#define CTL_CH(c) ((c) - 'a' + 1)
> +
> int serial_efi_setbrg(struct udevice *dev, int baudrate)
> {
> return 0;
> @@ -49,6 +52,7 @@ static int serial_efi_get_key(struct serial_efi_priv *priv)
> static int serial_efi_getc(struct udevice *dev)
> {
> struct serial_efi_priv *priv = dev_get_priv(dev);
> + char conv_scan[10] = {0, 'p', 'n', 'f', 'b', 'a', 'e', 0, 8};
> int ret, ch;
>
> ret = serial_efi_get_key(priv);
> @@ -63,8 +67,11 @@ static int serial_efi_getc(struct udevice *dev)
> * key scan code of 8. Handle this so that backspace works correctly
> * in the U-Boot command line.
> */
> - if (!ch && priv->key.scan_code == 8)
> - ch = 8;
> + if (!ch && priv->key.scan_code < sizeof(conv_scan))
> + ch = conv_scan[priv->key.scan_code];
> + if (ch >= 'a')
> + ch -= 'a' - 1;
All 23 EFI Scan Codes should be supported. Can't we use something like
kbd_to_ansi364[] from drivers/input/input.c to create the appropriate
escape sequences?
Best regards
Heinrich
> + }
> debug(" [%x %x %x] ", ch, priv->key.unicode_char, priv->key.scan_code);
>
> return ch;
>
^ permalink raw reply [flat|nested] 74+ messages in thread* Re: [PATCH v2 24/39] efi: serial: Support arrow keys
2021-10-18 16:55 ` Heinrich Schuchardt
@ 2021-10-26 3:29 ` Simon Glass
0 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-10-26 3:29 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: U-Boot Mailing List, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Alexander Graf
Hi Heinrich,
On Mon, 18 Oct 2021 at 11:00, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 9/25/21 2:30 AM, Simon Glass wrote:
> > At present only the backspace key is supported in U-Boot, when running as
> > an EFI app. Add support for arrows, home and end as well, to make the CLI
> > more friendly.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > (no changes since v1)
> >
> > drivers/serial/serial_efi.c | 11 +++++++++--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/serial/serial_efi.c b/drivers/serial/serial_efi.c
> > index 33ddbd6080c..0067576389d 100644
> > --- a/drivers/serial/serial_efi.c
> > +++ b/drivers/serial/serial_efi.c
> > @@ -24,6 +24,9 @@ struct serial_efi_priv {
> > bool have_key;
> > };
> >
> > +/* Convert a lower-case character to its ctrl-char equivalent */
> > +#define CTL_CH(c) ((c) - 'a' + 1)
> > +
> > int serial_efi_setbrg(struct udevice *dev, int baudrate)
> > {
> > return 0;
> > @@ -49,6 +52,7 @@ static int serial_efi_get_key(struct serial_efi_priv *priv)
> > static int serial_efi_getc(struct udevice *dev)
> > {
> > struct serial_efi_priv *priv = dev_get_priv(dev);
> > + char conv_scan[10] = {0, 'p', 'n', 'f', 'b', 'a', 'e', 0, 8};
> > int ret, ch;
> >
> > ret = serial_efi_get_key(priv);
> > @@ -63,8 +67,11 @@ static int serial_efi_getc(struct udevice *dev)
> > * key scan code of 8. Handle this so that backspace works correctly
> > * in the U-Boot command line.
> > */
> > - if (!ch && priv->key.scan_code == 8)
> > - ch = 8;
> > + if (!ch && priv->key.scan_code < sizeof(conv_scan))
> > + ch = conv_scan[priv->key.scan_code];
> > + if (ch >= 'a')
> > + ch -= 'a' - 1;
>
> All 23 EFI Scan Codes should be supported. Can't we use something like
> kbd_to_ansi364[] from drivers/input/input.c to create the appropriate
> escape sequences?
I think you are referring to this:
Table 107. EFI Scan Codes for EFI_SIMPLE_TEXT_INPUT_PROTOCOL
EFI Scan Code Description
0x00 Null scan code.
0x01 Move cursor up 1 row.
0x02 Move cursor down 1 row.
0x03 Move cursor right 1 column.
0x04 Move cursor left 1 column.
0x05 Home.
0x06 End.
0x07 Insert.
0x08 Delete.
0x09 Page Up.
0x0a Page Down.
0x0b Function 1.
0x0c Function 2.
0x0d Function 3.
0x0e Function 4.
0x0f Function 5.
0x10 Function 6.
0x11 Function 7.
0x12 Function 8.
0x13 Function 9.
0x14 Function 10.
Which ones (other than what I have added) do you think U-Boot
supports? I cannot find any.
Regards,
Simon
^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH v2 25/39] bloblist: Support allocating the bloblist
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (23 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 24/39] efi: serial: Support arrow keys Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 26/39] x86: Allow booting a kernel from the EFI app Simon Glass
` (13 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass
Typically the bloblist is positioned at a fixed address in memory until
relocation. This is convenient when it is set up in SPL or before
relocation.
But for EFI we want to set it up only when U-Boot proper is running. Add
a way to allocate it using malloc() and update the documentation to cover
this aspect of bloblist.
Note there are no tests of this feature at present, nor any direct testing
of bloblist_init().
This can be added, e.g. by making this option controllable at runtime.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
common/Kconfig | 15 +++++++++++++--
common/bloblist.c | 16 ++++++++++++++--
common/board_f.c | 8 +++++++-
doc/develop/bloblist.rst | 16 ++++++++++++++++
4 files changed, 50 insertions(+), 5 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index 0543b839d18..75e50b51b64 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -719,6 +719,8 @@ config TPL_BLOBLIST
This enables a bloblist in TPL. The bloblist is set up in TPL and
passed to SPL and U-Boot proper.
+if BLOBLIST
+
config BLOBLIST_SIZE
hex "Size of bloblist"
depends on BLOBLIST
@@ -729,17 +731,24 @@ config BLOBLIST_SIZE
is set up in the first part of U-Boot to run (TPL, SPL or U-Boot
proper), and this sane bloblist is used for subsequent stages.
+config BLOBLIST_ALLOC
+ bool "Allocate bloblist"
+ help
+ Allocate the bloblist using malloc(). This avoids the need to
+ specify a fixed address on systems where this is unknown or can
+ change at runtime.
+
config BLOBLIST_ADDR
hex "Address of bloblist"
- depends on BLOBLIST
default 0xc000 if SANDBOX
help
Sets the address of the bloblist, set up by the first part of U-Boot
which runs. Subsequent U-Boot stages typically use the same address.
+ This is not used if BLOBLIST_ALLOC is selected.
+
config BLOBLIST_SIZE_RELOC
hex "Size of bloblist after relocation"
- depends on BLOBLIST
default BLOBLIST_SIZE
help
Sets the size of the bloblist in bytes after relocation. Since U-Boot
@@ -747,6 +756,8 @@ config BLOBLIST_SIZE_RELOC
size than the one set up by SPL. This bloblist is set up during the
relocation process.
+endif # BLOBLIST
+
endmenu
source "common/spl/Kconfig"
diff --git a/common/bloblist.c b/common/bloblist.c
index 1290fff8504..01b04103d91 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -7,6 +7,7 @@
#include <common.h>
#include <bloblist.h>
#include <log.h>
+#include <malloc.h>
#include <mapmem.h>
#include <spl.h>
#include <asm/global_data.h>
@@ -416,10 +417,21 @@ int bloblist_init(void)
ret = bloblist_check(CONFIG_BLOBLIST_ADDR,
CONFIG_BLOBLIST_SIZE);
if (ret) {
+ ulong addr;
+
log(LOGC_BLOBLIST, expected ? LOGL_WARNING : LOGL_DEBUG,
"Existing bloblist not found: creating new bloblist\n");
- ret = bloblist_new(CONFIG_BLOBLIST_ADDR, CONFIG_BLOBLIST_SIZE,
- 0);
+ if (IS_ENABLED(CONFIG_BLOBLIST_ALLOC)) {
+ void *ptr = memalign(BLOBLIST_ALIGN,
+ CONFIG_BLOBLIST_SIZE);
+
+ if (!ptr)
+ return log_msg_ret("alloc", -ENOMEM);
+ addr = map_to_sysmem(ptr);
+ } else {
+ addr = CONFIG_BLOBLIST_ADDR;
+ }
+ ret = bloblist_new(addr, CONFIG_BLOBLIST_SIZE, 0);
} else {
log(LOGC_BLOBLIST, LOGL_DEBUG, "Found existing bloblist\n");
}
diff --git a/common/board_f.c b/common/board_f.c
index 3dc0eaa59c5..c8d25b5e1de 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -655,8 +655,14 @@ static int reloc_bootstage(void)
static int reloc_bloblist(void)
{
#ifdef CONFIG_BLOBLIST
- if (gd->flags & GD_FLG_SKIP_RELOC)
+ /*
+ * Relocate only if we are supposed to send it
+ */
+ if ((gd->flags & GD_FLG_SKIP_RELOC) &&
+ CONFIG_BLOBLIST_SIZE == CONFIG_BLOBLIST_SIZE_RELOC) {
+ debug("Not relocating bloblist\n");
return 0;
+ }
if (gd->new_bloblist) {
int size = CONFIG_BLOBLIST_SIZE;
diff --git a/doc/develop/bloblist.rst b/doc/develop/bloblist.rst
index 317ebc4919d..47274cf8e26 100644
--- a/doc/develop/bloblist.rst
+++ b/doc/develop/bloblist.rst
@@ -59,6 +59,22 @@ Bloblist provides a fairly simple API which allows blobs to be created and
found. All access is via the blob's tag. Blob records are zeroed when added.
+Placing the bloblist
+--------------------
+
+The bloblist is typically positioned at a fixed address by TPL, or SPL. This
+is controlled by `CONFIG_BLOBLIST_ADDR`. But in some cases it is preferable to
+allocate the bloblist in the malloc() space. Use the `CONFIG_BLOBLIST_ALLOC`
+option to enable this.
+
+The bloblist is automatically relocated as part of U-Boot relocation. Sometimes
+it is useful to expand the bloblist in U-Boot proper, since it may want to add
+information for use by Linux. Note that this does not mean that Linux needs to
+know anything about the bloblist format, just that it is convenient to use
+bloblist to place things contiguously in memory. Set
+`CONFIG_BLOBLIST_SIZE_RELOC` to define the expanded size, if needed.
+
+
Finishing the bloblist
----------------------
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 26/39] x86: Allow booting a kernel from the EFI app
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (24 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 25/39] bloblist: Support allocating the bloblist Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 27/39] x86: Don't process the kernel command line unless enabled Simon Glass
` (12 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass
At present this is disabled, but it should work so long as the kernel does
not need EFI services. Enable it and add a note about remaining work.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Update documentation
arch/x86/lib/bootm.c | 11 +++++++----
doc/develop/uefi/u-boot_on_efi.rst | 2 +-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/x86/lib/bootm.c b/arch/x86/lib/bootm.c
index 667e5e689e3..57cba5c65d3 100644
--- a/arch/x86/lib/bootm.c
+++ b/arch/x86/lib/bootm.c
@@ -179,10 +179,14 @@ int boot_linux_kernel(ulong setup_base, ulong load_address, bool image_64bit)
* U-Boot is setting them up that way for itself in
* arch/i386/cpu/cpu.c.
*
- * Note that we cannot currently boot a kernel while running as
- * an EFI application. Please use the payload option for that.
+ * Note: this is incomplete for EFI kernels!
+ *
+ * This can boot a kernel while running as an EFI application,
+ * but if the kernel requires EFI support then that support needs
+ * to be enabled first (see EFI_LOADER). Also the EFI information
+ * must enabled with setup_efi_info(). See setup_zimage() for
+ * how this is done with the stub.
*/
-#ifndef CONFIG_EFI_APP
__asm__ __volatile__ (
"movl $0, %%ebp\n"
"cli\n"
@@ -191,7 +195,6 @@ int boot_linux_kernel(ulong setup_base, ulong load_address, bool image_64bit)
[boot_params] "S"(setup_base),
"b"(0), "D"(0)
);
-#endif
}
/* We can't get to here */
diff --git a/doc/develop/uefi/u-boot_on_efi.rst b/doc/develop/uefi/u-boot_on_efi.rst
index f39be4a1ed9..7bd757ca645 100644
--- a/doc/develop/uefi/u-boot_on_efi.rst
+++ b/doc/develop/uefi/u-boot_on_efi.rst
@@ -267,7 +267,7 @@ This work could be extended in a number of ways:
- Avoid turning off boot services in the stub. Instead allow U-Boot to make
use of boot services in case it wants to. It is unclear what it might want
- though.
+ though. It is better to use the app.
Where is the code?
------------------
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 27/39] x86: Don't process the kernel command line unless enabled
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (25 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 26/39] x86: Allow booting a kernel from the EFI app Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 28/39] x86: efi: Add room for the binman definition in the dtb Simon Glass
` (11 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass
If the 'bootm' command is not enabled then this code is not available and
this causes a link error. Fix it.
Note that for the EFI app, there is no indication of missing code. It just
hangs!
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/x86/lib/zimage.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index 7ce02226ef9..9cc04490307 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -365,11 +365,14 @@ int setup_zimage(struct boot_params *setup_base, char *cmd_line, int auto_boot,
strcpy(cmd_line, (char *)cmdline_force);
else
build_command_line(cmd_line, auto_boot);
- ret = bootm_process_cmdline(cmd_line, max_size, BOOTM_CL_ALL);
- if (ret) {
- printf("Cmdline setup failed (max_size=%x, bootproto=%x, err=%d)\n",
- max_size, bootproto, ret);
- return ret;
+ if (IS_ENABLED(CONFIG_CMD_BOOTM)) {
+ ret = bootm_process_cmdline(cmd_line, max_size,
+ BOOTM_CL_ALL);
+ if (ret) {
+ printf("Cmdline setup failed (max_size=%x, bootproto=%x, err=%d)\n",
+ max_size, bootproto, ret);
+ return ret;
+ }
}
printf("Kernel command line: \"");
puts(cmd_line);
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 28/39] x86: efi: Add room for the binman definition in the dtb
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (26 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 27/39] x86: Don't process the kernel command line unless enabled Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 29/39] efi: Add comments to struct efi_priv Simon Glass
` (10 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
At present only 4KB of spare space is left in the DTB when building the
EFI app. Increase this to 32KB so there is plenty of space to insert the
binman definition. This cannot be expanded later (as with OF_SEPARATE)
because the ELF image has already been built.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/x86/dts/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/dts/Makefile b/arch/x86/dts/Makefile
index be209aaaf8f..5c8c05ec499 100644
--- a/arch/x86/dts/Makefile
+++ b/arch/x86/dts/Makefile
@@ -24,7 +24,7 @@ dtb-y += bayleybay.dtb \
targets += $(dtb-y)
-DTC_FLAGS += -R 4 -p 0x1000
+DTC_FLAGS += -R 4 -p $(if $(CONFIG_EFI_APP),0x8000,0x1000)
PHONY += dtbs
dtbs: $(addprefix $(obj)/, $(dtb-y))
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 29/39] efi: Add comments to struct efi_priv
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (27 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 28/39] x86: efi: Add room for the binman definition in the dtb Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-10-23 11:28 ` Heinrich Schuchardt
2021-09-25 0:30 ` [PATCH v2 30/39] efi: Fix ll_boot_init() operation with the app Simon Glass
` (9 subsequent siblings)
38 siblings, 1 reply; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
This structure is uncommented. Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
include/efi.h | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/include/efi.h b/include/efi.h
index 908c5dc6ebd..3c215618dab 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -400,15 +400,39 @@ static inline struct efi_mem_desc *efi_get_next_mem_desc(
return (struct efi_mem_desc *)((ulong)desc + map->desc_size);
}
+/**
+ * struct efi_priv - Information about the environment provided by EFI
+ *
+ * @parent_image: image passed into the EFI app or stub
+ * @sys_table: Pointer to system table
+ * @boot: Pointer to boot-services table
+ * @run: Pointer to runtime-services table
+ *
+ * Used by app only:
+ * @use_pool_for_malloc: true if all allocation should go through the EFI 'pool'
+ * methods allocate_pool() and free_pool(); false to use 'pages' methods
+ * allocate_pages() and free_pages()
+ * @ram_base: Base address of RAM (size CONFIG_EFI_RAM_SIZE)
+ * @image_data_type: Type of the loaded image (e.g. EFI_LOADER_CODE)
+ *
+ * Used by stub only:
+ * @info: Header of the info list, holding info collected by the stub and passed
+ * to U-Boot
+ * @info_size: Size of the info list, in bytes from @info
+ * @next_hdr: Pointer to where to put the next header when adding to the list
+ */
struct efi_priv {
efi_handle_t parent_image;
- struct efi_device_path *device_path;
struct efi_system_table *sys_table;
struct efi_boot_services *boot;
struct efi_runtime_services *run;
+
+ /* app: */
bool use_pool_for_malloc;
unsigned long ram_base;
unsigned int image_data_type;
+
+ /* stub: */
struct efi_info_hdr *info;
unsigned int info_size;
void *next_hdr;
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [PATCH v2 29/39] efi: Add comments to struct efi_priv
2021-09-25 0:30 ` [PATCH v2 29/39] efi: Add comments to struct efi_priv Simon Glass
@ 2021-10-23 11:28 ` Heinrich Schuchardt
0 siblings, 0 replies; 74+ messages in thread
From: Heinrich Schuchardt @ 2021-10-23 11:28 UTC (permalink / raw)
To: Simon Glass
Cc: Bin Meng, Christian Melki, Tom Rini, Ilias Apalodimas,
Alexander Graf, U-Boot Mailing List
On 9/25/21 02:30, Simon Glass wrote:
> This structure is uncommented. Fix it.
The commit message is incomplete. You are deleting field device path.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> (no changes since v1)
>
> include/efi.h | 26 +++++++++++++++++++++++++-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/include/efi.h b/include/efi.h
> index 908c5dc6ebd..3c215618dab 100644
> --- a/include/efi.h
> +++ b/include/efi.h
> @@ -400,15 +400,39 @@ static inline struct efi_mem_desc *efi_get_next_mem_desc(
> return (struct efi_mem_desc *)((ulong)desc + map->desc_size);
> }
>
> +/**
> + * struct efi_priv - Information about the environment provided by EFI
> + *
> + * @parent_image: image passed into the EFI app or stub
> + * @sys_table: Pointer to system table
> + * @boot: Pointer to boot-services table
> + * @run: Pointer to runtime-services table
> + *
> + * Used by app only:
Sphinx will render this line *after* all parameters. Please, remove it.
<cite>
...
info_size
Size of the info list, in bytes from info
next_hdr
Pointer to where to put the next header when adding to the list
Description
-----------
Used by app only: Used by stub only:
struct efi_system_table *efi_get_sys_table(void)
</cite>
> + * @use_pool_for_malloc: true if all allocation should go through the EFI 'pool'
> + * methods allocate_pool() and free_pool(); false to use 'pages' methods
> + * allocate_pages() and free_pages()
> + * @ram_base: Base address of RAM (size CONFIG_EFI_RAM_SIZE)
> + * @image_data_type: Type of the loaded image (e.g. EFI_LOADER_CODE)
> + *
> + * Used by stub only:
Remove this line.
> + * @info: Header of the info list, holding info collected by the stub and passed
> + * to U-Boot
> + * @info_size: Size of the info list, in bytes from @info
> + * @next_hdr: Pointer to where to put the next header when adding to the list
> + */
> struct efi_priv {
> efi_handle_t parent_image;
> - struct efi_device_path *device_path;
This change seems to be unrelated.
Best regards
Heinrich
> struct efi_system_table *sys_table;
> struct efi_boot_services *boot;
> struct efi_runtime_services *run;
> +
> + /* app: */
> bool use_pool_for_malloc;
> unsigned long ram_base;
> unsigned int image_data_type;
> +
> + /* stub: */
> struct efi_info_hdr *info;
> unsigned int info_size;
> void *next_hdr;
>
^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH v2 30/39] efi: Fix ll_boot_init() operation with the app
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (28 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 29/39] efi: Add comments to struct efi_priv Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 32/39] efi: Share struct efi_priv between the app and stub code Simon Glass
` (8 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
This should return false when the EFI app is running, since UEFI has done
the required low-level init. Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
include/init.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/init.h b/include/init.h
index c781789e367..6d682b02b05 100644
--- a/include/init.h
+++ b/include/init.h
@@ -15,7 +15,7 @@
#include <linux/types.h>
/* Avoid using CONFIG_EFI_STUB directly as we may boot from other loaders */
-#ifdef CONFIG_EFI_STUB
+#ifdef CONFIG_EFI
#define ll_boot_init() false
#else
#include <asm/global_data.h>
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 32/39] efi: Share struct efi_priv between the app and stub code
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (29 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 30/39] efi: Fix ll_boot_init() operation with the app Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 33/39] efi: Move exit_boot_services into a function Simon Glass
` (7 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
At present each of these has its own static variable and helper functions.
Move them into a shared file.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
include/efi.h | 21 +++++++++++++++++++++
lib/efi/efi.c | 29 +++++++++++++++++++++++++++++
lib/efi/efi_app.c | 21 ++-------------------
lib/efi/efi_stub.c | 7 ++++---
4 files changed, 56 insertions(+), 22 deletions(-)
diff --git a/include/efi.h b/include/efi.h
index 3c215618dab..6d0eae67479 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -476,6 +476,27 @@ extern char _binary_u_boot_bin_start[], _binary_u_boot_bin_end[];
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS | \
EFI_VARIABLE_APPEND_WRITE)
+/**
+ * efi_get_priv() - Get access to the EFI-private information
+ *
+ * This struct it used by both the stub and the app to record things about the
+ * EFI environment. It is not available in U-Boot proper after the stub has
+ * jumped there. Use efi_info_get() to obtain info in that case.
+ *
+ * @return pointer to private info
+ */
+struct efi_priv *efi_get_priv(void);
+
+/**
+ * efi_set_priv() - Set up a pointer to the EFI-private information
+ *
+ * This is called in the stub and app to record the location of this
+ * information.
+ *
+ * @priv: New location of private data
+ */
+void efi_set_priv(struct efi_priv *priv);
+
/**
* efi_get_sys_table() - Get access to the main EFI system table
*
diff --git a/lib/efi/efi.c b/lib/efi/efi.c
index 69e52e45748..cd6bf47b180 100644
--- a/lib/efi/efi.c
+++ b/lib/efi/efi.c
@@ -1,5 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
+ * Functions shared by the app and stub
+ *
* Copyright (c) 2015 Google, Inc
*
* EFI information obtained here:
@@ -17,6 +19,33 @@
#include <efi.h>
#include <efi_api.h>
+static struct efi_priv *global_priv;
+
+struct efi_priv *efi_get_priv(void)
+{
+ return global_priv;
+}
+
+void efi_set_priv(struct efi_priv *priv)
+{
+ global_priv = priv;
+}
+
+struct efi_system_table *efi_get_sys_table(void)
+{
+ return global_priv->sys_table;
+}
+
+struct efi_boot_services *efi_get_boot(void)
+{
+ return global_priv->boot;
+}
+
+unsigned long efi_get_ram_base(void)
+{
+ return global_priv->ram_base;
+}
+
/*
* Global declaration of gd.
*
diff --git a/lib/efi/efi_app.c b/lib/efi/efi_app.c
index e38d46b15db..a0ae2a531ee 100644
--- a/lib/efi/efi_app.c
+++ b/lib/efi/efi_app.c
@@ -27,23 +27,6 @@
DECLARE_GLOBAL_DATA_PTR;
-static struct efi_priv *global_priv;
-
-struct efi_system_table *efi_get_sys_table(void)
-{
- return global_priv->sys_table;
-}
-
-struct efi_boot_services *efi_get_boot(void)
-{
- return global_priv->boot;
-}
-
-unsigned long efi_get_ram_base(void)
-{
- return global_priv->ram_base;
-}
-
int efi_info_get(enum efi_entry_t type, void **datap, int *sizep)
{
return -ENOSYS;
@@ -344,7 +327,7 @@ efi_status_t EFIAPI efi_main(efi_handle_t image,
/* Set up access to EFI data structures */
efi_init(priv, "App", image, sys_table);
- global_priv = priv;
+ efi_set_priv(priv);
/*
* Set up the EFI debug UART so that printf() works. This is
@@ -370,7 +353,7 @@ efi_status_t EFIAPI efi_main(efi_handle_t image,
static void efi_exit(void)
{
- struct efi_priv *priv = global_priv;
+ struct efi_priv *priv = efi_get_priv();
free_memory(priv);
printf("U-Boot EFI exiting\n");
diff --git a/lib/efi/efi_stub.c b/lib/efi/efi_stub.c
index 156cbf0b928..bc4c3a48720 100644
--- a/lib/efi/efi_stub.c
+++ b/lib/efi/efi_stub.c
@@ -31,7 +31,6 @@
#error "This file needs to be ported for use on architectures"
#endif
-static struct efi_priv *global_priv;
static bool use_uart;
struct __packed desctab_info {
@@ -63,6 +62,8 @@ void _debug_uart_init(void)
void putc(const char ch)
{
+ struct efi_priv *priv = efi_get_priv();
+
if (ch == '\n')
putc('\r');
@@ -73,7 +74,7 @@ void putc(const char ch)
;
outb(ch, (ulong)&com_port->thr);
} else {
- efi_putc(global_priv, ch);
+ efi_putc(priv, ch);
}
}
@@ -313,7 +314,7 @@ efi_status_t EFIAPI efi_main(efi_handle_t image,
puts(" efi_init() failed\n");
return ret;
}
- global_priv = priv;
+ efi_set_priv(priv);
cs32 = get_codeseg32();
if (cs32 < 0)
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 33/39] efi: Move exit_boot_services into a function
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (30 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 32/39] efi: Share struct efi_priv between the app and stub code Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 34/39] efi: Check for failure when initing the app Simon Glass
` (6 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
At present this code is inline in the app and stub. But they do the same
thing. The difference is that the stub does it immediately and the app
doesn't want to do it until the end (when it boots a kernel) or not at
all, if returning to UEFI.
Move it into a function so it can be called as needed.
Also store the memory map so that it can be accessed within the app if
needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Add a sentence about what the patch does
include/efi.h | 32 ++++++++++++++++++++++
lib/efi/efi.c | 68 ++++++++++++++++++++++++++++++++++++++++++++++
lib/efi/efi_app.c | 3 ++
lib/efi/efi_stub.c | 66 ++++++++------------------------------------
4 files changed, 114 insertions(+), 55 deletions(-)
diff --git a/include/efi.h b/include/efi.h
index 6d0eae67479..e04ef942161 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -407,6 +407,12 @@ static inline struct efi_mem_desc *efi_get_next_mem_desc(
* @sys_table: Pointer to system table
* @boot: Pointer to boot-services table
* @run: Pointer to runtime-services table
+ * @memmap_key: Key returned from get_memory_map()
+ * @memmap_desc: List of memory-map records
+ * @memmap_alloc: Amount of memory allocated for memory map list
+ * @memmap_size Size of memory-map list in bytes
+ * @memmap_desc_size: Size of an individual memory-map record, in bytes
+ * @memmap_version: Memory-map version
*
* Used by app only:
* @use_pool_for_malloc: true if all allocation should go through the EFI 'pool'
@@ -426,6 +432,12 @@ struct efi_priv {
struct efi_system_table *sys_table;
struct efi_boot_services *boot;
struct efi_runtime_services *run;
+ efi_uintn_t memmap_key;
+ struct efi_mem_desc *memmap_desc;
+ efi_uintn_t memmap_alloc;
+ efi_uintn_t memmap_size;
+ efi_uintn_t memmap_desc_size;
+ u32 memmap_version;
/* app: */
bool use_pool_for_malloc;
@@ -576,4 +588,24 @@ void efi_putc(struct efi_priv *priv, const char ch);
*/
int efi_info_get(enum efi_entry_t type, void **datap, int *sizep);
+/**
+ * efi_store_memory_map() - Collect the memory-map info from EFI
+ *
+ * Collect the memory info and store it for later use, e.g. in calling
+ * exit_boot_services()
+ *
+ * @priv: Pointer to private EFI structure
+ * @return 0 if OK, non-zero on error
+ */
+int efi_store_memory_map(struct efi_priv *priv);
+
+/**
+ * efi_call_exit_boot_services() - Handlet eh exit-boot-service procedure
+ *
+ * Tell EFI we don't want their boot services anymore
+ *
+ * @return 0 if OK, non-zero on error
+ */
+int efi_call_exit_boot_services(void);
+
#endif /* _LINUX_EFI_H */
diff --git a/lib/efi/efi.c b/lib/efi/efi.c
index cd6bf47b180..20da88c9151 100644
--- a/lib/efi/efi.c
+++ b/lib/efi/efi.c
@@ -135,3 +135,71 @@ void efi_free(struct efi_priv *priv, void *ptr)
boot->free_pool(ptr);
}
+
+int efi_store_memory_map(struct efi_priv *priv)
+{
+ struct efi_boot_services *boot = priv->sys_table->boottime;
+ efi_uintn_t size, desc_size;
+ efi_status_t ret;
+
+ /* Get the memory map so we can switch off EFI */
+ size = 0;
+ ret = boot->get_memory_map(&size, NULL, &priv->memmap_key,
+ &priv->memmap_desc_size,
+ &priv->memmap_version);
+ if (ret != EFI_BUFFER_TOO_SMALL) {
+ printhex2(EFI_BITS_PER_LONG);
+ putc(' ');
+ printhex2(ret);
+ puts(" No memory map\n");
+ return ret;
+ }
+ /*
+ * Since doing a malloc() may change the memory map and also we want to
+ * be able to read the memory map in efi_call_exit_boot_services()
+ * below, after more changes have happened
+ */
+ priv->memmap_alloc = size + 1024;
+ priv->memmap_size = priv->memmap_alloc;
+ priv->memmap_desc = efi_malloc(priv, size, &ret);
+ if (!priv->memmap_desc) {
+ printhex2(ret);
+ puts(" No memory for memory descriptor\n");
+ return ret;
+ }
+
+ ret = boot->get_memory_map(&priv->memmap_size, priv->memmap_desc,
+ &priv->memmap_key, &desc_size,
+ &priv->memmap_version);
+ if (ret) {
+ printhex2(ret);
+ puts(" Can't get memory map\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+int efi_call_exit_boot_services(void)
+{
+ struct efi_priv *priv = efi_get_priv();
+ const struct efi_boot_services *boot = priv->boot;
+ efi_uintn_t size;
+ u32 version;
+ efi_status_t ret;
+
+ size = priv->memmap_alloc;
+ ret = boot->get_memory_map(&size, priv->memmap_desc,
+ &priv->memmap_key,
+ &priv->memmap_desc_size, &version);
+ if (ret) {
+ printhex2(ret);
+ puts(" Can't get memory map\n");
+ return ret;
+ }
+ ret = boot->exit_boot_services(priv->parent_image, priv->memmap_key);
+ if (ret)
+ return ret;
+
+ return 0;
+}
diff --git a/lib/efi/efi_app.c b/lib/efi/efi_app.c
index a0ae2a531ee..23a65c46fd4 100644
--- a/lib/efi/efi_app.c
+++ b/lib/efi/efi_app.c
@@ -341,6 +341,9 @@ efi_status_t EFIAPI efi_main(efi_handle_t image,
printf("Failed to set up memory: ret=%lx\n", ret);
return ret;
}
+ ret = efi_store_memory_map(priv);
+ if (ret)
+ return ret;
printf("starting\n");
diff --git a/lib/efi/efi_stub.c b/lib/efi/efi_stub.c
index bc4c3a48720..5b08c1c40c7 100644
--- a/lib/efi/efi_stub.c
+++ b/lib/efi/efi_stub.c
@@ -297,15 +297,12 @@ efi_status_t EFIAPI efi_main(efi_handle_t image,
{
struct efi_priv local_priv, *priv = &local_priv;
struct efi_boot_services *boot = sys_table->boottime;
- struct efi_mem_desc *desc;
struct efi_entry_memmap map;
struct efi_gop *gop;
struct efi_entry_gopmode mode;
struct efi_entry_systable table;
efi_guid_t efi_gop_guid = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;
- efi_uintn_t key, desc_size, size;
efi_status_t ret;
- u32 version;
int cs32;
ret = efi_init(priv, "Payload", image, sys_table);
@@ -320,24 +317,11 @@ efi_status_t EFIAPI efi_main(efi_handle_t image,
if (cs32 < 0)
return EFI_UNSUPPORTED;
- /* Get the memory map so we can switch off EFI */
- size = 0;
- ret = boot->get_memory_map(&size, NULL, &key, &desc_size, &version);
- if (ret != EFI_BUFFER_TOO_SMALL) {
- printhex2(EFI_BITS_PER_LONG);
- putc(' ');
- printhex2(ret);
- puts(" No memory map\n");
- return ret;
- }
- size += 1024; /* Since doing a malloc() may change the memory map! */
- desc = efi_malloc(priv, size, &ret);
- if (!desc) {
- printhex2(ret);
- puts(" No memory for memory descriptor\n");
+ ret = efi_store_memory_map(priv);
+ if (ret)
return ret;
- }
- ret = setup_info_table(priv, size + 128);
+
+ ret = setup_info_table(priv, priv->memmap_size + 128);
if (ret)
return ret;
@@ -353,48 +337,20 @@ efi_status_t EFIAPI efi_main(efi_handle_t image,
sizeof(struct efi_gop_mode_info));
}
- ret = boot->get_memory_map(&size, desc, &key, &desc_size, &version);
- if (ret) {
- printhex2(ret);
- puts(" Can't get memory map\n");
- return ret;
- }
-
table.sys_table = (ulong)sys_table;
add_entry_addr(priv, EFIET_SYS_TABLE, &table, sizeof(table), NULL, 0);
- ret = boot->exit_boot_services(image, key);
- if (ret) {
- /*
- * Unfortunately it happens that we cannot exit boot services
- * the first time. But the second time it work. I don't know
- * why but this seems to be a repeatable problem. To get
- * around it, just try again.
- */
- printhex2(ret);
- puts(" Can't exit boot services\n");
- size = sizeof(desc);
- ret = boot->get_memory_map(&size, desc, &key, &desc_size,
- &version);
- if (ret) {
- printhex2(ret);
- puts(" Can't get memory map\n");
- return ret;
- }
- ret = boot->exit_boot_services(image, key);
- if (ret) {
- printhex2(ret);
- puts(" Can't exit boot services 2\n");
- return ret;
- }
- }
+ ret = efi_call_exit_boot_services();
+ if (ret)
+ return ret;
/* The EFI UART won't work now, switch to a debug one */
use_uart = true;
- map.version = version;
- map.desc_size = desc_size;
- add_entry_addr(priv, EFIET_MEMORY_MAP, &map, sizeof(map), desc, size);
+ map.version = priv->memmap_version;
+ map.desc_size = priv->memmap_desc_size;
+ add_entry_addr(priv, EFIET_MEMORY_MAP, &map, sizeof(map),
+ priv->memmap_desc, priv->memmap_size);
add_entry_addr(priv, EFIET_END, NULL, 0, 0, 0);
memcpy((void *)CONFIG_SYS_TEXT_BASE, _binary_u_boot_bin_start,
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 34/39] efi: Check for failure when initing the app
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (31 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 33/39] efi: Move exit_boot_services into a function Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 35/39] efi: Mention that efi_info_get() is only used in the stub Simon Glass
` (5 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
The stub checks for failure with efi_init(). Add this for the app as well.
It is unlikely that anything can be done, but we may as well stop.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
lib/efi/efi_app.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/efi/efi_app.c b/lib/efi/efi_app.c
index 23a65c46fd4..e454f1a1564 100644
--- a/lib/efi/efi_app.c
+++ b/lib/efi/efi_app.c
@@ -325,8 +325,11 @@ efi_status_t EFIAPI efi_main(efi_handle_t image,
efi_status_t ret;
/* Set up access to EFI data structures */
- efi_init(priv, "App", image, sys_table);
-
+ ret = efi_init(priv, "App", image, sys_table);
+ if (ret) {
+ printf("Failed to set up ARP: err=%lx\n", ret);
+ return ret;
+ }
efi_set_priv(priv);
/*
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 35/39] efi: Mention that efi_info_get() is only used in the stub
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (32 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 34/39] efi: Check for failure when initing the app Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 36/39] efi: Show when allocated pages are used Simon Glass
` (4 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
This provides access to EFI tables after U-Boot has exited boot services.
It is not needed in the app since boot services remain alive and we can
just call them whenever needed.
Add a comment to explain this.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Fix 'as' typo
include/efi.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/efi.h b/include/efi.h
index e04ef942161..8198394e7e0 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -580,6 +580,10 @@ void efi_putc(struct efi_priv *priv, const char ch);
/**
* efi_info_get() - get an entry from an EFI table
*
+ * This is called from U-Boot proper to read information set up by the EFI stub.
+ * It can only be used when running from the EFI stuff, not when U-Boot is
+ * running as an app.
+ *
* @type: Entry type to search for
* @datap: Returns pointer to entry data
* @sizep: Returns pointer to entry size
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 36/39] efi: Show when allocated pages are used
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (33 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 35/39] efi: Mention that efi_info_get() is only used in the stub Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 37/39] efi: Allow easy selection of serial-only operation Simon Glass
` (3 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
Add a message here so that both paths of memory allocation are reported.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Use log_info() instead of printf()
lib/efi/efi_app.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/efi/efi_app.c b/lib/efi/efi_app.c
index e454f1a1564..36e3f1de427 100644
--- a/lib/efi/efi_app.c
+++ b/lib/efi/efi_app.c
@@ -121,13 +121,14 @@ static efi_status_t setup_memory(struct efi_priv *priv)
ret = boot->allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
priv->image_data_type, pages, &addr);
if (ret) {
- printf("(using pool %lx) ", ret);
+ log_info("(using pool %lx) ", ret);
priv->ram_base = (ulong)efi_malloc(priv, CONFIG_EFI_RAM_SIZE,
&ret);
if (!priv->ram_base)
return ret;
priv->use_pool_for_malloc = true;
} else {
+ log_info("(using allocated RAM address %lx) ", (ulong)addr);
priv->ram_base = addr;
}
gd->ram_size = pages << 12;
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 37/39] efi: Allow easy selection of serial-only operation
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (34 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 36/39] efi: Show when allocated pages are used Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 38/39] efi: Update efi_get_next_mem_desc() to avoid needing a map Simon Glass
` (2 subsequent siblings)
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
Add info about how to select vidconsole or serial.
Also set up a demo boot command.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Add a better boot command too
include/configs/efi-x86_app.h | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/include/configs/efi-x86_app.h b/include/configs/efi-x86_app.h
index 6061a6db0a4..33afb7ca0f9 100644
--- a/include/configs/efi-x86_app.h
+++ b/include/configs/efi-x86_app.h
@@ -10,8 +10,33 @@
#undef CONFIG_TPM_TIS_BASE_ADDRESS
+/*
+ * Select the output device: Put an 'x' prefix before one of these to disable it
+ */
+
+/*
+ * Video output - can normally continue after exit_boot_services has been
+ * called, since output to the display does not require EFI services at that
+ * point. U-Boot sets up the console memory and does its own drawing.
+ */
#define CONFIG_STD_DEVICES_SETTINGS "stdin=serial\0" \
"stdout=vidconsole\0" \
"stderr=vidconsole\0"
+/*
+ * Serial output with no console. Run qemu with:
+ *
+ * -display none -serial mon:stdio
+ *
+ * This will hang or fail to output on the console after exit_boot_services is
+ * called.
+ */
+#define xCONFIG_STD_DEVICES_SETTINGS "stdin=serial\0" \
+ "stdout=serial\0" \
+ "stderr=serial\0"
+
+#undef CONFIG_BOOTCOMMAND
+
+#define CONFIG_BOOTCOMMAND "part list efi 0; fatls efi 0:1"
+
#endif
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 38/39] efi: Update efi_get_next_mem_desc() to avoid needing a map
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (35 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 37/39] efi: Allow easy selection of serial-only operation Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-09-25 0:30 ` [PATCH v2 39/39] efi: Support the efi command in the app Simon Glass
2021-10-18 15:25 ` [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
At present this function requires a pointer to struct efi_entry_memmap
but the only field used in there is the desc_size. We want to be able
to use it from the app, so update it to use desc_size directly.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/x86/cpu/efi/payload.c | 8 ++++----
cmd/efi.c | 34 ++++++++++++++++++----------------
include/efi.h | 4 ++--
3 files changed, 24 insertions(+), 22 deletions(-)
diff --git a/arch/x86/cpu/efi/payload.c b/arch/x86/cpu/efi/payload.c
index 3a9f7d72868..d2aa889a2b9 100644
--- a/arch/x86/cpu/efi/payload.c
+++ b/arch/x86/cpu/efi/payload.c
@@ -50,7 +50,7 @@ ulong board_get_usable_ram_top(ulong total_size)
end = (struct efi_mem_desc *)((ulong)map + size);
desc = map->desc;
- for (; desc < end; desc = efi_get_next_mem_desc(map, desc)) {
+ for (; desc < end; desc = efi_get_next_mem_desc(desc, map->desc_size)) {
if (desc->type != EFI_CONVENTIONAL_MEMORY ||
desc->physical_start >= 1ULL << 32)
continue;
@@ -88,7 +88,7 @@ int dram_init(void)
end = (struct efi_mem_desc *)((ulong)map + size);
gd->ram_size = 0;
desc = map->desc;
- for (; desc < end; desc = efi_get_next_mem_desc(map, desc)) {
+ for (; desc < end; desc = efi_get_next_mem_desc(desc, map->desc_size)) {
if (desc->type < EFI_MMAP_IO)
gd->ram_size += desc->num_pages << EFI_PAGE_SHIFT;
}
@@ -113,7 +113,7 @@ int dram_init_banksize(void)
desc = map->desc;
for (num_banks = 0;
desc < end && num_banks < CONFIG_NR_DRAM_BANKS;
- desc = efi_get_next_mem_desc(map, desc)) {
+ desc = efi_get_next_mem_desc(desc, map->desc_size)) {
/*
* We only use conventional memory and ignore
* anything less than 1MB.
@@ -196,7 +196,7 @@ unsigned int install_e820_map(unsigned int max_entries,
end = (struct efi_mem_desc *)((ulong)map + size);
for (desc = map->desc; desc < end;
- desc = efi_get_next_mem_desc(map, desc)) {
+ desc = efi_get_next_mem_desc(desc, map->desc_size)) {
if (desc->num_pages == 0)
continue;
diff --git a/cmd/efi.c b/cmd/efi.c
index f2ed26bd4b2..d2400acbbba 100644
--- a/cmd/efi.c
+++ b/cmd/efi.c
@@ -75,16 +75,17 @@ static int h_cmp_entry(const void *v1, const void *v2)
/**
* efi_build_mem_table() - make a sorted copy of the memory table
*
- * @map: Pointer to EFI memory map table
+ * @desc_base: Pointer to EFI memory map table
* @size: Size of table in bytes
+ * @desc_size: Size of each @desc_base record
* @skip_bs: True to skip boot-time memory and merge it with conventional
* memory. This will significantly reduce the number of table
* entries.
* Return: pointer to the new table. It should be freed with free() by the
* caller.
*/
-static void *efi_build_mem_table(struct efi_entry_memmap *map, int size,
- bool skip_bs)
+static void *efi_build_mem_table(struct efi_mem_desc *desc_base, int size,
+ int desc_size, bool skip_bs)
{
struct efi_mem_desc *desc, *end, *base, *dest, *prev;
int count;
@@ -95,15 +96,16 @@ static void *efi_build_mem_table(struct efi_entry_memmap *map, int size,
debug("%s: Cannot allocate %#x bytes\n", __func__, size);
return NULL;
}
- end = (struct efi_mem_desc *)((ulong)map + size);
- count = ((ulong)end - (ulong)map->desc) / map->desc_size;
- memcpy(base, map->desc, (ulong)end - (ulong)map->desc);
- qsort(base, count, map->desc_size, h_cmp_entry);
+ end = (void *)desc_base + size;
+ count = ((ulong)end - (ulong)desc_base) / desc_size;
+ memcpy(base, desc_base, (ulong)end - (ulong)desc_base);
+ qsort(base, count, desc_size, h_cmp_entry);
prev = NULL;
addr = 0;
dest = base;
- end = (struct efi_mem_desc *)((ulong)base + count * map->desc_size);
- for (desc = base; desc < end; desc = efi_get_next_mem_desc(map, desc)) {
+ end = (struct efi_mem_desc *)((ulong)base + count * desc_size);
+ for (desc = base; desc < end;
+ desc = efi_get_next_mem_desc(desc, desc_size)) {
bool merge = true;
u32 type = desc->type;
@@ -116,7 +118,7 @@ static void *efi_build_mem_table(struct efi_entry_memmap *map, int size,
if (skip_bs && is_boot_services(desc->type))
type = EFI_CONVENTIONAL_MEMORY;
- memcpy(dest, desc, map->desc_size);
+ memcpy(dest, desc, desc_size);
dest->type = type;
if (!skip_bs || !prev)
merge = false;
@@ -131,7 +133,7 @@ static void *efi_build_mem_table(struct efi_entry_memmap *map, int size,
prev->num_pages += desc->num_pages;
} else {
prev = dest;
- dest = efi_get_next_mem_desc(map, dest);
+ dest = efi_get_next_mem_desc(dest, desc_size);
}
addr = desc->physical_start + (desc->num_pages <<
EFI_PAGE_SHIFT);
@@ -143,8 +145,8 @@ static void *efi_build_mem_table(struct efi_entry_memmap *map, int size,
return base;
}
-static void efi_print_mem_table(struct efi_entry_memmap *map,
- struct efi_mem_desc *desc, bool skip_bs)
+static void efi_print_mem_table(struct efi_mem_desc *desc, int desc_size,
+ bool skip_bs)
{
u64 attr_seen[ATTR_SEEN_MAX];
int attr_seen_count;
@@ -158,7 +160,7 @@ static void efi_print_mem_table(struct efi_entry_memmap *map,
attr_seen_count = 0;
addr = 0;
for (upto = 0; desc->type != EFI_MAX_MEMORY_TYPE;
- upto++, desc = efi_get_next_mem_desc(map, desc)) {
+ upto++, desc = efi_get_next_mem_desc(desc, desc_size)) {
const char *name;
u64 size;
@@ -238,13 +240,13 @@ static int do_efi_mem(struct cmd_tbl *cmdtp, int flag, int argc,
goto done;
}
- desc = efi_build_mem_table(map, size, skip_bs);
+ desc = efi_build_mem_table(map->desc, size, map->desc_size, skip_bs);
if (!desc) {
ret = -ENOMEM;
goto done;
}
- efi_print_mem_table(map, desc, skip_bs);
+ efi_print_mem_table(desc, map->desc_size, skip_bs);
free(desc);
done:
if (ret)
diff --git a/include/efi.h b/include/efi.h
index 8198394e7e0..8d9399631eb 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -395,9 +395,9 @@ struct efi_entry_systable {
};
static inline struct efi_mem_desc *efi_get_next_mem_desc(
- struct efi_entry_memmap *map, struct efi_mem_desc *desc)
+ struct efi_mem_desc *desc, int desc_size)
{
- return (struct efi_mem_desc *)((ulong)desc + map->desc_size);
+ return (struct efi_mem_desc *)((ulong)desc + desc_size);
}
/**
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* [PATCH v2 39/39] efi: Support the efi command in the app
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (36 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 38/39] efi: Update efi_get_next_mem_desc() to avoid needing a map Simon Glass
@ 2021-09-25 0:30 ` Simon Glass
2021-10-18 15:25 ` [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-09-25 0:30 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Simon Glass, Alexander Graf
At present the 'efi' command only works in the EFI payload. Update it to
work in the app too, so the memory map can be examined.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Add new patch to support the efi command in the app
cmd/Makefile | 2 +-
cmd/efi.c | 46 +++++++++++++++++++++++++++++++---------------
include/efi.h | 15 +++++++++++++++
lib/efi/efi_app.c | 33 +++++++++++++++++++++++++++++++++
4 files changed, 80 insertions(+), 16 deletions(-)
diff --git a/cmd/Makefile b/cmd/Makefile
index ed3669411e6..3e9f23ebf30 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -58,7 +58,7 @@ obj-$(CONFIG_CMD_EXTENSION) += extension_board.o
obj-$(CONFIG_CMD_ECHO) += echo.o
obj-$(CONFIG_ENV_IS_IN_EEPROM) += eeprom.o
obj-$(CONFIG_CMD_EEPROM) += eeprom.o
-obj-$(CONFIG_EFI_STUB) += efi.o
+obj-$(CONFIG_EFI) += efi.o
obj-$(CONFIG_CMD_EFIDEBUG) += efidebug.o
obj-$(CONFIG_CMD_ELF) += elf.o
obj-$(CONFIG_HUSH_PARSER) += exit.o
diff --git a/cmd/efi.c b/cmd/efi.c
index d2400acbbba..04225ee45b5 100644
--- a/cmd/efi.c
+++ b/cmd/efi.c
@@ -217,37 +217,53 @@ static void efi_print_mem_table(struct efi_mem_desc *desc, int desc_size,
static int do_efi_mem(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
- struct efi_mem_desc *desc;
- struct efi_entry_memmap *map;
+ struct efi_mem_desc *orig, *desc;
+ uint version, key;
+ int desc_size;
int size, ret;
bool skip_bs;
skip_bs = !argc || *argv[0] != 'a';
- ret = efi_info_get(EFIET_MEMORY_MAP, (void **)&map, &size);
- switch (ret) {
- case -ENOENT:
- printf("No EFI table available\n");
- goto done;
- case -EPROTONOSUPPORT:
- printf("Incorrect EFI table version\n");
- goto done;
+ if (IS_ENABLED(CONFIG_EFI_APP)) {
+ ret = efi_get_mmap(&orig, &size, &key, &desc_size, &version);
+ if (ret) {
+ printf("Cannot read memory map (err=%d)\n", ret);
+ return CMD_RET_FAILURE;
+ }
+ } else {
+ struct efi_entry_memmap *map;
+
+ ret = efi_info_get(EFIET_MEMORY_MAP, (void **)&map, &size);
+ switch (ret) {
+ case -ENOENT:
+ printf("No EFI table available\n");
+ goto done;
+ case -EPROTONOSUPPORT:
+ printf("Incorrect EFI table version\n");
+ goto done;
+ }
+ orig = map->desc;
+ desc_size = map->desc_size;
+ version = map->version;
}
- printf("EFI table at %lx, memory map %p, size %x, version %x, descr. size %#x\n",
- gd->arch.table, map, size, map->version, map->desc_size);
- if (map->version != EFI_MEM_DESC_VERSION) {
+ printf("EFI table at %lx, memory map %p, size %x, key %x, version %x, descr. size %#x\n",
+ gd->arch.table, orig, size, key, version, desc_size);
+ if (version != EFI_MEM_DESC_VERSION) {
printf("Incorrect memory map version\n");
ret = -EPROTONOSUPPORT;
goto done;
}
- desc = efi_build_mem_table(map->desc, size, map->desc_size, skip_bs);
+ desc = efi_build_mem_table(orig, size, desc_size, skip_bs);
if (!desc) {
ret = -ENOMEM;
goto done;
}
- efi_print_mem_table(desc, map->desc_size, skip_bs);
+ efi_print_mem_table(desc, desc_size, skip_bs);
free(desc);
+ if (IS_ENABLED(CONFIG_EFI_APP))
+ free(orig);
done:
if (ret)
printf("Error: %d\n", ret);
diff --git a/include/efi.h b/include/efi.h
index 8d9399631eb..e628746476a 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -612,4 +612,19 @@ int efi_store_memory_map(struct efi_priv *priv);
*/
int efi_call_exit_boot_services(void);
+/**
+ * efi_get_mmap() - Get the memory map from EFI
+ *
+ * This is used in the app. The caller must free *@descp when done
+ *
+ * @descp: Returns allocated pointer to EFI memory map table
+ * @sizep: Returns size of table in bytes
+ * @keyp: Returns memory-map key
+ * @desc_sizep: Returns size of each @desc_base record
+ * @versionp: Returns version number of memory map
+ * @return 0 on success, -ve on error
+ */
+int efi_get_mmap(struct efi_mem_desc **descp, int *sizep, uint *keyp,
+ int *desc_sizep, uint *versionp);
+
#endif /* _LINUX_EFI_H */
diff --git a/lib/efi/efi_app.c b/lib/efi/efi_app.c
index 36e3f1de427..55fa1ac57d5 100644
--- a/lib/efi/efi_app.c
+++ b/lib/efi/efi_app.c
@@ -32,6 +32,39 @@ int efi_info_get(enum efi_entry_t type, void **datap, int *sizep)
return -ENOSYS;
}
+int efi_get_mmap(struct efi_mem_desc **descp, int *sizep, uint *keyp,
+ int *desc_sizep, uint *versionp)
+{
+ struct efi_priv *priv = efi_get_priv();
+ struct efi_boot_services *boot = priv->sys_table->boottime;
+ efi_uintn_t size, desc_size, key;
+ struct efi_mem_desc *desc;
+ efi_status_t ret;
+ u32 version;
+
+ /* Get the memory map so we can switch off EFI */
+ size = 0;
+ ret = boot->get_memory_map(&size, NULL, &key, &desc_size, &version);
+ if (ret != EFI_BUFFER_TOO_SMALL)
+ return log_msg_ret("get", -ENOMEM);
+
+ desc = malloc(size);
+ if (!desc)
+ return log_msg_ret("mem", -ENOMEM);
+
+ ret = boot->get_memory_map(&size, desc, &key, &desc_size, &version);
+ if (ret)
+ return log_msg_ret("get", -EINVAL);
+
+ *descp = desc;
+ *sizep = size;
+ *desc_sizep = desc_size;
+ *versionp = version;
+ *keyp = key;
+
+ return 0;
+}
+
/**
* efi_print_str() - Print a UFT-16 string to the U-Boot console
*
--
2.33.0.685.g46640cef36-goog
^ permalink raw reply related [flat|nested] 74+ messages in thread* Re: [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI
2021-09-25 0:30 [PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI Simon Glass
` (37 preceding siblings ...)
2021-09-25 0:30 ` [PATCH v2 39/39] efi: Support the efi command in the app Simon Glass
@ 2021-10-18 15:25 ` Simon Glass
38 siblings, 0 replies; 74+ messages in thread
From: Simon Glass @ 2021-10-18 15:25 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Heinrich Schuchardt, Bin Meng, Christian Melki, Tom Rini,
Ilias Apalodimas, Alexander Graf
Hi Heinrich,
On Fri, 24 Sept 2021 at 18:31, Simon Glass <sjg@chromium.org> wrote:
>
> At present U-Boot can be built as an EFI app, but it is really just for
> testing, with very few features. Instead, the payload build is used for
> booting on top of UEFI, where U-Boot takes over the machine immediately
> and supplies its own drivers.
>
> But the app could be made more useful.
>
> This series provides access to EFI block devices and the video console
> within U-Boot. It also restructures the app to make it possible to boot
> a kernel, although further work is needed to implement this.
>
> This can be thought of as making U-Boot perform a little like 'grub', in
> that it runs purely based on UEFI-provided services.
>
> Of course a lot more work is required, but this is a start.
>
> Note: It would be very useful to include qemu tests of the app and stub
> in CI.
>
> This is available at u-boot-dm/efi-working
>
> Changes in v2:
> - Add MAINTAINERS entry
> - Add a better boot command too
> - Add a note that EFI_GRAPHICS_OUTPUT_PROTOCOL is used
> - Add a sentence about what the patch does
> - Add a work-around to avoid a toolchain crash
> - Add new patch to drop the OF_EMBED warning for EFI
> - Add new patch to enable DM_ETH for the app
> - Add new patch to support the efi command in the app
> - Add new patch with maintainer entry
> - Add support for creating a partition table with a filesystem inside
> - Add support for running qemu with just a serial console (no display)
> - Drop mention of partitions from the commit message
> - Expand the commit message to make things clearer
> - Fix 'as' typo
> - Mention why this patch is included in this series
> - Put this patch first so that it is separated from the rest of the series
> - Show the correct interface type with 'part list'
> - Update commit message to mention that these function are x86-specific
> - Update commit message to mention why the data structure is like it is
> - Update commit message to mention why ulong is used
> - Update documentation
> - Update the commit message to explain things better
> - Use log_info() instead of printf()
>
> Simon Glass (39):
> RFC: efi: Drop code that doesn't work with driver model
> efi: Add a separate maintainer entry for the app
> x86: Keep symbol information in u-boot ELF file
> x86: Create a new header for EFI
> x86: Show some EFI info with the bdinfo command
> x86: Tidy up global_data pointer for 64-bit
> efi: Add a script for building and testing U-Boot on UEFI
> efi: Enable DM_ETH for the app
> efi: Drop the OF_EMBED warning for EFI
> x86: Create a 32/64-bit selection for the app
> efi: Create a 64-bit app
> x86: Don't duplicate global_ptr in 64-bit EFI app
> efi: Add a way to obtain boot services in the app
> efi: Add video support to the app
> efi: Add EFI uclass for media
> efi: Add a media/block driver for EFI block devices
> efi: Locate all block devices in the app
> patman: Use a ValueError exception if tools.Run() fails
> binman: Report an error if test files fail to compile
> binman: Support reading the offset of an ELF-file symbol
> binman: Allow timeout to occur in the image or its section
> binman: Tidy up comments on _DoTestFile()
> binman: Support updating the dtb in an ELF file
> efi: serial: Support arrow keys
> bloblist: Support allocating the bloblist
> x86: Allow booting a kernel from the EFI app
> x86: Don't process the kernel command line unless enabled
> x86: efi: Add room for the binman definition in the dtb
> efi: Add comments to struct efi_priv
> efi: Fix ll_boot_init() operation with the app
> efi: Add a few comments to the stub
> efi: Share struct efi_priv between the app and stub code
> efi: Move exit_boot_services into a function
> efi: Check for failure when initing the app
> efi: Mention that efi_info_get() is only used in the stub
> efi: Show when allocated pages are used
> efi: Allow easy selection of serial-only operation
> efi: Update efi_get_next_mem_desc() to avoid needing a map
> efi: Support the efi command in the app
>
> MAINTAINERS | 14 +
> Makefile | 10 +-
> arch/sandbox/dts/test.dts | 4 +
> arch/x86/config.mk | 4 +-
> arch/x86/cpu/efi/payload.c | 21 +-
> arch/x86/cpu/intel_common/Makefile | 2 +-
> arch/x86/cpu/u-boot-64.lds | 2 +
> arch/x86/cpu/x86_64/Makefile | 4 +
> arch/x86/cpu/x86_64/cpu.c | 32 +-
> arch/x86/cpu/x86_64/misc.c | 41 +++
> arch/x86/dts/Makefile | 2 +-
> arch/x86/dts/efi-x86_app.dts | 4 +
> arch/x86/include/asm/efi.h | 39 +++
> arch/x86/include/asm/global_data.h | 2 +
> arch/x86/include/asm/zimage.h | 3 -
> arch/x86/lib/Makefile | 1 +
> arch/x86/lib/bdinfo.c | 22 ++
> arch/x86/lib/bootm.c | 11 +-
> arch/x86/lib/zimage.c | 14 +-
> board/efi/Kconfig | 15 +-
> board/efi/efi-x86_app/Kconfig | 6 +-
> board/efi/efi-x86_app/MAINTAINERS | 11 +-
> cmd/Makefile | 2 +-
> cmd/efi.c | 76 +++--
> common/Kconfig | 15 +-
> common/bloblist.c | 16 +-
> common/board_f.c | 8 +-
> ..._app_defconfig => efi-x86_app32_defconfig} | 3 +-
> configs/efi-x86_app64_defconfig | 39 +++
> disk/part.c | 5 +-
> doc/develop/bloblist.rst | 16 +
> doc/develop/uefi/u-boot_on_efi.rst | 74 ++++-
> drivers/block/Kconfig | 33 +++
> drivers/block/Makefile | 4 +
> drivers/block/blk-uclass.c | 2 +-
> drivers/block/efi-media-uclass.c | 15 +
> drivers/block/efi_blk.c | 115 ++++++++
> drivers/block/sb_efi_media.c | 20 ++
> drivers/serial/serial_efi.c | 11 +-
> drivers/video/Kconfig | 2 +-
> drivers/video/efi.c | 45 ++-
> include/configs/efi-x86_app.h | 31 +-
> include/dm/uclass-id.h | 1 +
> include/efi.h | 123 +++++++-
> include/efi_api.h | 15 +
> include/init.h | 2 +-
> lib/efi/Kconfig | 34 ++-
> lib/efi/efi.c | 106 +++++++
> lib/efi/efi_app.c | 276 +++++++++++++++++-
> lib/efi/efi_stub.c | 95 +++---
> lib/efi_driver/Makefile | 2 +-
> lib/efi_loader/Kconfig | 1 +
> lib/efi_loader/efi_device_path.c | 96 ++----
> lib/efi_loader/efi_disk.c | 48 ---
> scripts/build-efi.sh | 188 ++++++++++++
> test/dm/Makefile | 1 +
> test/dm/efi_media.c | 24 ++
> tools/binman/binman.rst | 36 +++
> tools/binman/cmdline.py | 2 +
> tools/binman/control.py | 11 +
> tools/binman/elf.py | 74 ++++-
> tools/binman/elf_test.py | 45 ++-
> tools/binman/ftest.py | 91 +++++-
> tools/binman/test/Makefile | 13 +-
> tools/binman/test/bss_data.c | 2 +-
> tools/binman/test/embed_data.c | 16 +
> tools/binman/test/embed_data.lds | 23 ++
> tools/binman/test/u_boot_binman_embed.c | 13 +
> tools/binman/test/u_boot_binman_embed.lds | 29 ++
> tools/binman/test/u_boot_binman_embed_sm.c | 13 +
> tools/patman/tools.py | 2 +-
> 71 files changed, 1841 insertions(+), 337 deletions(-)
> create mode 100644 arch/x86/cpu/x86_64/misc.c
> create mode 100644 arch/x86/include/asm/efi.h
> create mode 100644 arch/x86/lib/bdinfo.c
> rename configs/{efi-x86_app_defconfig => efi-x86_app32_defconfig} (94%)
> create mode 100644 configs/efi-x86_app64_defconfig
> create mode 100644 drivers/block/efi-media-uclass.c
> create mode 100644 drivers/block/efi_blk.c
> create mode 100644 drivers/block/sb_efi_media.c
> create mode 100755 scripts/build-efi.sh
> create mode 100644 test/dm/efi_media.c
> create mode 100644 tools/binman/test/embed_data.c
> create mode 100644 tools/binman/test/embed_data.lds
> create mode 100644 tools/binman/test/u_boot_binman_embed.c
> create mode 100644 tools/binman/test/u_boot_binman_embed.lds
> create mode 100644 tools/binman/test/u_boot_binman_embed_sm.c
>
> --
> 2.33.0.685.g46640cef36-goog
>
These patches seem to be in your queue. Can you please give me an update?
Thanks,
Simon
^ permalink raw reply [flat|nested] 74+ messages in thread