[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Solved: GRUB rebuild without -fno-PIC and -fno-pie / -fno-PIE options fo

From: Julien ROBIN
Subject: Solved: GRUB rebuild without -fno-PIC and -fno-pie / -fno-PIE options for ARM 64 (Qualcomm EFI)
Date: Sun, 30 Dec 2018 23:54:45 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

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 :

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.

Best regards,
Julien ROBIN

-------- Message transféré --------
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 :

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" (, 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 :

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 :

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
# 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
#elif [ x"$pic_possible" = xyes ]; then

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

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 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 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]