c: Huacai Chen
> Cc: Atish Patra
> Cc: Heinrich Schuchardt
> Cc: Daniel Kiper
> Cc: Leif Lindholm
For the series:
Acked-by: Leif Lindholm
Thanks!
>
> Ard Biesheuvel (2):
> efi: libstub: Always enable initrd command line loader and bump
> version
> efi: Put
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
> > > > is definitely user error, that change removed a potentially useful
> > >
On Wed, Nov 09, 2022 at 12:33:58 +0100, Ard Biesheuvel wrote:
> > > Can we get rid of these header definitions entirely?
> > >
> > > The only GRUB code that seems to care about the fields that are not
> > > defined in the PE/COFF spec is grub_cmd_file(), which currently parses
> > > the magic field
On Tue, Nov 08, 2022 at 17:36:51 +0100, Ard Biesheuvel wrote:
> > I can agree that hdr_offset makes more sense but
> > Documentation/riscv/boot-image-header.rst names this member as res3.
> > So, I would rename hdr_offset to res3 too. Or fix
> > Documentation/riscv/boot-image-header.rst in the kern
On Thu, Sep 08, 2022 at 15:30:12 +0200, 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,
back for DRAM base computation.
> >
> > This is similar to what is done by Peter Jones in commit 3c1a5d940be5
> > ("arm/arm64 loader: Better memory allocation and error messages.") in
> > Fedora's grub[1]. This patch reduces the modifications to a minimum.
> >
&
On Wed, Nov 04, 2020 at 13:19:47 +0100, Ard Biesheuvel wrote:
> On Wed, 4 Nov 2020 at 13:11, Leif Lindholm wrote:
> >
> > On Sun, Oct 25, 2020 at 14:49:34 +0100, Ard Biesheuvel wrote:
> > > The hdr_offset member of the ARM Linux image header appears at
> > >
On Sun, Oct 25, 2020 at 14:49:34 +0100, Ard Biesheuvel wrote:
> The hdr_offset member of the ARM Linux image header appears at
> offset 0x3c, matching the PE/COFF spec's placement of the COFF
> header offset in the MS-DOS header. We're currently off by four,
> so fix that.
>
> Signed-off-by: Ard B
On Fri, Oct 23, 2020 at 15:12:50 +0200, Ard Biesheuvel wrote:
> On Fri, 23 Oct 2020 at 14:47, Leif Lindholm wrote:
> >
> > On Fri, Oct 23, 2020 at 14:08:25 +0200, Ard Biesheuvel wrote:
> > > Now that we implemented supported for the LoadFile2 protocol for initrd
> >
b code to be certain I've caught all aspects
of style adherence, so with that in mind, for 1-2/4:
Reviewed-by: Leif Lindholm
For 3-4/4, I did have some minor comments, but this is a really great
feature and I would like to see it merged.
/
Leif
> Cc: grub-devel@gnu.org
> Cc
On Fri, Oct 23, 2020 at 14:08:25 +0200, Ard Biesheuvel wrote:
> 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
initrd typo in subject
minor style comments below
On Fri, Oct 23, 2020 at 14:08:24 +0200, Ard Biesheuvel wrote:
> 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 prefe
cache maintenance.
>
> We can thus avoid being paranoid, and align the 32bit behaviour with
> its 64bit equivalent.
>
> Signed-off-by: Marc Zyngier
This patch has the added benfit that it gets rid of a (gnu-specific)
case range.
Reviewed-by: Leif Lindholm
Thanks!
> ---
>
on which caused the build
> to break when compiling with clang.
>
> Break that out into a static helper function to make the code portable
> again.
Works for me.
Acked-by: Leif Lindholm
> Reported-by: Daniel Axtens
> Signed-off-by: Javier Martinez Canillas
> Tested-by:
Hi Javier,
On Tue, May 19, 2020 at 10:34:22 +0200, Javier Martinez Canillas wrote:
> Nested functions are supported as an extension in GNU C, but are not in
> the clang compiler. Commit cb2f15c5448 ("normal/main: Search for specific
> config files for netboot") added a nested function which caused
On Wed, May 13, 2020 at 14:02:46 +0200, Daniel Kiper wrote:
> Hey,
>
> As in subject... Please review...
Hi Daniel,
This looks good to me.
For the series:
Reviewed-by: Leif Lindholm
> Daniel
>
> INSTALL | 47 +++
&g
On Tue, Apr 21, 2020 at 16:55:25 +0200, Daniel Kiper wrote:
> > > > > You need to use following options to specify tools and platforms.
> > > > > For minimum
> > > > > version look at prerequisites. All tools not mentioned in this
> > > > > section under
> > > > > @@ -182,28 +182,31 @@ correspo
Hi Atish,
On Tue, Apr 28, 2020 at 11:21:05 -0700, Atish Patra wrote:
> > > Hello Ard,
> > >
> > > Did I misunderstand you and you want to provide a LOAD_FILE2
> > > implementation in GRUB and not use the one in the firmware?
> >
> > Yes. If you use GRUB, it is provided by GRUB. Otherwise, it can b
change the intended meaning of the text
> and only touches about the first 1300 of about 7000 lines
> in docs/grub.texi.
>
> Signed-off-by: Hans Ulrich Niedermann
A couple of *additional* comments below (on text being changed), but
for all the changes:
Reviewed-b
On Fri, Apr 10, 2020 at 05:05:48 -0700, Daniel Kiper wrote:
> On Tue, Apr 07, 2020 at 12:16:09PM +0100, Leif Lindholm wrote:
> > On Fri, Apr 03, 2020 at 14:45:02 +0200, Daniel Kiper wrote:
> > > ..to reflect the GRUB build reality in them.
> > >
> > > Additiona
may reduce pool of older compilers which can be used to
> > > build the GRUB. So, let's live with gnu99 until we do not discover that
> > > we strongly require a feature from newer C standard.
> > >
> > > Signed-off-by: Daniel Kiper
> > > ---
>
On Fri, Apr 03, 2020 at 14:45:02 +0200, Daniel Kiper wrote:
> ..to reflect the GRUB build reality in them.
>
> Additionally, fix ./configure command example formatting in INSTALL file.
>
> Signed-off-by: Daniel Kiper
> ---
> INSTALL | 51 +++
r
> ---
> v2 - suggestions/fixes:
>- unconditionally enforce gnu99 C language standard
> (suggested by Leif Lindholm).
> ---
> configure.ac | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index b2576b013..fc74ee800 100
On Thu, Apr 02, 2020 at 19:08:21 +0200, Daniel Kiper wrote:
> > > -# Optimization flag. Allow user to override.
> > > +if test "x$BUILD_CFLAGS" = x; then
> > > + BUILD_CFLAGS='-std=gnu99'
> > > +fi
> > > +
> > > +if test "x$HOST_CFLAGS" = x; then
> > > + HOST_CFLAGS='-std=gnu99'
> > > +fi
> > >
On Thu, Apr 02, 2020 at 17:07:48 +0200, Daniel Kiper wrote:
> Commit d5a32255d (misc: Make grub_strtol() "end" pointers have safer
> const qualifiers) introduced "restrict" keyword into some functions
> definitions. This keyword was introduced in C99 standard. However, some
> compilers by default m
On Tue, Mar 17, 2020 at 06:51:54 +0100, Patrick Steinhardt wrote:
> > > some open questions, and I'm not sure I feel comfortable with hitting
> > > master so close to the pending release. Let me know if you feel
> > > otherwise.
> >
> > I have the same feeling. So, if it is not very critical for y
On Tue, Mar 10, 2020 at 19:58:28 +0100, Patrick Steinhardt wrote:
> By default, GRUB will allocate a quarter of the pages it got available
> in the EFI subsystem. On many current systems, this will amount to
> roughly 800MB of RAM assuming an address space of 32 bits. This is
> plenty for most use
Hi Patrick,
On Thu, Feb 20, 2020 at 19:00:48 +0100, Patrick Steinhardt wrote:
> this is the second version of my patchset to add support for Argon2
> encryption keys for LUKS2.
>
> The most important change is that I've now verbosely imported the argon2
> code from the official reference implemen
On Thu, Feb 06, 2020 at 15:27:29 +0100, Patrick Steinhardt wrote:
> By default, GRUB will allocate a quarter of the pages it got available
> in the EFI subsystem. On many current systems, this will amount to
> roughly 800MB of RAM assuming an address space of 32 bits. This is
> plenty for most use
On Thu, Jan 16, 2020 at 13:14:39 +, Atish Patra wrote:
> > Thanks a lot for tackling this problem - it's been on the back
> burner for way too long :). Unfortunately this patch set loads grub
> via UEFI, but then does not execute Linux using the UEFI
> protocol. While that's a nice hack for sta
On Thu, Oct 31, 2019 at 11:37:40AM +0100, Javier Martinez Canillas wrote:
> From: Mark Salter
>
> Recent upstream changes to kexec-tools relies on #address-cells
> and #size-cells properties in the FDT. If grub2 needs to create
> a chosen node, it is likely because firmware did not provide one.
>
On Tue, Aug 06, 2019 at 08:52:09PM +0200, Heinrich Schuchardt wrote:
> > > > EFI_PXE_BASE_CODE_PACKET DhcpAck is a union:
> > > >
> > > > typedef union {
> > > > UINT8 Raw[1472];
> > > > EFI_PXE_BASE_CODE_DHCPV4_PACKET Dhcpv4;
> > > > EFI_PXE_BASE_CODE_DHCPV6_PA
+Peter Jones (sorry Peter)
On Tue, Aug 06, 2019 at 08:34:58AM +0200, Heinrich Schuchardt wrote:
> iPXE uses the EFI simple network protocol to execute DHCP.
OK.
> Can GRUB already do the same when the EFI_PXE_BASE_CODE_PROTOCOL is not
> present?
Yes. As of very recently (proper* DHCP support wa
On Fri, Jul 05, 2019 at 01:58:59PM +0100, Dimitri John Ledkov wrote:
> On Fri, 5 Jul 2019 at 13:48, David Michael wrote:
> >
> > The following are two use cases from Rajat Jain :
> >
> > 1) We have a board that boots Linux and this board itself can be
> >plugged into one of different chassis t
On Sat, Jul 06, 2019 at 12:23:17PM +0100, Leif Lindholm wrote:
> > Another use case is aarch64 laptops effort. We have the same kernel,
> > and the same image bootable and usable across 4 different laptop
> > models, with the only difference between them being the DTB to load.
&g
On Fri, Jul 05, 2019 at 08:47:02AM -0400, David Michael wrote:
> This adds the GUID, and includes it in lsefisystab output.
>
> Signed-off-by: David Michael
Oh, and here we already have the SMBIOS 3.0 entry, splendid.
Reviewed-by: Leif Lindholm
Daniel: please consider merging
ff-by: Heinrich Schuchardt
Good idea!
Reviewed-by: Leif Lindholm
This is also a good nudge that I ought to go through and update that
table in general. SMBIOS 3.0, ESRT and MEMATTR are missing - and some
of the others are architecture-specific.
/
Leif
> ---
> grub-core/comman
ectures in order to not get
missing symbol errors when running grub-mkimage.
Reported-by: Alexander Graf
Signed-off-by: Leif Lindholm
Tested-by: John Paul Adrian Glaubitz
---
Changes in v2:
- Alphabetically sort macros in conditional.
- Add Adrian's T-b.
include/grub/cache.h | 3 ++-
1
On Wed, Jun 05, 2019 at 12:11:00AM +0200, John Paul Adrian Glaubitz wrote:
> On 6/4/19 8:51 PM, Leif Lindholm wrote:
> > Add ia64 to the architectures excluding a declaration for
> > grub_arch_sync_dma_caches.
> >
> > IA64 does not include any of the source file
ectures in order to not get
missing symbol errors when running grub-mkimage.
Reported-by: Alexander Graf
Signed-off-by: Leif Lindholm
---
include/grub/cache.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/grub/cache.h b/include/grub/cache.h
index ccfa717e6..85819f
s actually make sense
But until someone steps up to clean up and look after mips, from my
point of view:
Reviewed-by: Leif Lindholm
> Signed-off-by: Alexander Graf
> ---
> .travis.yml | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/.tra
On Tue, Jun 04, 2019 at 03:37:39PM +0200, John Paul Adrian Glaubitz wrote:
> On 6/4/19 3:34 PM, Leif Lindholm wrote:
> > I am reasonably convinced this was simply neglected when d8901e3ba1
> > ("cache: Fix compilation for ppc, sparc and arm64") was pushed.
> > (An
On Tue, Jun 04, 2019 at 12:27:34PM +0200, Alexander Graf wrote:
> The IA64 target currently does not compile due to the following error
> message:
>
> grub-mkimage: error: undefined symbol grub_arch_sync_dma_caches.
>
> If anyone cares enough about IA64 to fix it up, be my guest and revert
> thi
On Tue, Jun 04, 2019 at 12:27:30PM +0200, Alexander Graf wrote:
> We've had an arm regression in grub recently where grub would not even
> be able to boot up anymore. So let's include arm and aarch64 in our
> simple "hello world" smoke tests as well.
>
> For OVMF on ARM to work, we need a newer ve
tions' flag used by GCC.
Reported-by: Alexander Graf
Signed-off-by: Leif Lindholm
---
Note: unless this is added before the travis-ci set, the arm ci build
will fail when enabled.
---
configure.ac | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/co
Hi Eric,
On Fri, May 31, 2019 at 07:22:26AM -0400, Eric McCorkle wrote:
> I've been doing some work to refurbish the FreeBSD port, and I may take
> over maintaining it. I also want to modify GRUB to pass GELI keys into
> the kernel using the newer keybuf mechanism, but that's later (I posted
> ab
On Wed, May 29, 2019 at 05:41:07PM +0200, Alexander Graf wrote:
> On 14.05.19 16:06, Leif Lindholm wrote:
> > On Tue, May 14, 2019 at 06:32:06AM -0700, Alexander Graf wrote:
> >>> But, wait...
> >>> arm-linux-gnueabi is the softfloat (v5te) toolchain - if we want
On Tue, May 28, 2019 at 11:27:08AM +0200, Daniel Kiper wrote:
> On Thu, May 23, 2019 at 10:31:13PM +0100, Dimitri John Ledkov wrote:
> > Specifically support dtb paths as created by flash-kernel package on
> > Debian/Ubuntu systems, and a generic one. Possibly this needs to be
> > extended to suppo
On Tue, May 14, 2019 at 06:32:06AM -0700, Alexander Graf wrote:
> > But, wait...
> > arm-linux-gnueabi is the softfloat (v5te) toolchain - if we want to
> > test that, fine - but we definitely need to test arm-linux-gnueabihf.
> >
> > First of all, I would expect that this toolchain will not use T3
Comment here as well:
On Thu, May 02, 2019 at 08:55:36AM +0200, Alexander Graf wrote:
> We hit an error case which only got triggered on ARM Thumb code. So
> let's make sure we test that combination as well.
This is the default for at least several and possibly most ARMv7-A
distributions/prebuilt
Just noticed this hadn't been merged, so time for a comment :)
On Thu, May 02, 2019 at 08:55:35AM +0200, Alexander Graf wrote:
> We've had an arm regression in grub recently where grub would not even
> be able to boot up anymore. So let's include arm and aarch64 in our
> simple "hello world" smoke
red because of the change
>
> 2) A missing adjustment in the original patch
>
> This patch set fixes both issues, making 32bit ARM targets for UEFI
> fully functional again for me.
This looks good to me.
Reviewed-by: Leif Lindholm
Tested-by: Leif Lindholm
Thanks!
>
On Tue, Apr 30, 2019 at 03:06:35PM +0200, Alexander Graf wrote:
> > Right, so with a brain that's actually awake:
> >
> >> ---
> >> util/grub-mkimagexx.c | 29 +
> >> 1 file changed, 13 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/util/grub-mkimagexx.c b/util/g
nes into the
> .text section instead. That way everyone knows they are executable.
>
> Fixes: a51f953f4ee87 ("mkimage: Align efi sections on 4k boundary")
> Reported-by: Julien ROBIN
> Reported-by: Leif Lindholm
>
> Signed-off-by: Alexander Graf
Right, so
xt section instead. That way everyone knows they are executable.
>
> Fixes: a51f953f4ee87 ("mkimage: Align efi sections on 4k boundary")
> Reported-by: Julien ROBIN
> Reported-by: Leif Lindholm
>
> Signed-off-by: Alexander Graf
I can confirm that in combination
On Mon, Apr 08, 2019 at 12:19:05PM +0300, Alexander Graf wrote:
> On 05.04.19 06:06, Leif Lindholm wrote:
> > This does bring to mind the clunkiness of the above. Marking
> > *everything* executable bypasses the improved security provided by the
> > firmware. Should I register
to release.
This complements f826330683675f0deb55b58fd229afd7d65fb053
("efi: change heap allocation type to GRUB_EFI_LOADER_CODE"), so I'm
all for it.
Reviewed-by: Leif Lindholm
This does bring to mind the clunkiness of the above. Marking
*everything* executable bypasses the improved se
On Thu, Feb 21, 2019 at 04:31:32PM +0100, Daniel Kiper wrote:
> On Thu, Feb 21, 2019 at 03:04:26PM +0000, Leif Lindholm wrote:
> > On Thu, Feb 21, 2019 at 02:46:11PM +, Steve McIntyre wrote:
> > > Much like on x86, we can work out if the system is running on top of
> &g
oad the efivar module and check for
> /sys/firmware/efi into a common helper routine is_efi_system()
>
> Signed-off-by: Steve McIntyre <93...@debian.org>
LGTM:
Reviewed-by: Leif Lindholm
> ---
> grub-core/osdep/basic/platfor
On Thu, Feb 21, 2019 at 02:53:48PM +, Steve McIntyre wrote:
> >> Right, this clearly needs a fix.
> >>
> >> > Heavily inspired by the existing code for x86.
> >>
> >> Mmm. I would much prefer if we could break out the efi test in a
> >> separate helper function. And clean it up while we're at i
Hi Steve,
On Mon, Feb 11, 2019 at 02:42:34AM +, Steve McIntyre wrote:
> Much like on x86, we can work out if the system is running on top of
> EFI firmware. If so, return "arm-efi". If not, fall back to
> "arm-uboot" as previously.
Right, this clearly needs a fix.
> Heavily inspired by the e
l value to GRUB_EFI_MAX_USABLE_ADDRESS, as originally
intended.
Reported-by: Steve McIntyre <93...@debian.org>
Signed-off-by: Leif Lindholm
---
grub-core/kern/efi/mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
On Fri, Feb 01, 2019 at 11:46:14AM +0100, Daniel Kiper wrote:
> > diff --git a/include/grub/arm/linux.h b/include/grub/arm/linux.h
> > index 712ba17b9..d0b24d474 100644
> > --- a/include/grub/arm/linux.h
> > +++ b/include/grub/arm/linux.h
> > @@ -42,7 +42,7 @@ struct linux_arm_kernel_header {
> >
On Wed, Jan 23, 2019 at 05:53:00PM +0100, Daniel Kiper wrote:
> On Wed, Jan 23, 2019 at 11:47:25AM +0000, Leif Lindholm wrote:
> > On Tue, Jan 22, 2019 at 05:09:18PM +0100, Alexander Graf wrote:
> > > On 17.01.19 13:24, Daniel Kiper wrote:
> > > > On Mon, No
On Tue, Jan 22, 2019 at 05:09:18PM +0100, Alexander Graf wrote:
> On 17.01.19 13:24, Daniel Kiper wrote:
> > On Mon, Nov 26, 2018 at 12:38:11AM +0100, Alexander Graf wrote:
> >> We currently only support to run grub on RISC-V as UEFI payload. Ideally,
> >> we also only want to support running Linux
A certain amount of dynamic space is required for the handover from
GRUB/Linux-EFI-stub. This entails things like initrd addresses,
address-cells entries and associated strings.
But move this into a proper centralised #define rather than live-code
it in the loader.
Signed-off-by: Leif Lindholm
On Thu, Jan 17, 2019 at 01:24:29PM +0100, Daniel Kiper wrote:
> > +static grub_err_t
> > +finalize_params_linux (void)
> > +{
> > + int node, retval;
> > +
>
> Please drop this empty line.
>
> > + void *fdt;
> > +
> > + fdt = grub_fdt_load (0x400);
>
> Why this number? Please define constant
On Mon, Jan 14, 2019 at 02:41:30PM +0100, Alexander Graf wrote:
> On 01/14/2019 02:37 PM, Daniel Kiper wrote:
> > On Sun, Dec 23, 2018 at 03:52:07AM +0100, Alexander Graf wrote:
> > > In order to enforce NX semantics on non-code pages, UEFI firmware
> > > may require that all code is EFI_PAGE_SIZE
On Thu, Jan 10, 2019 at 09:59:38AM +0100, Alexander Graf wrote:
> > Am 10.01.2019 um 09:12 schrieb Michael Chang :
> >
> > Hi,
> >
> > With the advent of new verifier framework and shim lock protocol support
> > to the grub's community, we are driving to the world of UEFI Secure
> > Boot, well, a
ust bumps the
> header alignment to 4K always on arm64-efi. This way we improve overall
> compatibility - there surely will be more devices coming with similar
> constraints.
>
> v1 -> v2:
>
> - Remove explicit device wording from patch
> - Use GRUB_EFI_PAGE
, yes.
Reviewed-by: Leif Lindholm
> ---
> grub-core/loader/efi/fdt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/grub-core/loader/efi/fdt.c b/grub-core/loader/efi/fdt.c
> index a18ca8ccb..ee9c5592c 100644
> --- a/grub-core/loader/efi/fdt.
On Wed, Nov 28, 2018 at 03:31:05PM +0100, Alexander Graf wrote:
> I got a new toy this week: An HP Envy X2 system. This is one of those shiny
> new Qualcomm Snapdragon based Windows tablet/notebook hybrid things.
>
> While running Windows on those is actually not a terribly bad experience now
> th
Hi Alex,
On Wed, Nov 28, 2018 at 03:31:05PM +0100, Alexander Graf wrote:
> I got a new toy this week: An HP Envy X2 system. This is one of those shiny
> new Qualcomm Snapdragon based Windows tablet/notebook hybrid things.
>
> While running Windows on those is actually not a terribly bad experienc
se their threat level is the same.
>
> Signed-off-by: Alexander Graf
Acked-by: Leif Lindholm
>
> ---
>
> v3 -> v4:
>
> - Rebase onto current git master
> ---
> grub-core/commands/efi/shim_lock.c | 1 +
> include/grub/file.h| 4 ++
On Mon, Nov 19, 2018 at 11:11:09AM +0100, Andreas Schwab wrote:
> On Nov 14 2018, Alexander Graf wrote:
>
> > diff --git a/grub-core/loader/efi/fdt.c b/grub-core/loader/efi/fdt.c
> > index a4c6e8036..d8ebe648e 100644
> > --- a/grub-core/loader/efi/fdt.c
> > +++ b/grub-core/loader/efi/fdt.c
> > @@
On Fri, Nov 16, 2018 at 03:05:22PM +0100, Daniel Kiper wrote:
> On Wed, Nov 14, 2018 at 07:29:14PM +0000, Leif Lindholm wrote:
> > The verifiers framework caused some breakage for non-x86
> > platforms that need fixing.
> >
> > Basically, this boils down to:
> > -
The verifiers framework changed the grub_file_open interface,
breaking all non-x86 linux loaders.
Add file types to the grub_file_open calls to make them build
again.
Signed-off-by: Leif Lindholm
---
Bundling these changes together in a single patch, since I
haven't actually tested
- add variable "err" (used but not defined)
- add GRUB_FILE_TYPE_LINUX_KERNEL to grub_file_open call
Signed-off-by: Leif Lindholm
---
grub-core/loader/arm64/linux.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/grub-core/loader/arm64/linux.c b/grub-core/lo
common and arm64 fixes have actually been tested.
Fu Wei, Julien - can you guys have a look at fixing arm64/xen_boot.c?
I'm not 100% certain how multiboot should be handled.
Cc: Fu Wei
Cc: Julien Grall
Reported-by: Alexander Graf
Leif Lindholm (5):
grub/verify.h: add include guard
f
The verifiers framework changed the api of grub_file_open, but did not
fix up all users. Add the file type GRUB_FILE_TYPE_DEVICE_TREE_IMAGE
to the "devicetree" command handler call.
Signed-off-by: Leif Lindholm
---
grub-core/loader/efi/fdt.c | 2 +-
1 file changed, 1 insertion(+),
verify.h was added without include guards. This means compiling anything
including both grub/verify.h and grub/lib/cmdline.h fails (at least
loader/arm64/linux.c.
Add the necessary include guard.
Signed-off-by: Leif Lindholm
---
include/grub/verify.h | 5 +
1 file changed, 5 insertions
The api change of grub_file_open for adding verifiers did not include
a type for device tree blobs. Add GRUB_FILE_TYPE_DEVICE_TREE_IMAGE to
the grub_file_type enum.
Signed-off-by: Leif Lindholm
---
include/grub/file.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/grub/file.h b
ion of
https://docs.microsoft.com/en-gb/windows/desktop/Debug/pe-format
Reviewed-by: Leif Lindholm
> ---
> include/grub/efi/pe32.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/grub/efi/pe32.h b/include/grub/efi/pe32.h
> index 7d44732d2..d1359eb66 100644
&
ly.
>
> Signed-off-by: Alexander Graf
Certainly no objection to this.
Only comment: if this is the way to go, perhaps linux.c should move to
loader/efi/linux-generic.c or something?
Anyway - Acked-by: Leif Lindholm
> ---
> grub-core/loader/arm64/linux.c| 10 +-
> gru
On Tue, Aug 28, 2018 at 01:33:48PM -0600, dann frazier wrote:
> From: dann frazier
>
> We currently default to the arm-uboot target in grub-install,
> but arm-efi should be used for some systems with UEFI firmware, such as
> Tianocore/EDK2-based QEMU models. We could change the default to arm-efi
Delete local copy of function to determine required buffer size for the
UEFI memory map, use helper in kern/efi/mm.c.
Signed-off-by: Leif Lindholm
---
grub-core/loader/ia64/efi/linux.c | 46 ++-
1 file changed, 2 insertions(+), 44 deletions(-)
diff --git a
Delete local copy of function to determine required buffer size for the
UEFI memory map, use helper in kern/efi/mm.c.
Signed-off-by: Leif Lindholm
---
grub-core/loader/multiboot_mbi2.c | 38 +-
1 file changed, 1 insertion(+), 37 deletions(-)
diff --git a
ested.
Leif Lindholm (3):
loader/i386/linux: use central copy of grub_efi_find_mmap_size
loader/ia64/linux: use central copy of grub_efi_find_mmap_size
loader/multiboot_mbi2: use central copy of grub_efi_find_mmap_size
grub-core/loader/i386/linux.c
Delete local copy of function to determine required buffer size for the
UEFI memory map, use helper in kern/efi/mm.c.
Signed-off-by: Leif Lindholm
---
grub-core/loader/i386/linux.c | 51 +--
1 file changed, 1 insertion(+), 50 deletions(-)
diff --git a
On Fri, Jul 13, 2018 at 03:59:38PM +0200, Daniel Kiper wrote:
> On Fri, Jul 13, 2018 at 01:53:52PM +0100, Leif Lindholm wrote:
> > On Fri, Jul 13, 2018 at 01:27:08PM +0200, Daniel Kiper wrote:
> > > > > > (i386_)ieee1275 implements its own grub_reboot(), so that should
On Fri, Jul 13, 2018 at 01:27:08PM +0200, Daniel Kiper wrote:
> > > > (i386_)ieee1275 implements its own grub_reboot(), so that should be
> > > > fine. (This does mean that i386_ieee1275 may currently be unable to
> > > > load the reboot module on master.)
> > >
> > > Hmmm... So, it looks that your
On Thu, Jul 12, 2018 at 01:44:36PM +0200, Daniel Kiper wrote:
> On Wed, Jul 11, 2018 at 12:53:01PM +0100, Leif Lindholm wrote:
> > On Wed, Jul 11, 2018 at 01:03:12PM +0200, Daniel Kiper wrote:
> > > On Mon, Jul 09, 2018 at 07:49:06PM +0100, Leif Lindholm wrote:
> > >
On Wed, Jul 11, 2018 at 01:03:12PM +0200, Daniel Kiper wrote:
> On Mon, Jul 09, 2018 at 07:49:06PM +0100, Leif Lindholm wrote:
> > Commit 0ba90a7f0178 ("efi: Move grub_reboot() into kernel") broke
> > the build on i386-efi - genmoddep.awk bails out with message
>
each i386 platform variant in
Makefile.core.def, include the contents of lib/i386/reset.c only when
GRUB_MACHINE_EFI is not set.
Signed-off-by: Leif Lindholm
---
grub-core/lib/i386/reboot.c | 4
1 file changed, 4 insertions(+)
diff --git a/grub-core/lib/i386/reboot.c b/grub-core/lib/i38
runtime.
Signed-off-by: Leif Lindholm
---
grub-core/kern/efi/mm.c | 31 +++
include/grub/efi/efi.h | 3 +++
2 files changed, 34 insertions(+)
diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
index fd39d23b4..b7cf144e5 100644
--- a/grub-core/kern/efi/mm.c
The 32-bit arm efi port now shares the 64-bit linux loader, so delete
the now unused bits from the 32-bit linux loader.
This in turn leaves the grub-core/kern/arm/efi/misc.c unused, so
delete that too.
Signed-off-by: Leif Lindholm
---
grub-core/Makefile.am | 1 -
grub-core/kern/arm
.
Signed-off-by: Leif Lindholm
---
grub-core/loader/arm64/linux.c | 39 ++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c
index f90c5f926..1f86229f8 100644
--- a/grub-core/loader/arm64
There are several implementations of this function in the tree.
Add a central version in grub-core/efi/mm.c.
Signed-off-by: Leif Lindholm
---
grub-core/kern/efi/mm.c | 20
include/grub/efi/efi.h | 1 +
2 files changed, 21 insertions(+)
diff --git a/grub-core/kern/efi
In preparation for using the linux loader for 32-bit and 64-bit platforms,
rename grub_arm64*/GRUB_ARM64* to grub_armxx*/GRUB_ARMXX*.
Move prototypes for now-common functions to efi/efi.h.
Signed-off-by: Leif Lindholm
---
grub-core/loader/arm64/linux.c| 14 +++---
grub-core/loader
Linux kernels from booting on arm-efi.
Signed-off-by: Leif Lindholm
---
grub-core/Makefile.core.def | 7 ---
grub-core/kern/efi/mm.c | 2 +-
include/grub/arm/linux.h| 5 +
include/grub/efi/efi.h | 2 --
4 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/grub-core
1 - 100 of 386 matches
Mail list logo
