The commit 80948f532d (lib/i386/relocator64: Build fixes for i386) has
broken 64-bit FreeBSD boot on BIOS. This patch fixes the issue.
Fixes: 80948f532d (lib/i386/relocator64: Build fixes for i386)
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This fixes cross-compiling to x86 (e.g., the Hurd) from x86-linux of
grub-core/lib/i386/relocator64.S
This file has six sections that only build with a 64-bit assembler,
yet only the first two sections had support for a 32-bit assembler.
This patch completes this for the remaining sections.
To reproduce, update the GRUB source description in your local Guix
archive and run
./pre-inst-env guix build --system=i686-linux --target=i586-pc-gnu grub
or install an x86 cross-build environment on x86-linux (32-bit!) and
configure to cross build and make, e.g., do something like
./configure \
CC_FOR_BUILD=gcc \
--build=i686-unknown-linux-gnu \
--host=i586-pc-gnu
make
Additionally, remove a line with redundant spaces.
Signed-off-by: Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Unified Extensible Firmware Interface Specification, Version 2.6,
section 2.3.4, x64 Platforms, boot services, says among others:
The stack must be 16-byte aligned. So, do it. Otherwise OS may
boot only by chance as it happens right now.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS. Relocator
will set lower parts of %rax and %rbx accordingly to multiboot2 specification.
On the other hand processor mode, just before jumping into loaded image, will
be set accordingly to Unified Extensible Firmware Interface Specification,
Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services. This way
loaded image will be able to use EFI boot services without any issues.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Vladimir 'phcoder' Serbinenko