Hello back,
After reading the mail archive, I found the following messages
from Alexander Graf
I was already happy, then I saw that the patch was into others
mails :
- https://lists.gnu.org/archive/html/grub-devel/2018-12/msg00054.html
- https://lists.gnu.org/archive/html/grub-devel/2018-12/msg00055.html
Thousands of thanks to him ! I guess PIC / PIE options were a wrong way. I don't know why those options were causing trouble when trying it on "UEFI-SIMPLE" if the problem wasn't this.
Let's say Asus Novago, TP370QL is now supported too :)
I'm really happy to see an error message appearing ! With
"Welcome to GRUB!" displayed on this screen after all that time
freezing, I'm happy. I will try to manage to boot Debian or Ubuntu
installers (distros using Kernel 4.18 or more, in order to have
all the Qualcomm things that have been mainlined recently) by
configuring it the right way.
| Sujet : | GRUB rebuild without -fno-PIC and -fno-pie / -fno-PIE options for ARM 64 (Qualcomm EFI) |
|---|---|
| Date : | Sun, 30 Dec 2018 16:34:24 +0100 |
| De : | Julien ROBIN <address@hidden> |
| Pour : | address@hidden |
Hello everybody,
I feel sorry to mail everyone and I hope this won't disturb too
much people. But I'm stuck and I'm pretty sure your help will be
valuable.
First I would like to give all the information :
I have a laptop computer (Asus Novago, TP370QL) running on an
ARM64 platform (Qualcomm Snapragon 835), with UEFI support,
Secure Boot disabled, and "Boot USB First" enabled. It's a
laptop shaped smart-phone that has the same features that a
standard x86_64-efi computer.
It's delivered with Windows 10 Pro on it, installed in the
exact same way that on a x86_64-efi computer (same partitions
scheme, ESP, recovery, same files etc... just it's aarch64 built
instead of x86_64).
I have a working USB re-installation media (that can be booted
trough EFI) and I already successfully cleared the entire disk
(like dd if=/dev/zero of=/dev/sda but with Windows "diskpart"
and "clean" commands). And of course the re-installation media
is working - if not I would have been really disappointed ;)
I'm also able to boot EFI files on it, I just have to ensure the USB disk (or SD card) has GPT partitionning, at least 1 partition that is ESP type, and FAT32 formatted, containing a "/efi/boot/bootaa64.efi" file that the computer will execute at startup.
Is some of you are interested in seeing what it looks like : http://image.noelshack.com/fichiers/2018/52/6/1546083005-infact.png
My problem :
GRUB doesn't work (it freezes on the "Asus" logo and I have to
force shutdown the computer by pressing the power button 5
seconds). Same problem for GRUB versions used in Debian, Ubuntu,
even Buster and 18.10 versions (using 4.18 kernel, where all the
Qualcomm things are now mainlined).
And by seeing what are the gcc used options for GRUB, and
comparing those options with the ones that are used for the
working "UEFI-SIMPLE" (https://github.com/pbatard/uefi-simple),
I found that the -fno-PIE, -fno-pie, and -fno-pic and -fno-PIC
options shouldn't be used ! The default compiler behavior is the
right one (-fPIC and -fPIE are enabled by default) but grub
Makefiles are disabling it. And it does not work on this
computer when disabled. If one of the "-fno-PIE -fno-pie
-fno-pic -fno-PIC" are used, the computer won't be able to start
the resulting UEFI-SIMPLE efi file.
The "-no-pie" option, however, isn't causing any problem (and
can be used in parallel of -fPIC and -fPIE option, even if it
sound pretty strange : the resulting UEFI-SIMPLE efi file is
still working that way). As I understand, those options are
dealing with Global Offset Tables (GOT) with more information
here : https://en.wikipedia.org/wiki/Position-independent_code
What I did and where I'm stuck :
I'm trying to create a GRUB efi file that my ARM64 computer
will be able to execute, even if the first result is a working
error message ! I would then be happy because I will then manage
to reconfigure things in order to make the debian installer to
start with this grub file. Having grub to work on this computer
is my quest, today. In order to test what should happen when it
will be working, I already did that on a x86_64-efi computer
(and I got an error message and a grub-rescue line but that's
fine).
I downloaded the grub source code here : ftp://ftp.gnu.org/gnu/grub/grub-2.02.tar.gz
And I found an ARM64 computer already working on Linux (Debian
9) on "Scaleway" provider, in order to build things in an easy
way.
By running ./configure command, then make -j 4, and by playing
with grub-install, it's giving an EFI file that my arm64
computer won't boot (freeze). So I tried to modify the
"configure" file by commenting lines 26055, 26056, 26057, then
26116, 26117.
# Need that, because some distributions ship compilers that include
# `-fPIE' or '-fpie' and '-pie' in the default specs.
# if [ x"$pie_possible" = xyes ]; then
# TARGET_CFLAGS="$TARGET_CFLAGS -fno-PIE -fno-pie"
# fi
if ( test x$target_cpu = xmips || test x$target_cpu = xmipsel || test x$target_cpu = xarm64 ) && test "x$grub_cv_cc_target_clang" = xyes ; then
TARGET_CFLAGS="$TARGET_CFLAGS -fPIC"
#elif [ x"$pic_possible" = xyes ]; then
# TARGET_CFLAGS="$TARGET_CFLAGS -fno-PIC"
fi
Disabling those options are making, by default, the -fPIE and -fPIC flags active. This is not compatible with the mcmodel=large flag, so I disabled it too, in conf/Makefile.common : 17, 18, 19
#if COND_arm64
# CFLAGS_PLATFORM += -mcmodel=large
#endif
However, disabling only the -mcmodel=large flag, with no other modification, is already giving an error at the end of the build process, when trying to transform the xxx.module files into xxx.mod files.
TARGET_OBJ2ELF= sh genmod.sh moddep.lst disk.module build-grub-module-verifier disk.mod
build-grub-module-verifier: error: relocation 0x113 is not module-local.
Removing the -fno-PIC, -fno-PIE and -fno-pie flags then leads
to a different error, at the end too.
TARGET_OBJ2ELF= sh genmod.sh moddep.lst acpi.module build-grub-module-verifier acpi.mod
build-grub-module-verifier: error: LD64_GOT_LO12_NC without matching ADR_GOT_PAGE.
Enabling the -fpic and -fpie flags (lower case) is leading to another error :
_GLOBAL_OFFSET_TABLE_ in acpi is not defined
_GLOBAL_OFFSET_TABLE_ in affs is not defined
_GLOBAL_OFFSET_TABLE_ in afs is not defined
_GLOBAL_OFFSET_TABLE_ in [...] is not defined
[...]
I also tried to remove the -no-pie flag but it makes another
flag (-Wl,-r) incompatible. When I removed the -r flag to the
linker, I got sooner build errors when trying to create *.module
files from *.o files
gcc [...] -o disk.module lib/disk_module-disk.o
/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 00000000004004e0
lib/disk_module-disk.o: In function `grub_disk_cache_invalidate':
/home/debian/grub-2.02/grub-core/lib/disk.c:42: undefined reference to `grub_disk_cache_table'
/home/debian/grub-2.02/grub-core/lib/disk.c:48: undefined reference to `grub_free'
[...and lot of others 'undefined reference' errors...]
So here I'm stuck ! Despite the days I spent on this, I'm definitely not able to deal with those flags as finely as you, developers, seemed to enable it or disable it in different portions of the grub's code.
Can someone help me in this quest of having grub working on
those Qualcomm ARM64 laptops ? I think the initial mission is to
re-enable the -fPIC and -fPIE flags but it's like this missions
implies others missions to succeed.
Thank you (very) much in advance for your help !
Best regards,
Julien ROBIN