On 13.08.24 15:52, Daniel Kiper wrote:
On Mon, Aug 12, 2024 at 04:13:18PM +0200, Heinrich Schuchardt wrote:
The cycle register is not guaranteed to count at constant frequency.
If it is counting at all depends on the state the performance monitoring
unit.
Use the time register to measure time
; then would provide the output.
But I don't see good reason to require such debug output.
Acked-by: Heinrich Schuchardt
Signed-off-by: Mate Kukri
---
grub-core/loader/efi/chainloader.c | 4
1 file changed, 4 deletions(-)
diff --git a/grub-core/loader/efi/chainloader.
The cycle register is not guaranteed to count at constant frequency.
If it is counting at all depends on the state the performance monitoring
unit.
Use the time register to measure time.
Signed-off-by: Heinrich Schuchardt
---
grub-core/kern/riscv/efi/init.c | 15 +++
1 file changed
Many escape sequences are only valid in raw string. Use these when
invoking re.match() and re.search() to avoid syntax warnings.
Signed-off-by: Heinrich Schuchardt
---
util/import_gcry.py | 100 ++--
1 file changed, 50 insertions(+), 50 deletions(-)
diff
a possibly easier value to write by an
attacker. Initialize canary to static random bytes, so that it is still
random when there is not RNG protocol.
Signed-off-by: Glenn Washburn
Reviewed-by: Heinrich Schuchardt
---
grub-core/kern/efi/init.c | 2 +-
1 file changed, 1 insertion(+), 1
On 9/27/23 18:02, darkpenguin wrote:
That's what I'd like to do, but I couldn't figure out how to make 'git
format-patch -2' output a single patch. It always outputs one patch per
commit.
Is there an option I've missed, or is there no other way than creating a
throwaway repo to squash the commit
signal that the EFI GOP protocol is
not usable.
Signed-off-by: Heinrich Schuchardt
---
grub-core/video/efi_gop.c | 4
1 file changed, 4 insertions(+)
diff --git a/grub-core/video/efi_gop.c b/grub-core/video/efi_gop.c
index 7247aeea7..09ee71b45 100644
--- a/grub-core/video/efi_gop.c
+++ b/grub
Print the UEFI specification revision in human readable form, e.g.
2.10 instead of 00020064 and 2.3.1 instead of 0002001f.
See UEFI 2.10 specification, chapter 4.2.1 EFI_TABLE_HEADER
Signed-off-by: Heinrich Schuchardt
---
grub-core/commands/efi/lsefisystab.c | 10 --
1 file changed, 8
and non-x86 EFI boot paths.
Note that 32-bit ARM already uses the same location in the header for a
different purpose, but the ARM support is already widely implemented and
the EFI zboot decompressor is not available on ARM anyway, so we just
disregard it here.
Cc: Huacai Chen
Cc: Atish Patra
On 11/9/22 13:50, Ard Biesheuvel wrote:
On Wed, 9 Nov 2022 at 13:38, Leif Lindholm wrote:
On Wed, Nov 09, 2022 at 13:10:29 +0100, Ard Biesheuvel wrote:
The drawback to that is that not all EFI executables are destined for
the Linux loader. So while trying to boot them using the linux loader
i
On 9/12/22 16:19, Zhang Boyang wrote:
The code of dynamically adding new regions has two problems. First, it
always invalidate disk caches, which decreases performance severely.
Second, it request exactly "size" bytes for new region, ignoring region
overheads.
This patch makes adding new regions
for the
table.
Provide a short text for the EFI_CONFORMANCE_PROFILES_TABLE_GUID.
Signed-off-by: Heinrich Schuchardt
---
grub-core/commands/efi/lsefisystab.c | 1 +
include/grub/efi/api.h | 5 +
2 files changed, 6 insertions(+)
diff --git a/grub-core/commands/efi/lsefisystab.c
b
cent 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
Reviewed-by: Heinrich Schuchardt
___
Grub-devel ma
losed when grub_net_fini_hw() is called.
Signed-off-by: Ard Biesheuvel
Reviewed-by: Heinrich Schuchardt
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
On 8/18/22 16:51, Ard Biesheuvel wrote:
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,
linux loader
Best regards
Heinrich
Cc: Daniel Kiper
Cc: Leif Lindholm
Cc: Nikita Ermakov
Cc: Atish Patra
Cc: Huacai Chen
Cc: Heinrich Schuchardt
Cc: dann frazier
Cc: Julian Andres Klode
Ard Biesheuvel (7):
efi: move MS-DOS stub out of generic PE header definition
arm64/linux: Remov
On 8/18/22 16:51, Ard Biesheuvel wrote:
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
er amounts of memory.
Reviewed-by: Heinrich Schuchardt
Beyond the scope of this patch:
Using LoaderCode here seems wrong. Heap should be LoaderData.
The problematic part of heap allocation is function add_memory_regions()
that does not let AllocatePages() do its job to find a fitting region
her file system drivers) pass buffers with
a higher alignment already.
Signed-off-by: Stefan Agner
Acked-by: Heinrich Schuchardt
---
This latest revision seems to work fine for Home Assistant OS 8.1.
Heinrich, since the logic changed a bit, I removed your Acked-by again.
--
Stefan
gru
On 5/16/22 14:22, Stefan Agner wrote:
Hi Heinrich,
On 2022-05-10 22:40, Stefan Agner wrote:
On 2022-05-10 22:26, Heinrich Schuchardt wrote:
On 5/10/22 21:59, Stefan Agner wrote:
Despite the UEFI specification saying "the requirement is that the
start address of a buffer must be e
On 5/10/22 21:59, Stefan Agner wrote:
Despite the UEFI specification saying "the requirement is that the
start address of a buffer must be evenly divisible by IoAlign with
no remainder.", it seems that a higher alignment requirement is
neecssary on some system (e.g. a Intel NUC system with NVMe S
On 5/9/22 21:45, Stefan Agner wrote:
On 2022-05-09 21:19, Heinrich Schuchardt wrote:
On 5/5/22 15:54, Stefan Agner wrote:
Despite the UEFI specification saying "the requirement is that the
start address of a buffer must be evenly divisible by IoAlign with
no remainder.", it seems tha
On 5/5/22 15:54, Stefan Agner wrote:
Despite the UEFI specification saying "the requirement is that the
start address of a buffer must be evenly divisible by IoAlign with
no remainder.", it seems that a higher alignment requirement is
neecssary on some system (e.g. a Intel NUC system with NVMe SS
On 3/31/22 09:13, Ard Biesheuvel wrote:
On Thu, 31 Mar 2022 at 02:36, Daniel P. Smith
wrote:
Greetings Matthew,
First thank you to you and James for taking time out of your busy
schedules to sit down with us and work through all of this.
Hey Ard,
On 3/30/22 03:02, Ard Biesheuvel wrote:>> 1)
short text for the
table.
Provide a short text for the EFI_IMAGE_SECURITY_DATABASE_GUID.
Signed-off-by: Heinrich Schuchardt
---
grub-core/commands/efi/lsefisystab.c | 1 +
include/grub/efi/api.h | 5 +
2 files changed, 6 insertions(+)
diff --git a/grub-core/commands/efi
On 2/7/22 16:29, James Bottomley wrote:
From: James Bottomley
v4: Update to new password passing API and fold in review comments
original patch 1 (which contained a password passing API) is
removed and patch 2 is updated and patch 3 largely unchanged.
v3: make password getter specify
On 2/26/22 02:50, Glenn Washburn wrote:
On Tue, 22 Feb 2022 18:17:51 +0100
Daniel Kiper wrote:
The GRUB INSTALL file says:
The Requirements
GRUB depends on some software packages installed into your system. If
you don't have any of them, please obtain and install
have to adjust the -march flag passed to the
compiler accordingly.
Signed-off-by: Heinrich Schuchardt
---
configure.ac | 8
1 file changed, 8 insertions(+)
diff --git a/configure.ac b/configure.ac
index 7517fc49d..7b094a63d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -852,11 +852,19
2022 at 8:33 PM Heinrich Schuchardt
wrote:
ls / for a FAT partition leads to
error: invalid modification timestamp for /.
Not all entries of the directory are displayed.
Linux never updates the modification timestamp of the /. directory entry.
The FAT specification allows the access and creat
The UEFI specification defines that the EFI_BOOT_SERVICES.Exit(() service
may return EFI_SUCCESS or EFI_INVALID_PARAMETER. So it cannot be
__attribute__((noreturn)).
Signed-off-by: Heinrich Schuchardt
---
include/grub/efi/api.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
follow Linux and render initial FAT timestamps as start of
the epoch.
Signed-off-by: Heinrich Schuchardt
---
grub-core/fs/fat.c | 12
1 file changed, 12 insertions(+)
diff --git a/grub-core/fs/fat.c b/grub-core/fs/fat.c
index dd82e4ee3..35ff0b27c 100644
--- a/grub-core/fs/fat.c
+++ b
On 1/15/22 00:46, Jamo wrote:
According to https://www.ietf.org/rfc/rfc2616.txt 4.2, header names
shall be case insensitive and we are now forced to read headers like
"Content-Length" capitalized.
The problem with that is when a HTTP server responds with a
"content-length" header in lowercase, G
protocol which
we opened non-exclusively when searching for a card, we have to do this
before opening the protocol exclusively.
As there is no guarantee that we successfully open the protocol add checks
in the transmit and receive functions.
Reported-by: Andreas Schwab
Signed-off-by: Heinrich
Create a library function for CloseProtocol() and use it for the SNP
driver.
Signed-off-by: Heinrich Schuchardt
---
v2:
adjust code style
---
grub-core/kern/efi/efi.c | 12
grub-core/net/drivers/efi/efinet.c | 8 ++--
include/grub/efi/efi.h | 3
first patch.
The second patch provides a new function grub_efi_close_protocol() to
simplify the coding.
v2:
do not open SNP protocol non-exclusively
adjust code style
Heinrich Schuchardt (2):
efinet: correct closing of SNP protocol
efi: library function grub_efi_close_protocol
On 10/28/21 22:31, Nikita Ermakov wrote:
Hello,
This is the third version of the patch series. In v3 the series was rebased
on top of the master branch.
This series contains patches to add support for LoadFile2 protocol to load
initrd on EFI systems. Also it contains patches to load Linux kerne
On 10/16/21 15:39, Nikita Ermakov wrote:
Hi Daniel, all,
On Thu, 14 Oct 2021, 21:50 Daniel Kiper, mailto:daniel.ki...@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:
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 E
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 bo
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
Create a library function for CloseProtocol() and use it for the SNP
driver.
Signed-off-by: Heinrich Schuchardt
---
grub-core/kern/efi/efi.c | 18 ++
grub-core/net/drivers/efi/efinet.c | 8 ++--
include/grub/efi/efi.h | 3 +++
3 files changed, 23
first patch.
The second patch provides a new function grub_efi_close_protocol() to
simplify the coding.
Heinrich Schuchardt (2):
efinet: correct closing of SNP protocol
efi: library function grub_efi_close_protocol()
grub-core/kern/efi/efi.c | 18 ++
grub-core/net
protocol which
we opened non-exclusively when searching for a card, we have to do this
before opening the protocol exclusively.
As there is no guarantee that we successfully open the protocol add checks
in the transmit and receive functions.
Reported-by: Andreas Schwab
Signed-off-by: Heinrich
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 SN
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 pro
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 n
Am 18. September 2021 18:04:13 MESZ schrieb Alec Brown
:
>Hi everyone,
>
>I've been working on improving the specification for the firmware and
>bootloader
>log that Daniel Kiper has proposed and take into account most of the
>suggestions
>that were made in these threads [1], [2].
>
>The goal
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
On 8/16/21 4:59 PM, Tomasz Kramkowski via Grub-devel wrote:
20def1a3c introduced support for file modification times to allow
comparison of file ages on EFI systems. This patch used
grub_datetime2unixtime which uses a 32 bit unix timestamp and as a
result did not allow the full range of times tha
On 8/24/21 3:32 PM, Daniel Axtens wrote:
grub is a trusted component of the secure boot process, including
"traditional" GPG-based secure boot, UEFI-based secure boot, and the
WIP secure boot process using appended signatures. Most of grub is
written in C and has suffered from a number of memory-
On 8/16/21 9:04 AM, Ard Biesheuvel wrote:
On Sat, 14 Aug 2021 at 00:39, Heinrich Schuchardt wrote:
Am 13. August 2021 22:22:49 MESZ schrieb Daniel Kiper :
On Fri, Aug 13, 2021 at 06:22:49PM +0200, Heinrich Schuchardt wrote:
On 8/2/21 5:18 PM, Daniel Kiper wrote:
Hi Heinrich,
On Mon, Aug
Am 13. August 2021 22:22:49 MESZ schrieb Daniel Kiper :
>On Fri, Aug 13, 2021 at 06:22:49PM +0200, Heinrich Schuchardt wrote:
>> On 8/2/21 5:18 PM, Daniel Kiper wrote:
>> > Hi Heinrich,
>> >
>> > On Mon, Aug 02, 2021 at 03:00:55PM +0200, Heinrich S
On some current distributions there is no /usr/bin/python. The Python
binary is /usr/bin/python3. If a command python3 is available, use it
instead.
Signed-off-by: Heinrich Schuchardt
---
autogen.sh | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/autogen.sh b/autogen.sh
On 8/2/21 5:18 PM, Daniel Kiper wrote:
Hi Heinrich,
On Mon, Aug 02, 2021 at 03:00:55PM +0200, Heinrich Schuchardt wrote:
Hello Daniel,
I sent this series when you were in the middle of getting GRUB-2.06 out.
Unfortunately I did not see any feedback yet. Could you, please, share your
thoughts
Avoid a warning
lib/libgcrypt-grub/cipher/rijndael.c:352:21: warning:
comparison of integer expressions of different signedness:
‘int’ and ‘unsigned int’ [-Wsign-compare]
352 | for (i = 0; i < keylen; i++)
|
Signed-off-by: Heinrich Schuchardt
Reviewed-by: Daniel Kiper
---
Avoid a warning
lib/libgcrypt-grub/cipher/rijndael.c:229:9:
warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
229 | ;
| ^
Signed-off-by: Heinrich Schuchardt
---
grub-core/lib/libgcrypt/cipher/rijndael.c | 4 +++-
1 file changed, 3 insertions
Avoid a warning
lib/libgcrypt-grub/cipher/rijndael.c:352:21: warning:
comparison of integer expressions of different signedness:
‘int’ and ‘unsigned int’ [-Wsign-compare]
352 | for (i = 0; i < keylen; i++)
|
Signed-off-by: Heinrich Schuchardt
---
grub-core/lib/libgcrypt/cip
Hello Daniel,
I sent this series when you were in the middle of getting GRUB-2.06 out.
Unfortunately I did not see any feedback yet. Could you, please, share
your thoughts.
Best regards
Heinrich
On 04.02.21 14:15, Heinrich Schuchardt wrote:
Operating systems need a description of the
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
+cc Ard Biesheuvel
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
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 togethe
On 5/28/21 3:04 PM, Nikita Ermakov wrote:
The load_file2_guid and device_path_guid variables must be preserved
outside of the function scope.
It is not helpful to introduce a bug in patch 3 and later resolve it in
patch 8. Please, squash the two patches into one.
Best regards
Heinrich
Sign
On 5/28/21 3:04 PM, Nikita Ermakov wrote:
From: Ard Biesheuvel
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
olute 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 file 2" },
To stay closer to the UEFI nomenclature maybe:
"
On 5/28/21 3:04 PM, Nikita Ermakov wrote:
From: Ard Biesheuvel
grub_initrd_load() takes a char *argv[] argument which is only used
when an error occurs, to print the name of the file that caused the
error. In order to be able to split initrd loading from handling the
initrd command, let's permi
On 4/9/21 8:12 AM, Ard Biesheuvel wrote:
On Thu, 8 Apr 2021 at 20:57, Heinrich Schuchardt wrote:
On 10/25/20 2:49 PM, Ard Biesheuvel wrote:
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
On 4/9/21 8:10 AM, Ard Biesheuvel wrote:
On Thu, 8 Apr 2021 at 20:45, Heinrich Schuchardt wrote:
On 10/25/20 2:49 PM, Ard Biesheuvel wrote:
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
On 10/25/20 2:49 PM, Ard Biesheuvel wrote:
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 sp
On 10/25/20 2:49 PM, Ard Biesheuvel wrote:
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-D
Hello Atish, hello Nikita,
I have seen these alternative patch series implementing launching Linux
via the RISC-V EFI stub.
Nikita Ermakov, 2021/03/24
[PATCH 0/2] Linux loader for riscv64
https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00343.html
Atish Patra, 2020/04/26
[PATCH RFC/RFT
On 11.02.21 17:01, Michael Lawnick wrote:
> Am 11.02.2021 um 15:04 schrieb Heinrich Schuchardt:
>> On 11.02.21 13:50, Michael Lawnick wrote:
>>> Hi,
>>> Several boot parameters are stored in our SPI flash to configure the
>>> systems for different use cases.
>
On 11.02.21 13:50, Michael Lawnick wrote:
> Am 11.02.2021 um 09:51 schrieb Heinrich Schuchardt:
>> On 11.02.21 08:36, Michael Lawnick wrote:
>>>
>>> Hi,
>>>
>>> seven days of silence. In the end no interest for extending EFI support?
>>>
>
On 11.02.21 08:36, Michael Lawnick wrote:
>
> Hi,
>
> seven days of silence. In the end no interest for extending EFI support?
>
> KR
> Michael
>
> Am 05.02.2021 um 09:58 schrieb Michael Lawnick:
>> Add EFI SPI NOR driver
>>
>> Use UEFI interface for accessing SPI NOR flashes.
>> If supported the i
rding to the /reserved-memory node and the memory
reservation block
* install the device-tree as configuration table
With the patch GRUB checks if the protocol is installed and invokes it if
available.
Signed-off-by: Heinrich Schuchardt
---
grub-core/loader/efi/fdt.c
the file (or file dtb as
fallback) is found, a devicetree command is added to grub.cfg.
[1] EFI_DT_FIXUP_PROTOCOL specification
https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL
Heinrich Schuchardt (2):
efi: EFI Device Tree Fixup Protocol
10_linux: support loading device trees
docs
If in /etc/default/grub GRUB_LOAD_DEVICE_TREE=true, the boot directory
is scanned for files dtb-${version} and dtb. If such a file exists,
a devicetree command is added per Linux menu entry.
Signed-off-by: Heinrich Schuchardt
---
docs/grub.texi | 6 ++
util/grub-mkconfig.in | 1
the EFI_RT_PROPERTIES_TABLE_GUID.
Signed-off-by: Heinrich Schuchardt
---
grub-core/commands/efi/lsefisystab.c | 1 +
include/grub/efi/api.h | 5 +
2 files changed, 6 insertions(+)
diff --git a/grub-core/commands/efi/lsefisystab.c
b/grub-core/commands/efi/lsefisystab.c
index
According to the Embedded Base Boot Requirements (EBBR) specification the
device-tree passed to Linux as a configuration table must reside in
EfiACPIReclaimMemory.
Signed-off-by: Heinrich Schuchardt
---
Resend due to Leif's changed email address
---
grub-core/loader/efi/fdt.c | 6 +-
1
According to the Embedded Base Boot Requirements (EBBR) specification the
device-tree passed to Linux as a configuration table must reside in
EfiACPIReclaimMemory.
Signed-off-by: Heinrich Schuchardt
---
grub-core/loader/efi/fdt.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff
On 14.11.20 00:52, Daniel Kiper wrote:
> Hey,
>
> This is next attempt to create firmware and bootloader log specification.
> Due to high interest among industry it is an extension to the initial
> bootloader log only specification. It takes into the account most of the
> comments which I got up un
Am 30. Juli 2020 22:11:39 MESZ schrieb Heinrich Schuchardt :
>Am 30. Juli 2020 20:31:47 MESZ schrieb Atish Patra
>:
>>On Thu, Jul 30, 2020 at 4:04 AM Heinrich Schuchardt
>> wrote:
>>>
>>> On 30.07.20 12:16, Sean Anderson wrote:
>>> > On 7/30/20 6:03
Am 30. Juli 2020 20:31:47 MESZ schrieb Atish Patra :
>On Thu, Jul 30, 2020 at 4:04 AM Heinrich Schuchardt
> wrote:
>>
>> On 30.07.20 12:16, Sean Anderson wrote:
>> > On 7/30/20 6:03 AM, Heinrich Schuchardt wrote:
>> >> Dear Sean,
>> >>
>> &
On 30.07.20 12:16, Sean Anderson wrote:
> On 7/30/20 6:03 AM, Heinrich Schuchardt wrote:
>> Dear Sean,
>>
>> when trying to run grubriscv64.efi from the
>> trini/u-boot-gitlab-ci-runner:bionic-20200526-18Jun2020 Docker image on
>> a MAIXDUINO the relocations are
Am April 27, 2020 8:58:57 PM UTC schrieb Heinrich Schuchardt
:
>Am April 27, 2020 8:52:43 PM UTC schrieb Ard Biesheuvel
>:
>>On Mon, 27 Apr 2020 at 22:47, Ard Biesheuvel wrote:
>>>
>>> On Mon, 27 Apr 2020 at 22:47, Heinrich Schuchardt
>> wrote:
>>
Am April 27, 2020 8:52:43 PM UTC schrieb Ard Biesheuvel :
>On Mon, 27 Apr 2020 at 22:47, Ard Biesheuvel wrote:
>>
>> On Mon, 27 Apr 2020 at 22:47, Heinrich Schuchardt
> wrote:
>> >
>> > Am April 27, 2020 7:39:38 PM UTC schrieb Ard Biesheuvel
>:
>&
Am April 27, 2020 8:47:51 PM UTC schrieb Ard Biesheuvel :
>On Mon, 27 Apr 2020 at 22:47, Heinrich Schuchardt
>wrote:
>>
>> Am April 27, 2020 7:39:38 PM UTC schrieb Ard Biesheuvel
>:
>> >On Mon, 27 Apr 2020 at 21:36, Heinrich Schuchardt
>
>> >wrote:
&g
Am April 27, 2020 7:39:38 PM UTC schrieb Ard Biesheuvel :
>On Mon, 27 Apr 2020 at 21:36, Heinrich Schuchardt
>wrote:
>>
>> On 4/27/20 1:01 PM, Daniel Kiper wrote:
>> > On Mon, Apr 27, 2020 at 08:15:41AM +0200, Ard Biesheuvel wrote:
>> >> On Sun, 26
On 4/27/20 1:01 PM, Daniel Kiper wrote:
> On Mon, Apr 27, 2020 at 08:15:41AM +0200, Ard Biesheuvel wrote:
>> On Sun, 26 Apr 2020 at 21:40, Atish Patra wrote:
>>>
>>> This series adds grub loader support for RISC-V Linux. Thanks to the awesome
>>> initial RISC-V support added by Alex, we just neede
sh Patra
Tested on Odroid-C2 (ARMv8) using GRUB master c543d678105037a plus this
patch series booting from U-Boot via GRUB to Debian Bullseye successfully.
Tested-by: Heinrich Schuchardt
> ---
> grub-core/Makefile.core.def| 4 +--
> grub-core/loader/riscv/linux.c | 59
tch series booting from U-Boot via GRUB to Debian Bullseye successfully.
Tested-by: Heinrich Schuchardt
> ---
> include/grub/riscv32/linux.h | 15 ---
> include/grub/riscv64/linux.h | 15 ---
> 2 files changed, 16 insertions(+), 14 deletions(-)
>
> diff
a
Tested on Odroid-C2 (ARMv8) using GRUB master c543d678105037a plus this
patch series booting from U-Boot via GRUB to Debian Bullseye successfully.
Tested-by: Heinrich Schuchardt
> ---
> grub-core/Makefile.core.def | 4 ++--
> grub-core/loader/{arm64 => efi}/linux.c |
On 8/6/19 7:02 PM, Peter Jones wrote:
On Tue, Aug 06, 2019 at 09:44:14AM +0100, Leif Lindholm wrote:
+Peter Jones (sorry Peter)
+ Javier Martinez Canillas
On Tue, Aug 06, 2019 at 08:34:58AM +0200, Heinrich Schuchardt wrote:
iPXE uses the EFI simple network protocol to execute DHCP.
OK
hcpv6;
} EFI_PXE_BASE_CODE_PACKET;
Should the check be done in grub_efi_net_config_real()?
Best regards
Heinrich
On 8/5/19 10:08 PM, Heinrich Schuchardt wrote:
Hello Alex,
lib/efi_loader/efi_net.c contains pieces of the
EFI_PXE_BASE_CODE_PROTOCOL. But it is incompletely implemented: all
function pointers are NULL a
ion=20190700
2 tables:
0xbe741000 eb9d2d31-2d88-11d3-9a160090273fc14d SMBIOS
0x87f0 b1b621d5-f19c-41a5-830bd9152c69aae0 DEVICE TREE
Signed-off-by: Heinrich Schuchardt
---
grub-core/commands/efi/lsefisystab.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/grub-core/commands/
my time for testing things, feel free to ask me!
Best regards,
Julien ROBIN
On 4/18/19 5:14 PM, Heinrich Schuchardt wrote:
On 4/18/19 12:41 PM, Daniel Kiper wrote:
On Wed, Apr 17, 2019 at 07:50:09AM +0200, Heinrich Schuchardt wrote:
Since this commit a51f953f4ee8 ("mkimage: Align efi se
On 4/18/19 12:41 PM, Daniel Kiper wrote:
On Wed, Apr 17, 2019 at 07:50:09AM +0200, Heinrich Schuchardt wrote:
Since this commit a51f953f4ee8 ("mkimage: Align efi sections on 4k
boundary") grubarm.efi crashes. Let's revert it.
Everywhere or on a specific machines?
I observed
Since this commit a51f953f4ee8 ("mkimage: Align efi sections on 4k
boundary") grubarm.efi crashes. Let's revert it.
a51f953f4ee8 ("mkimage: Align efi sections on 4k boundary")
Signed-off-by: Heinrich Schuchardt
---
As Alexander Graf pointed out in a private mail w
in this case just return NULL
from the function.
Signed-off-by: Heinrich Schuchardt
Reviewed-by: Leif Lindholm
---
Resend
Cc: grub-devel@gnu.org
---
grub-core/kern/efi/efi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/grub-core/kern/efi/efi.c b/grub-core/kern/efi/efi.c
index
We should not try to copy any memory area which is outside of the original
fdt. If this extra memory is controlled by a hypervisor this might end
with a crash.
Signed-off-by: Heinrich Schuchardt
---
grub-core/loader/efi/fdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
99 matches
Mail list logo
