Fedora/RHEL Sauce doesn't work on the Surface Pro X

[Maximilian Luz]

The Surface Pro X seems to be a bit picky about GRUB modifications.

What works

Upstream grub-2.06 works using the following procedure to cross-compile from a non-ARM host:

./bootstrap
./configure --with-platform=efi --target=aarch64-linux-gnu
make
make DESTDIR="${PWD}../grub-install install"

This creates modules for aarch64 as well as host-tools that will run on the current host architecture (e.g. x86_64). Those can then be used to generate a self-contained bootaa64.efi image as follows (from ../grub-install directory):

./usr/local/bin/grub-mkimage                \
    -O arm64-efi -o bootaa64.efi --prefix=  \
    -d $PWD/usr/local/lib/grub/arm64-efi    \
    $(cat grubmodules.txt)

using grubmodules.txt from https://github.com/SMFloris/acer-spin7-linux/blob/main/grub/grubmodules.txt. I've tested this both on an Arch Linux host and a Fedora 35 container using aarch64-linux-gnu-gcc (or gcc-aarch64-linux-gnu on Fedora).

What doesn't

The same procedure using fedora-36 (or any other Fedora branch that I've tested). Failures start with include and other errors during compilation compilation, which can be fixed by changing the configure command to

./configure                     \
    HOST_CPPFLAGS="-I$(pwd)"    \
    TARGET_CPPFLAGS="-I$(pwd)"  \
    --with-platform="efi"       \
    --with-utils="host"         \
    --disable-werror            \
    --disable-rpm-sort          \
    --target=aarch64-linux-gnu

Similarly, using the precompiled aarch64 modules from either Fedora OpenSuse (similar to https://github.com/SMFloris/acer-spin7-linux) doesn't work. I assume OpenSuse uses the same Fedora/RHEL patches.

Unfortunately, git bisect is pretty much impossible on the Fedora/RHEL patches as about 90% of them seem to introduce some new build failure. I've narrowed the problem down to the following four commits (applied on top of grub-2.06):

• 8e07346 ("Add support for Linux EFI stub loading.")
• b3c53b6 ("Add secureboot support on efi chainloader")
• 68728a6 ("Make any of the loaders that link in efi mode honor secure boot.")
• ef491c6 ("Rework how the fdt command builds.")

[Dorian Stoll]

I dont know a lot about GRUB and even less about SPX / ARM, but random thought: The first commit you linked changes the linux command, so that it doesnt pass the kernel image to the UEFI, but instead loads it, parses the PE header and then jumps to some handover function defined in that header.

I digged around a bit and found this, which might be related? torvalds/linux@5b94046 The version numbers seem to line up with the 5.13 kernel that seems to be the most current one for the SPX.

[Maximilian Luz]

The first commit you linked changes the linux command, so that it doesnt pass the kernel image to the UEFI, but instead loads it, parses the PE header and then jumps to some handover function defined in that header.

Yeah, haven't looked into it in detail yet but I gathered that it replaces the default Linux image loading mechanism with some custom loader from the commit message.

Thanks for that pointer! Looks like that could indeed be the cause of this issue. I definitely need to test this.

[Maximilian Luz]

So cherry picking that commit onto my v5.13 branch didn't work. I should probably finally update the patches to v5.17 already... Before that I'll probably set up a build for a known good GRUB image so that we have something (more or less) reliable to start with.

[Maximilian Luz]

I've set up an automated build system at https://github.com/linux-surface/grub-image-aarch64. See releases/packages and README for details.

[Maximilian Luz]

Turns out memory for the kernel code pages is allocated as "data" and not "code", and the SPX seems to be pretty much the only aarch64 device that cares about that... Fixed with 55b95a3, and I've opened up a PR in rhboot/grub2.