* [PATCH v2 1/7] loader: drop argv[] argument in grub_initrd_load()
2021-06-02 21:12 [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader Nikita Ermakov
@ 2021-06-02 21:12 ` Nikita Ermakov
2021-06-02 21:12 ` [PATCH v2 2/7] efi: add definition of LoadFile2 protocol Nikita Ermakov
` (8 subsequent siblings)
9 siblings, 0 replies; 36+ messages in thread
From: Nikita Ermakov @ 2021-06-02 21:12 UTC (permalink / raw)
To: GRUB development mailing list
Cc: Ard Biesheuvel, Atish Patra, Daniel Kiper, Heinrich Schuchardt,
Leif Lindholm, Nikita Ermakov
In the case of an error grub_initrd_load() uses argv[] to print the
filename that caused the error. It is also possible to obtain the
filename from the file handles and there is no need to duplicate that
information in argv[], so let's drop it.
Signed-off-by: Nikita Ermakov <arei@altlinux.org>
---
grub-core/loader/arm/linux.c | 2 +-
grub-core/loader/arm64/linux.c | 2 +-
grub-core/loader/i386/linux.c | 2 +-
grub-core/loader/i386/pc/linux.c | 2 +-
grub-core/loader/i386/xen.c | 3 +--
grub-core/loader/ia64/efi/linux.c | 2 +-
grub-core/loader/linux.c | 4 ++--
grub-core/loader/mips/linux.c | 2 +-
grub-core/loader/powerpc/ieee1275/linux.c | 2 +-
grub-core/loader/sparc64/ieee1275/linux.c | 2 +-
include/grub/linux.h | 2 +-
11 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/grub-core/loader/arm/linux.c b/grub-core/loader/arm/linux.c
index ed23dc71e..1f7ab7578 100644
--- a/grub-core/loader/arm/linux.c
+++ b/grub-core/loader/arm/linux.c
@@ -422,7 +422,7 @@ grub_cmd_initrd (grub_command_t cmd __attribute__ ((unused)),
grub_dprintf ("loader", "Loading initrd to 0x%08x\n",
(grub_addr_t) initrd_start);
- if (grub_initrd_load (&initrd_ctx, argv, (void *) initrd_start))
+ if (grub_initrd_load (&initrd_ctx, (void *) initrd_start))
goto fail;
initrd_end = initrd_start + size;
diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c
index ef3e9f944..aed7a200b 100644
--- a/grub-core/loader/arm64/linux.c
+++ b/grub-core/loader/arm64/linux.c
@@ -266,7 +266,7 @@ grub_cmd_initrd (grub_command_t cmd __attribute__ ((unused)),
goto fail;
}
- if (grub_initrd_load (&initrd_ctx, argv, initrd_mem))
+ if (grub_initrd_load (&initrd_ctx, initrd_mem))
goto fail;
initrd_start = (grub_addr_t) initrd_mem;
diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
index 9f74a96b1..f30a1586a 100644
--- a/grub-core/loader/i386/linux.c
+++ b/grub-core/loader/i386/linux.c
@@ -1107,7 +1107,7 @@ grub_cmd_initrd (grub_command_t cmd __attribute__ ((unused)),
initrd_mem_target = get_physical_target_address (ch);
}
- if (grub_initrd_load (&initrd_ctx, argv, initrd_mem))
+ if (grub_initrd_load (&initrd_ctx, initrd_mem))
goto fail;
grub_dprintf ("linux", "Initrd, addr=0x%x, size=0x%x\n",
diff --git a/grub-core/loader/i386/pc/linux.c b/grub-core/loader/i386/pc/linux.c
index 2a2995201..efeeeb206 100644
--- a/grub-core/loader/i386/pc/linux.c
+++ b/grub-core/loader/i386/pc/linux.c
@@ -462,7 +462,7 @@ grub_cmd_initrd (grub_command_t cmd __attribute__ ((unused)),
initrd_addr = get_physical_target_address (ch);
}
- if (grub_initrd_load (&initrd_ctx, argv, initrd_chunk))
+ if (grub_initrd_load (&initrd_ctx, initrd_chunk))
goto fail;
lh->ramdisk_image = initrd_addr;
diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader/i386/xen.c
index cd24874ca..3b856e842 100644
--- a/grub-core/loader/i386/xen.c
+++ b/grub-core/loader/i386/xen.c
@@ -809,8 +809,7 @@ grub_cmd_initrd (grub_command_t cmd __attribute__ ((unused)),
if (err)
goto fail;
- if (grub_initrd_load (&initrd_ctx, argv,
- get_virtual_current_address (ch)))
+ if (grub_initrd_load (&initrd_ctx, get_virtual_current_address (ch)))
goto fail;
}
diff --git a/grub-core/loader/ia64/efi/linux.c b/grub-core/loader/ia64/efi/linux.c
index 7987fd1ba..8873b7a55 100644
--- a/grub-core/loader/ia64/efi/linux.c
+++ b/grub-core/loader/ia64/efi/linux.c
@@ -563,7 +563,7 @@ grub_cmd_initrd (grub_command_t cmd __attribute__ ((unused)),
grub_dprintf ("linux", "[addr=0x%lx, size=0x%lx]\n",
(grub_uint64_t) initrd_mem, initrd_size);
- if (grub_initrd_load (&initrd_ctx, argv, initrd_mem))
+ if (grub_initrd_load (&initrd_ctx, initrd_mem))
goto fail;
fail:
grub_initrd_close (&initrd_ctx);
diff --git a/grub-core/loader/linux.c b/grub-core/loader/linux.c
index 3fe390f17..d19df670e 100644
--- a/grub-core/loader/linux.c
+++ b/grub-core/loader/linux.c
@@ -271,7 +271,7 @@ grub_initrd_close (struct grub_linux_initrd_context *initrd_ctx)
grub_err_t
grub_initrd_load (struct grub_linux_initrd_context *initrd_ctx,
- char *argv[], void *target)
+ void *target)
{
grub_uint8_t *ptr = target;
int i;
@@ -317,7 +317,7 @@ grub_initrd_load (struct grub_linux_initrd_context *initrd_ctx,
{
if (!grub_errno)
grub_error (GRUB_ERR_FILE_READ_ERROR, N_("premature end of file %s"),
- argv[i]);
+ initrd_ctx->components[i].file->name);
grub_initrd_close (initrd_ctx);
return grub_errno;
}
diff --git a/grub-core/loader/mips/linux.c b/grub-core/loader/mips/linux.c
index e4ed95921..94594721d 100644
--- a/grub-core/loader/mips/linux.c
+++ b/grub-core/loader/mips/linux.c
@@ -452,7 +452,7 @@ grub_cmd_initrd (grub_command_t cmd __attribute__ ((unused)),
initrd_dest = get_physical_target_address (ch) | 0x80000000;
}
- if (grub_initrd_load (&initrd_ctx, argv, initrd_src))
+ if (grub_initrd_load (&initrd_ctx, initrd_src))
goto fail;
#ifdef GRUB_MACHINE_MIPS_QEMU_MIPS
diff --git a/grub-core/loader/powerpc/ieee1275/linux.c b/grub-core/loader/powerpc/ieee1275/linux.c
index 818b2a86d..a51e7a786 100644
--- a/grub-core/loader/powerpc/ieee1275/linux.c
+++ b/grub-core/loader/powerpc/ieee1275/linux.c
@@ -363,7 +363,7 @@ grub_cmd_initrd (grub_command_t cmd __attribute__ ((unused)),
grub_dprintf ("loader", "Loading initrd at 0x%x, size 0x%x\n", addr, size);
- if (grub_initrd_load (&initrd_ctx, argv, (void *) addr))
+ if (grub_initrd_load (&initrd_ctx, (void *) addr))
goto fail;
initrd_addr = addr;
diff --git a/grub-core/loader/sparc64/ieee1275/linux.c b/grub-core/loader/sparc64/ieee1275/linux.c
index bb47ee0cc..ac2206f3c 100644
--- a/grub-core/loader/sparc64/ieee1275/linux.c
+++ b/grub-core/loader/sparc64/ieee1275/linux.c
@@ -413,7 +413,7 @@ grub_cmd_initrd (grub_command_t cmd __attribute__ ((unused)),
grub_dprintf ("loader", "Loading initrd at vaddr 0x%lx, paddr 0x%lx, size 0x%lx\n",
addr, paddr, size);
- if (grub_initrd_load (&initrd_ctx, argv, (void *) addr))
+ if (grub_initrd_load (&initrd_ctx, (void *) addr))
goto fail;
initrd_addr = addr;
diff --git a/include/grub/linux.h b/include/grub/linux.h
index 594a3f307..a96ac2048 100644
--- a/include/grub/linux.h
+++ b/include/grub/linux.h
@@ -21,4 +21,4 @@ grub_initrd_close (struct grub_linux_initrd_context *initrd_ctx);
grub_err_t
grub_initrd_load (struct grub_linux_initrd_context *initrd_ctx,
- char *argv[], void *target);
+ void *target);
--
2.29.3
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH v2 2/7] efi: add definition of LoadFile2 protocol
2021-06-02 21:12 [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader Nikita Ermakov
2021-06-02 21:12 ` [PATCH v2 1/7] loader: drop argv[] argument in grub_initrd_load() Nikita Ermakov
@ 2021-06-02 21:12 ` Nikita Ermakov
2021-06-02 21:12 ` [PATCH v2 3/7] efi: implemented LoadFile2 initrd loading protocol for Linux Nikita Ermakov
` (7 subsequent siblings)
9 siblings, 0 replies; 36+ messages in thread
From: Nikita Ermakov @ 2021-06-02 21:12 UTC (permalink / raw)
To: GRUB development mailing list
Cc: Ard Biesheuvel, Atish Patra, Daniel Kiper, Heinrich Schuchardt,
Leif Lindholm, Nikita Ermakov
From: Ard Biesheuvel <ard.biesheuvel@arm.com>
Incorporate the EFI_LOAD_FILE2_PROTOCOL GUID and C types from the
UEFI spec.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Nikita Ermakov <arei@altlinux.org>
---
grub-core/commands/efi/lsefi.c | 1 +
include/grub/efi/api.h | 15 +++++++++++++++
2 files changed, 16 insertions(+)
diff --git a/grub-core/commands/efi/lsefi.c b/grub-core/commands/efi/lsefi.c
index d1ce99af4..4085f5df2 100644
--- a/grub-core/commands/efi/lsefi.c
+++ b/grub-core/commands/efi/lsefi.c
@@ -55,6 +55,7 @@ struct known_protocol
{ GRUB_EFI_ABSOLUTE_POINTER_PROTOCOL_GUID, "absolute pointer" },
{ GRUB_EFI_DRIVER_BINDING_PROTOCOL_GUID, "EFI driver binding" },
{ GRUB_EFI_LOAD_FILE_PROTOCOL_GUID, "load file" },
+ { GRUB_EFI_LOAD_FILE2_PROTOCOL_GUID, "load file2" },
{ GRUB_EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID, "simple FS" },
{ GRUB_EFI_TAPE_IO_PROTOCOL_GUID, "tape I/O" },
{ GRUB_EFI_UNICODE_COLLATION_PROTOCOL_GUID, "unicode collation" },
diff --git a/include/grub/efi/api.h b/include/grub/efi/api.h
index f1a52210c..3de0a7d12 100644
--- a/include/grub/efi/api.h
+++ b/include/grub/efi/api.h
@@ -149,6 +149,11 @@
{ 0x8E, 0x3F, 0x00, 0xA0, 0xC9, 0x69, 0x72, 0x3B } \
}
+#define GRUB_EFI_LOAD_FILE2_PROTOCOL_GUID \
+ { 0x4006c0c1, 0xfcb3, 0x403e, \
+ { 0x99, 0x6d, 0x4a, 0x6c, 0x87, 0x24, 0xe0, 0x6d } \
+ }
+
#define GRUB_EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID \
{ 0x0964e5b22, 0x6459, 0x11d2, \
{ 0x8e, 0x39, 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b } \
@@ -1729,6 +1734,16 @@ struct grub_efi_rng_protocol
};
typedef struct grub_efi_rng_protocol grub_efi_rng_protocol_t;
+struct grub_efi_load_file2
+{
+ grub_efi_status_t (*load_file)(struct grub_efi_load_file2 *this,
+ grub_efi_device_path_t *file_path,
+ grub_efi_boolean_t boot_policy,
+ grub_efi_uintn_t *buffer_size,
+ void *buffer);
+};
+typedef struct grub_efi_load_file2 grub_efi_load_file2_t;
+
#if (GRUB_TARGET_SIZEOF_VOID_P == 4) || defined (__ia64__) \
|| defined (__aarch64__) || defined (__MINGW64__) || defined (__CYGWIN__) \
|| defined(__riscv)
--
2.29.3
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH v2 3/7] efi: implemented LoadFile2 initrd loading protocol for Linux
2021-06-02 21:12 [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader Nikita Ermakov
2021-06-02 21:12 ` [PATCH v2 1/7] loader: drop argv[] argument in grub_initrd_load() Nikita Ermakov
2021-06-02 21:12 ` [PATCH v2 2/7] efi: add definition of LoadFile2 protocol Nikita Ermakov
@ 2021-06-02 21:12 ` Nikita Ermakov
2021-09-23 12:18 ` Andreas Schwab
2021-06-02 21:12 ` [PATCH v2 4/7] linux: ignore FDT unless we need to modify it Nikita Ermakov
` (6 subsequent siblings)
9 siblings, 1 reply; 36+ messages in thread
From: Nikita Ermakov @ 2021-06-02 21:12 UTC (permalink / raw)
To: GRUB development mailing list
Cc: Ard Biesheuvel, Atish Patra, Daniel Kiper, Heinrich Schuchardt,
Leif Lindholm, Nikita Ermakov
From: Ard Biesheuvel <ard.biesheuvel@arm.com>
Recent Linux kernels will invoke the LoadFile2 protocol installed on
a well-known vendor media path to load the initrd if it is exposed by
the firmware. Using this method is preferred for two reasons:
- the Linux kernel is in charge of allocating the memory, and so it can
implement any placement policy it wants (given that these tend to
change between kernel versions),
- it is no longer necessary to modify the device tree provided by the
firmware.
So let's install this protocol when handling the 'initrd' command if
such a recent kernel was detected (based on the PE/COFF image version),
and defer loading the initrd contents until the point where the kernel
invokes the LoadFile2 protocol.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Nikita Ermakov <arei@altlinux.org>
---
grub-core/loader/arm64/linux.c | 117 ++++++++++++++++++++++++++++++++-
1 file changed, 116 insertions(+), 1 deletion(-)
diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c
index aed7a200b..6b03455d1 100644
--- a/grub-core/loader/arm64/linux.c
+++ b/grub-core/loader/arm64/linux.c
@@ -48,9 +48,18 @@ static grub_uint32_t cmdline_size;
static grub_addr_t initrd_start;
static grub_addr_t initrd_end;
+static struct grub_linux_initrd_context initrd_ctx = { 0, 0, 0 };
+static grub_efi_handle_t initrd_lf2_handle;
+static int initrd_use_loadfile2;
+static grub_efi_guid_t load_file2_guid = GRUB_EFI_LOAD_FILE2_PROTOCOL_GUID;
+static grub_efi_guid_t device_path_guid = GRUB_EFI_DEVICE_PATH_GUID;
+
grub_err_t
grub_arch_efi_linux_check_image (struct linux_arch_kernel_header * lh)
{
+ struct grub_pe32_coff_header *coff_header;
+ struct grub_pe32_optional_header *optional_header;
+
if (lh->magic != GRUB_LINUX_ARMXX_MAGIC_SIGNATURE)
return grub_error(GRUB_ERR_BAD_OS, "invalid magic number");
@@ -61,6 +70,21 @@ grub_arch_efi_linux_check_image (struct linux_arch_kernel_header * lh)
grub_dprintf ("linux", "UEFI stub kernel:\n");
grub_dprintf ("linux", "PE/COFF header @ %08x\n", lh->hdr_offset);
+ coff_header = (struct grub_pe32_coff_header *)((unsigned long)lh + lh->hdr_offset);
+ optional_header = (struct grub_pe32_optional_header *)(coff_header + 1);
+
+ /*
+ * Linux kernels built for any architecture are guaranteed to support the
+ * LoadFile2 based initrd loading protocol if the image version is >= 1.
+ */
+ if (optional_header->major_image_version >= 1)
+ initrd_use_loadfile2 = 1;
+ else
+ initrd_use_loadfile2 = 0;
+
+ grub_dprintf ("linux", "LoadFile2 initrd loading %sabled\n",
+ initrd_use_loadfile2 ? "en" : "dis");
+
return GRUB_ERR_NONE;
}
@@ -230,13 +254,86 @@ allocate_initrd_mem (int initrd_pages)
GRUB_EFI_LOADER_DATA);
}
+struct initrd_media_device_path {
+ grub_efi_vendor_media_device_path_t vendor;
+ grub_efi_device_path_t end;
+} GRUB_PACKED;
+
+#define LINUX_EFI_INITRD_MEDIA_GUID \
+ { 0x5568e427, 0x68fc, 0x4f3d, \
+ { 0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68 } \
+ }
+
+static struct initrd_media_device_path initrd_lf2_device_path = {
+ {
+ {
+ GRUB_EFI_MEDIA_DEVICE_PATH_TYPE,
+ GRUB_EFI_VENDOR_MEDIA_DEVICE_PATH_SUBTYPE,
+ sizeof(grub_efi_vendor_media_device_path_t),
+ },
+ LINUX_EFI_INITRD_MEDIA_GUID
+ }, {
+ GRUB_EFI_END_DEVICE_PATH_TYPE,
+ GRUB_EFI_END_ENTIRE_DEVICE_PATH_SUBTYPE,
+ sizeof(grub_efi_device_path_t)
+ }
+};
+
+static grub_efi_status_t
+grub_efi_initrd_load_file2(grub_efi_load_file2_t *this,
+ grub_efi_device_path_t *device_path,
+ grub_efi_boolean_t boot_policy,
+ grub_efi_uintn_t *buffer_size,
+ void *buffer);
+
+static grub_efi_load_file2_t initrd_lf2 = {
+ grub_efi_initrd_load_file2
+};
+
+static grub_efi_status_t
+grub_efi_initrd_load_file2(grub_efi_load_file2_t *this,
+ grub_efi_device_path_t *device_path,
+ grub_efi_boolean_t boot_policy,
+ grub_efi_uintn_t *buffer_size,
+ void *buffer)
+{
+ grub_efi_status_t status = GRUB_EFI_SUCCESS;
+ grub_efi_uintn_t initrd_size;
+
+ if (!this || this != &initrd_lf2 || !buffer_size)
+ return GRUB_EFI_INVALID_PARAMETER;
+
+ if (device_path->type != GRUB_EFI_END_DEVICE_PATH_TYPE ||
+ device_path->subtype != GRUB_EFI_END_ENTIRE_DEVICE_PATH_SUBTYPE)
+ return GRUB_EFI_NOT_FOUND;
+
+ if (boot_policy)
+ return GRUB_EFI_UNSUPPORTED;
+
+ initrd_size = grub_get_initrd_size (&initrd_ctx);
+ if (!buffer || *buffer_size < initrd_size)
+ {
+ *buffer_size = initrd_size;
+ return GRUB_EFI_BUFFER_TOO_SMALL;
+ }
+
+ grub_dprintf ("linux", "Providing initrd via LOAD_FILE2_PROTOCOL\n");
+
+ if (grub_initrd_load (&initrd_ctx, buffer))
+ status = GRUB_EFI_LOAD_ERROR;
+
+ grub_initrd_close (&initrd_ctx);
+ return status;
+}
+
static grub_err_t
grub_cmd_initrd (grub_command_t cmd __attribute__ ((unused)),
int argc, char *argv[])
{
- struct grub_linux_initrd_context initrd_ctx = { 0, 0, 0 };
int initrd_size, initrd_pages;
void *initrd_mem = NULL;
+ grub_efi_boot_services_t *b;
+ grub_efi_status_t status;
if (argc == 0)
{
@@ -254,6 +351,24 @@ grub_cmd_initrd (grub_command_t cmd __attribute__ ((unused)),
if (grub_initrd_init (argc, argv, &initrd_ctx))
goto fail;
+ if (initrd_use_loadfile2 && !initrd_lf2_handle)
+ {
+ b = grub_efi_system_table->boot_services;
+ status = b->install_multiple_protocol_interfaces (&initrd_lf2_handle,
+ &load_file2_guid,
+ &initrd_lf2,
+ &device_path_guid,
+ &initrd_lf2_device_path,
+ NULL);
+ if (status == GRUB_EFI_OUT_OF_RESOURCES)
+ {
+ grub_error (GRUB_ERR_OUT_OF_MEMORY, N_("out of memory"));
+ return grub_errno;
+ }
+ grub_dprintf ("linux", "LoadFile2 initrd loading protocol installed\n");
+ return GRUB_ERR_NONE;
+ }
+
initrd_size = grub_get_initrd_size (&initrd_ctx);
grub_dprintf ("linux", "Loading initrd\n");
--
2.29.3
^ permalink raw reply related [flat|nested] 36+ messages in thread* Re: [PATCH v2 3/7] efi: implemented LoadFile2 initrd loading protocol for Linux
2021-06-02 21:12 ` [PATCH v2 3/7] efi: implemented LoadFile2 initrd loading protocol for Linux Nikita Ermakov
@ 2021-09-23 12:18 ` Andreas Schwab
2021-10-05 9:45 ` Heinrich Schuchardt
0 siblings, 1 reply; 36+ messages in thread
From: Andreas Schwab @ 2021-09-23 12:18 UTC (permalink / raw)
To: Nikita Ermakov
Cc: GRUB development mailing list, Ard Biesheuvel, Atish Patra,
Daniel Kiper, Heinrich Schuchardt, Leif Lindholm
That appears to have issues with loading the initrd over network. I can
see the RRQ packet for the initrd arriving at the tftp server, the first
DATA packet sent out by the sever, which is acknowleged by the client.
But all subsequent DATA packages are never acknowleged by the client,
which just times out. The kernel is loaded without problem.
Loading kernel ...
Loading initial ramdisk ...
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
error: ../../grub-core/net/drivers/efi/efinet.c:81:couldn't send network
packet.
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Exiting boot services and installing virtual address map...
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 3/7] efi: implemented LoadFile2 initrd loading protocol for Linux
2021-09-23 12:18 ` Andreas Schwab
@ 2021-10-05 9:45 ` Heinrich Schuchardt
2021-10-05 10:05 ` Andreas Schwab
0 siblings, 1 reply; 36+ messages in thread
From: Heinrich Schuchardt @ 2021-10-05 9:45 UTC (permalink / raw)
To: Andreas Schwab, Nikita Ermakov
Cc: GRUB development mailing list, Ard Biesheuvel, Atish Patra,
Daniel Kiper, Leif Lindholm
On 9/23/21 14:18, Andreas Schwab wrote:
> That appears to have issues with loading the initrd over network. I can
> see the RRQ packet for the initrd arriving at the tftp server, the first
> DATA packet sent out by the sever, which is acknowleged by the client.
> But all subsequent DATA packages are never acknowleged by the client,
> which just times out. The kernel is loaded without problem.
>
> Loading kernel ...
> Loading initial ramdisk ...
> EFI stub: Booting Linux Kernel...
> EFI stub: Using DTB from configuration table
> error: ../../grub-core/net/drivers/efi/efinet.c:81:couldn't send network
> packet.
> EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
> EFI stub: Exiting boot services and installing virtual address map...
>
> Andreas.
>
Hello Andreas,
Do you think this problem is RISC-V specific and related to the series?
Cf. https://gist.github.com/kvaps/4a61233e4427740c636a0cbd885e54cd
Should the problem in the network driver stop merging this series?
Booting on RISC-V works fine on block devices with this series. I would
be happy if this series were merged as is.
Best regards
Heinrich
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 3/7] efi: implemented LoadFile2 initrd loading protocol for Linux
2021-10-05 9:45 ` Heinrich Schuchardt
@ 2021-10-05 10:05 ` Andreas Schwab
2021-10-05 14:57 ` Heinrich Schuchardt
0 siblings, 1 reply; 36+ messages in thread
From: Andreas Schwab @ 2021-10-05 10:05 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Nikita Ermakov, GRUB development mailing list, Ard Biesheuvel,
Atish Patra, Daniel Kiper, Leif Lindholm
On Okt 05 2021, Heinrich Schuchardt wrote:
> Do you think this problem is RISC-V specific
No, I don't think so.
> and related to the series?
Since network download of the kernel works, this seems to be related to
the use of the LoadFile2 protocol.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 3/7] efi: implemented LoadFile2 initrd loading protocol for Linux
2021-10-05 10:05 ` Andreas Schwab
@ 2021-10-05 14:57 ` Heinrich Schuchardt
2021-10-05 15:07 ` Andreas Schwab
2021-10-05 15:30 ` Andreas Schwab
0 siblings, 2 replies; 36+ messages in thread
From: Heinrich Schuchardt @ 2021-10-05 14:57 UTC (permalink / raw)
To: Andreas Schwab
Cc: Nikita Ermakov, GRUB development mailing list, Ard Biesheuvel,
Atish Patra, Daniel Kiper, Leif Lindholm
On 10/5/21 12:05, Andreas Schwab wrote:
> On Okt 05 2021, Heinrich Schuchardt wrote:
>
>> Do you think this problem is RISC-V specific
>
> No, I don't think so.
>
>> and related to the series?
>
> Since network download of the kernel works, this seems to be related to
> the use of the LoadFile2 protocol.
>
> Andreas.
>
Which firmware did you use? U-Boot or EDK II? Which version?
I have appended a log for U-Boot v2021.10-rc4 on the Unmatched board below.
Before the 'boot' command the communication via TFTP seems to work fine.
The init command can identify which file exists on the TFTP server.
The boot command calls ShutDown() and Stop() on the SNP protocol and
closes it. And then tries to open it again for the LOAD_FILE2 protocol.
The question remains why the protocol cannot be reopened. It is unclear
if this is a GRUB or a U-Boot issue.
Best regards
Heinrich
=> load mmc 0:f $fdt_addr_r sifive/hifive-unmatched-a00.dtb
9740 bytes read in 15 ms (633.8 KiB/s)
=> load mmc 0:f $kernel_addr_r grubriscv64.efi
1306624 bytes read in 1193 ms (1 MiB/s)
=> bootefi $kernel_addr_r $fdt_addr_r
grub> debug=linux,loader,fdt
grub> net_dhcp
net/drivers/efi/efinet.c:155: Trying to reopen SNP exclusively
grub> linux (tftp,192.168.0.3)/riscv64/vmlinuz
loader/efi/linux.c:70: UEFI stub kernel:
loader/efi/linux.c:71: PE/COFF header @ 00000040
loader/efi/linux.c:85: LoadFile2 initrd loading enabled
loader/efi/linux.c:430: kernel file size: 29496832
loader/efi/linux.c:432: kernel numpages: 7202
loader/efi/linux.c:449: kernel @ 0xdd040000
grub> initrd (tftp,192.168.0.3)/risv64/initrd
error: File not found.
grub> initrd (tftp,192.168.0.3)/riscv64/initrd
loader/efi/linux.c:368: LoadFile2 initrd loading protocol installed
grub> boot
net/drivers/efi/efinet.c:214: Closing the SNP protocol
loader/efi/linux.c:168: linux command line:
'BOOT_IMAGE=(tftp,192.168.0.3)/riscv64/vmlinuz'
loader/efi/linux.c:183: starting image 0xff745320
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
loader/efi/linux.c:320: Providing initrd via LOAD_FILE2_PROTOCOL
net/drivers/efi/efinet.c:155: Trying to reopen SNP exclusively
net/drivers/efi/efinet.c:162: Failed to open SNP protocol!
net/drivers/efi/efinet.c:79: Transmit() returned: 8000000000000013
error: couldn't send network packet.
net/drivers/efi/efinet.c:79: Transmit() returned: 8000000000000013
error: couldn't send network packet.
...
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Exiting boot services and installing virtual address map...
[ 0.000000] Linux version 5.13.0-1004-generic
(buildd@riscv64-qemu-lcy01-074) (gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0,
GNU ld (GNU Binutils for Ubuntu) 2.37) #4-Ubuntu SMP Thu Sep 30 05:02:57
UTC 2021 (Ubuntu 5.13.0-1004.4-generic 5.13.14)
[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
[ 0.000000] Machine model: SiFive HiFive Unmatched A00
[ 0.000000] efi: EFI v2.80 by Das U-Boot
[ 0.000000] efi: RTPROP=0xfe6fb040 SMBIOS=0xfe6f7000
MEMRESERVE=0xd2b92040
[ 0.000000] secureboot: Secure boot disabled
...
[ 3.001432] ---[ end Kernel panic - not syncing: No working init
found. Try passing init= option to kernel. See Linux
Documentation/admin-guide/init.rst for guidance. ]-
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 3/7] efi: implemented LoadFile2 initrd loading protocol for Linux
2021-10-05 14:57 ` Heinrich Schuchardt
@ 2021-10-05 15:07 ` Andreas Schwab
2021-10-05 15:30 ` Andreas Schwab
1 sibling, 0 replies; 36+ messages in thread
From: Andreas Schwab @ 2021-10-05 15:07 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Nikita Ermakov, GRUB development mailing list, Ard Biesheuvel,
Atish Patra, Daniel Kiper, Leif Lindholm
On Okt 05 2021, Heinrich Schuchardt wrote:
> Which firmware did you use? U-Boot or EDK II? Which version?
U-Boot.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 3/7] efi: implemented LoadFile2 initrd loading protocol for Linux
2021-10-05 14:57 ` Heinrich Schuchardt
2021-10-05 15:07 ` Andreas Schwab
@ 2021-10-05 15:30 ` Andreas Schwab
2021-10-06 7:58 ` Heinrich Schuchardt
1 sibling, 1 reply; 36+ messages in thread
From: Andreas Schwab @ 2021-10-05 15:30 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Nikita Ermakov, GRUB development mailing list, Ard Biesheuvel,
Atish Patra, Daniel Kiper, Leif Lindholm
On Okt 05 2021, Heinrich Schuchardt wrote:
> Before the 'boot' command the communication via TFTP seems to work fine.
> The init command can identify which file exists on the TFTP server.
>
> The boot command calls ShutDown() and Stop() on the SNP protocol and
> closes it. And then tries to open it again for the LOAD_FILE2 protocol.
>
> The question remains why the protocol cannot be reopened. It is unclear
> if this is a GRUB or a U-Boot issue.
The strange thing is that the first two packets+ACK still get through.
Maybe related to the size of the following DATA packet?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 3/7] efi: implemented LoadFile2 initrd loading protocol for Linux
2021-10-05 15:30 ` Andreas Schwab
@ 2021-10-06 7:58 ` Heinrich Schuchardt
2021-10-08 17:39 ` Heinrich Schuchardt
0 siblings, 1 reply; 36+ messages in thread
From: Heinrich Schuchardt @ 2021-10-06 7:58 UTC (permalink / raw)
To: Andreas Schwab
Cc: Nikita Ermakov, GRUB development mailing list, Ard Biesheuvel,
Atish Patra, Daniel Kiper, Leif Lindholm
On 10/5/21 17:30, Andreas Schwab wrote:
> On Okt 05 2021, Heinrich Schuchardt wrote:
>
>> Before the 'boot' command the communication via TFTP seems to work fine.
>> The init command can identify which file exists on the TFTP server.
>>
>> The boot command calls ShutDown() and Stop() on the SNP protocol and
>> closes it. And then tries to open it again for the LOAD_FILE2 protocol.
>>
>> The question remains why the protocol cannot be reopened. It is unclear
>> if this is a GRUB or a U-Boot issue.
>
> The strange thing is that the first two packets+ACK still get through.
> Maybe related to the size of the following DATA packet?
When the initrd command is issued it checks that the file exists. It is
after the boot command that things run awry.
There are multiple bugs in efinet.c. I am working on a patch.
Best regards
Heinrich
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 3/7] efi: implemented LoadFile2 initrd loading protocol for Linux
2021-10-06 7:58 ` Heinrich Schuchardt
@ 2021-10-08 17:39 ` Heinrich Schuchardt
0 siblings, 0 replies; 36+ messages in thread
From: Heinrich Schuchardt @ 2021-10-08 17:39 UTC (permalink / raw)
To: GRUB development mailing list
Cc: Nikita Ermakov, Ard Biesheuvel, Atish Patra, Daniel Kiper,
Leif Lindholm, Andreas Schwab
On 10/6/21 09:58, Heinrich Schuchardt wrote:
>
>
> On 10/5/21 17:30, Andreas Schwab wrote:
>> On Okt 05 2021, Heinrich Schuchardt wrote:
>>
>>> Before the 'boot' command the communication via TFTP seems to work fine.
>>> The init command can identify which file exists on the TFTP server.
>>>
>>> The boot command calls ShutDown() and Stop() on the SNP protocol and
>>> closes it. And then tries to open it again for the LOAD_FILE2 protocol.
>>>
>>> The question remains why the protocol cannot be reopened. It is unclear
>>> if this is a GRUB or a U-Boot issue.
>>
>> The strange thing is that the first two packets+ACK still get through.
>> Maybe related to the size of the following DATA packet?
>
> When the initrd command is issued it checks that the file exists. It is
> after the boot command that things run awry.
>
> There are multiple bugs in efinet.c. I am working on a patch.
Andreas has confirmed in
https://lists.gnu.org/archive/html/grub-devel/2021-10/msg00035.html
that [PATCH 0/2] efinet: correct closing of SNP protocol
https://lists.gnu.org/archive/html/grub-devel/2021-10/msg00028.html
solves the issued.
Best regards
Heinrich
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v2 4/7] linux: ignore FDT unless we need to modify it
2021-06-02 21:12 [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader Nikita Ermakov
` (2 preceding siblings ...)
2021-06-02 21:12 ` [PATCH v2 3/7] efi: implemented LoadFile2 initrd loading protocol for Linux Nikita Ermakov
@ 2021-06-02 21:12 ` Nikita Ermakov
2021-06-02 21:12 ` [PATCH v2 5/7] loader: Move arm64 linux loader to common code Nikita Ermakov
` (5 subsequent siblings)
9 siblings, 0 replies; 36+ messages in thread
From: Nikita Ermakov @ 2021-06-02 21:12 UTC (permalink / raw)
To: GRUB development mailing list
Cc: Ard Biesheuvel, Atish Patra, Daniel Kiper, Heinrich Schuchardt,
Leif Lindholm, Nikita Ermakov
From: Ard Biesheuvel <ard.biesheuvel@arm.com>
Now that we implemented supported for the LoadFile2 protocol for initrd
loading, there is no longer a need to pass the initrd parameters via
the device tree. This means there is no longer a reason to update the
device tree in the first place, and so we can ignore it entirely.
The only remaining reason to deal with the devicetree is if we are
using the 'devicetree' command to load one from disk, so tweak the
logic in grub_fdt_install() to take that into account.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
---
grub-core/loader/arm64/linux.c | 22 +++++++++++-----------
grub-core/loader/efi/fdt.c | 7 +++++--
2 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c
index 6b03455d1..65f1275fb 100644
--- a/grub-core/loader/arm64/linux.c
+++ b/grub-core/loader/arm64/linux.c
@@ -95,21 +95,21 @@ finalize_params_linux (void)
void *fdt;
- fdt = grub_fdt_load (GRUB_EFI_LINUX_FDT_EXTRA_SPACE);
+ /* Set initrd info */
+ if (initrd_start && initrd_end > initrd_start)
+ {
+ fdt = grub_fdt_load (GRUB_EFI_LINUX_FDT_EXTRA_SPACE);
- if (!fdt)
- goto failure;
+ if (!fdt)
+ goto failure;
- node = grub_fdt_find_subnode (fdt, 0, "chosen");
- if (node < 0)
- node = grub_fdt_add_subnode (fdt, 0, "chosen");
+ node = grub_fdt_find_subnode (fdt, 0, "chosen");
+ if (node < 0)
+ node = grub_fdt_add_subnode (fdt, 0, "chosen");
- if (node < 1)
- goto failure;
+ if (node < 1)
+ goto failure;
- /* Set initrd info */
- if (initrd_start && initrd_end > initrd_start)
- {
grub_dprintf ("linux", "Initrd @ %p-%p\n",
(void *) initrd_start, (void *) initrd_end);
diff --git a/grub-core/loader/efi/fdt.c b/grub-core/loader/efi/fdt.c
index c86f283d7..771d455c7 100644
--- a/grub-core/loader/efi/fdt.c
+++ b/grub-core/loader/efi/fdt.c
@@ -89,13 +89,16 @@ grub_fdt_install (void)
grub_efi_guid_t fdt_guid = GRUB_EFI_DEVICE_TREE_GUID;
grub_efi_status_t status;
+ if (!fdt && !loaded_fdt)
+ return GRUB_ERR_NONE;
+
b = grub_efi_system_table->boot_services;
- status = b->install_configuration_table (&fdt_guid, fdt);
+ status = b->install_configuration_table (&fdt_guid, fdt ?: loaded_fdt);
if (status != GRUB_EFI_SUCCESS)
return grub_error (GRUB_ERR_IO, "failed to install FDT");
grub_dprintf ("fdt", "Installed/updated FDT configuration table @ %p\n",
- fdt);
+ fdt ?: loaded_fdt);
return GRUB_ERR_NONE;
}
--
2.29.3
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH v2 5/7] loader: Move arm64 linux loader to common code
2021-06-02 21:12 [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader Nikita Ermakov
` (3 preceding siblings ...)
2021-06-02 21:12 ` [PATCH v2 4/7] linux: ignore FDT unless we need to modify it Nikita Ermakov
@ 2021-06-02 21:12 ` Nikita Ermakov
2021-06-02 21:12 ` [PATCH v2 6/7] RISC-V: Update image header Nikita Ermakov
` (4 subsequent siblings)
9 siblings, 0 replies; 36+ messages in thread
From: Nikita Ermakov @ 2021-06-02 21:12 UTC (permalink / raw)
To: GRUB development mailing list
Cc: Ard Biesheuvel, Atish Patra, Daniel Kiper, Heinrich Schuchardt,
Leif Lindholm, Nikita Ermakov, Atish Patra
From: Atish Patra <atish.patra@wdc.com>
ARM64 linux loader code is written in such a way that it can be reused
across different architectures without much change. Move it to common
code so that RISC-V doesn't have to define a separate loader.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
---
grub-core/Makefile.core.def | 4 ++--
grub-core/loader/{arm64 => efi}/linux.c | 2 +-
include/grub/arm/linux.h | 2 +-
include/grub/arm64/linux.h | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
rename grub-core/loader/{arm64 => efi}/linux.c (99%)
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 8022e1c0a..b36cf663a 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1806,9 +1806,9 @@ module = {
sparc64_ieee1275 = loader/sparc64/ieee1275/linux.c;
ia64_efi = loader/ia64/efi/linux.c;
arm_coreboot = loader/arm/linux.c;
- arm_efi = loader/arm64/linux.c;
+ arm_efi = loader/efi/linux.c;
arm_uboot = loader/arm/linux.c;
- arm64 = loader/arm64/linux.c;
+ arm64 = loader/efi/linux.c;
riscv32 = loader/riscv/linux.c;
riscv64 = loader/riscv/linux.c;
common = loader/linux.c;
diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/efi/linux.c
similarity index 99%
rename from grub-core/loader/arm64/linux.c
rename to grub-core/loader/efi/linux.c
index 65f1275fb..60f0fa264 100644
--- a/grub-core/loader/arm64/linux.c
+++ b/grub-core/loader/efi/linux.c
@@ -60,7 +60,7 @@ grub_arch_efi_linux_check_image (struct linux_arch_kernel_header * lh)
struct grub_pe32_coff_header *coff_header;
struct grub_pe32_optional_header *optional_header;
- if (lh->magic != GRUB_LINUX_ARMXX_MAGIC_SIGNATURE)
+ if (lh->magic != GRUB_LINUX_ARCH_MAGIC_SIGNATURE)
return grub_error(GRUB_ERR_BAD_OS, "invalid magic number");
if ((lh->code0 & 0xffff) != GRUB_PE32_MAGIC)
diff --git a/include/grub/arm/linux.h b/include/grub/arm/linux.h
index bcd5a7eb1..8c13978d2 100644
--- a/include/grub/arm/linux.h
+++ b/include/grub/arm/linux.h
@@ -35,7 +35,7 @@ struct linux_arm_kernel_header {
};
#if defined(__arm__)
-# define GRUB_LINUX_ARMXX_MAGIC_SIGNATURE GRUB_LINUX_ARM_MAGIC_SIGNATURE
+# define GRUB_LINUX_ARCH_MAGIC_SIGNATURE GRUB_LINUX_ARM_MAGIC_SIGNATURE
# define linux_arch_kernel_header linux_arm_kernel_header
#endif
diff --git a/include/grub/arm64/linux.h b/include/grub/arm64/linux.h
index 7e22b4ab6..effd870ef 100644
--- a/include/grub/arm64/linux.h
+++ b/include/grub/arm64/linux.h
@@ -39,7 +39,7 @@ struct linux_arm64_kernel_header
};
#if defined(__aarch64__)
-# define GRUB_LINUX_ARMXX_MAGIC_SIGNATURE GRUB_LINUX_ARM64_MAGIC_SIGNATURE
+# define GRUB_LINUX_ARCH_MAGIC_SIGNATURE GRUB_LINUX_ARM64_MAGIC_SIGNATURE
# define linux_arch_kernel_header linux_arm64_kernel_header
#endif
--
2.29.3
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH v2 6/7] RISC-V: Update image header
2021-06-02 21:12 [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader Nikita Ermakov
` (4 preceding siblings ...)
2021-06-02 21:12 ` [PATCH v2 5/7] loader: Move arm64 linux loader to common code Nikita Ermakov
@ 2021-06-02 21:12 ` Nikita Ermakov
2021-06-02 21:12 ` [PATCH v2 7/7] RISC-V: Use common linux loader Nikita Ermakov
` (3 subsequent siblings)
9 siblings, 0 replies; 36+ messages in thread
From: Nikita Ermakov @ 2021-06-02 21:12 UTC (permalink / raw)
To: GRUB development mailing list
Cc: Ard Biesheuvel, Atish Patra, Daniel Kiper, Heinrich Schuchardt,
Leif Lindholm, Nikita Ermakov, Atish Patra
From: Atish Patra <atish.patra@wdc.com>
Update the RISC-V Linux kernel image headers as per the current header.
Reference:
<Linux kernel source>/Documentation/riscv/boot-image-header.rst
Signed-off-by: Atish Patra <atish.patra@wdc.com>
---
include/grub/riscv32/linux.h | 15 ++++++++-------
include/grub/riscv64/linux.h | 15 ++++++++-------
2 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/include/grub/riscv32/linux.h b/include/grub/riscv32/linux.h
index 512b777c8..de0dbdcd1 100644
--- a/include/grub/riscv32/linux.h
+++ b/include/grub/riscv32/linux.h
@@ -19,20 +19,21 @@
#ifndef GRUB_RISCV32_LINUX_HEADER
#define GRUB_RISCV32_LINUX_HEADER 1
-#define GRUB_LINUX_RISCV_MAGIC_SIGNATURE 0x52534356 /* 'RSCV' */
+#define GRUB_LINUX_RISCV_MAGIC_SIGNATURE 0x05435352 /* 'RSC\0x5' */
-/* From linux/Documentation/riscv/booting.txt */
+/* From linux/Documentation/riscv/boot-image-header.rst */
struct linux_riscv_kernel_header
{
grub_uint32_t code0; /* Executable code */
grub_uint32_t code1; /* Executable code */
- grub_uint64_t text_offset; /* Image load offset */
- grub_uint64_t res0; /* reserved */
- grub_uint64_t res1; /* reserved */
+ grub_uint64_t text_offset; /* Image load offset, little endian */
+ grub_uint64_t image_size; /* Effective Image size, little endian */
+ grub_uint64_t flags; /* kernel flags, little endian */
+ grub_uint32_t version; /* Version of this header */
+ grub_uint32_t res1; /* reserved */
grub_uint64_t res2; /* reserved */
grub_uint64_t res3; /* reserved */
- grub_uint64_t res4; /* reserved */
- grub_uint32_t magic; /* Magic number, little endian, "RSCV" */
+ grub_uint32_t magic; /* Magic number, little endian, "RSC\x05" */
grub_uint32_t hdr_offset; /* Offset of PE/COFF header */
};
diff --git a/include/grub/riscv64/linux.h b/include/grub/riscv64/linux.h
index 3630c30fb..7c28bc922 100644
--- a/include/grub/riscv64/linux.h
+++ b/include/grub/riscv64/linux.h
@@ -19,22 +19,23 @@
#ifndef GRUB_RISCV64_LINUX_HEADER
#define GRUB_RISCV64_LINUX_HEADER 1
-#define GRUB_LINUX_RISCV_MAGIC_SIGNATURE 0x52534356 /* 'RSCV' */
+#define GRUB_LINUX_RISCV_MAGIC_SIGNATURE 0x05435352 /* 'RSC\0x5' */
#define GRUB_EFI_PE_MAGIC 0x5A4D
-/* From linux/Documentation/riscv/booting.txt */
+/* From linux/Documentation/riscv/boot-image-header.rst */
struct linux_riscv_kernel_header
{
grub_uint32_t code0; /* Executable code */
grub_uint32_t code1; /* Executable code */
- grub_uint64_t text_offset; /* Image load offset */
- grub_uint64_t res0; /* reserved */
- grub_uint64_t res1; /* reserved */
+ grub_uint64_t text_offset; /* Image load offset, little endian */
+ grub_uint64_t image_size; /* Effective Image size, little endian */
+ grub_uint64_t flags; /* kernel flags, little endian */
+ grub_uint32_t version; /* Version of this header */
+ grub_uint32_t res1; /* reserved */
grub_uint64_t res2; /* reserved */
grub_uint64_t res3; /* reserved */
- grub_uint64_t res4; /* reserved */
- grub_uint32_t magic; /* Magic number, little endian, "RSCV" */
+ grub_uint32_t magic; /* Magic number, little endian, "RSC\x05" */
grub_uint32_t hdr_offset; /* Offset of PE/COFF header */
};
--
2.29.3
^ permalink raw reply related [flat|nested] 36+ messages in thread* [PATCH v2 7/7] RISC-V: Use common linux loader
2021-06-02 21:12 [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader Nikita Ermakov
` (5 preceding siblings ...)
2021-06-02 21:12 ` [PATCH v2 6/7] RISC-V: Update image header Nikita Ermakov
@ 2021-06-02 21:12 ` Nikita Ermakov
2021-06-26 18:07 ` [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader Andreas Schwab
` (2 subsequent siblings)
9 siblings, 0 replies; 36+ messages in thread
From: Nikita Ermakov @ 2021-06-02 21:12 UTC (permalink / raw)
To: GRUB development mailing list
Cc: Ard Biesheuvel, Atish Patra, Daniel Kiper, Heinrich Schuchardt,
Leif Lindholm, Nikita Ermakov, Atish Patra
From: Atish Patra <atish.patra@wdc.com>
RISC-V doesn't have to do anything very different from other architectures
to loader EFI stub linux kernel. As a result, just use the common linux
loader instead of defining a RISC-V specific linux loader.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
---
grub-core/Makefile.core.def | 4 +--
grub-core/loader/riscv/linux.c | 59 ----------------------------------
include/grub/riscv32/linux.h | 1 +
include/grub/riscv64/linux.h | 1 +
4 files changed, 4 insertions(+), 61 deletions(-)
delete mode 100644 grub-core/loader/riscv/linux.c
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index b36cf663a..0536575bc 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1809,8 +1809,8 @@ module = {
arm_efi = loader/efi/linux.c;
arm_uboot = loader/arm/linux.c;
arm64 = loader/efi/linux.c;
- riscv32 = loader/riscv/linux.c;
- riscv64 = loader/riscv/linux.c;
+ riscv32 = loader/efi/linux.c;
+ riscv64 = loader/efi/linux.c;
common = loader/linux.c;
common = lib/cmdline.c;
enable = noemu;
diff --git a/grub-core/loader/riscv/linux.c b/grub-core/loader/riscv/linux.c
deleted file mode 100644
index d17c488e1..000000000
--- a/grub-core/loader/riscv/linux.c
+++ /dev/null
@@ -1,59 +0,0 @@
-/*
- * GRUB -- GRand Unified Bootloader
- * Copyright (C) 2018 Free Software Foundation, Inc.
- *
- * GRUB is free software: you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation, either version 3 of the License, or
- * (at your option) any later version.
- *
- * GRUB is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with GRUB. If not, see <http://www.gnu.org/licenses/>.
- */
-
-#include <grub/command.h>
-#include <grub/dl.h>
-#include <grub/lib/cmdline.h>
-
-GRUB_MOD_LICENSE ("GPLv3+");
-
-static grub_err_t
-grub_cmd_initrd (grub_command_t cmd __attribute__ ((unused)),
- int argc __attribute__ ((unused)),
- char *argv[] __attribute__ ((unused)))
-{
- grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET, N_("Linux not supported yet"));
-
- return grub_errno;
-}
-
-static grub_err_t
-grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
- int argc __attribute__ ((unused)),
- char *argv[] __attribute__ ((unused)))
-{
- grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET, N_("Linux not supported yet"));
-
- return grub_errno;
-}
-
-static grub_command_t cmd_linux, cmd_initrd;
-
-GRUB_MOD_INIT (linux)
-{
- cmd_linux = grub_register_command ("linux", grub_cmd_linux, 0,
- N_("Load Linux."));
- cmd_initrd = grub_register_command ("initrd", grub_cmd_initrd, 0,
- N_("Load initrd."));
-}
-
-GRUB_MOD_FINI (linux)
-{
- grub_unregister_command (cmd_linux);
- grub_unregister_command (cmd_initrd);
-}
diff --git a/include/grub/riscv32/linux.h b/include/grub/riscv32/linux.h
index de0dbdcd1..706c69087 100644
--- a/include/grub/riscv32/linux.h
+++ b/include/grub/riscv32/linux.h
@@ -38,5 +38,6 @@ struct linux_riscv_kernel_header
};
#define linux_arch_kernel_header linux_riscv_kernel_header
+# define GRUB_LINUX_ARCH_MAGIC_SIGNATURE GRUB_LINUX_RISCV_MAGIC_SIGNATURE
#endif /* ! GRUB_RISCV32_LINUX_HEADER */
diff --git a/include/grub/riscv64/linux.h b/include/grub/riscv64/linux.h
index 7c28bc922..88d5df781 100644
--- a/include/grub/riscv64/linux.h
+++ b/include/grub/riscv64/linux.h
@@ -40,5 +40,6 @@ struct linux_riscv_kernel_header
};
#define linux_arch_kernel_header linux_riscv_kernel_header
+# define GRUB_LINUX_ARCH_MAGIC_SIGNATURE GRUB_LINUX_RISCV_MAGIC_SIGNATURE
#endif /* ! GRUB_RISCV64_LINUX_HEADER */
--
2.29.3
^ permalink raw reply related [flat|nested] 36+ messages in thread* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-06-02 21:12 [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader Nikita Ermakov
` (6 preceding siblings ...)
2021-06-02 21:12 ` [PATCH v2 7/7] RISC-V: Use common linux loader Nikita Ermakov
@ 2021-06-26 18:07 ` Andreas Schwab
2021-06-27 21:01 ` Heinrich Schuchardt
2021-08-27 16:22 ` Atish Patra
2021-10-08 17:46 ` Heinrich Schuchardt
9 siblings, 1 reply; 36+ messages in thread
From: Andreas Schwab @ 2021-06-26 18:07 UTC (permalink / raw)
To: Nikita Ermakov
Cc: GRUB development mailing list, Ard Biesheuvel, Atish Patra,
Daniel Kiper, Heinrich Schuchardt, Leif Lindholm
On Jun 03 2021, Nikita Ermakov wrote:
> This series contains patches to add support for LoadFile2 protocol to load
> initrd on EFI systems. Also it contains patches to load Linux kernel with EFI
> stub on riscv platforms and unites arm and riscv codes together into common
> loader code for EFI systems.
That doesn't work with a CD image. When I try to run
http://download.opensuse.org/ports/riscv/tumbleweed/iso/openSUSE-Tumbleweed-NET-riscv64-Media.iso
with qemu, the initrd fails to load.
$ qemu-system-riscv64 -M virt -nographic -serial mon:stdio -smp 4 -m 8g -kernel u-boot.bin -drive format=raw,if=virtio,media=cdrom,file=openSUSE-Tumbleweed-NET-riscv64-Media.iso
OpenSBI v0.9
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
Platform Name : riscv-virtio,qemu
Platform Features : timer,mfdeleg
Platform HART Count : 4
Firmware Base : 0x80000000
Firmware Size : 124 KB
Runtime SBI Version : 0.2
Domain0 Name : root
Domain0 Boot HART : 1
Domain0 HARTs : 0*,1*,2*,3*
Domain0 Region00 : 0x0000000080000000-0x000000008001ffff ()
Domain0 Region01 : 0x0000000000000000-0xffffffffffffffff (R,W,X)
Domain0 Next Address : 0x0000000080200000
Domain0 Next Arg1 : 0x00000000bf000000
Domain0 Next Mode : S-mode
Domain0 SysReset : yes
Boot HART ID : 1
Boot HART Domain : root
Boot HART ISA : rv64imafdcsu
Boot HART Features : scounteren,mcounteren,time
Boot HART PMP Count : 16
Boot HART PMP Granularity : 4
Boot HART PMP Address Bits: 54
Boot HART MHPM Count : 0
Boot HART MHPM Count : 0
Boot HART MIDELEG : 0x0000000000000222
Boot HART MEDELEG : 0x000000000000b109
U-Boot 2021.04 (Jun 09 2021 - 00:00:00 +0000)
CPU: rv64imafdcsu
Model: riscv-virtio,qemu
DRAM: 8 GiB
In: uart@10000000
Out: uart@10000000
Err: uart@10000000
Net: No ethernet found.
Hit any key to stop autoboot: 0
Device 0: 1af4 VirtIO Block Device
Type: Hard Disk
Capacity: 225.7 MB = 0.2 GB (462376 x 512)
... is now current device
** Invalid partition 3 **
** Invalid partition 4 **
** Invalid partition 2 **
Scanning virtio 0:1...
** Unable to read file / **
Failed to load '/'
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Scanning disk virtio-blk#8...
Found 2 disks
No EFI system partition
BootOrder not defined
EFI boot manager: Cannot load any image
Found EFI removable media binary efi/boot/bootriscv64.efi
2584576 bytes read in 3 ms (821.6 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Booting /efi\boot\bootriscv64.efi
Welcome to GRUB!
Please press 't' to show the boot menu on this console
error: ../../grub-core/video/video.c:761:no suitable video mode found.
openSUSE Tumbleweed
┌────────────────────────────────────────────────────────────────────────────┐
│ Boot from Hard Disk │
│*Installation │
│ Upgrade │
│ More ... │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
└────────────────────────────────────────────────────────────────────────────┘
Use the ▲ and ▼ keys to select which entry is highlighted.
Press enter to boot the selected OS, `e' to edit the commands
before booting or `c' for a command-line.
Loading kernel ...
Loading initial ramdisk ...
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: ERROR: Failed to load initrd!
EFI stub: Exiting boot services and installing virtual address map...
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-06-26 18:07 ` [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader Andreas Schwab
@ 2021-06-27 21:01 ` Heinrich Schuchardt
2021-06-27 22:07 ` Andreas Schwab
2021-06-28 21:24 ` Heinrich Schuchardt
0 siblings, 2 replies; 36+ messages in thread
From: Heinrich Schuchardt @ 2021-06-27 21:01 UTC (permalink / raw)
To: Andreas Schwab, Ard Biesheuvel
Cc: GRUB development mailing list, Atish Patra, Daniel Kiper,
Leif Lindholm, Nikita Ermakov, Ilias Apalodimas
On 6/26/21 8:07 PM, Andreas Schwab wrote:
> On Jun 03 2021, Nikita Ermakov wrote:
>
>> This series contains patches to add support for LoadFile2 protocol to load
>> initrd on EFI systems. Also it contains patches to load Linux kernel with EFI
>> stub on riscv platforms and unites arm and riscv codes together into common
>> loader code for EFI systems.
>
> That doesn't work with a CD image. When I try to run
> http://download.opensuse.org/ports/riscv/tumbleweed/iso/openSUSE-Tumbleweed-NET-riscv64-Media.iso
> with qemu, the initrd fails to load.
Please, indicate how you built u-boot.bin.
>
> $ qemu-system-riscv64 -M virt -nographic -serial mon:stdio -smp 4 -m 8g -kernel u-boot.bin -drive format=raw,if=virtio,media=cdrom,file=openSUSE-Tumbleweed-NET-riscv64-Media.iso
This command results in an error
qemu-system-riscv64: warning:
No -bios option specified. Not loading a firmware.
Please, provide a repo with the GRUB code you have been compiling.
>
> OpenSBI v0.9
> ____ _____ ____ _____
> / __ \ / ____| _ \_ _|
> | | | |_ __ ___ _ __ | (___ | |_) || |
> | | | | '_ \ / _ \ '_ \ \___ \| _ < | |
> | |__| | |_) | __/ | | |____) | |_) || |_
> \____/| .__/ \___|_| |_|_____/|____/_____|
> | |
> |_|
>
> Platform Name : riscv-virtio,qemu
> Platform Features : timer,mfdeleg
> Platform HART Count : 4
> Firmware Base : 0x80000000
> Firmware Size : 124 KB
> Runtime SBI Version : 0.2
>
> Domain0 Name : root
> Domain0 Boot HART : 1
> Domain0 HARTs : 0*,1*,2*,3*
> Domain0 Region00 : 0x0000000080000000-0x000000008001ffff ()
> Domain0 Region01 : 0x0000000000000000-0xffffffffffffffff (R,W,X)
> Domain0 Next Address : 0x0000000080200000
> Domain0 Next Arg1 : 0x00000000bf000000
> Domain0 Next Mode : S-mode
> Domain0 SysReset : yes
>
> Boot HART ID : 1
> Boot HART Domain : root
> Boot HART ISA : rv64imafdcsu
> Boot HART Features : scounteren,mcounteren,time
> Boot HART PMP Count : 16
> Boot HART PMP Granularity : 4
> Boot HART PMP Address Bits: 54
> Boot HART MHPM Count : 0
> Boot HART MHPM Count : 0
> Boot HART MIDELEG : 0x0000000000000222
> Boot HART MEDELEG : 0x000000000000b109
>
>
> U-Boot 2021.04 (Jun 09 2021 - 00:00:00 +0000)
>
> CPU: rv64imafdcsu
> Model: riscv-virtio,qemu
> DRAM: 8 GiB
> In: uart@10000000
> Out: uart@10000000
> Err: uart@10000000
> Net: No ethernet found.
> Hit any key to stop autoboot: 0
>
> Device 0: 1af4 VirtIO Block Device
> Type: Hard Disk
> Capacity: 225.7 MB = 0.2 GB (462376 x 512)
> ... is now current device
> ** Invalid partition 3 **
> ** Invalid partition 4 **
> ** Invalid partition 2 **
> Scanning virtio 0:1...
> ** Unable to read file / **
> Failed to load '/'
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> Scanning disk virtio-blk#8...
> Found 2 disks
> No EFI system partition
> BootOrder not defined
> EFI boot manager: Cannot load any image
> Found EFI removable media binary efi/boot/bootriscv64.efi
When I press 'e' in GRUB I see:
setparams 'Installation'
set gfxpayload=keep
echo 'Loading kernel ...'
linux /boot/riscv64/linux splash=silent
echo 'Loading
initial ramdisk ...'
initrd /boot/riscv64/initrd
With debug=all I get as output:
kern/verifiers.c:88: file: /boot/riscv64/initrd type: 131076
loader/efi/linux.c:368: LoadFile2 initrd loading protocol installed
With a bit of debugging enabled in U-Boot:
EFI: Call: image_obj->entry(image_handle, &systab)
EFI: Entry efi_open_protocol(00000000ff751310,
EFI_LOADED_IMAGE_PROTOCOL_GUID, 00000000ff73a6e0, 00000000ff750050,
0000000000000000, 0x1)
EFI: Exit: efi_open_protocol: 0
EFI stub: Booting Linux Kernel...
EFI: Entry efi_locate_handle_ext(2,
EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID, 0000000000000000, 00000000ff73a740,
0000000000000000)
EFI: Exit: efi_locate_handle_ext: 14
EFI: Entry efi_locate_protocol(EFI_TPM2_GUID, 0000000000000000,
00000000ff73a648)
EFI: Exit: efi_locate_protocol: 14
EFI stub: Using DTB from configuration table
EFI: Entry efi_locate_device_path(EFI_LOAD_FILE2_PROTOCOL_GUID,
00000000ff73a648, 00000000ff73a668)
EFI: Call: efi_locate_handle_buffer(BY_PROTOCOL, protocol,
NULL, &no_handles, &handles)
EFI: Entry efi_locate_handle_buffer(2,
EFI_LOAD_FILE2_PROTOCOL_GUID, 0000000000000000, 00000000ff73a5d8,
00000000ff73a5d0)
EFI: Exit: efi_locate_handle_buffer: 0
EFI: 0 returned by efi_locate_handle_buffer(BY_PROTOCOL,
protocol, NULL, &no_handles, &handles)
EFI: Exit: efi_locate_device_path: 0
EFI: Entry efi_open_protocol(00000000ff74c8b0,
EFI_LOAD_FILE2_PROTOCOL_GUID, 00000000ff73a650, 00000000ff750050,
0000000000000000, 0x1)
EFI: Exit: efi_open_protocol: 0
EFI: Exit: efi_open_protocol: 0
EFI: Entry efi_allocate_pages_ext(AllocateMaxAddress,
EfiLoaderData, 0xc024, 00000000ff73a618)
EFI: Exit: efi_allocate_pages_ext: 9 (EFI_OUT_OF_RESOURCES)
EFI stub: ERROR: Failed to load initrd!
The LOAD_FILE2 protocol was successfully opened on the handle ff74c8b0
where it was installed by GRUB.
*Allocating memory for the initrd fails.*
0xC024 pages are requested below 0x901fffff.
This is the memory map when the call is executed:
Type Start End Attributes
================ ================ ================ ==========
BOOT DATA 0000000100000000-0000000280000000 WB
LOADER DATA 00000000fff62000-0000000100000000 WB
RUNTIME CODE 00000000fff61000-00000000fff62000 WB|RT
LOADER DATA 00000000fe73f000-00000000fff61000 WB
BOOT DATA 00000000fe73d000-00000000fe73f000 WB
RESERVED 00000000fe73c000-00000000fe73d000 WB
BOOT DATA 00000000fe73a000-00000000fe73c000 WB
RESERVED 00000000fe739000-00000000fe73a000 WB
RUNTIME DATA 00000000fe735000-00000000fe739000 WB|RT
BOOT DATA 00000000fe734000-00000000fe735000 WB
RUNTIME DATA 00000000fe730000-00000000fe734000 WB|RT
BOOT DATA 00000000fe72f000-00000000fe730000 WB
RESERVED 00000000fe728000-00000000fe72f000 WB
LOADER CODE 00000000fe4aa000-00000000fe728000 WB
LOADER DATA 00000000fe4a9000-00000000fe4aa000 WB
BOOT DATA 00000000fe4a8000-00000000fe4a9000 WB
RESERVED 00000000fe4a6000-00000000fe4a8000 WB
LOADER DATA 00000000fe4a3000-00000000fe4a6000 WB
LOADER CODE 00000000deb8d000-00000000fe4a3000 WB
LOADER DATA 00000000dd620000-00000000deb8d000 WB
LOADER CODE 00000000dbfc3000-00000000dd620000 WB
BOOT DATA 00000000dbfc2000-00000000dbfc3000 WB
CONVENTIONAL 0000000087f05000-00000000dbfc2000 WB
ACPI RECLAIM MEM 0000000087efb000-0000000087f05000 WB
CONVENTIONAL 000000008185d000-0000000087efb000 WB
LOADER DATA 0000000080200000-000000008185d000 WB
CONVENTIONAL 0000000080040000-0000000080200000 WB
BOOT DATA 0000000080000000-0000000080040000 WB
0x901fffff - 0x1000 * 0xC024 = 0x841DBFFF
So U-Boot is correct in indicating that the memory is not available at
the required low address.
In Linux efi_load_initrd() is called with parameter hard_limit being the
'minimum size of allocated memory'. But this parameter is passed to
efi_load_initrd_dev_path() as 'upper limit for the initrd memory
allocation' and further to efi_allocate_pages() as 'the address that the
last allocated memory page shall not exceed'.
@Ard
Why does Linux require allocating the memory below 0x901fffff which is
the value of 'minimum size of allocated memory'? I think initrd can be
allocated anywhere in memory even above 4GiB.
Best regards
Heinrich
> 2584576 bytes read in 3 ms (821.6 MiB/s)
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> Booting /efi\boot\bootriscv64.efi
> Welcome to GRUB!
>
> Please press 't' to show the boot menu on this console
> error: ../../grub-core/video/video.c:761:no suitable video mode found.
>
>
> openSUSE Tumbleweed
>
> ┌────────────────────────────────────────────────────────────────────────────┐
> │ Boot from Hard Disk │
> │*Installation │
> │ Upgrade │
> │ More ... │
> │ │
> │ │
> │ │
> │ │
> │ │
> │ │
> │ │
> │ │
> │ │
> └────────────────────────────────────────────────────────────────────────────┘
>
> Use the ▲ and ▼ keys to select which entry is highlighted.
> Press enter to boot the selected OS, `e' to edit the commands
> before booting or `c' for a command-line.
>
> Loading kernel ...
> Loading initial ramdisk ...
> EFI stub: Booting Linux Kernel...
> EFI stub: Using DTB from configuration table
> EFI stub: ERROR: Failed to load initrd!
> EFI stub: Exiting boot services and installing virtual address map...
>
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-06-27 21:01 ` Heinrich Schuchardt
@ 2021-06-27 22:07 ` Andreas Schwab
2021-06-29 13:44 ` Heinrich Schuchardt
2021-06-28 21:24 ` Heinrich Schuchardt
1 sibling, 1 reply; 36+ messages in thread
From: Andreas Schwab @ 2021-06-27 22:07 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Ard Biesheuvel, GRUB development mailing list, Atish Patra,
Daniel Kiper, Leif Lindholm, Nikita Ermakov, Ilias Apalodimas
On Jun 27 2021, Heinrich Schuchardt wrote:
> On 6/26/21 8:07 PM, Andreas Schwab wrote:
>> On Jun 03 2021, Nikita Ermakov wrote:
>>
>>> This series contains patches to add support for LoadFile2 protocol to load
>>> initrd on EFI systems. Also it contains patches to load Linux kernel with EFI
>>> stub on riscv platforms and unites arm and riscv codes together into common
>>> loader code for EFI systems.
>>
>> That doesn't work with a CD image. When I try to run
>> http://download.opensuse.org/ports/riscv/tumbleweed/iso/openSUSE-Tumbleweed-NET-riscv64-Media.iso
>> with qemu, the initrd fails to load.
>
> Please, indicate how you built u-boot.bin.
With qemu-riscv64_smode_defconfig.
>> $ qemu-system-riscv64 -M virt -nographic -serial mon:stdio -smp 4 -m 8g -kernel u-boot.bin -drive format=raw,if=virtio,media=cdrom,file=openSUSE-Tumbleweed-NET-riscv64-Media.iso
>
> This command results in an error
>
> qemu-system-riscv64: warning:
> No -bios option specified. Not loading a firmware.
Looks like you use an old qemu. Nowadays it automatically loads opensbi
as firmware.
> Please, provide a repo with the GRUB code you have been compiling.
https://build.opensuse.org/package/show/openSUSE:Factory:RISCV/grub2
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-06-27 22:07 ` Andreas Schwab
@ 2021-06-29 13:44 ` Heinrich Schuchardt
2021-10-08 17:34 ` Heinrich Schuchardt
0 siblings, 1 reply; 36+ messages in thread
From: Heinrich Schuchardt @ 2021-06-29 13:44 UTC (permalink / raw)
To: Andreas Schwab
Cc: GRUB development mailing list, Atish Patra, Daniel Kiper,
Leif Lindholm, Nikita Ermakov, Ilias Apalodimas, Ard Biesheuvel
On 6/28/21 12:07 AM, Andreas Schwab wrote:
> On Jun 27 2021, Heinrich Schuchardt wrote:
>
>> On 6/26/21 8:07 PM, Andreas Schwab wrote:
>>> On Jun 03 2021, Nikita Ermakov wrote:
>>>
>>>> This series contains patches to add support for LoadFile2 protocol to load
>>>> initrd on EFI systems. Also it contains patches to load Linux kernel with EFI
>>>> stub on riscv platforms and unites arm and riscv codes together into common
>>>> loader code for EFI systems.
>>>
>>> That doesn't work with a CD image. When I try to run
>>> http://download.opensuse.org/ports/riscv/tumbleweed/iso/openSUSE-Tumbleweed-NET-riscv64-Media.iso
>>> with qemu, the initrd fails to load.
>>
>> Please, indicate how you built u-boot.bin.
>
> With qemu-riscv64_smode_defconfig.
>
>>> $ qemu-system-riscv64 -M virt -nographic -serial mon:stdio -smp 4 -m 8g -kernel u-boot.bin -drive format=raw,if=virtio,media=cdrom,file=openSUSE-Tumbleweed-NET-riscv64-Media.iso
>>
>> This command results in an error
>>
>> qemu-system-riscv64: warning:
>> No -bios option specified. Not loading a firmware.
>
> Looks like you use an old qemu. Nowadays it automatically loads opensbi
> as firmware.
>
>> Please, provide a repo with the GRUB code you have been compiling.
>
> https://build.opensuse.org/package/show/openSUSE:Factory:RISCV/grub2
>
> Andreas.
>
See
[PATCH 1/1] RISC-V: load initrd wherever it fits into memory
https://lore.kernel.org/linux-riscv/20210629134018.62859-1-xypron.glpk@gmx.de/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-06-29 13:44 ` Heinrich Schuchardt
@ 2021-10-08 17:34 ` Heinrich Schuchardt
0 siblings, 0 replies; 36+ messages in thread
From: Heinrich Schuchardt @ 2021-10-08 17:34 UTC (permalink / raw)
To: Andreas Schwab
Cc: GRUB development mailing list, Atish Patra, Daniel Kiper,
Leif Lindholm, Nikita Ermakov, Ilias Apalodimas, Ard Biesheuvel
On 6/29/21 15:44, Heinrich Schuchardt wrote:
> On 6/28/21 12:07 AM, Andreas Schwab wrote:
>> On Jun 27 2021, Heinrich Schuchardt wrote:
>>
>>> On 6/26/21 8:07 PM, Andreas Schwab wrote:
>>>> On Jun 03 2021, Nikita Ermakov wrote:
>>>>
>>>>> This series contains patches to add support for LoadFile2 protocol
>>>>> to load
>>>>> initrd on EFI systems. Also it contains patches to load Linux
>>>>> kernel with EFI
>>>>> stub on riscv platforms and unites arm and riscv codes together
>>>>> into common
>>>>> loader code for EFI systems.
>>>>
>>>> That doesn't work with a CD image. When I try to run
>>>> http://download.opensuse.org/ports/riscv/tumbleweed/iso/openSUSE-Tumbleweed-NET-riscv64-Media.iso
>>>>
>>>> with qemu, the initrd fails to load.
>>>
>>> Please, indicate how you built u-boot.bin.
>>
>> With qemu-riscv64_smode_defconfig.
>>
>>>> $ qemu-system-riscv64 -M virt -nographic -serial mon:stdio -smp 4 -m
>>>> 8g -kernel u-boot.bin -drive
>>>> format=raw,if=virtio,media=cdrom,file=openSUSE-Tumbleweed-NET-riscv64-Media.iso
>>>>
>>>
>>> This command results in an error
>>>
>>> qemu-system-riscv64: warning:
>>> No -bios option specified. Not loading a firmware.
>>
>> Looks like you use an old qemu. Nowadays it automatically loads opensbi
>> as firmware.
>>
>>> Please, provide a repo with the GRUB code you have been compiling.
>>
>> https://build.opensuse.org/package/show/openSUSE:Factory:RISCV/grub2
>>
>> Andreas.
>>
>
> See
> [PATCH 1/1] RISC-V: load initrd wherever it fits into memory
> https://lore.kernel.org/linux-riscv/20210629134018.62859-1-xypron.glpk@gmx.de/
>
With
http://download.opensuse.org/ports/riscv/tumbleweed/iso/openSUSE-Tumbleweed-DVD-riscv64-Build809.3-Media.iso
the error does not occur anymore. It uses Linux version 5.14.6 which
contains the aforementioned patch. So we can mark this issue as closed.
Best regards
Heinrich
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-06-27 21:01 ` Heinrich Schuchardt
2021-06-27 22:07 ` Andreas Schwab
@ 2021-06-28 21:24 ` Heinrich Schuchardt
2021-06-29 19:13 ` Atish Patra
1 sibling, 1 reply; 36+ messages in thread
From: Heinrich Schuchardt @ 2021-06-28 21:24 UTC (permalink / raw)
To: Andreas Schwab
Cc: GRUB development mailing list, Atish Patra, Daniel Kiper,
Leif Lindholm, Nikita Ermakov, Ilias Apalodimas, Ard Biesheuvel
+cc Ard Biesheuvel <ardb@kernel.org>
Ard, please see question for you below.
On 6/27/21 11:01 PM, Heinrich Schuchardt wrote:
> On 6/26/21 8:07 PM, Andreas Schwab wrote:
>> On Jun 03 2021, Nikita Ermakov wrote:
>>
>>> This series contains patches to add support for LoadFile2 protocol to
>>> load
>>> initrd on EFI systems. Also it contains patches to load Linux kernel
>>> with EFI
>>> stub on riscv platforms and unites arm and riscv codes together into
>>> common
>>> loader code for EFI systems.
>>
>> That doesn't work with a CD image. When I try to run
>> http://download.opensuse.org/ports/riscv/tumbleweed/iso/openSUSE-Tumbleweed-NET-riscv64-Media.iso
>>
>> with qemu, the initrd fails to load.
>
> Please, indicate how you built u-boot.bin.
>
>>
>> $ qemu-system-riscv64 -M virt -nographic -serial mon:stdio -smp 4 -m
>> 8g -kernel u-boot.bin -drive
>> format=raw,if=virtio,media=cdrom,file=openSUSE-Tumbleweed-NET-riscv64-Media.iso
>>
>
> This command results in an error
>
> qemu-system-riscv64: warning:
> No -bios option specified. Not loading a firmware.
>
> Please, provide a repo with the GRUB code you have been compiling.
>
>>
>> OpenSBI v0.9
>> ____ _____ ____ _____
>> / __ \ / ____| _ \_ _|
>> | | | |_ __ ___ _ __ | (___ | |_) || |
>> | | | | '_ \ / _ \ '_ \ \___ \| _ < | |
>> | |__| | |_) | __/ | | |____) | |_) || |_
>> \____/| .__/ \___|_| |_|_____/|____/_____|
>> | |
>> |_|
>>
>> Platform Name : riscv-virtio,qemu
>> Platform Features : timer,mfdeleg
>> Platform HART Count : 4
>> Firmware Base : 0x80000000
>> Firmware Size : 124 KB
>> Runtime SBI Version : 0.2
>>
>> Domain0 Name : root
>> Domain0 Boot HART : 1
>> Domain0 HARTs : 0*,1*,2*,3*
>> Domain0 Region00 : 0x0000000080000000-0x000000008001ffff ()
>> Domain0 Region01 : 0x0000000000000000-0xffffffffffffffff (R,W,X)
>> Domain0 Next Address : 0x0000000080200000
>> Domain0 Next Arg1 : 0x00000000bf000000
>> Domain0 Next Mode : S-mode
>> Domain0 SysReset : yes
>>
>> Boot HART ID : 1
>> Boot HART Domain : root
>> Boot HART ISA : rv64imafdcsu
>> Boot HART Features : scounteren,mcounteren,time
>> Boot HART PMP Count : 16
>> Boot HART PMP Granularity : 4
>> Boot HART PMP Address Bits: 54
>> Boot HART MHPM Count : 0
>> Boot HART MHPM Count : 0
>> Boot HART MIDELEG : 0x0000000000000222
>> Boot HART MEDELEG : 0x000000000000b109
>>
>>
>> U-Boot 2021.04 (Jun 09 2021 - 00:00:00 +0000)
>>
>> CPU: rv64imafdcsu
>> Model: riscv-virtio,qemu
>> DRAM: 8 GiB
>> In: uart@10000000
>> Out: uart@10000000
>> Err: uart@10000000
>> Net: No ethernet found.
>> Hit any key to stop autoboot: 0
>>
>> Device 0: 1af4 VirtIO Block Device
>> Type: Hard Disk
>> Capacity: 225.7 MB = 0.2 GB (462376 x 512)
>> ... is now current device
>> ** Invalid partition 3 **
>> ** Invalid partition 4 **
>> ** Invalid partition 2 **
>> Scanning virtio 0:1...
>> ** Unable to read file / **
>> Failed to load '/'
>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>> Scanning disk virtio-blk#8...
>> Found 2 disks
>> No EFI system partition
>> BootOrder not defined
>> EFI boot manager: Cannot load any image
>> Found EFI removable media binary efi/boot/bootriscv64.efi
>
> When I press 'e' in GRUB I see:
>
> setparams 'Installation'
> set gfxpayload=keep
> echo 'Loading kernel ...'
> linux /boot/riscv64/linux splash=silent
> echo 'Loading
> initial ramdisk ...' initrd
> /boot/riscv64/initrd
>
> With debug=all I get as output:
>
> kern/verifiers.c:88: file: /boot/riscv64/initrd type: 131076
> loader/efi/linux.c:368: LoadFile2 initrd loading protocol installed
>
> With a bit of debugging enabled in U-Boot:
>
> EFI: Call: image_obj->entry(image_handle, &systab)
> EFI: Entry efi_open_protocol(00000000ff751310,
> EFI_LOADED_IMAGE_PROTOCOL_GUID, 00000000ff73a6e0, 00000000ff750050,
> 0000000000000000, 0x1)
> EFI: Exit: efi_open_protocol: 0
> EFI stub: Booting Linux Kernel...
> EFI: Entry efi_locate_handle_ext(2,
> EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID, 0000000000000000, 00000000ff73a740,
> 0000000000000000)
> EFI: Exit: efi_locate_handle_ext: 14
> EFI: Entry efi_locate_protocol(EFI_TPM2_GUID, 0000000000000000,
> 00000000ff73a648)
> EFI: Exit: efi_locate_protocol: 14
> EFI stub: Using DTB from configuration table
> EFI: Entry efi_locate_device_path(EFI_LOAD_FILE2_PROTOCOL_GUID,
> 00000000ff73a648, 00000000ff73a668)
> EFI: Call: efi_locate_handle_buffer(BY_PROTOCOL, protocol,
> NULL, &no_handles, &handles)
> EFI: Entry efi_locate_handle_buffer(2,
> EFI_LOAD_FILE2_PROTOCOL_GUID, 0000000000000000, 00000000ff73a5d8,
> 00000000ff73a5d0)
> EFI: Exit: efi_locate_handle_buffer: 0
> EFI: 0 returned by efi_locate_handle_buffer(BY_PROTOCOL,
> protocol, NULL, &no_handles, &handles)
> EFI: Exit: efi_locate_device_path: 0
> EFI: Entry efi_open_protocol(00000000ff74c8b0,
> EFI_LOAD_FILE2_PROTOCOL_GUID, 00000000ff73a650, 00000000ff750050,
> 0000000000000000, 0x1)
> EFI: Exit: efi_open_protocol: 0
> EFI: Exit: efi_open_protocol: 0
> EFI: Entry efi_allocate_pages_ext(AllocateMaxAddress,
> EfiLoaderData, 0xc024, 00000000ff73a618)
> EFI: Exit: efi_allocate_pages_ext: 9 (EFI_OUT_OF_RESOURCES)
>
> EFI stub: ERROR: Failed to load initrd!
>
> The LOAD_FILE2 protocol was successfully opened on the handle ff74c8b0
> where it was installed by GRUB.
>
> *Allocating memory for the initrd fails.*
>
> 0xC024 pages are requested below 0x901fffff.
>
> This is the memory map when the call is executed:
>
> Type Start End Attributes
> ================ ================ ================ ==========
> BOOT DATA 0000000100000000-0000000280000000 WB
> LOADER DATA 00000000fff62000-0000000100000000 WB
> RUNTIME CODE 00000000fff61000-00000000fff62000 WB|RT
> LOADER DATA 00000000fe73f000-00000000fff61000 WB
> BOOT DATA 00000000fe73d000-00000000fe73f000 WB
> RESERVED 00000000fe73c000-00000000fe73d000 WB
> BOOT DATA 00000000fe73a000-00000000fe73c000 WB
> RESERVED 00000000fe739000-00000000fe73a000 WB
> RUNTIME DATA 00000000fe735000-00000000fe739000 WB|RT
> BOOT DATA 00000000fe734000-00000000fe735000 WB
> RUNTIME DATA 00000000fe730000-00000000fe734000 WB|RT
> BOOT DATA 00000000fe72f000-00000000fe730000 WB
> RESERVED 00000000fe728000-00000000fe72f000 WB
> LOADER CODE 00000000fe4aa000-00000000fe728000 WB
> LOADER DATA 00000000fe4a9000-00000000fe4aa000 WB
> BOOT DATA 00000000fe4a8000-00000000fe4a9000 WB
> RESERVED 00000000fe4a6000-00000000fe4a8000 WB
> LOADER DATA 00000000fe4a3000-00000000fe4a6000 WB
> LOADER CODE 00000000deb8d000-00000000fe4a3000 WB
> LOADER DATA 00000000dd620000-00000000deb8d000 WB
> LOADER CODE 00000000dbfc3000-00000000dd620000 WB
> BOOT DATA 00000000dbfc2000-00000000dbfc3000 WB
> CONVENTIONAL 0000000087f05000-00000000dbfc2000 WB
> ACPI RECLAIM MEM 0000000087efb000-0000000087f05000 WB
> CONVENTIONAL 000000008185d000-0000000087efb000 WB
> LOADER DATA 0000000080200000-000000008185d000 WB
> CONVENTIONAL 0000000080040000-0000000080200000 WB
> BOOT DATA 0000000080000000-0000000080040000 WB
>
> 0x901fffff - 0x1000 * 0xC024 = 0x841DBFFF
>
> So U-Boot is correct in indicating that the memory is not available at
> the required low address.
>
> In Linux efi_load_initrd() is called with parameter hard_limit being the
> 'minimum size of allocated memory'. But this parameter is passed to
> efi_load_initrd_dev_path() as 'upper limit for the initrd memory
> allocation' and further to efi_allocate_pages() as 'the address that the
> last allocated memory page shall not exceed'.
>
> @Ard
> Why does Linux require allocating the memory below 0x901fffff which is
> the value of 'minimum size of allocated memory'? I think initrd can be
> allocated anywhere in memory even above 4GiB.
>
> Best regards
>
> Heinrich
>
>> 2584576 bytes read in 3 ms (821.6 MiB/s)
>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>> Booting /efi\boot\bootriscv64.efi
>> Welcome to GRUB!
>>
>> Please press 't' to show the boot menu on this console
>> error: ../../grub-core/video/video.c:761:no suitable video mode found.
>>
>>
>> openSUSE Tumbleweed
>>
>>
>> ┌────────────────────────────────────────────────────────────────────────────┐
>>
>> │ Boot from Hard
>> Disk │
>>
>> │*Installation
>> │
>> │
>> Upgrade
>> │
>> │ More
>> ... │
>>
>> │
>> │
>>
>> │
>> │
>>
>> │
>> │
>>
>> │
>> │
>>
>> │
>> │
>>
>> │
>> │
>>
>> │
>> │
>>
>> │
>> │
>>
>> │
>> │
>>
>> └────────────────────────────────────────────────────────────────────────────┘
>>
>>
>> Use the ▲ and ▼ keys to select which entry is highlighted.
>> Press enter to boot the selected OS, `e' to edit the commands
>> before booting or `c' for a command-line.
>>
>> Loading kernel ...
>> Loading initial ramdisk ...
>> EFI stub: Booting Linux Kernel...
>> EFI stub: Using DTB from configuration table
>> EFI stub: ERROR: Failed to load initrd!
>> EFI stub: Exiting boot services and installing virtual address map...
>>
>
>
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-06-28 21:24 ` Heinrich Schuchardt
@ 2021-06-29 19:13 ` Atish Patra
2021-06-30 7:26 ` Ard Biesheuvel
0 siblings, 1 reply; 36+ messages in thread
From: Atish Patra @ 2021-06-29 19:13 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Andreas Schwab, Atish Patra, Daniel Kiper, Leif Lindholm,
Nikita Ermakov, Ilias Apalodimas, Ard Biesheuvel
On Mon, Jun 28, 2021 at 2:24 PM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
>
> +cc Ard Biesheuvel <ardb@kernel.org>
>
> Ard, please see question for you below.
>
> On 6/27/21 11:01 PM, Heinrich Schuchardt wrote:
> > On 6/26/21 8:07 PM, Andreas Schwab wrote:
> >> On Jun 03 2021, Nikita Ermakov wrote:
> >>
> >>> This series contains patches to add support for LoadFile2 protocol to
> >>> load
> >>> initrd on EFI systems. Also it contains patches to load Linux kernel
> >>> with EFI
> >>> stub on riscv platforms and unites arm and riscv codes together into
> >>> common
> >>> loader code for EFI systems.
> >>
> >> That doesn't work with a CD image. When I try to run
> >> http://download.opensuse.org/ports/riscv/tumbleweed/iso/openSUSE-Tumbleweed-NET-riscv64-Media.iso
> >>
> >> with qemu, the initrd fails to load.
> >
> > Please, indicate how you built u-boot.bin.
> >
> >>
> >> $ qemu-system-riscv64 -M virt -nographic -serial mon:stdio -smp 4 -m
> >> 8g -kernel u-boot.bin -drive
> >> format=raw,if=virtio,media=cdrom,file=openSUSE-Tumbleweed-NET-riscv64-Media.iso
> >>
> >
> > This command results in an error
> >
> > qemu-system-riscv64: warning:
> > No -bios option specified. Not loading a firmware.
> >
> > Please, provide a repo with the GRUB code you have been compiling.
> >
> >>
> >> OpenSBI v0.9
> >> ____ _____ ____ _____
> >> / __ \ / ____| _ \_ _|
> >> | | | |_ __ ___ _ __ | (___ | |_) || |
> >> | | | | '_ \ / _ \ '_ \ \___ \| _ < | |
> >> | |__| | |_) | __/ | | |____) | |_) || |_
> >> \____/| .__/ \___|_| |_|_____/|____/_____|
> >> | |
> >> |_|
> >>
> >> Platform Name : riscv-virtio,qemu
> >> Platform Features : timer,mfdeleg
> >> Platform HART Count : 4
> >> Firmware Base : 0x80000000
> >> Firmware Size : 124 KB
> >> Runtime SBI Version : 0.2
> >>
> >> Domain0 Name : root
> >> Domain0 Boot HART : 1
> >> Domain0 HARTs : 0*,1*,2*,3*
> >> Domain0 Region00 : 0x0000000080000000-0x000000008001ffff ()
> >> Domain0 Region01 : 0x0000000000000000-0xffffffffffffffff (R,W,X)
> >> Domain0 Next Address : 0x0000000080200000
> >> Domain0 Next Arg1 : 0x00000000bf000000
> >> Domain0 Next Mode : S-mode
> >> Domain0 SysReset : yes
> >>
> >> Boot HART ID : 1
> >> Boot HART Domain : root
> >> Boot HART ISA : rv64imafdcsu
> >> Boot HART Features : scounteren,mcounteren,time
> >> Boot HART PMP Count : 16
> >> Boot HART PMP Granularity : 4
> >> Boot HART PMP Address Bits: 54
> >> Boot HART MHPM Count : 0
> >> Boot HART MHPM Count : 0
> >> Boot HART MIDELEG : 0x0000000000000222
> >> Boot HART MEDELEG : 0x000000000000b109
> >>
> >>
> >> U-Boot 2021.04 (Jun 09 2021 - 00:00:00 +0000)
> >>
> >> CPU: rv64imafdcsu
> >> Model: riscv-virtio,qemu
> >> DRAM: 8 GiB
> >> In: uart@10000000
> >> Out: uart@10000000
> >> Err: uart@10000000
> >> Net: No ethernet found.
> >> Hit any key to stop autoboot: 0
> >>
> >> Device 0: 1af4 VirtIO Block Device
> >> Type: Hard Disk
> >> Capacity: 225.7 MB = 0.2 GB (462376 x 512)
> >> ... is now current device
> >> ** Invalid partition 3 **
> >> ** Invalid partition 4 **
> >> ** Invalid partition 2 **
> >> Scanning virtio 0:1...
> >> ** Unable to read file / **
> >> Failed to load '/'
> >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> >> Scanning disk virtio-blk#8...
> >> Found 2 disks
> >> No EFI system partition
> >> BootOrder not defined
> >> EFI boot manager: Cannot load any image
> >> Found EFI removable media binary efi/boot/bootriscv64.efi
> >
> > When I press 'e' in GRUB I see:
> >
> > setparams 'Installation'
> > set gfxpayload=keep
> > echo 'Loading kernel ...'
> > linux /boot/riscv64/linux splash=silent
> > echo 'Loading
> > initial ramdisk ...' initrd
> > /boot/riscv64/initrd
> >
> > With debug=all I get as output:
> >
> > kern/verifiers.c:88: file: /boot/riscv64/initrd type: 131076
> > loader/efi/linux.c:368: LoadFile2 initrd loading protocol installed
> >
> > With a bit of debugging enabled in U-Boot:
> >
> > EFI: Call: image_obj->entry(image_handle, &systab)
> > EFI: Entry efi_open_protocol(00000000ff751310,
> > EFI_LOADED_IMAGE_PROTOCOL_GUID, 00000000ff73a6e0, 00000000ff750050,
> > 0000000000000000, 0x1)
> > EFI: Exit: efi_open_protocol: 0
> > EFI stub: Booting Linux Kernel...
> > EFI: Entry efi_locate_handle_ext(2,
> > EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID, 0000000000000000, 00000000ff73a740,
> > 0000000000000000)
> > EFI: Exit: efi_locate_handle_ext: 14
> > EFI: Entry efi_locate_protocol(EFI_TPM2_GUID, 0000000000000000,
> > 00000000ff73a648)
> > EFI: Exit: efi_locate_protocol: 14
> > EFI stub: Using DTB from configuration table
> > EFI: Entry efi_locate_device_path(EFI_LOAD_FILE2_PROTOCOL_GUID,
> > 00000000ff73a648, 00000000ff73a668)
> > EFI: Call: efi_locate_handle_buffer(BY_PROTOCOL, protocol,
> > NULL, &no_handles, &handles)
> > EFI: Entry efi_locate_handle_buffer(2,
> > EFI_LOAD_FILE2_PROTOCOL_GUID, 0000000000000000, 00000000ff73a5d8,
> > 00000000ff73a5d0)
> > EFI: Exit: efi_locate_handle_buffer: 0
> > EFI: 0 returned by efi_locate_handle_buffer(BY_PROTOCOL,
> > protocol, NULL, &no_handles, &handles)
> > EFI: Exit: efi_locate_device_path: 0
> > EFI: Entry efi_open_protocol(00000000ff74c8b0,
> > EFI_LOAD_FILE2_PROTOCOL_GUID, 00000000ff73a650, 00000000ff750050,
> > 0000000000000000, 0x1)
> > EFI: Exit: efi_open_protocol: 0
> > EFI: Exit: efi_open_protocol: 0
> > EFI: Entry efi_allocate_pages_ext(AllocateMaxAddress,
> > EfiLoaderData, 0xc024, 00000000ff73a618)
> > EFI: Exit: efi_allocate_pages_ext: 9 (EFI_OUT_OF_RESOURCES)
> >
> > EFI stub: ERROR: Failed to load initrd!
> >
> > The LOAD_FILE2 protocol was successfully opened on the handle ff74c8b0
> > where it was installed by GRUB.
> >
> > *Allocating memory for the initrd fails.*
> >
> > 0xC024 pages are requested below 0x901fffff.
> >
> > This is the memory map when the call is executed:
> >
> > Type Start End Attributes
> > ================ ================ ================ ==========
> > BOOT DATA 0000000100000000-0000000280000000 WB
> > LOADER DATA 00000000fff62000-0000000100000000 WB
> > RUNTIME CODE 00000000fff61000-00000000fff62000 WB|RT
> > LOADER DATA 00000000fe73f000-00000000fff61000 WB
> > BOOT DATA 00000000fe73d000-00000000fe73f000 WB
> > RESERVED 00000000fe73c000-00000000fe73d000 WB
> > BOOT DATA 00000000fe73a000-00000000fe73c000 WB
> > RESERVED 00000000fe739000-00000000fe73a000 WB
> > RUNTIME DATA 00000000fe735000-00000000fe739000 WB|RT
> > BOOT DATA 00000000fe734000-00000000fe735000 WB
> > RUNTIME DATA 00000000fe730000-00000000fe734000 WB|RT
> > BOOT DATA 00000000fe72f000-00000000fe730000 WB
> > RESERVED 00000000fe728000-00000000fe72f000 WB
> > LOADER CODE 00000000fe4aa000-00000000fe728000 WB
> > LOADER DATA 00000000fe4a9000-00000000fe4aa000 WB
> > BOOT DATA 00000000fe4a8000-00000000fe4a9000 WB
> > RESERVED 00000000fe4a6000-00000000fe4a8000 WB
> > LOADER DATA 00000000fe4a3000-00000000fe4a6000 WB
> > LOADER CODE 00000000deb8d000-00000000fe4a3000 WB
> > LOADER DATA 00000000dd620000-00000000deb8d000 WB
> > LOADER CODE 00000000dbfc3000-00000000dd620000 WB
> > BOOT DATA 00000000dbfc2000-00000000dbfc3000 WB
> > CONVENTIONAL 0000000087f05000-00000000dbfc2000 WB
> > ACPI RECLAIM MEM 0000000087efb000-0000000087f05000 WB
> > CONVENTIONAL 000000008185d000-0000000087efb000 WB
> > LOADER DATA 0000000080200000-000000008185d000 WB
> > CONVENTIONAL 0000000080040000-0000000080200000 WB
> > BOOT DATA 0000000080000000-0000000080040000 WB
> >
> > 0x901fffff - 0x1000 * 0xC024 = 0x841DBFFF
> >
> > So U-Boot is correct in indicating that the memory is not available at
> > the required low address.
> >
> > In Linux efi_load_initrd() is called with parameter hard_limit being the
> > 'minimum size of allocated memory'. But this parameter is passed to
The function comment header should be updated to reflect the correct usage. No ?
> > efi_load_initrd_dev_path() as 'upper limit for the initrd memory
> > allocation' and further to efi_allocate_pages() as 'the address that the
> > last allocated memory page shall not exceed'.
> >
> > @Ard
> > Why does Linux require allocating the memory below 0x901fffff which is
> > the value of 'minimum size of allocated memory'? I think initrd can be
> > allocated anywhere in memory even above 4GiB.
> >
That should be fine. I think this bug was present during initial
porting but never got exposed because I never used
such a big initrd. Thanks for providing the fix.
> > Best regards
> >
> > Heinrich
> >
> >> 2584576 bytes read in 3 ms (821.6 MiB/s)
> >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> >> Booting /efi\boot\bootriscv64.efi
> >> Welcome to GRUB!
> >>
> >> Please press 't' to show the boot menu on this console
> >> error: ../../grub-core/video/video.c:761:no suitable video mode found.
> >>
> >>
> >> openSUSE Tumbleweed
> >>
> >>
> >> ┌────────────────────────────────────────────────────────────────────────────┐
> >>
> >> │ Boot from Hard
> >> Disk │
> >>
> >> │*Installation
> >> │
> >> │
> >> Upgrade
> >> │
> >> │ More
> >> ... │
> >>
> >> │
> >> │
> >>
> >> │
> >> │
> >>
> >> │
> >> │
> >>
> >> │
> >> │
> >>
> >> │
> >> │
> >>
> >> │
> >> │
> >>
> >> │
> >> │
> >>
> >> │
> >> │
> >>
> >> │
> >> │
> >>
> >> └────────────────────────────────────────────────────────────────────────────┘
> >>
> >>
> >> Use the ▲ and ▼ keys to select which entry is highlighted.
> >> Press enter to boot the selected OS, `e' to edit the commands
> >> before booting or `c' for a command-line.
> >>
> >> Loading kernel ...
> >> Loading initial ramdisk ...
> >> EFI stub: Booting Linux Kernel...
> >> EFI stub: Using DTB from configuration table
> >> EFI stub: ERROR: Failed to load initrd!
> >> EFI stub: Exiting boot services and installing virtual address map...
> >>
> >
> >
> >
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards,
Atish
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-06-29 19:13 ` Atish Patra
@ 2021-06-30 7:26 ` Ard Biesheuvel
2021-07-02 18:48 ` Atish Patra
0 siblings, 1 reply; 36+ messages in thread
From: Ard Biesheuvel @ 2021-06-30 7:26 UTC (permalink / raw)
To: Atish Patra
Cc: The development of GNU GRUB, Andreas Schwab, Atish Patra,
Daniel Kiper, Leif Lindholm, Nikita Ermakov, Ilias Apalodimas
On Tue, 29 Jun 2021 at 21:13, Atish Patra <atishp@atishpatra.org> wrote:
>
> On Mon, Jun 28, 2021 at 2:24 PM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >
> >
> > +cc Ard Biesheuvel <ardb@kernel.org>
> >
> > Ard, please see question for you below.
> >
> > On 6/27/21 11:01 PM, Heinrich Schuchardt wrote:
> > > On 6/26/21 8:07 PM, Andreas Schwab wrote:
> > >> On Jun 03 2021, Nikita Ermakov wrote:
> > >>
> > >>> This series contains patches to add support for LoadFile2 protocol to
> > >>> load
> > >>> initrd on EFI systems. Also it contains patches to load Linux kernel
> > >>> with EFI
> > >>> stub on riscv platforms and unites arm and riscv codes together into
> > >>> common
> > >>> loader code for EFI systems.
> > >>
> > >> That doesn't work with a CD image. When I try to run
> > >> http://download.opensuse.org/ports/riscv/tumbleweed/iso/openSUSE-Tumbleweed-NET-riscv64-Media.iso
> > >>
> > >> with qemu, the initrd fails to load.
> > >
> > > Please, indicate how you built u-boot.bin.
> > >
> > >>
> > >> $ qemu-system-riscv64 -M virt -nographic -serial mon:stdio -smp 4 -m
> > >> 8g -kernel u-boot.bin -drive
> > >> format=raw,if=virtio,media=cdrom,file=openSUSE-Tumbleweed-NET-riscv64-Media.iso
> > >>
> > >
> > > This command results in an error
> > >
> > > qemu-system-riscv64: warning:
> > > No -bios option specified. Not loading a firmware.
> > >
> > > Please, provide a repo with the GRUB code you have been compiling.
> > >
> > >>
> > >> OpenSBI v0.9
> > >> ____ _____ ____ _____
> > >> / __ \ / ____| _ \_ _|
> > >> | | | |_ __ ___ _ __ | (___ | |_) || |
> > >> | | | | '_ \ / _ \ '_ \ \___ \| _ < | |
> > >> | |__| | |_) | __/ | | |____) | |_) || |_
> > >> \____/| .__/ \___|_| |_|_____/|____/_____|
> > >> | |
> > >> |_|
> > >>
> > >> Platform Name : riscv-virtio,qemu
> > >> Platform Features : timer,mfdeleg
> > >> Platform HART Count : 4
> > >> Firmware Base : 0x80000000
> > >> Firmware Size : 124 KB
> > >> Runtime SBI Version : 0.2
> > >>
> > >> Domain0 Name : root
> > >> Domain0 Boot HART : 1
> > >> Domain0 HARTs : 0*,1*,2*,3*
> > >> Domain0 Region00 : 0x0000000080000000-0x000000008001ffff ()
> > >> Domain0 Region01 : 0x0000000000000000-0xffffffffffffffff (R,W,X)
> > >> Domain0 Next Address : 0x0000000080200000
> > >> Domain0 Next Arg1 : 0x00000000bf000000
> > >> Domain0 Next Mode : S-mode
> > >> Domain0 SysReset : yes
> > >>
> > >> Boot HART ID : 1
> > >> Boot HART Domain : root
> > >> Boot HART ISA : rv64imafdcsu
> > >> Boot HART Features : scounteren,mcounteren,time
> > >> Boot HART PMP Count : 16
> > >> Boot HART PMP Granularity : 4
> > >> Boot HART PMP Address Bits: 54
> > >> Boot HART MHPM Count : 0
> > >> Boot HART MHPM Count : 0
> > >> Boot HART MIDELEG : 0x0000000000000222
> > >> Boot HART MEDELEG : 0x000000000000b109
> > >>
> > >>
> > >> U-Boot 2021.04 (Jun 09 2021 - 00:00:00 +0000)
> > >>
> > >> CPU: rv64imafdcsu
> > >> Model: riscv-virtio,qemu
> > >> DRAM: 8 GiB
> > >> In: uart@10000000
> > >> Out: uart@10000000
> > >> Err: uart@10000000
> > >> Net: No ethernet found.
> > >> Hit any key to stop autoboot: 0
> > >>
> > >> Device 0: 1af4 VirtIO Block Device
> > >> Type: Hard Disk
> > >> Capacity: 225.7 MB = 0.2 GB (462376 x 512)
> > >> ... is now current device
> > >> ** Invalid partition 3 **
> > >> ** Invalid partition 4 **
> > >> ** Invalid partition 2 **
> > >> Scanning virtio 0:1...
> > >> ** Unable to read file / **
> > >> Failed to load '/'
> > >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> > >> Scanning disk virtio-blk#8...
> > >> Found 2 disks
> > >> No EFI system partition
> > >> BootOrder not defined
> > >> EFI boot manager: Cannot load any image
> > >> Found EFI removable media binary efi/boot/bootriscv64.efi
> > >
> > > When I press 'e' in GRUB I see:
> > >
> > > setparams 'Installation'
> > > set gfxpayload=keep
> > > echo 'Loading kernel ...'
> > > linux /boot/riscv64/linux splash=silent
> > > echo 'Loading
> > > initial ramdisk ...' initrd
> > > /boot/riscv64/initrd
> > >
> > > With debug=all I get as output:
> > >
> > > kern/verifiers.c:88: file: /boot/riscv64/initrd type: 131076
> > > loader/efi/linux.c:368: LoadFile2 initrd loading protocol installed
> > >
> > > With a bit of debugging enabled in U-Boot:
> > >
> > > EFI: Call: image_obj->entry(image_handle, &systab)
> > > EFI: Entry efi_open_protocol(00000000ff751310,
> > > EFI_LOADED_IMAGE_PROTOCOL_GUID, 00000000ff73a6e0, 00000000ff750050,
> > > 0000000000000000, 0x1)
> > > EFI: Exit: efi_open_protocol: 0
> > > EFI stub: Booting Linux Kernel...
> > > EFI: Entry efi_locate_handle_ext(2,
> > > EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID, 0000000000000000, 00000000ff73a740,
> > > 0000000000000000)
> > > EFI: Exit: efi_locate_handle_ext: 14
> > > EFI: Entry efi_locate_protocol(EFI_TPM2_GUID, 0000000000000000,
> > > 00000000ff73a648)
> > > EFI: Exit: efi_locate_protocol: 14
> > > EFI stub: Using DTB from configuration table
> > > EFI: Entry efi_locate_device_path(EFI_LOAD_FILE2_PROTOCOL_GUID,
> > > 00000000ff73a648, 00000000ff73a668)
> > > EFI: Call: efi_locate_handle_buffer(BY_PROTOCOL, protocol,
> > > NULL, &no_handles, &handles)
> > > EFI: Entry efi_locate_handle_buffer(2,
> > > EFI_LOAD_FILE2_PROTOCOL_GUID, 0000000000000000, 00000000ff73a5d8,
> > > 00000000ff73a5d0)
> > > EFI: Exit: efi_locate_handle_buffer: 0
> > > EFI: 0 returned by efi_locate_handle_buffer(BY_PROTOCOL,
> > > protocol, NULL, &no_handles, &handles)
> > > EFI: Exit: efi_locate_device_path: 0
> > > EFI: Entry efi_open_protocol(00000000ff74c8b0,
> > > EFI_LOAD_FILE2_PROTOCOL_GUID, 00000000ff73a650, 00000000ff750050,
> > > 0000000000000000, 0x1)
> > > EFI: Exit: efi_open_protocol: 0
> > > EFI: Exit: efi_open_protocol: 0
> > > EFI: Entry efi_allocate_pages_ext(AllocateMaxAddress,
> > > EfiLoaderData, 0xc024, 00000000ff73a618)
> > > EFI: Exit: efi_allocate_pages_ext: 9 (EFI_OUT_OF_RESOURCES)
> > >
> > > EFI stub: ERROR: Failed to load initrd!
> > >
> > > The LOAD_FILE2 protocol was successfully opened on the handle ff74c8b0
> > > where it was installed by GRUB.
> > >
> > > *Allocating memory for the initrd fails.*
> > >
> > > 0xC024 pages are requested below 0x901fffff.
> > >
> > > This is the memory map when the call is executed:
> > >
> > > Type Start End Attributes
> > > ================ ================ ================ ==========
> > > BOOT DATA 0000000100000000-0000000280000000 WB
> > > LOADER DATA 00000000fff62000-0000000100000000 WB
> > > RUNTIME CODE 00000000fff61000-00000000fff62000 WB|RT
> > > LOADER DATA 00000000fe73f000-00000000fff61000 WB
> > > BOOT DATA 00000000fe73d000-00000000fe73f000 WB
> > > RESERVED 00000000fe73c000-00000000fe73d000 WB
> > > BOOT DATA 00000000fe73a000-00000000fe73c000 WB
> > > RESERVED 00000000fe739000-00000000fe73a000 WB
> > > RUNTIME DATA 00000000fe735000-00000000fe739000 WB|RT
> > > BOOT DATA 00000000fe734000-00000000fe735000 WB
> > > RUNTIME DATA 00000000fe730000-00000000fe734000 WB|RT
> > > BOOT DATA 00000000fe72f000-00000000fe730000 WB
> > > RESERVED 00000000fe728000-00000000fe72f000 WB
> > > LOADER CODE 00000000fe4aa000-00000000fe728000 WB
> > > LOADER DATA 00000000fe4a9000-00000000fe4aa000 WB
> > > BOOT DATA 00000000fe4a8000-00000000fe4a9000 WB
> > > RESERVED 00000000fe4a6000-00000000fe4a8000 WB
> > > LOADER DATA 00000000fe4a3000-00000000fe4a6000 WB
> > > LOADER CODE 00000000deb8d000-00000000fe4a3000 WB
> > > LOADER DATA 00000000dd620000-00000000deb8d000 WB
> > > LOADER CODE 00000000dbfc3000-00000000dd620000 WB
> > > BOOT DATA 00000000dbfc2000-00000000dbfc3000 WB
> > > CONVENTIONAL 0000000087f05000-00000000dbfc2000 WB
> > > ACPI RECLAIM MEM 0000000087efb000-0000000087f05000 WB
> > > CONVENTIONAL 000000008185d000-0000000087efb000 WB
> > > LOADER DATA 0000000080200000-000000008185d000 WB
> > > CONVENTIONAL 0000000080040000-0000000080200000 WB
> > > BOOT DATA 0000000080000000-0000000080040000 WB
> > >
> > > 0x901fffff - 0x1000 * 0xC024 = 0x841DBFFF
> > >
> > > So U-Boot is correct in indicating that the memory is not available at
> > > the required low address.
> > >
> > > In Linux efi_load_initrd() is called with parameter hard_limit being the
> > > 'minimum size of allocated memory'. But this parameter is passed to
>
> The function comment header should be updated to reflect the correct usage. No ?
>
Agreed. The allocation limits are physical upper bounds, not sizes.
> > > efi_load_initrd_dev_path() as 'upper limit for the initrd memory
> > > allocation' and further to efi_allocate_pages() as 'the address that the
> > > last allocated memory page shall not exceed'.
> > >
> > > @Ard
> > > Why does Linux require allocating the memory below 0x901fffff which is
> > > the value of 'minimum size of allocated memory'? I think initrd can be
> > > allocated anywhere in memory even above 4GiB.
> > >
>
> That should be fine. I think this bug was present during initial
> porting but never got exposed because I never used
> such a big initrd. Thanks for providing the fix.
>
I don't know about RISC-V in particular, but in general, there are
limits to where the initrd can be loaded, depending on how the
architecture organizes its linear mapping of DRAM. If no such
limitation exists for RISC-V, the code should be updated accordingly.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-06-30 7:26 ` Ard Biesheuvel
@ 2021-07-02 18:48 ` Atish Patra
0 siblings, 0 replies; 36+ messages in thread
From: Atish Patra @ 2021-07-02 18:48 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: The development of GNU GRUB, Andreas Schwab, Atish Patra,
Daniel Kiper, Leif Lindholm, Nikita Ermakov, Ilias Apalodimas
On Wed, Jun 30, 2021 at 12:26 AM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Tue, 29 Jun 2021 at 21:13, Atish Patra <atishp@atishpatra.org> wrote:
> >
> > On Mon, Jun 28, 2021 at 2:24 PM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> > >
> > >
> > > +cc Ard Biesheuvel <ardb@kernel.org>
> > >
> > > Ard, please see question for you below.
> > >
> > > On 6/27/21 11:01 PM, Heinrich Schuchardt wrote:
> > > > On 6/26/21 8:07 PM, Andreas Schwab wrote:
> > > >> On Jun 03 2021, Nikita Ermakov wrote:
> > > >>
> > > >>> This series contains patches to add support for LoadFile2 protocol to
> > > >>> load
> > > >>> initrd on EFI systems. Also it contains patches to load Linux kernel
> > > >>> with EFI
> > > >>> stub on riscv platforms and unites arm and riscv codes together into
> > > >>> common
> > > >>> loader code for EFI systems.
> > > >>
> > > >> That doesn't work with a CD image. When I try to run
> > > >> http://download.opensuse.org/ports/riscv/tumbleweed/iso/openSUSE-Tumbleweed-NET-riscv64-Media.iso
> > > >>
> > > >> with qemu, the initrd fails to load.
> > > >
> > > > Please, indicate how you built u-boot.bin.
> > > >
> > > >>
> > > >> $ qemu-system-riscv64 -M virt -nographic -serial mon:stdio -smp 4 -m
> > > >> 8g -kernel u-boot.bin -drive
> > > >> format=raw,if=virtio,media=cdrom,file=openSUSE-Tumbleweed-NET-riscv64-Media.iso
> > > >>
> > > >
> > > > This command results in an error
> > > >
> > > > qemu-system-riscv64: warning:
> > > > No -bios option specified. Not loading a firmware.
> > > >
> > > > Please, provide a repo with the GRUB code you have been compiling.
> > > >
> > > >>
> > > >> OpenSBI v0.9
> > > >> ____ _____ ____ _____
> > > >> / __ \ / ____| _ \_ _|
> > > >> | | | |_ __ ___ _ __ | (___ | |_) || |
> > > >> | | | | '_ \ / _ \ '_ \ \___ \| _ < | |
> > > >> | |__| | |_) | __/ | | |____) | |_) || |_
> > > >> \____/| .__/ \___|_| |_|_____/|____/_____|
> > > >> | |
> > > >> |_|
> > > >>
> > > >> Platform Name : riscv-virtio,qemu
> > > >> Platform Features : timer,mfdeleg
> > > >> Platform HART Count : 4
> > > >> Firmware Base : 0x80000000
> > > >> Firmware Size : 124 KB
> > > >> Runtime SBI Version : 0.2
> > > >>
> > > >> Domain0 Name : root
> > > >> Domain0 Boot HART : 1
> > > >> Domain0 HARTs : 0*,1*,2*,3*
> > > >> Domain0 Region00 : 0x0000000080000000-0x000000008001ffff ()
> > > >> Domain0 Region01 : 0x0000000000000000-0xffffffffffffffff (R,W,X)
> > > >> Domain0 Next Address : 0x0000000080200000
> > > >> Domain0 Next Arg1 : 0x00000000bf000000
> > > >> Domain0 Next Mode : S-mode
> > > >> Domain0 SysReset : yes
> > > >>
> > > >> Boot HART ID : 1
> > > >> Boot HART Domain : root
> > > >> Boot HART ISA : rv64imafdcsu
> > > >> Boot HART Features : scounteren,mcounteren,time
> > > >> Boot HART PMP Count : 16
> > > >> Boot HART PMP Granularity : 4
> > > >> Boot HART PMP Address Bits: 54
> > > >> Boot HART MHPM Count : 0
> > > >> Boot HART MHPM Count : 0
> > > >> Boot HART MIDELEG : 0x0000000000000222
> > > >> Boot HART MEDELEG : 0x000000000000b109
> > > >>
> > > >>
> > > >> U-Boot 2021.04 (Jun 09 2021 - 00:00:00 +0000)
> > > >>
> > > >> CPU: rv64imafdcsu
> > > >> Model: riscv-virtio,qemu
> > > >> DRAM: 8 GiB
> > > >> In: uart@10000000
> > > >> Out: uart@10000000
> > > >> Err: uart@10000000
> > > >> Net: No ethernet found.
> > > >> Hit any key to stop autoboot: 0
> > > >>
> > > >> Device 0: 1af4 VirtIO Block Device
> > > >> Type: Hard Disk
> > > >> Capacity: 225.7 MB = 0.2 GB (462376 x 512)
> > > >> ... is now current device
> > > >> ** Invalid partition 3 **
> > > >> ** Invalid partition 4 **
> > > >> ** Invalid partition 2 **
> > > >> Scanning virtio 0:1...
> > > >> ** Unable to read file / **
> > > >> Failed to load '/'
> > > >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> > > >> Scanning disk virtio-blk#8...
> > > >> Found 2 disks
> > > >> No EFI system partition
> > > >> BootOrder not defined
> > > >> EFI boot manager: Cannot load any image
> > > >> Found EFI removable media binary efi/boot/bootriscv64.efi
> > > >
> > > > When I press 'e' in GRUB I see:
> > > >
> > > > setparams 'Installation'
> > > > set gfxpayload=keep
> > > > echo 'Loading kernel ...'
> > > > linux /boot/riscv64/linux splash=silent
> > > > echo 'Loading
> > > > initial ramdisk ...' initrd
> > > > /boot/riscv64/initrd
> > > >
> > > > With debug=all I get as output:
> > > >
> > > > kern/verifiers.c:88: file: /boot/riscv64/initrd type: 131076
> > > > loader/efi/linux.c:368: LoadFile2 initrd loading protocol installed
> > > >
> > > > With a bit of debugging enabled in U-Boot:
> > > >
> > > > EFI: Call: image_obj->entry(image_handle, &systab)
> > > > EFI: Entry efi_open_protocol(00000000ff751310,
> > > > EFI_LOADED_IMAGE_PROTOCOL_GUID, 00000000ff73a6e0, 00000000ff750050,
> > > > 0000000000000000, 0x1)
> > > > EFI: Exit: efi_open_protocol: 0
> > > > EFI stub: Booting Linux Kernel...
> > > > EFI: Entry efi_locate_handle_ext(2,
> > > > EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID, 0000000000000000, 00000000ff73a740,
> > > > 0000000000000000)
> > > > EFI: Exit: efi_locate_handle_ext: 14
> > > > EFI: Entry efi_locate_protocol(EFI_TPM2_GUID, 0000000000000000,
> > > > 00000000ff73a648)
> > > > EFI: Exit: efi_locate_protocol: 14
> > > > EFI stub: Using DTB from configuration table
> > > > EFI: Entry efi_locate_device_path(EFI_LOAD_FILE2_PROTOCOL_GUID,
> > > > 00000000ff73a648, 00000000ff73a668)
> > > > EFI: Call: efi_locate_handle_buffer(BY_PROTOCOL, protocol,
> > > > NULL, &no_handles, &handles)
> > > > EFI: Entry efi_locate_handle_buffer(2,
> > > > EFI_LOAD_FILE2_PROTOCOL_GUID, 0000000000000000, 00000000ff73a5d8,
> > > > 00000000ff73a5d0)
> > > > EFI: Exit: efi_locate_handle_buffer: 0
> > > > EFI: 0 returned by efi_locate_handle_buffer(BY_PROTOCOL,
> > > > protocol, NULL, &no_handles, &handles)
> > > > EFI: Exit: efi_locate_device_path: 0
> > > > EFI: Entry efi_open_protocol(00000000ff74c8b0,
> > > > EFI_LOAD_FILE2_PROTOCOL_GUID, 00000000ff73a650, 00000000ff750050,
> > > > 0000000000000000, 0x1)
> > > > EFI: Exit: efi_open_protocol: 0
> > > > EFI: Exit: efi_open_protocol: 0
> > > > EFI: Entry efi_allocate_pages_ext(AllocateMaxAddress,
> > > > EfiLoaderData, 0xc024, 00000000ff73a618)
> > > > EFI: Exit: efi_allocate_pages_ext: 9 (EFI_OUT_OF_RESOURCES)
> > > >
> > > > EFI stub: ERROR: Failed to load initrd!
> > > >
> > > > The LOAD_FILE2 protocol was successfully opened on the handle ff74c8b0
> > > > where it was installed by GRUB.
> > > >
> > > > *Allocating memory for the initrd fails.*
> > > >
> > > > 0xC024 pages are requested below 0x901fffff.
> > > >
> > > > This is the memory map when the call is executed:
> > > >
> > > > Type Start End Attributes
> > > > ================ ================ ================ ==========
> > > > BOOT DATA 0000000100000000-0000000280000000 WB
> > > > LOADER DATA 00000000fff62000-0000000100000000 WB
> > > > RUNTIME CODE 00000000fff61000-00000000fff62000 WB|RT
> > > > LOADER DATA 00000000fe73f000-00000000fff61000 WB
> > > > BOOT DATA 00000000fe73d000-00000000fe73f000 WB
> > > > RESERVED 00000000fe73c000-00000000fe73d000 WB
> > > > BOOT DATA 00000000fe73a000-00000000fe73c000 WB
> > > > RESERVED 00000000fe739000-00000000fe73a000 WB
> > > > RUNTIME DATA 00000000fe735000-00000000fe739000 WB|RT
> > > > BOOT DATA 00000000fe734000-00000000fe735000 WB
> > > > RUNTIME DATA 00000000fe730000-00000000fe734000 WB|RT
> > > > BOOT DATA 00000000fe72f000-00000000fe730000 WB
> > > > RESERVED 00000000fe728000-00000000fe72f000 WB
> > > > LOADER CODE 00000000fe4aa000-00000000fe728000 WB
> > > > LOADER DATA 00000000fe4a9000-00000000fe4aa000 WB
> > > > BOOT DATA 00000000fe4a8000-00000000fe4a9000 WB
> > > > RESERVED 00000000fe4a6000-00000000fe4a8000 WB
> > > > LOADER DATA 00000000fe4a3000-00000000fe4a6000 WB
> > > > LOADER CODE 00000000deb8d000-00000000fe4a3000 WB
> > > > LOADER DATA 00000000dd620000-00000000deb8d000 WB
> > > > LOADER CODE 00000000dbfc3000-00000000dd620000 WB
> > > > BOOT DATA 00000000dbfc2000-00000000dbfc3000 WB
> > > > CONVENTIONAL 0000000087f05000-00000000dbfc2000 WB
> > > > ACPI RECLAIM MEM 0000000087efb000-0000000087f05000 WB
> > > > CONVENTIONAL 000000008185d000-0000000087efb000 WB
> > > > LOADER DATA 0000000080200000-000000008185d000 WB
> > > > CONVENTIONAL 0000000080040000-0000000080200000 WB
> > > > BOOT DATA 0000000080000000-0000000080040000 WB
> > > >
> > > > 0x901fffff - 0x1000 * 0xC024 = 0x841DBFFF
> > > >
> > > > So U-Boot is correct in indicating that the memory is not available at
> > > > the required low address.
> > > >
> > > > In Linux efi_load_initrd() is called with parameter hard_limit being the
> > > > 'minimum size of allocated memory'. But this parameter is passed to
> >
> > The function comment header should be updated to reflect the correct usage. No ?
> >
>
> Agreed. The allocation limits are physical upper bounds, not sizes.
>
I will send the patch.
> > > > efi_load_initrd_dev_path() as 'upper limit for the initrd memory
> > > > allocation' and further to efi_allocate_pages() as 'the address that the
> > > > last allocated memory page shall not exceed'.
> > > >
> > > > @Ard
> > > > Why does Linux require allocating the memory below 0x901fffff which is
> > > > the value of 'minimum size of allocated memory'? I think initrd can be
> > > > allocated anywhere in memory even above 4GiB.
> > > >
> >
> > That should be fine. I think this bug was present during initial
> > porting but never got exposed because I never used
> > such a big initrd. Thanks for providing the fix.
> >
>
> I don't know about RISC-V in particular, but in general, there are
> limits to where the initrd can be loaded, depending on how the
> architecture organizes its linear mapping of DRAM. If no such
> limitation exists for RISC-V, the code should be updated accordingly.
I am not aware of any such limitation for RISC-V as long as the initrd
is placed somewhere that
doesn't overwrite fdt or kernel image. I believe the U-boot/EDK2 will
take care of that during allocation itself.
I will cross-check anyways in case I missed something.
--
Regards,
Atish
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-06-02 21:12 [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader Nikita Ermakov
` (7 preceding siblings ...)
2021-06-26 18:07 ` [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader Andreas Schwab
@ 2021-08-27 16:22 ` Atish Patra
2021-08-27 16:29 ` Fu Wei
2021-10-08 17:46 ` Heinrich Schuchardt
9 siblings, 1 reply; 36+ messages in thread
From: Atish Patra @ 2021-08-27 16:22 UTC (permalink / raw)
To: The development of GNU GRUB, Wei Fu
Cc: Ard Biesheuvel, Atish Patra, Daniel Kiper, Heinrich Schuchardt,
Leif Lindholm, Nikita Ermakov
On Wed, Jun 2, 2021 at 2:13 PM Nikita Ermakov <arei@altlinux.org> wrote:
>
> Hello,
>
> This is the second version of the patch series. The patch series is almost the
> same as the previous one except that the Heinrich's suggestions were
> implemented.
>
> This series contains patches to add support for LoadFile2 protocol to load
> initrd on EFI systems. Also it contains patches to load Linux kernel with EFI
> stub on riscv platforms and unites arm and riscv codes together into common
> loader code for EFI systems.
+ Wei Fu who tested this series on Beagleboard.
According to Wei we do another patch to add a boot-hartid entry in the
chosen node if DTB is
loaded from grub instead of U-Boot [1].
[1] https://github.com/tekkamanninja/grub/commit/99c5dc1ba897e506f185eb19d4dadc6d41937214
>
> Ard Biesheuvel (3):
> efi: add definition of LoadFile2 protocol
> efi: implemented LoadFile2 initrd loading protocol for Linux
> linux: ignore FDT unless we need to modify it
>
> Atish Patra (3):
> loader: Move arm64 linux loader to common code
> RISC-V: Update image header
> RISC-V: Use common linux loader
>
> Nikita Ermakov (1):
> loader: drop argv[] argument in grub_initrd_load()
>
> grub-core/Makefile.core.def | 8 +-
> grub-core/commands/efi/lsefi.c | 1 +
> grub-core/loader/arm/linux.c | 2 +-
> grub-core/loader/efi/fdt.c | 7 +-
> grub-core/loader/{arm64 => efi}/linux.c | 143 +++++++++++++++++++---
> grub-core/loader/i386/linux.c | 2 +-
> grub-core/loader/i386/pc/linux.c | 2 +-
> grub-core/loader/i386/xen.c | 3 +-
> grub-core/loader/ia64/efi/linux.c | 2 +-
> grub-core/loader/linux.c | 4 +-
> grub-core/loader/mips/linux.c | 2 +-
> grub-core/loader/powerpc/ieee1275/linux.c | 2 +-
> grub-core/loader/riscv/linux.c | 59 ---------
> grub-core/loader/sparc64/ieee1275/linux.c | 2 +-
> include/grub/arm/linux.h | 2 +-
> include/grub/arm64/linux.h | 2 +-
> include/grub/efi/api.h | 15 +++
> include/grub/linux.h | 2 +-
> include/grub/riscv32/linux.h | 16 +--
> include/grub/riscv64/linux.h | 16 +--
> 20 files changed, 185 insertions(+), 107 deletions(-)
> rename grub-core/loader/{arm64 => efi}/linux.c (72%)
> delete mode 100644 grub-core/loader/riscv/linux.c
>
> --
> 2.29.3
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards,
Atish
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-08-27 16:22 ` Atish Patra
@ 2021-08-27 16:29 ` Fu Wei
2021-08-28 12:21 ` Nikita Ermakov
0 siblings, 1 reply; 36+ messages in thread
From: Fu Wei @ 2021-08-27 16:29 UTC (permalink / raw)
To: Atish Patra
Cc: The development of GNU GRUB, Ard Biesheuvel, Atish Patra,
Daniel Kiper, Heinrich Schuchardt, Leif Lindholm, Nikita Ermakov
Hi Atish,
Great thanks for adding me the loop!
I have tested this these whole patchset on Starlight board and Allwinner D1 ,
https://github.com/tekkamanninja/grub/tree/riscv_devel_Nikita_V2
I would be nice If you can add my Tested-by for this patchset!
Tested-by: Wei Fu <tekkamanninja@gmail.com>
Atish Patra <atishp@atishpatra.org> 于2021年8月28日周六 上午12:22写道：
>
> On Wed, Jun 2, 2021 at 2:13 PM Nikita Ermakov <arei@altlinux.org> wrote:
> >
> > Hello,
> >
> > This is the second version of the patch series. The patch series is almost the
> > same as the previous one except that the Heinrich's suggestions were
> > implemented.
> >
> > This series contains patches to add support for LoadFile2 protocol to load
> > initrd on EFI systems. Also it contains patches to load Linux kernel with EFI
> > stub on riscv platforms and unites arm and riscv codes together into common
> > loader code for EFI systems.
>
> + Wei Fu who tested this series on Beagleboard.
>
> According to Wei we do another patch to add a boot-hartid entry in the
> chosen node if DTB is
> loaded from grub instead of U-Boot [1].
>
> [1] https://github.com/tekkamanninja/grub/commit/99c5dc1ba897e506f185eb19d4dadc6d41937214
> >
> > Ard Biesheuvel (3):
> > efi: add definition of LoadFile2 protocol
> > efi: implemented LoadFile2 initrd loading protocol for Linux
> > linux: ignore FDT unless we need to modify it
> >
> > Atish Patra (3):
> > loader: Move arm64 linux loader to common code
> > RISC-V: Update image header
> > RISC-V: Use common linux loader
> >
> > Nikita Ermakov (1):
> > loader: drop argv[] argument in grub_initrd_load()
> >
> > grub-core/Makefile.core.def | 8 +-
> > grub-core/commands/efi/lsefi.c | 1 +
> > grub-core/loader/arm/linux.c | 2 +-
> > grub-core/loader/efi/fdt.c | 7 +-
> > grub-core/loader/{arm64 => efi}/linux.c | 143 +++++++++++++++++++---
> > grub-core/loader/i386/linux.c | 2 +-
> > grub-core/loader/i386/pc/linux.c | 2 +-
> > grub-core/loader/i386/xen.c | 3 +-
> > grub-core/loader/ia64/efi/linux.c | 2 +-
> > grub-core/loader/linux.c | 4 +-
> > grub-core/loader/mips/linux.c | 2 +-
> > grub-core/loader/powerpc/ieee1275/linux.c | 2 +-
> > grub-core/loader/riscv/linux.c | 59 ---------
> > grub-core/loader/sparc64/ieee1275/linux.c | 2 +-
> > include/grub/arm/linux.h | 2 +-
> > include/grub/arm64/linux.h | 2 +-
> > include/grub/efi/api.h | 15 +++
> > include/grub/linux.h | 2 +-
> > include/grub/riscv32/linux.h | 16 +--
> > include/grub/riscv64/linux.h | 16 +--
> > 20 files changed, 185 insertions(+), 107 deletions(-)
> > rename grub-core/loader/{arm64 => efi}/linux.c (72%)
> > delete mode 100644 grub-core/loader/riscv/linux.c
> >
> > --
> > 2.29.3
> >
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
>
>
>
> --
> Regards,
> Atish
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-08-27 16:29 ` Fu Wei
@ 2021-08-28 12:21 ` Nikita Ermakov
2021-08-29 2:30 ` Fu Wei
0 siblings, 1 reply; 36+ messages in thread
From: Nikita Ermakov @ 2021-08-28 12:21 UTC (permalink / raw)
To: Fu Wei, Atish Patra
Cc: The development of GNU GRUB, Ard Biesheuvel, Atish Patra,
Daniel Kiper, Heinrich Schuchardt, Leif Lindholm
Hi Atish, Fu,
On Fri, 27 Aug 2021 at 19:29, Fu Wei <tekkamanninja@gmail.com> wrote:
>
> Hi Atish,
>
> Great thanks for adding me the loop!
>
> I have tested this these whole patchset on Starlight board and Allwinner D1 ,
>
> https://github.com/tekkamanninja/grub/tree/riscv_devel_Nikita_V2
>
> I would be nice If you can add my Tested-by for this patchset!
>
> Tested-by: Wei Fu <tekkamanninja@gmail.com>
>
Fu, thank you for the test and the patch regarding boot-hartid.
I can send V3 with "Tested-by: Wei Fu <tekkamanninja@gmail.com>"
appended to the patchset and add the 8'th patch to set boot-hartid.
Is it ok?
> Atish Patra <atishp@atishpatra.org> 于2021年8月28日周六 上午12:22写道：
> >
> > On Wed, Jun 2, 2021 at 2:13 PM Nikita Ermakov <arei@altlinux.org> wrote:
> > >
> > > Hello,
> > >
> > > This is the second version of the patch series. The patch series is almost the
> > > same as the previous one except that the Heinrich's suggestions were
> > > implemented.
> > >
> > > This series contains patches to add support for LoadFile2 protocol to load
> > > initrd on EFI systems. Also it contains patches to load Linux kernel with EFI
> > > stub on riscv platforms and unites arm and riscv codes together into common
> > > loader code for EFI systems.
> >
> > + Wei Fu who tested this series on Beagleboard.
> >
> > According to Wei we do another patch to add a boot-hartid entry in the
> > chosen node if DTB is
> > loaded from grub instead of U-Boot [1].
> >
> > [1] https://github.com/tekkamanninja/grub/commit/99c5dc1ba897e506f185eb19d4dadc6d41937214
> > >
> > > Ard Biesheuvel (3):
> > > efi: add definition of LoadFile2 protocol
> > > efi: implemented LoadFile2 initrd loading protocol for Linux
> > > linux: ignore FDT unless we need to modify it
> > >
> > > Atish Patra (3):
> > > loader: Move arm64 linux loader to common code
> > > RISC-V: Update image header
> > > RISC-V: Use common linux loader
> > >
> > > Nikita Ermakov (1):
> > > loader: drop argv[] argument in grub_initrd_load()
> > >
> > > grub-core/Makefile.core.def | 8 +-
> > > grub-core/commands/efi/lsefi.c | 1 +
> > > grub-core/loader/arm/linux.c | 2 +-
> > > grub-core/loader/efi/fdt.c | 7 +-
> > > grub-core/loader/{arm64 => efi}/linux.c | 143 +++++++++++++++++++---
> > > grub-core/loader/i386/linux.c | 2 +-
> > > grub-core/loader/i386/pc/linux.c | 2 +-
> > > grub-core/loader/i386/xen.c | 3 +-
> > > grub-core/loader/ia64/efi/linux.c | 2 +-
> > > grub-core/loader/linux.c | 4 +-
> > > grub-core/loader/mips/linux.c | 2 +-
> > > grub-core/loader/powerpc/ieee1275/linux.c | 2 +-
> > > grub-core/loader/riscv/linux.c | 59 ---------
> > > grub-core/loader/sparc64/ieee1275/linux.c | 2 +-
> > > include/grub/arm/linux.h | 2 +-
> > > include/grub/arm64/linux.h | 2 +-
> > > include/grub/efi/api.h | 15 +++
> > > include/grub/linux.h | 2 +-
> > > include/grub/riscv32/linux.h | 16 +--
> > > include/grub/riscv64/linux.h | 16 +--
> > > 20 files changed, 185 insertions(+), 107 deletions(-)
> > > rename grub-core/loader/{arm64 => efi}/linux.c (72%)
> > > delete mode 100644 grub-core/loader/riscv/linux.c
> > >
> > > --
> > > 2.29.3
> > >
> > >
> > > _______________________________________________
> > > Grub-devel mailing list
> > > Grub-devel@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/grub-devel
> >
> >
> >
> > --
> > Regards,
> > Atish
--
Thanks,
Nikita
B8 00 4C CD 21
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-08-28 12:21 ` Nikita Ermakov
@ 2021-08-29 2:30 ` Fu Wei
2021-08-29 12:44 ` Nikita Ermakov
0 siblings, 1 reply; 36+ messages in thread
From: Fu Wei @ 2021-08-29 2:30 UTC (permalink / raw)
To: Nikita Ermakov
Cc: Atish Patra, The development of GNU GRUB, Ard Biesheuvel,
Atish Patra, Daniel Kiper, Heinrich Schuchardt, Leif Lindholm
Hi Nikita,
Nikita Ermakov <arei@altlinux.org> 于2021年8月28日周六 下午8:22写道：
>
> Hi Atish, Fu,
>
> On Fri, 27 Aug 2021 at 19:29, Fu Wei <tekkamanninja@gmail.com> wrote:
> >
> > Hi Atish,
> >
> > Great thanks for adding me the loop!
> >
> > I have tested this these whole patchset on Starlight board and Allwinner D1 ,
> >
> > https://github.com/tekkamanninja/grub/tree/riscv_devel_Nikita_V2
> >
> > I would be nice If you can add my Tested-by for this patchset!
> >
> > Tested-by: Wei Fu <tekkamanninja@gmail.com>
> >
> Fu, thank you for the test and the patch regarding boot-hartid.
> I can send V3 with "Tested-by: Wei Fu <tekkamanninja@gmail.com>"
> appended to the patchset and add the 8'th patch to set boot-hartid.
> Is it ok?
Sure , NP :-) .
Please add my Tested-by :-)
>
> > Atish Patra <atishp@atishpatra.org> 于2021年8月28日周六 上午12:22写道：
> > >
> > > On Wed, Jun 2, 2021 at 2:13 PM Nikita Ermakov <arei@altlinux.org> wrote:
> > > >
> > > > Hello,
> > > >
> > > > This is the second version of the patch series. The patch series is almost the
> > > > same as the previous one except that the Heinrich's suggestions were
> > > > implemented.
> > > >
> > > > This series contains patches to add support for LoadFile2 protocol to load
> > > > initrd on EFI systems. Also it contains patches to load Linux kernel with EFI
> > > > stub on riscv platforms and unites arm and riscv codes together into common
> > > > loader code for EFI systems.
> > >
> > > + Wei Fu who tested this series on Beagleboard.
> > >
> > > According to Wei we do another patch to add a boot-hartid entry in the
> > > chosen node if DTB is
> > > loaded from grub instead of U-Boot [1].
> > >
> > > [1] https://github.com/tekkamanninja/grub/commit/99c5dc1ba897e506f185eb19d4dadc6d41937214
> > > >
> > > > Ard Biesheuvel (3):
> > > > efi: add definition of LoadFile2 protocol
> > > > efi: implemented LoadFile2 initrd loading protocol for Linux
> > > > linux: ignore FDT unless we need to modify it
> > > >
> > > > Atish Patra (3):
> > > > loader: Move arm64 linux loader to common code
> > > > RISC-V: Update image header
> > > > RISC-V: Use common linux loader
> > > >
> > > > Nikita Ermakov (1):
> > > > loader: drop argv[] argument in grub_initrd_load()
> > > >
> > > > grub-core/Makefile.core.def | 8 +-
> > > > grub-core/commands/efi/lsefi.c | 1 +
> > > > grub-core/loader/arm/linux.c | 2 +-
> > > > grub-core/loader/efi/fdt.c | 7 +-
> > > > grub-core/loader/{arm64 => efi}/linux.c | 143 +++++++++++++++++++---
> > > > grub-core/loader/i386/linux.c | 2 +-
> > > > grub-core/loader/i386/pc/linux.c | 2 +-
> > > > grub-core/loader/i386/xen.c | 3 +-
> > > > grub-core/loader/ia64/efi/linux.c | 2 +-
> > > > grub-core/loader/linux.c | 4 +-
> > > > grub-core/loader/mips/linux.c | 2 +-
> > > > grub-core/loader/powerpc/ieee1275/linux.c | 2 +-
> > > > grub-core/loader/riscv/linux.c | 59 ---------
> > > > grub-core/loader/sparc64/ieee1275/linux.c | 2 +-
> > > > include/grub/arm/linux.h | 2 +-
> > > > include/grub/arm64/linux.h | 2 +-
> > > > include/grub/efi/api.h | 15 +++
> > > > include/grub/linux.h | 2 +-
> > > > include/grub/riscv32/linux.h | 16 +--
> > > > include/grub/riscv64/linux.h | 16 +--
> > > > 20 files changed, 185 insertions(+), 107 deletions(-)
> > > > rename grub-core/loader/{arm64 => efi}/linux.c (72%)
> > > > delete mode 100644 grub-core/loader/riscv/linux.c
> > > >
> > > > --
> > > > 2.29.3
> > > >
> > > >
> > > > _______________________________________________
> > > > Grub-devel mailing list
> > > > Grub-devel@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/grub-devel
> > >
> > >
> > >
> > > --
> > > Regards,
> > > Atish
>
> --
> Thanks,
> Nikita
> B8 00 4C CD 21
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-08-29 2:30 ` Fu Wei
@ 2021-08-29 12:44 ` Nikita Ermakov
2021-08-30 1:43 ` Heinrich Schuchardt
0 siblings, 1 reply; 36+ messages in thread
From: Nikita Ermakov @ 2021-08-29 12:44 UTC (permalink / raw)
To: Fu Wei
Cc: Atish Patra, The development of GNU GRUB, Ard Biesheuvel,
Atish Patra, Daniel Kiper, Heinrich Schuchardt, Leif Lindholm
[-- Attachment #1: Type: text/plain, Size: 5041 bytes --]
Btw, I have a minor suggestion [1] for your patch.
AFAIK hartid terminology and /chosen/boot-hartid are RISC-V specifics. So,
I think, we should not emit the warning and change DTB with a null
boot-hartid value. If get_hartid is not defined then we should, probably,
just skip this boot-hartid thing.
What do you think? If it is alright I can change your patch with these
changes and send V3 or you can change it by yourself.
[1]
https://github.com/sh1r4s3/grub/commit/af66530842dd3058e1ac0acd8e4ddfd51671fa6c
--
Thanks,
Nikita
B8 4C 00 CD 21
нд, 29 серп. 2021, 05:30 користувач Fu Wei <tekkamanninja@gmail.com> пише:
> Hi Nikita,
>
> Nikita Ermakov <arei@altlinux.org> 于2021年8月28日周六 下午8:22写道：
> >
> > Hi Atish, Fu,
> >
> > On Fri, 27 Aug 2021 at 19:29, Fu Wei <tekkamanninja@gmail.com> wrote:
> > >
> > > Hi Atish,
> > >
> > > Great thanks for adding me the loop!
> > >
> > > I have tested this these whole patchset on Starlight board and
> Allwinner D1 ,
> > >
> > > https://github.com/tekkamanninja/grub/tree/riscv_devel_Nikita_V2
> > >
> > > I would be nice If you can add my Tested-by for this patchset!
> > >
> > > Tested-by: Wei Fu <tekkamanninja@gmail.com>
> > >
> > Fu, thank you for the test and the patch regarding boot-hartid.
> > I can send V3 with "Tested-by: Wei Fu <tekkamanninja@gmail.com>"
> > appended to the patchset and add the 8'th patch to set boot-hartid.
> > Is it ok?
>
> Sure , NP :-) .
> Please add my Tested-by :-)
>
> >
> > > Atish Patra <atishp@atishpatra.org> 于2021年8月28日周六 上午12:22写道：
> > > >
> > > > On Wed, Jun 2, 2021 at 2:13 PM Nikita Ermakov <arei@altlinux.org>
> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > This is the second version of the patch series. The patch series
> is almost the
> > > > > same as the previous one except that the Heinrich's suggestions
> were
> > > > > implemented.
> > > > >
> > > > > This series contains patches to add support for LoadFile2 protocol
> to load
> > > > > initrd on EFI systems. Also it contains patches to load Linux
> kernel with EFI
> > > > > stub on riscv platforms and unites arm and riscv codes together
> into common
> > > > > loader code for EFI systems.
> > > >
> > > > + Wei Fu who tested this series on Beagleboard.
> > > >
> > > > According to Wei we do another patch to add a boot-hartid entry in
> the
> > > > chosen node if DTB is
> > > > loaded from grub instead of U-Boot [1].
> > > >
> > > > [1]
> https://github.com/tekkamanninja/grub/commit/99c5dc1ba897e506f185eb19d4dadc6d41937214
> > > > >
> > > > > Ard Biesheuvel (3):
> > > > > efi: add definition of LoadFile2 protocol
> > > > > efi: implemented LoadFile2 initrd loading protocol for Linux
> > > > > linux: ignore FDT unless we need to modify it
> > > > >
> > > > > Atish Patra (3):
> > > > > loader: Move arm64 linux loader to common code
> > > > > RISC-V: Update image header
> > > > > RISC-V: Use common linux loader
> > > > >
> > > > > Nikita Ermakov (1):
> > > > > loader: drop argv[] argument in grub_initrd_load()
> > > > >
> > > > > grub-core/Makefile.core.def | 8 +-
> > > > > grub-core/commands/efi/lsefi.c | 1 +
> > > > > grub-core/loader/arm/linux.c | 2 +-
> > > > > grub-core/loader/efi/fdt.c | 7 +-
> > > > > grub-core/loader/{arm64 => efi}/linux.c | 143
> +++++++++++++++++++---
> > > > > grub-core/loader/i386/linux.c | 2 +-
> > > > > grub-core/loader/i386/pc/linux.c | 2 +-
> > > > > grub-core/loader/i386/xen.c | 3 +-
> > > > > grub-core/loader/ia64/efi/linux.c | 2 +-
> > > > > grub-core/loader/linux.c | 4 +-
> > > > > grub-core/loader/mips/linux.c | 2 +-
> > > > > grub-core/loader/powerpc/ieee1275/linux.c | 2 +-
> > > > > grub-core/loader/riscv/linux.c | 59 ---------
> > > > > grub-core/loader/sparc64/ieee1275/linux.c | 2 +-
> > > > > include/grub/arm/linux.h | 2 +-
> > > > > include/grub/arm64/linux.h | 2 +-
> > > > > include/grub/efi/api.h | 15 +++
> > > > > include/grub/linux.h | 2 +-
> > > > > include/grub/riscv32/linux.h | 16 +--
> > > > > include/grub/riscv64/linux.h | 16 +--
> > > > > 20 files changed, 185 insertions(+), 107 deletions(-)
> > > > > rename grub-core/loader/{arm64 => efi}/linux.c (72%)
> > > > > delete mode 100644 grub-core/loader/riscv/linux.c
> > > > >
> > > > > --
> > > > > 2.29.3
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Grub-devel mailing list
> > > > > Grub-devel@gnu.org
> > > > > https://lists.gnu.org/mailman/listinfo/grub-devel
> > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Atish
> >
> > --
> > Thanks,
> > Nikita
> > B8 00 4C CD 21
>
[-- Attachment #2: Type: text/html, Size: 7862 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-08-29 12:44 ` Nikita Ermakov
@ 2021-08-30 1:43 ` Heinrich Schuchardt
0 siblings, 0 replies; 36+ messages in thread
From: Heinrich Schuchardt @ 2021-08-30 1:43 UTC (permalink / raw)
To: Nikita Ermakov, Fu Wei
Cc: Atish Patra, The development of GNU GRUB, Ard Biesheuvel,
Atish Patra, Daniel Kiper, Leif Lindholm, Heinrich Schuchardt
On 8/29/21 2:44 PM, Nikita Ermakov wrote:
> Btw, I have a minor suggestion [1] for your patch.
> AFAIK hartid terminology and /chosen/boot-hartid are RISC-V specifics.
> So, I think, we should not emit the warning and change DTB with a null
> boot-hartid value. If get_hartid is not defined then we should,
> probably, just skip this boot-hartid thing.
>
> What do you think? If it is alright I can change your patch with these
> changes and send V3 or you can change it by yourself.
>
> [1]
> https://github.com/sh1r4s3/grub/commit/af66530842dd3058e1ac0acd8e4ddfd51671fa6c
> <https://github.com/sh1r4s3/grub/commit/af66530842dd3058e1ac0acd8e4ddfd51671fa6c>
Why should /chosen/boot-hartid be set in GRUB?
This property is set in the devicetree by U-Boot or EDK II before
invoking GRUB.
If GRUB is loading a device-tree from file, it should call the
EFI_DT_FIXUP_PROTOCOL available in U-Boot to set /chosen/boot-hartid.
Cf. https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL
Best regards
Heinrich
>
> --
> Thanks,
> Nikita
> B8 4C 00 CD 21
>
> нд, 29 серп. 2021, 05:30 користувач Fu Wei <tekkamanninja@gmail.com
> <mailto:tekkamanninja@gmail.com>> пише:
>
> Hi Nikita,
>
> Nikita Ermakov <arei@altlinux.org <mailto:arei@altlinux.org>> 于2021
> 年8月28日周六 下午8:22写道：
> >
> > Hi Atish, Fu,
> >
> > On Fri, 27 Aug 2021 at 19:29, Fu Wei <tekkamanninja@gmail.com
> <mailto:tekkamanninja@gmail.com>> wrote:
> > >
> > > Hi Atish,
> > >
> > > Great thanks for adding me the loop!
> > >
> > > I have tested this these whole patchset on Starlight board and
> Allwinner D1 ,
> > >
> > >
> https://github.com/tekkamanninja/grub/tree/riscv_devel_Nikita_V2
> <https://github.com/tekkamanninja/grub/tree/riscv_devel_Nikita_V2>
> > >
> > > I would be nice If you can add my Tested-by for this patchset!
> > >
> > > Tested-by: Wei Fu <tekkamanninja@gmail.com
> <mailto:tekkamanninja@gmail.com>>
> > >
> > Fu, thank you for the test and the patch regarding boot-hartid.
> > I can send V3 with "Tested-by: Wei Fu <tekkamanninja@gmail.com
> <mailto:tekkamanninja@gmail.com>>"
> > appended to the patchset and add the 8'th patch to set boot-hartid.
> > Is it ok?
>
> Sure , NP :-) .
> Please add my Tested-by :-)
>
> >
> > > Atish Patra <atishp@atishpatra.org
> <mailto:atishp@atishpatra.org>> 于2021年8月28日周六 上午12:22写道：
> > > >
> > > > On Wed, Jun 2, 2021 at 2:13 PM Nikita Ermakov
> <arei@altlinux.org <mailto:arei@altlinux.org>> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > This is the second version of the patch series. The patch
> series is almost the
> > > > > same as the previous one except that the Heinrich's
> suggestions were
> > > > > implemented.
> > > > >
> > > > > This series contains patches to add support for LoadFile2
> protocol to load
> > > > > initrd on EFI systems. Also it contains patches to load
> Linux kernel with EFI
> > > > > stub on riscv platforms and unites arm and riscv codes
> together into common
> > > > > loader code for EFI systems.
> > > >
> > > > + Wei Fu who tested this series on Beagleboard.
> > > >
> > > > According to Wei we do another patch to add a boot-hartid
> entry in the
> > > > chosen node if DTB is
> > > > loaded from grub instead of U-Boot [1].
> > > >
> > > > [1]
> https://github.com/tekkamanninja/grub/commit/99c5dc1ba897e506f185eb19d4dadc6d41937214
> <https://github.com/tekkamanninja/grub/commit/99c5dc1ba897e506f185eb19d4dadc6d41937214>
> > > > >
> > > > > Ard Biesheuvel (3):
> > > > > efi: add definition of LoadFile2 protocol
> > > > > efi: implemented LoadFile2 initrd loading protocol for Linux
> > > > > linux: ignore FDT unless we need to modify it
> > > > >
> > > > > Atish Patra (3):
> > > > > loader: Move arm64 linux loader to common code
> > > > > RISC-V: Update image header
> > > > > RISC-V: Use common linux loader
> > > > >
> > > > > Nikita Ermakov (1):
> > > > > loader: drop argv[] argument in grub_initrd_load()
> > > > >
> > > > > grub-core/Makefile.core.def | 8 +-
> > > > > grub-core/commands/efi/lsefi.c | 1 +
> > > > > grub-core/loader/arm/linux.c | 2 +-
> > > > > grub-core/loader/efi/fdt.c | 7 +-
> > > > > grub-core/loader/{arm64 => efi}/linux.c | 143
> +++++++++++++++++++---
> > > > > grub-core/loader/i386/linux.c | 2 +-
> > > > > grub-core/loader/i386/pc/linux.c | 2 +-
> > > > > grub-core/loader/i386/xen.c | 3 +-
> > > > > grub-core/loader/ia64/efi/linux.c | 2 +-
> > > > > grub-core/loader/linux.c | 4 +-
> > > > > grub-core/loader/mips/linux.c | 2 +-
> > > > > grub-core/loader/powerpc/ieee1275/linux.c | 2 +-
> > > > > grub-core/loader/riscv/linux.c | 59 ---------
> > > > > grub-core/loader/sparc64/ieee1275/linux.c | 2 +-
> > > > > include/grub/arm/linux.h | 2 +-
> > > > > include/grub/arm64/linux.h | 2 +-
> > > > > include/grub/efi/api.h | 15 +++
> > > > > include/grub/linux.h | 2 +-
> > > > > include/grub/riscv32/linux.h | 16 +--
> > > > > include/grub/riscv64/linux.h | 16 +--
> > > > > 20 files changed, 185 insertions(+), 107 deletions(-)
> > > > > rename grub-core/loader/{arm64 => efi}/linux.c (72%)
> > > > > delete mode 100644 grub-core/loader/riscv/linux.c
> > > > >
> > > > > --
> > > > > 2.29.3
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Grub-devel mailing list
> > > > > Grub-devel@gnu.org <mailto:Grub-devel@gnu.org>
> > > > > https://lists.gnu.org/mailman/listinfo/grub-devel
> <https://lists.gnu.org/mailman/listinfo/grub-devel>
> > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Atish
> >
> > --
> > Thanks,
> > Nikita
> > B8 00 4C CD 21
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-06-02 21:12 [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader Nikita Ermakov
` (8 preceding siblings ...)
2021-08-27 16:22 ` Atish Patra
@ 2021-10-08 17:46 ` Heinrich Schuchardt
2021-10-14 18:49 ` Daniel Kiper
9 siblings, 1 reply; 36+ messages in thread
From: Heinrich Schuchardt @ 2021-10-08 17:46 UTC (permalink / raw)
To: Daniel Kiper
Cc: Ard Biesheuvel, Atish Patra, Heinrich Schuchardt, Leif Lindholm,
The development of GNU GRUB, Andreas Schwab, Nikita Ermakov
On 6/2/21 23:12, Nikita Ermakov wrote:
> Hello,
>
> This is the second version of the patch series. The patch series is almost the
> same as the previous one except that the Heinrich's suggestions were
> implemented.
>
> This series contains patches to add support for LoadFile2 protocol to load
> initrd on EFI systems. Also it contains patches to load Linux kernel with EFI
> stub on riscv platforms and unites arm and riscv codes together into common
> loader code for EFI systems.
Dear Daniel,
as all open questions regarding this series have been resolved, please,
consider the series for inclusion into GRUB.
The RISC-V platform specification requires support for booting via UEFI.
Redhat/Fedora, SUSE, Debian, Ubuntu are all working on RISC-V and are
therefore in need of this change.
Best regards
Heinrich
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-10-08 17:46 ` Heinrich Schuchardt
@ 2021-10-14 18:49 ` Daniel Kiper
2021-10-16 13:39 ` Nikita Ermakov
0 siblings, 1 reply; 36+ messages in thread
From: Daniel Kiper @ 2021-10-14 18:49 UTC (permalink / raw)
To: Nikita Ermakov
Cc: Heinrich Schuchardt, Ard Biesheuvel, Atish Patra,
Heinrich Schuchardt, Leif Lindholm, The development of GNU GRUB,
Andreas Schwab
On Fri, Oct 08, 2021 at 07:46:17PM +0200, Heinrich Schuchardt wrote:
> On 6/2/21 23:12, Nikita Ermakov wrote:
> > Hello,
> >
> > This is the second version of the patch series. The patch series is almost the
> > same as the previous one except that the Heinrich's suggestions were
> > implemented.
> >
> > This series contains patches to add support for LoadFile2 protocol to load
> > initrd on EFI systems. Also it contains patches to load Linux kernel with EFI
> > stub on riscv platforms and unites arm and riscv codes together into common
> > loader code for EFI systems.
>
> Dear Daniel,
>
> as all open questions regarding this series have been resolved, please,
> consider the series for inclusion into GRUB.
>
> The RISC-V platform specification requires support for booting via UEFI.
> Redhat/Fedora, SUSE, Debian, Ubuntu are all working on RISC-V and are
> therefore in need of this change.
Nikita, may I ask you to rebase this patch series on latest master?
When it is ready I will take a look at it in a week or two. Sorry,
I should do this earlier but I am plowing through backlog and trying to
not get more stalled patches.
Daniel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-10-14 18:49 ` Daniel Kiper
@ 2021-10-16 13:39 ` Nikita Ermakov
2021-10-18 9:27 ` Heinrich Schuchardt
0 siblings, 1 reply; 36+ messages in thread
From: Nikita Ermakov @ 2021-10-16 13:39 UTC (permalink / raw)
To: Daniel Kiper
Cc: Nikita Ermakov, Heinrich Schuchardt, Ard Biesheuvel, Atish Patra,
Heinrich Schuchardt, Leif Lindholm, The development of GNU GRUB,
Andreas Schwab
[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]
Hi Daniel, all,
On Thu, 14 Oct 2021, 21:50 Daniel Kiper, <daniel.kiper@oracle.com> wrote:
> On Fri, Oct 08, 2021 at 07:46:17PM +0200, Heinrich Schuchardt wrote:
> > On 6/2/21 23:12, Nikita Ermakov wrote:
> > > Hello,
> > >
> > > This is the second version of the patch series. The patch series is
> almost the
> > > same as the previous one except that the Heinrich's suggestions were
> > > implemented.
> > >
> > > This series contains patches to add support for LoadFile2 protocol to
> load
> > > initrd on EFI systems. Also it contains patches to load Linux kernel
> with EFI
> > > stub on riscv platforms and unites arm and riscv codes together into
> common
> > > loader code for EFI systems.
> >
> > Dear Daniel,
> >
> > as all open questions regarding this series have been resolved, please,
> > consider the series for inclusion into GRUB.
> >
> > The RISC-V platform specification requires support for booting via UEFI.
> > Redhat/Fedora, SUSE, Debian, Ubuntu are all working on RISC-V and are
> > therefore in need of this change.
>
> Nikita, may I ask you to rebase this patch series on latest master?
>
Sure, I'll do it in a couple of days.
I'm sorry, currently I'm a bit busy, I started to work on the Heinrich's
suggestion to use EFI to update devicetree but didn't finish it yet.
Probably we can add this part later in the other patch(set). What do you
think?
When it is
ready I will take a look at it in a week or two. Sorry,
> I should do this earlier but I am plowing through backlog and trying to
> not get more stalled patches.
>
> Daniel
>
--
Thanks,
Nikita
B8 4C 00 CD 21
>
[-- Attachment #2: Type: text/html, Size: 2996 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-10-16 13:39 ` Nikita Ermakov
@ 2021-10-18 9:27 ` Heinrich Schuchardt
2021-10-18 18:04 ` Daniel Kiper
0 siblings, 1 reply; 36+ messages in thread
From: Heinrich Schuchardt @ 2021-10-18 9:27 UTC (permalink / raw)
To: Nikita Ermakov, Daniel Kiper
Cc: Heinrich Schuchardt, Ard Biesheuvel, Atish Patra, Leif Lindholm,
The development of GNU GRUB, Andreas Schwab
On 10/16/21 15:39, Nikita Ermakov wrote:
>
> Hi Daniel, all,
>
>
> On Thu, 14 Oct 2021, 21:50 Daniel Kiper, <daniel.kiper@oracle.com
> <mailto:daniel.kiper@oracle.com>> wrote:
>
> On Fri, Oct 08, 2021 at 07:46:17PM +0200, Heinrich Schuchardt wrote:
> > On 6/2/21 23:12, Nikita Ermakov wrote:
> > > Hello,
> > >
> > > This is the second version of the patch series. The patch
> series is almost the
> > > same as the previous one except that the Heinrich's suggestions
> were
> > > implemented.
> > >
> > > This series contains patches to add support for LoadFile2
> protocol to load
> > > initrd on EFI systems. Also it contains patches to load Linux
> kernel with EFI
> > > stub on riscv platforms and unites arm and riscv codes together
> into common
> > > loader code for EFI systems.
> >
> > Dear Daniel,
> >
> > as all open questions regarding this series have been resolved,
> please,
> > consider the series for inclusion into GRUB.
> >
> > The RISC-V platform specification requires support for booting
> via UEFI.
> > Redhat/Fedora, SUSE, Debian, Ubuntu are all working on RISC-V and are
> > therefore in need of this change.
>
> Nikita, may I ask you to rebase this patch series on latest master?
>
> Sure, I'll do it in a couple of days.
> I'm sorry, currently I'm a bit busy, I started to work on the Heinrich's
> suggestion to use EFI to update devicetree but didn't finish it yet.
> Probably we can add this part later in the other patch(set). What do you
> think?
Enabling support for the the EFI Device Tree Fixup Protocol is
independent of RISC-V support. For me RISC-V would have priority.
Best regards
Heinrich
>
> When it is
>
> ready I will take a look at it in a week or two. Sorry,
> I should do this earlier but I am plowing through backlog and trying to
> not get more stalled patches.
>
> Daniel
>
>
> --
> Thanks,
> Nikita
> B8 4C 00 CD 21
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
2021-10-18 9:27 ` Heinrich Schuchardt
@ 2021-10-18 18:04 ` Daniel Kiper
0 siblings, 0 replies; 36+ messages in thread
From: Daniel Kiper @ 2021-10-18 18:04 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Nikita Ermakov, Heinrich Schuchardt, Ard Biesheuvel, Atish Patra,
Leif Lindholm, The development of GNU GRUB, Andreas Schwab
On Mon, Oct 18, 2021 at 11:27:15AM +0200, Heinrich Schuchardt wrote:
> On 10/16/21 15:39, Nikita Ermakov wrote:
> >
> > Hi Daniel, all,
> >
> > On Thu, 14 Oct 2021, 21:50 Daniel Kiper, <daniel.kiper@oracle.com
> > <mailto:daniel.kiper@oracle.com>> wrote:
> >
> > On Fri, Oct 08, 2021 at 07:46:17PM +0200, Heinrich Schuchardt wrote:
> > > On 6/2/21 23:12, Nikita Ermakov wrote:
> > > > Hello,
> > > >
> > > > This is the second version of the patch series. The patch
> > series is almost the
> > > > same as the previous one except that the Heinrich's suggestions
> > were
> > > > implemented.
> > > >
> > > > This series contains patches to add support for LoadFile2
> > protocol to load
> > > > initrd on EFI systems. Also it contains patches to load Linux
> > kernel with EFI
> > > > stub on riscv platforms and unites arm and riscv codes together
> > into common
> > > > loader code for EFI systems.
> > >
> > > Dear Daniel,
> > >
> > > as all open questions regarding this series have been resolved,
> > please,
> > > consider the series for inclusion into GRUB.
> > >
> > > The RISC-V platform specification requires support for booting
> > via UEFI.
> > > Redhat/Fedora, SUSE, Debian, Ubuntu are all working on RISC-V and are
> > > therefore in need of this change.
> >
> > Nikita, may I ask you to rebase this patch series on latest master?
> >
> > Sure, I'll do it in a couple of days.
> > I'm sorry, currently I'm a bit busy, I started to work on the Heinrich's
> > suggestion to use EFI to update devicetree but didn't finish it yet.
> > Probably we can add this part later in the other patch(set). What do you
> > think?
>
> Enabling support for the the EFI Device Tree Fixup Protocol is
> independent of RISC-V support. For me RISC-V would have priority.
I concur...
Daniel
^ permalink raw reply [flat|nested] 36+ messages in thread