On Fri, May 12, 2023 at 12:09:14AM +0200, Ard Biesheuvel wrote:
> Thanks, this could be helpful if we manage to find people that have
> the bandwidth to keep working on this. Would you be willing to spend
> time and development effort yourself on building and installing GRUB
> from the upstream rep
On 2023-05-11 18:09, Ard Biesheuvel wrote:
On Thu, 11 May 2023 at 20:59, matoro
wrote:
On 2023-05-11 10:29, Ard Biesheuvel wrote:
> On Thu, 11 May 2023 at 15:34, John Paul Adrian Glaubitz
> wrote:
>>
>> On Thu, 2023-05-11 at 14:17 +0200, Ard Biesheuvel wrote:
>> > On Thu, 11 May 2023 at 14:14
On Thu, 11 May 2023 at 20:59, matoro
wrote:
>
> On 2023-05-11 10:29, Ard Biesheuvel wrote:
> > On Thu, 11 May 2023 at 15:34, John Paul Adrian Glaubitz
> > wrote:
> >>
> >> On Thu, 2023-05-11 at 14:17 +0200, Ard Biesheuvel wrote:
> >> > On Thu, 11 May 2023 at 14:14, John Paul Adrian Glaubitz
> >>
On 2023-05-11 10:29, Ard Biesheuvel wrote:
On Thu, 11 May 2023 at 15:34, John Paul Adrian Glaubitz
wrote:
On Thu, 2023-05-11 at 14:17 +0200, Ard Biesheuvel wrote:
> On Thu, 11 May 2023 at 14:14, John Paul Adrian Glaubitz
> wrote:
> >
> > On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote
On Thu, 11 May 2023 at 15:34, John Paul Adrian Glaubitz
wrote:
>
> On Thu, 2023-05-11 at 14:17 +0200, Ard Biesheuvel wrote:
> > On Thu, 11 May 2023 at 14:14, John Paul Adrian Glaubitz
> > wrote:
> > >
> > > On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote:
> > > > Itanium IA-64 support is
On Thu, 2023-05-11 at 14:17 +0200, Ard Biesheuvel wrote:
> On Thu, 11 May 2023 at 14:14, John Paul Adrian Glaubitz
> wrote:
> >
> > On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote:
> > > Itanium IA-64 support is obsolete, and implements its own flavor of EFI
> > > boot that deviates from
On Thu, May 11, 2023 at 02:17:57PM +0200, Ard Biesheuvel wrote:
>On Thu, 11 May 2023 at 14:14, John Paul Adrian Glaubitz
> wrote:
>>
>> On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote:
>> > Itanium IA-64 support is obsolete, and implements its own flavor of EFI
>> > boot that deviates from
On Thu, 11 May 2023 at 14:14, John Paul Adrian Glaubitz
wrote:
>
> On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote:
> > Itanium IA-64 support is obsolete, and implements its own flavor of EFI
> > boot that deviates from other architectures. Given that IA64 is unused
> > and unmaintained, i
On Thu, 11 May 2023 at 14:06, Ard Biesheuvel wrote:
>
> Switch the x86 based EFI platform builds to the generic EFI loader,
> which exposes the initrd via the LoadFile2 protocol instead of the
> x86-specific setup header. This will launch the Linux kernel via its EFI
> stub, which performs its own
On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote:
> Itanium IA-64 support is obsolete, and implements its own flavor of EFI
> boot that deviates from other architectures. Given that IA64 is unused
> and unmaintained, it makes no sense to pretend that the EFI changes we
> are making are teste
The call wrappers are no longer needed now that GCC can generate
function calls using MS calling convention, so let's get rid of them.
Signed-off-by: Ard Biesheuvel
---
grub-core/Makefile.core.def | 1 -
grub-core/kern/x86_64/efi/callwrap.S | 129
include/grub/efi
The grub_efi_pxe_t struct definition has placeholders for the various
protocol method pointers, given that they are never called in the code,
and the prototypes have been omitted, and therefore do not comply with
the UEFI spec.
So let's convert them into void* pointers, so they cannot be called
in
Switch the i386-efi and x86_64-efi builds to the generic EFI loader,
which enters the Linux kernel via the EFI stub and provides the initrd
via the LoadFile2 protocol. This unifies x86 with other EFI
architectures, and removes the dependency on the setup header and struct
bootparams.
Do some prepa
Itanium IA-64 support is obsolete, and implements its own flavor of EFI
boot that deviates from other architectures. Given that IA64 is unused
and unmaintained, it makes no sense to pretend that the EFI changes we
are making are tested or supported on IA64, so let's just get rid of it.
Signed-off-
Now that GCC can generate function calls using the correct calling
convention for us, we can stop using the efi_call_XX () wrappers, and
just dereference the function pointers directly.
This avoids the untyped variadic wrapper routines, which means better
type checking for the method calls.
Signe
Switch the x86 based EFI platform builds to the generic EFI loader,
which exposes the initrd via the LoadFile2 protocol instead of the
x86-specific setup header. This will launch the Linux kernel via its EFI
stub, which performs its own initialization in the EFI boot services
context before calling
UEFI mandates MS calling convention on x86_64, which was not supported
on GCC when UEFI support was first introduced into GRUB. However, now we
can use the ms_abi function type attribute to annotate functions and
function pointers as adhering to the MS calling convention, and the
compiler will gene
On Wed, 10 May 2023 at 19:40, Ard Biesheuvel wrote:
>
> On Wed, 10 May 2023 at 15:15, Daniel Kiper wrote:
> >
> > On Wed, May 10, 2023 at 12:40:30PM +0200, Ard Biesheuvel wrote:
> > > On Tue, 9 May 2023 at 18:53, Ard Biesheuvel wrote:
> > > >
> > > > Switch the x86_64 build to the generic EFI lo
18 matches
Mail list logo
