Xen has its own version of the image header, to account for the
additional PE/COFF header fields. Since we are adding references to
those in the shared EFI loader code, update the common definitions
and drop the Xen specific one which no longer has a purpose.
Signed-off-by: Ard Biesheuvel
---
gr
The 'ARM\x64' magic number in the file header identifies an image as one
that implements the bare metal boot protocol, allowing the loader to
simply move the file to a suitably aligned address in memory, with
sufficient headroom for the trailing .bss segment (the required memory
size is described i
The PE/COFF spec permits the COFF signature and file header to appear
anywhere in the file, and the actual offset is recorded in 4 byte
little endian field at offset 0x3c of the image.
When GRUB is emitted as a PE/COFF binary, we reuse the 128 byte MS-DOS
stub (even for non-x86 architectures), put
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
From: 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
Incorporate the EFI_LOAD_FILE2_PROTOCOL GUID and C types from the
UEFI spec.
Reviewed-by: Heinrich Schuchardt
Signed-off-by: Ard Biesheuvel
---
grub-core/commands/efi/lsefi.c | 1 +
include/grub/efi/api.h | 15 +++
2 files changed, 16 insertions(+)
diff --git a/grub-core/c
On Thu, 18 Aug 2022 at 10:55, Ard Biesheuvel wrote:
>
> This implements the LoadFile2 initrd loading protocol, which is
> essentially a callback interface into the bootloader to load the initrd
> data into a caller provided buffer. This means the bootloader no longer
> has to contain any policy re
This implements the LoadFile2 initrd loading protocol, which is
essentially a callback interface into the bootloader to load the initrd
data into a caller provided buffer. This means the bootloader no longer
has to contain any policy regarding where to load the initrd (which
differs between archite
The way we load the Linux and PE/COFF image headers depends on a fixed
placement of the COFF header at offset 0x40 into the file. This is a
reasonable default, given that this is where Linux emits it today.
However, in order to comply with the PE/COFF spec, which allows this
header to appear anywhe
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 re
When GRUB runs on top of EFI firmware, it only has access to block and
network device abstractions exposed by the firmware, and it is up to the
firmware to quiesce the underlying hardware when handing over to the OS.
This is especially important for network devices, to prevent incoming
packets fro
This implements the LoadFile2 initrd loading protocol, which is
essentially a callback interface into the bootloader to load the initrd
data into a caller provided buffer. This means the bootloader no longer
has to contain any policy regarding where to load the initrd (which
differs between archite
From: 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
The PE/COFF spec permits the COFF signature and file header to appear
anywhere in the file, and the actual offset is recorded in 4 byte
little endian field at offset 0x3c of the image.
When GRUB is emitted as a PE/COFF binary, we reuse the 128 byte MS-DOS
stub (even for non-x86 architectures), put
The 'ARM\x64' magic number in the file header identifies an image as one
that implements the bare metal boot protocol, allowing the loader to
simply move the file to a suitably aligned address in memory, with
sufficient headroom for the trailing .bss segment (the required memory
size is described i
When GRUB runs on top of EFI firmware, it only has access to block and
network device abstractions exposed by the firmware, and it is up to the
firmware to quiesce the underlying hardware when handing over to the OS.
This is especially important for network devices, to prevent incoming
packets fro
Xen has its own version of the image header, to account for the
additional PE/COFF header fields. Since we are adding references to
those in the shared EFI loader code, update the common definitions
and drop the Xen specific one which no longer has a purpose.
Signed-off-by: Ard Biesheuvel
---
gr
The way we load the Linux and PE/COFF image headers depends on a fixed
placement of the COFF header at offset 0x40 into the file. This is a
reasonable default, given that this is where Linux emits it today.
However, in order to comply with the PE/COFF spec, which allows this
header to appear anywhe
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
Now that we implemented support for the LoadFile2 protocol for initrd
loading, there is no longer a need to pass the initrd parameters via
the device tree. This means that when the LoadFile2 protocol is being
used, there is no reason to update the device tree in the first place,
and so we can ignor
In this version: add and check `fwsetup --is-supported, and include the
changes for Paul's review that were left out accidentally in the previous
version.
Be well,
--Robbie
Javier Martinez Canillas (2):
templates: Check for EFI at runtime instead of config generation time
efi: Print an error
From: Javier Martinez Canillas
The 30_uefi-firmware template checks if an OsIndicationsSupported UEFI var
exists and EFI_OS_INDICATIONS_BOOT_TO_FW_UI bit is set, to decide whether
a "fwsetup" menu entry would be added or not to the GRUB menu.
But this has the problem that it will only work if th
This is believed to result in smaller code.
Signed-off-by: Robbie Harwood
---
grub-core/commands/efi/efifwsetup.c | 4 ++--
grub-core/efiemu/i386/pc/cfgtables.c | 6 +++---
grub-core/kern/efi/fdt.c | 2 +-
grub-core/loader/efi/fdt.c | 2 +-
grub-core/term/efi/console.c
From: Javier Martinez Canillas
The "fwsetup" command is only registered if the firmware supports booting
to the firmware setup UI. But it could be possible that the GRUB config
already contains a "fwsetup" entry, because it was generated in a machine
that has support for this feature.
To prevent
Each call of grub_efi_get_variable() needs a grub_free().
Signed-off-by: Robbie Harwood
---
grub-core/commands/efi/efifwsetup.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/grub-core/commands/efi/efifwsetup.c
b/grub-core/commands/efi/efifwsetup.c
index eaca032
Add a new --is-supported option to commands/efi/efifwsetup and
conditionalize display on it.
Signed-off-by: Robbie Harwood
---
grub-core/commands/efi/efifwsetup.c | 3 +++
util/grub.d/30_uefi-firmware.in | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/grub-core/commands
Each call of grub_efi_get_variable() needs a grub_free().
Signed-off-by: Robbie Harwood
---
grub-core/commands/efi/efifwsetup.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/grub-core/commands/efi/efifwsetup.c
b/grub-core/commands/efi/efifwsetup.c
index eaca032
This is believed to result in smaller code.
Signed-off-by: Robbie Harwood
---
grub-core/commands/efi/efifwsetup.c | 4 ++--
grub-core/efiemu/i386/pc/cfgtables.c | 6 +++---
grub-core/kern/efi/fdt.c | 2 +-
grub-core/loader/efi/fdt.c | 2 +-
grub-core/term/efi/console.c
In this version: fix wrong arg parsing in patch to address Glenn's review.
Be well,
--Robbie
Javier Martinez Canillas (2):
templates: Check for EFI at runtime instead of config generation time
efi: Print an error if boot to firmware setup is not supported
Robbie Harwood (3):
commands/efi/e
From: Javier Martinez Canillas
The 30_uefi-firmware template checks if an OsIndicationsSupported UEFI var
exists and EFI_OS_INDICATIONS_BOOT_TO_FW_UI bit is set, to decide whether
a "fwsetup" menu entry would be added or not to the GRUB menu.
But this has the problem that it will only work if th
Add a new --is-supported option to commands/efi/efifwsetup and
conditionalize display on it.
Signed-off-by: Robbie Harwood
---
grub-core/commands/efi/efifwsetup.c | 3 +++
util/grub.d/30_uefi-firmware.in | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/grub-core/commands
From: Javier Martinez Canillas
The "fwsetup" command is only registered if the firmware supports booting
to the firmware setup UI. But it could be possible that the GRUB config
already contains a "fwsetup" entry, because it was generated in a machine
that has support for this feature.
To prevent
32 matches
Mail list logo
