[SOLVED] How to rebuild GRUB (efi) with modifications

[jrobin28260]

Hi everybody
My mission is having the bootaa64.efi file working on my ARM64 Laptop (Asus Novago), which is able to boot others "bootaa64.efi" files. Today, Debian and Ubuntu versions does not boot (it freezes at running the EFI file).

I successfully managed to build an ISO in a way that is identical to the official way, using https://salsa.debian.org/images-team/debian-cd and having a local mirror as needed. But it does not rebuild all the packages, it just put them together into a new ISO file.

Also, with https://github.com/pbatard/uefi-simple I successfully managed to compile my own "aarch64.efi" file (for an ARM64 Laptop) and having it working on my ARM64 Laptop (it just shows a message and a "press any key" message in order to check if it works - and it works). On this ARM64 computer (Qualcomm Snapdragon 835 CPU) I'm also able to boot Windows and a working Windows installer. BUT : Linux distros EFI files do not boot (it freezes and does nothing) and I want to debug it, by building the EFI file myself, and customize code and target options in order understand what's not working (and may be find a solution). (Same problem for Ubuntu ARM64 and Debian ARM64)

What is the way to do, the correct entry point, if I want to rebuild my own version of Debian Grub "bootaa64.efi" file ?
I'm interested in doing this on the "Buster" version because Linux 4.18 and higher already contains all the necessary drivers for having Qualcomm functionnalities working out of the box with no kernel modifications

Thanks in advance !

[Head_on_a_Stick]

The grub-efi package is only available for the x86 architectures, unfortunately.

You could try systemd-boot, that provides /usr/lib/systemd/boot/efi/systemd-bootaa64.efi

If that is copied to ${ESP}/efi/boot/bootaa64.efi then the UEFI firmware should boot it automatically.[1]

The systemd-boot program looks for the configuration files defined on the ArchWiki page:

https://wiki.archlinux.org/index.php/Systemd-boot

I boot my (x86) Debian stable system this way, it works well

EDIT: the kernel & initramfs need to be on the ESP for this to work, see https://wiki.debian.org/EFIStub for an example of a kernel post-install script that can automate this task.

[jrobin28260]

That's a good entry point it means that what I'm looking to rebuild (the bootaa64.efi file) is not grub - In that case, I would have lost a lot of time by searching about GRUB

I noticed on a Intel x86_64 computer that placing "bootx64.efi" file only (the one contained into the amd64 ISO), grub command line appears on the screen
By doing the same on my Qualcomm aarch64 device with the "bootaa64.efi" from the ARM64 ISO, nothing happens (freeze), so I thought it was a grub EFI file problem

Seeing the packet "https://packages.debian.org/fr/buster/grub-efi-arm64" also gave me some doubts... Are you sure that the ARM64 version of the ISO isn't using it ?

Anyway, I'm going to take a look at your link : https://wiki.archlinux.org/index.php/Systemd-boot
I hope this will help me in my quest about "how to" !

[Head_on_a_Stick]

See my edit, the kernel image & initramfs need to be on the EFI system partition for systemd-boot to work.

[Head_on_a_Stick]

Seeing the packet "https://packages.debian.org/fr/buster/grub-efi-arm64" also gave me some doubts... Are you sure that the ARM64 version of the ISO isn't using it ?

Oh yes, my mistake, sorry, don't know how I missed that.

Ah well, now you have an alternative method

[jrobin28260]

An alternative method is more than welcome when talking about another one which doesn't work thank you !

[jrobin28260]

I've made some steps forward in my quest, I've found and downloaded the original/non-debian grub source code at ftp://ftp.gnu.org/gnu/grub/grub-2.02.tar.xz file and extracted it into a dedicated folder on my Desktop
Where can I find the equivalent file for Debian's version of grub ?

I've played the following lines :

Code: Select all

./configure
make

And I got a successful build of grub in its i386-pc version... that was not what was expected but I had no error. I saw on the Internet that I should play
./configure --platform=efi
But it tells me that platform isn't a recognized option, and I don't know what is the option for having an x86_64 efi version (and not a i386-pc version). May be I should go to a computer running Debian trough EFI ?
EDIT : OK nevermind, it was ./configure --with-platform=efi

./configure --help gives the following result :

Code: Select all

`configure' configures GRUB 2.02 to adapt to many kinds of systems.

Usage: ./configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE.  See below for descriptions of some of the useful variables.

Defaults for the options are specified in brackets.

Configuration:
  -h, --help              display this help and exit
      --help=short        display options specific to this package
      --help=recursive    display the short help of all the included packages
  -V, --version           display version information and exit
  -q, --quiet, --silent   do not print `checking ...' messages
      --cache-file=FILE   cache test results in FILE [disabled]
  -C, --config-cache      alias for `--cache-file=config.cache'
  -n, --no-create         do not create output files
      --srcdir=DIR        find the sources in DIR [configure dir or `..']

Installation directories:
  --prefix=PREFIX         install architecture-independent files in PREFIX
                          [/usr/local]
  --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
                          [PREFIX]

By default, `make install' will install all the files in
`/usr/local/bin', `/usr/local/lib' etc.  You can specify
an installation prefix other than `/usr/local' using `--prefix',
for instance `--prefix=$HOME'.

For better control, use the options below.

Fine tuning of the installation directories:
  --bindir=DIR            user executables [EPREFIX/bin]
  --sbindir=DIR           system admin executables [EPREFIX/sbin]
  --libexecdir=DIR        program executables [EPREFIX/libexec]
  --sysconfdir=DIR        read-only single-machine data [PREFIX/etc]
  --sharedstatedir=DIR    modifiable architecture-independent data [PREFIX/com]
  --localstatedir=DIR     modifiable single-machine data [PREFIX/var]
  --runstatedir=DIR       modifiable per-process data [LOCALSTATEDIR/run]
  --libdir=DIR            object code libraries [EPREFIX/lib]
  --includedir=DIR        C header files [PREFIX/include]
  --oldincludedir=DIR     C header files for non-gcc [/usr/include]
  --datarootdir=DIR       read-only arch.-independent data root [PREFIX/share]
  --datadir=DIR           read-only architecture-independent data [DATAROOTDIR]
  --infodir=DIR           info documentation [DATAROOTDIR/info]
  --localedir=DIR         locale-dependent data [DATAROOTDIR/locale]
  --mandir=DIR            man documentation [DATAROOTDIR/man]
  --docdir=DIR            documentation root [DATAROOTDIR/doc/grub]
  --htmldir=DIR           html documentation [DOCDIR]
  --dvidir=DIR            dvi documentation [DOCDIR]
  --pdfdir=DIR            pdf documentation [DOCDIR]
  --psdir=DIR             ps documentation [DOCDIR]

Program names:
  --program-prefix=PREFIX            prepend PREFIX to installed program names
  --program-suffix=SUFFIX            append SUFFIX to installed program names
  --program-transform-name=PROGRAM   run sed PROGRAM on installed program names

System types:
  --build=BUILD     configure for building on BUILD [guessed]
  --host=HOST       cross-compile to build programs to run on HOST [BUILD]
  --target=TARGET   configure for building compilers for TARGET [HOST]

Optional Features:
  --disable-option-checking  ignore unrecognized --enable/--with options
  --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
  --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
  --enable-silent-rules   less verbose build output (undo: "make V=1")
  --disable-silent-rules  verbose build output (undo: "make V=0")
  --enable-dependency-tracking
                          do not reject slow dependency extractors
  --disable-dependency-tracking
                          speeds up one-time build
  --disable-nls           do not use Native Language Support
  --disable-rpath         do not hardcode runtime library paths
  --disable-largefile     omit support for large files
  --enable-efiemu         build and install the efiemu runtimes
                          (default=guessed)
  --enable-mm-debug       include memory manager debugging
  --enable-cache-stats    enable disk cache statistics collection
  --enable-boot-time      enable boot time statistics collection
  --enable-grub-emu-sdl   build and install the `grub-emu' debugging utility
                          with SDL support (default=guessed)
  --enable-grub-emu-pci   build and install the `grub-emu' debugging utility
                          with PCI support (potentially dangerous)
                          (default=no)
  --enable-grub-mkfont    build and install the `grub-mkfont' utility
                          (default=guessed)
  --enable-grub-themes    build and install GRUB themes (default=guessed)
  --enable-grub-mount     build and install the `grub-mount' utility
                          (default=guessed)
  --enable-device-mapper  enable Linux device-mapper support (default=guessed)
  --enable-liblzma        enable liblzma integration (default=guessed)
  --enable-libzfs         enable libzfs integration (default=guessed)
  --disable-werror        do not use -Werror when building GRUB

Optional Packages:
  --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
  --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
  --with-platform=PLATFORM
                          select the host platform [[guessed]]
  --with-bootdir=DIR      set the name of /boot directory [[guessed]]
  --with-grubdir=DIR      set the name of grub directory [[guessed]]
  --with-gnu-ld           assume the C compiler uses GNU ld [default=no]
  --with-libiconv-prefix[=DIR]  search for libiconv in DIR/include and DIR/lib
  --without-libiconv-prefix     don't search for libiconv in includedir and libdir
  --with-libintl-prefix[=DIR]  search for libintl in DIR/include and DIR/lib
  --without-libintl-prefix     don't search for libintl in includedir and libdir
  --without-included-regex
                          don't compile regex; this is the default on systems
                          with recent-enough versions of the GNU C Library
                          (use with caution on other systems).

Some influential environment variables:
  CC          C compiler command
  CFLAGS      C compiler flags
  LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries in a
              nonstandard directory <lib dir>
  LIBS        libraries to pass to the linker, e.g. -l<library>
  CPPFLAGS    (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
              you have headers in a nonstandard directory <include dir>
  YACC        The `Yet Another Compiler Compiler' implementation to use.
              Defaults to the first program found out of: `bison -y', `byacc',
              `yacc'.
  YFLAGS      The list of arguments that will be passed by default to $YACC.
              This script will default YFLAGS to the empty string to avoid a
              default value of `-d' given by some make applications.
  CPP         C preprocessor
  CXX         C++ compiler command
  CXXFLAGS    C++ compiler flags
  CCAS        assembler compiler command (defaults to CC)
  CCASFLAGS   assembler compiler flags (defaults to CFLAGS)

Use these variables to override the choices made by `configure' or to help
it to find libraries and programs with nonstandard names/locations.

Report bugs to <bug-grub@gnu.org>.

What I would like to do is a bootx64.efi file that I can test on a x86_64 EFI laptop in order to see what should be expected on a working efi grub (command line, I guess). I would also be interested in trying to replace the efi file of the Debian installer USB key, just to see if it's working fine with the orginal grub code.
And then, build the arm64-efi version of grub in order to see if I can do the same, retry with different compiler flags, different options on "./configure"... and forget about code modifications because it looks like grub code is huge and separated into a lot of complicated files !

I've tried to reset the folder and play

Code: Select all

./configure --host=aarch64 --target=aarch64
make

But I got an error, like if the grub's code does not compile out of the box, at least for arm64 :

Code: Select all

[...]
[...]
gcc -DHAVE_CONFIG_H -I. -I..  -Wall -W  -DGRUB_MACHINE_EFI=1 -DGRUB_MACHINE=ARM64_EFI -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/6/include -I../include -I../include -DGRUB_FILE=\"loader/arm64/fdt.c\" -I. -I. -I.. -I.. -I../include -I../include -I../grub-core/lib/libgcrypt-grub/src/    -D_FILE_OFFSET_BITS=64 -Os -Wall -W -Wshadow -Wpointer-arith -Wundef -Wchar-subscripts -Wcomment -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wfloat-equal -Wformat-extra-args -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-braces -Wmissing-format-attribute -Wmultichar -Wparentheses -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wswitch -Wtrigraphs -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value  -Wunused-variable -Wwrite-strings -Wnested-externs -Wstrict-prototypes -g -Wredundant-decls -Wmissing-prototypes -Wmissing-declarations -Wcast-align  -Wextra -Wattributes -Wendif-labels -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wmissing-field-initializers -Wnonnull -Woverflow -Wvla -Wpointer-to-int-cast -Wstrict-aliasing -Wvariadic-macros -Wvolatile-register-var -Wpointer-sign -Wmissing-include-dirs -Wmissing-prototypes -Wmissing-declarations -Wformat=2 -freg-struct-return -msoft-float -fno-dwarf2-cfi-asm -mno-stack-arg-probe -fno-asynchronous-unwind-tables -fno-unwind-tables -Qn -fno-PIE -fno-pie -fno-stack-protector -Wtrampolines -Werror -mcmodel=large  -ffreestanding   -MT loader/arm64/fdt_module-fdt.o -MD -MP -MF loader/arm64/.deps-core/fdt_module-fdt.Tpo -c -o loader/arm64/fdt_module-fdt.o `test -f 'loader/arm64/fdt.c' || echo './'`loader/arm64/fdt.c
loader/arm64/fdt.c: In function ‘grub_fdt_load’:
loader/arm64/fdt.c:46:15: error: implicit declaration of function ‘grub_efi_get_firmware_fdt’ [-Werror=implicit-function-declaration]
     raw_fdt = grub_efi_get_firmware_fdt();
               ^~~~~~~~~~~~~~~~~~~~~~~~~
loader/arm64/fdt.c:46:5: error: nested extern declaration of ‘grub_efi_get_firmware_fdt’ [-Werror=nested-externs]
     raw_fdt = grub_efi_get_firmware_fdt();
     ^~~~~~~
loader/arm64/fdt.c:46:13: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]
     raw_fdt = grub_efi_get_firmware_fdt();
             ^
cc1: all warnings being treated as errors
Makefile:30552: recipe for target 'loader/arm64/fdt_module-fdt.o' failed
make[3]: *** [loader/arm64/fdt_module-fdt.o] Error 1
make[3]: Leaving directory '/home/user/Desktop/grub-source/grub-2.02/grub-core'
Makefile:23531: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/home/user/Desktop/grub-source/grub-2.02/grub-core'
Makefile:10904: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/user/Desktop/grub-source/grub-2.02'
Makefile:3130: recipe for target 'all' failed
make: *** [all] Error 2

If someone already did what I'm doing here, your suggestions are welcome !
I'll try to take a look at the error tomorrow after a good night, probably directly at the code, in order to understand what gcc is talking about.
And I'll try to build the bootx64.efi file for test from a standard x86_64 computer running on efi !

EDIT 2 : after the "make" command I do not find any "*.efi" file so I guess it builds tools that should, in a second time, be able to create the efi file ? May be grub-mkimage ?
I'm not very strong at "bootloaders" things but it's going to change quickly

[jrobin28260]

Hi back,

I had some lack of availability the last few days
For doing the test on my EFI x86_64 computer with the same conditions, I had to build the grub2.02 for x86_64-efi and use the freshly created "grub-install". It created a bootx64.efi file that my x86_64 EFI computer managed to run, giving me an error at the end but it's fine : it's alive. Now the step forward is doing the same for my ARM64 laptop and hoping to find the build parameters or specific configuration that would allow me to display something on it's screen, even if it's an error.

The error I got some days ago, by trying to build grub creator files for running on my x86_64, and targeting my arm64 laptop :

Code: Select all

loader/arm64/fdt.c: In function ‘grub_fdt_load’:
loader/arm64/fdt.c:46:15: error: implicit declaration of function ‘grub_efi_get_firmware_fdt’ [-Werror=implicit-function-declaration]

It means that the compiler didn't see the header of this function, or even it's implementation yet, before getting here and encountering a call to this unknown function.

It was due to something into the included "include/grub/efi.h" file :

Code: Select all

#if defined(__arm__) || defined(__aarch64__)
void *EXPORT_FUNC(grub_efi_get_firmware_fdt)(void); //<- the declaration of the function is here, and this is included into fdt.c !
#endif

It seems that __arm__ or __aarch64__ aren't defined, so I've placed the #if and #endif in comment, and it worked few lines more... before getting to a new error.
In file included from term/efi/serial.c:29:0:

Code: Select all

../include/grub/serial.h:25:25: fatal error: grub/cpu/io.h: No such file or directory
 #include <grub/cpu/io.h>

From serial.c, it tried to #include <grub/cpu/io.h> which is only available if cpu is i386, mips, or x86_64. Mine is a symbolic link to arm64, and there is no io.h file in it.

By seeing the serial.c source code :

Code: Select all

#if !defined (GRUB_MACHINE_EMU) && (defined(__mips__) || defined (__i386__) || defined (__x86_64__))
#include <grub/cpu/io.h>
#endif

It seems, again, that the compiler is thinking x86_64 is defined while __aarch64__ is not.

Although I'm on a x86_64 computer, I've installed crossbuild-essential-arm64 and I already successfully built an ARM64 efi file with "uefi-simple" (but this is not grub)

For the configure script, I'm typing ./configure --build=x86_64 --host=x86_64 --target=aarch64 --with-platform=efi
And I have the following output at the end of ./configure :

Code: Select all

GRUB2 will be compiled with following components:
Platform: arm64-efi
With devmapper support: No (need libdevmapper header)
With memory debugging: No
With disk cache statistics: No
With boot time statistics: No
efiemu runtime: No (not available on efi)
grub-mkfont: No (need freetype2 library)
grub-mount: No (need FUSE library)
starfield theme: No (No build-time grub-mkfont)
With libzfs support: No (need zfs library)
Build-time grub-mkfont: No (need freetype2 library)
Without unifont (no build-time grub-mkfont)
Without liblzma (no support for XZ-compressed mips images) (need lzma library)

I guess that I should find an ARM64 computer that is already working on Linux to get things better (haha, and I'm stuck at grub). Because here, I'm trying to build something that would execute on a x86_64 computer, in order to create a bootaa64.efi file for ARM64, and clearly the grub guys who worked on this part are delivering something that is not working, despite the fact that ./configure options are proposing it.

I have to go on scaleway few hours and I keep you informed !

[jrobin28260]

Going to scaleway with an ARM64 machine on Debian Stretch, helped me to have ./configure, make -j4 and make install command working fine.

I had to make an image (dd if=/dev/sdi of=imagefile.img) of an USB Key with GPT partitionning and an EFI System Partition on it, in order to mount it on my Arm64 machine with

Code: Select all

losetup /dev/loop0 /home/debian/imagefile.img --partscan
mount /dev/loop0p1 /media/EFI

Then I played ./grub-install /home/debian/anything.img --target=arm64-efi --efi-directory=/media/EFI/ --removable
And I have manufactured my own EFI file ! (What a mess, but it's done).

The bootaa64.efi file still doesn't work (it freezes on my Arm64 Laptop like the others linux ones), but now I will do some test and comparison about build options (compared to uefi-simple which is working fine on my Arm64 laptop) and grub options too.

[jrobin28260]

[...]
You could try systemd-boot, that provides /usr/lib/systemd/boot/efi/systemd-bootaa64.efi
If that is copied to ${ESP}/efi/boot/bootaa64.efi then the UEFI firmware should boot it automatically.[1]
[...]

By having the access to a working ARM64 machine I've found this file in its aa64 version, so I opened a parenthesis to my grub plans, and tried it !
I first tried the x64 version on a x64 computer in order to see what happens when this file is placed at the right place on a correctly formated USB key (GPT, ESP, Fat32, /efi/boot/bootx64.efi) and something appears on the screen.

Unfortunately, it doesn't work with the ARM64 computer and the systemd-bootaa64.efi file, same problem that grub : the computer freezes when trying to play the bootaa64.efi file (systemd-bootaa64.efi renamed and placed to /efi/boot/bootaa64.efi in an FAT32 formatted EFi System Partition)

It's interesting, because it tends to indicates that the target/build options used both for grub and systemd aren't the right ones for this computer, and probably are different compared to the "uefi-simple" hello world program.

For one of the numerous grub files, I isolated the following options passed to gcc :

Code: Select all

-Os
-freg-struct-return 
-mgeneral-regs-only 
-fno-dwarf2-cfi-asm 
-fno-asynchronous-unwind-tables 
-fno-unwind-tables 
-Qn 
-fno-PIE 
-fno-pie 
-fno-stack-protector 
-mcmodel=large  
-ffreestanding

I'll now compare it to uefi-simple options for arm64 too

EDIT : here is the options passed to GCC while building "uefi-simple" in a way that works with my arm64 laptop :

aarch64-linux-gnu-gcc
Different :

Code: Select all

-g 
-O2
-fpic  
-fshort-wchar 
-fno-strict-aliasing 
-fno-stack-check 
-fno-merge-all-constants 

Common :

Code: Select all

-ffreestanding 
-fno-stack-protector 

I'll first try to understand the differences. The simplest way to test is to rebuild "uefi simple" by trying the grub options to see which one breaks everything
My second fear is that the problematic option is completely incompatible with the CPU and used in every single Debian package. That would be very hard to solve.

[jrobin28260]

Well, the options -fno-PIE and -fno-pie from grub compilation, when applied to uefi-simple, are freezing the computer.

All the others options from grub (-Os -freg-struct-return -fno-dwarf2-cfi-asm -fno-asynchronous-unwind-tables -fno-unwind-tables -Qn) are working fine when used to create a working uefi-simple bootaa64.efi

I guess I found the guilty !

But I didn't tried the -mgeneral-regs-only and -mcmodel=large options, in fact I tried but I got build error because the first one is incompatible with floats while the second one is incompatible with "-fpic" option used in uefi-simple.

Also, I will now try to remove uefi-simple options that are not present in grub in order to see if some options from uefi-simple are mandatory for having something working.

-------------------------------------------------------------------------------------------

EDIT
I tested by removing from uefi-simple every flag that wasn't in the grub flags, and keeping the working grub flags into uefi-simple, in order to do a test that would match the same conditions.

What results it that the "-fpic" flag is the most important here. If deleted, it's still active by defaut, but if there is the -fno-pic flag, it freezes again at execution. Same problem that with the "-fno-pie" flag.

There is 2 others flags that I didn't successfully removed and tested because of build errors :
-fshort-wchar : gnu-efi build error (in console.c)
-fno-strict-aliasing : gnu-efi build error (in dpath.c)

Let's destroy the -fno-pie and -fno-PIE flags from grub and hope it will be working !

[stevepusser]

At the cost of introducing even more stuff to learn, you could try rebuilding the Debian packages from the Debianized source code: https://packages.debian.org/buster/grub-common

on the right side. Debian has any changes to the original source code in the /debian/patches folder, and compiler flags outside the normal ones automatically passed by debhelper can be added in the /debian/rules file. You can use the basic procedure for backporting to get the sources and rebuild the package, too, though you should increment the changelog so the Debian version doesn't just upgrade over yours. It's also pretty easy to turn any change that you make to the package's original source code into a patch with "dpkg-source --commit".

https://wiki.debian.org/SimpleBackportCreation

[jrobin28260]

Hi ! Thank you stevepusser for your answer

As today I'm following all my test/changes from the original with a local SVN, and because my final goal is to rebuild a working grub for my Debian installer (then for my Debian installed ) I'll try to see what can be submitted for everybody else but I guess I got to be very sure of my modifications, and understand everything that it implies.

Yesterday was a rude day of raw editing of too much files and having errors everywhere during the build process with nothing to compare with and lack of knowledge I started today with better approach !
Grub Makefiles and Makefiles generator files are pretty hard to deal with and by searching term in all the files, editing them in almost 50 places and having a summary of what has changed will help me in my quest.
I also kept the stdout of an original build in order to compare with mines.

For now, I'm stuck with something that some of you will find pretty simple, and I will try to solve it in the evening.
There is a build error while I'm building grub with my changes.

Simplified working version (original grub parameters)

Code: Select all

gcc -DHAVE_CONFIG_H -I. -I..  -Wall -W  -DGRUB_MACHINE_EFI=1 -DGRUB_MACHINE=ARM64_EFI -nostdinc -isystem /usr/lib/gcc/aarch64-linux-gnu/6/include -I../include -I../include -DGRUB_FILE=\"lib/disk.c\" -I. -I. -I.. -I.. -I../include -I../include -I../grub-core/lib/libgcrypt-grub/src/    -D_FILE_OFFSET_BITS=64 -Wmissing-declarations -Wformat=2 -freg-struct-return -mgeneral-regs-only -fno-dwarf2-cfi-asm -fno-asynchronous-unwind-tables -fno-unwind-tables -Qn -fno-PIE -fno-pie -fno-stack-protector -Wtrampolines -Werror -mcmodel=large  -ffreestanding   -MT lib/disk_module-disk.o -MD -MP -MF lib/.deps-core/disk_module-disk.Tpo -c -o lib/disk_module-disk.o `test -f 'lib/disk.c' || echo './'`lib/disk.c

mv -f lib/.deps-core/disk_module-disk.Tpo lib/.deps-core/disk_module-disk.Po

gcc -Wmissing-declarations -Wformat=2 -freg-struct-return -mgeneral-regs-only -fno-dwarf2-cfi-asm -fno-asynchronous-unwind-tables -fno-unwind-tables -Qn -fno-PIE -fno-pie -fno-stack-protector -Wtrampolines -Werror   -ffreestanding   -Wl,--build-id=none  -nostdlib -Wl,-N -Wl,-r,-d -o disk.module lib/disk_module-disk.o

Simplified not working version (with my changes, which are addition of -fpic, and removing of -fno-PIE -fno-pie and --mcmodel=large) (and also a -Wl,-r removed parameter which was incompatible with my changes about pic and pie)

Code: Select all

gcc -DHAVE_CONFIG_H -I. -I..  -Wall -W  -DGRUB_MACHINE_EFI=1 -DGRUB_MACHINE=ARM64_EFI -nostdinc -isystem /usr/lib/gcc/aarch64-linux-gnu/6/include -I../include -I../include -DGRUB_FILE=\"lib/disk.c\" -I. -I. -I.. -I.. -I../include -I../include -I../grub-core/lib/libgcrypt-grub/src/    -D_FILE_OFFSET_BITS=64 -Wmissing-declarations -Wformat=2 -freg-struct-return -mgeneral-regs-only -fno-dwarf2-cfi-asm -fno-asynchronous-unwind-tables -fno-unwind-tables -Qn -fpic             -fno-stack-protector -Wtrampolines -Werror                 -ffreestanding   -MT lib/disk_module-disk.o -MD -MP -MF lib/.deps-core/disk_module-disk.Tpo -c -o lib/disk_module-disk.o `test -f 'lib/disk.c' || echo './'`lib/disk.c

mv -f lib/.deps-core/disk_module-disk.Tpo lib/.deps-core/disk_module-disk.Po

gcc -Wmissing-declarations -Wformat=2 -freg-struct-return -mgeneral-regs-only -fno-dwarf2-cfi-asm -fno-asynchronous-unwind-tables -fno-unwind-tables -Qn -fpic             -fno-stack-protector -Wtrampolines -Werror -fpic  -ffreestanding   -Wl,--build-id=none  -nostdlib -Wl,-N -Wl,-d    -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'

[...]

If someone obviously sees what I should do, you're welcome !

[jrobin28260]

It seems that they are compiling one of the files (disk.c) in two steps.

So I created a small file with 2 functions in it (sub_and_add_a_and_b.c)

Code: Select all

int add_a_b(int a, int b);
int sub_a_b(int a, int b);

int add_a_b(int a, int b)
{
    return a+b;
}

int sub_a_b(int a, int b)
{
    return a-b;
}

I also created a main.c file (in order to play with static and shared library builds) but it's not used here.

If I do many simplifications of their gcc line, with original values, it's doing :
gcc -fno-PIE -fno-pie -mcmodel=large -MT prog.o -MD -MP -MF prog.Tpo -c -o prog.o sub_and_add_a_and_b.c
gcc -fno-PIE -fno-pie -mcmodel=large -Wl,--build-id=none -nostdlib -no-pie -Wl,-N -Wl,-r,-d -o prog.module prog.o

With those parameters and will ALL the parameters that grub uses it gives the same : no error no warning.

But in order to disable -fno-PIE and -fno-pie, because it doesn't work with the Qualcomm computer, I'm trying to do :
gcc -fpic -MT prog.o -MD -MP -MF prog.Tpo -c -o prog.o sub_and_add_a_and_b.c
gcc -fpic -Wl,--build-id=none -nostdlib -no-pie -Wl,-N -Wl,-d -o prog.module prog.o

Then I get one of the errors : /usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 00000000004000b0
But I haven't the others error. Anyway I think this warning is enough to say something is wrong in this case too.
If I put ALL the parameters I have the same result.

But there is also a -no-pie option that I removed, an subsequently, a -Wl,-r option that I had to remove because "-pie" is considered active.
However, it seems that it's not incompatible with -fpic to do :
gcc -fpic -MT prog.o -MD -MP -MF prog.Tpo -c -o prog.o sub_and_add_a_and_b.c
gcc -fpic -Wl,--build-id=none -nostdlib -no-pie -Wl,-N -Wl,-r,-d -o prog.module prog.o

Then I get no error and no warning about entry symbol not found.
The "-Wl,-r" option is the key, here. according to https://www.computerhope.com/unix/uld.htm it means "--relocatable" : "generate an output file that can in turn serve as input to ld."
So now I got to see if this could work into the Qualcomm computer... having -fpic, not having -fno-pie or -fno-PIE, but having -no-pie.

But I'm not sure of what this is doing ! Why do they pass prog.o to GCC in order to do a prog.module, instead of using the prog.o directly ? The second line, played with the "-shared" parameter, is giving a shared object file, but here, it's like it's doing nothing clear... and I'm trying to play with option about something that is doing something I don't understand

---------------------------------
EDIT

By watching the output of the original configuration, disk.module is used 2 times in the following steps :

Code: Select all

for m in disk.module trig.module regexp.module [....and lot of others module...]; do \
sh gensyminfo.sh $m >> syminfo.lst.new || exit 1; \

Then,

Code: Select all

TARGET_OBJ2ELF= sh genmod.sh moddep.lst disk.module build-grub-module-verifier disk.mod

Those *.mod files are then placed at 2 places :
/boot/grub/arm64-efi/disk.mod
/usr/lib/grub/arm64-efi/disk.mod

It means those modules are placed by grub-install, likely used by grub at it's execution, I guess, or used when manufacturing the bootaa64.efi file, but I'm not sure.
---------------------------------
EDIT 2
It seems that the following line :

Code: Select all

TARGET_OBJ2ELF= sh genmod.sh moddep.lst disk.module build-grub-module-verifier disk.mod

Didn't worked : _GLOBAL_OFFSET_TABLE_ in disk is not defined
The GOT is the thing that the -fpic option ensure to create (-fPIC if the GOT is too big for -fpic on some CPU).

According to https://gcc.gnu.org/onlinedocs/gcc/Code ... en-Options
-fpic gives a GOT that is suitable for libraries, while -fpie gives a GOT that can only be linked against an executable (I guess -fpic is better ? But there is probably some support restrictions)

Anyway, disk.module had -fpic active, but may be not -fpie (which can be played even if -no-pie is present... but I'm not sure of the results !)

Code: Select all

gcc -DHAVE_CONFIG_H -I. -I..  -Wall -W  -DGRUB_MACHINE_EFI=1 -DGRUB_MACHINE=ARM64_EFI -nostdinc -isystem /usr/lib/gcc/aarch64-linux-gnu/6/include -I../include -I../include -DGRUB_FILE=\"lib/disk.c\" -I. -I. -I.. -I.. -I../include -I../include -I../grub-core/lib/libgcrypt-grub/src/    -D_FILE_OFFSET_BITS=64 -Os -Wall -W -Wshadow -Wpointer-arith -Wundef -Wchar-subscripts -Wcomment -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wfloat-equal -Wformat-extra-args -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-braces -Wmissing-format-attribute -Wmultichar -Wparentheses -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wswitch -Wtrigraphs -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value  -Wunused-variable -Wwrite-strings -Wnested-externs -Wstrict-prototypes -g -Wredundant-decls -Wmissing-prototypes -Wmissing-declarations -Wcast-align  -Wextra -Wattributes -Wendif-labels -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wmissing-field-initializers -Wnonnull -Woverflow -Wvla -Wpointer-to-int-cast -Wstrict-aliasing -Wvariadic-macros -Wvolatile-register-var -Wpointer-sign -Wmissing-include-dirs -Wmissing-prototypes -Wmissing-declarations -Wformat=2 -freg-struct-return -mgeneral-regs-only -fno-dwarf2-cfi-asm -fno-asynchronous-unwind-tables -fno-unwind-tables -Qn -fpic -fpic -fno-stack-protector -Wtrampolines -Werror -fpic  -ffreestanding   -MT lib/disk_module-disk.o -MD -MP -MF lib/.deps-core/disk_module-disk.Tpo -c -o lib/disk_module-disk.o `test -f 'lib/disk.c' || echo './'`lib/disk.c
mv -f lib/.deps-core/disk_module-disk.Tpo lib/.deps-core/disk_module-disk.Po
gcc -Os -Wall -W -Wshadow -Wpointer-arith -Wundef -Wchar-subscripts -Wcomment -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wfloat-equal -Wformat-extra-args -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-braces -Wmissing-format-attribute -Wmultichar -Wparentheses -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wswitch -Wtrigraphs -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value  -Wunused-variable -Wwrite-strings -Wnested-externs -Wstrict-prototypes -g -Wredundant-decls -Wmissing-prototypes -Wmissing-declarations -Wcast-align  -Wextra -Wattributes -Wendif-labels -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wmissing-field-initializers -Wnonnull -Woverflow -Wvla -Wpointer-to-int-cast -Wstrict-aliasing -Wvariadic-macros -Wvolatile-register-var -Wpointer-sign -Wmissing-include-dirs -Wmissing-prototypes -Wmissing-declarations -Wformat=2 -freg-struct-return -mgeneral-regs-only -fno-dwarf2-cfi-asm -fno-asynchronous-unwind-tables -fno-unwind-tables -Qn -fpic -fpic -fno-stack-protector -Wtrampolines -Werror -fpic  -ffreestanding   -no-pie -Wl,--build-id=none  -nostdlib -Wl,-N -Wl,-r,-d   -o disk.module lib/disk_module-disk.o

Let's try with -fpie.

---------------------------------
EDIT 3
Tried with -fpic -fpie into all of the CFLAGS and LDFLAGS untouched, same error at the end of the end of the building process : _GLOBAL_OFFSET_TABLE_ in disk is not defined
By reading my changes on the SVN, I'm able to see that there is CFLAGS/LDFLAGS for kernel, module, target, platform...
If the thing that the computer executes when running bootaa64.efi is not the modules, I guess I can be more restrictive when I'm applying (or not) my CFLAGS "-fpic" and or "-fpie".

Anyway, on UEFI-SIMPLE the -fpic -fpie as CFLAGS and -no-pie as LDFLAGS work and gives something that the computer is able to start.
To be continued tomorrow !

[llivv]

By having the access to a working ARM64 machine I've found this file in its aa64 version, so I opened a parenthesis to my grub plans, and tried it !
I first tried the x64 version on a x64 computer in order to see what happens when this file is placed at the right place on a correctly formated USB key (GPT, ESP, Fat32, /efi/boot/bootx64.efi) and something appears on the screen.

Unfortunately, it doesn't work with the ARM64 computer and the systemd-bootaa64.efi file, same problem that grub : the computer freezes when trying to play the bootaa64.efi file (systemd-bootaa64.efi renamed and placed to /efi/boot/bootaa64.efi in an FAT32 formatted EFi System Partition)

It's interesting, because it tends to indicates that the target/build options used both for grub and systemd aren't the right ones for this computer, and probably are different compared to the "uefi-simple" hello world program.

I'll first try to understand the differences. The simplest way to test is to rebuild "uefi simple" by trying the grub options to see which one breaks everything
My second fear is that the problematic option is completely incompatible with the CPU and used in every single Debian package. That would be very hard to solve.

Before I close out all the tabs I have open
From what I see so far it looks like what you are trying to do is - essentially hack the Windows 10 (S) bootloader.
So far, Only 4 or 5 of the biggest wintel OEM's have access to the special win 10 S boot process. (from what I have read so far).
[...]

If someone already did what I'm doing here, your suggestions are welcome !
I'll try to take a look at the error tomorrow after a good night, probably directly at the code, in order to understand what gcc is talking about.

ARM64 link below

And I'll try to build the bootx64.efi file for test from a standard x86_64 computer running on efi !

There are a lot of others trying to figure this out too. From what I've read so far some are trying to access the windows 10 s boot stack from the ((OPE) - ( RE)) ((oem preinstallation envir) - (recovery envir?)) and if I know how ($$) works - it is probably in a boot (S) release of the OPK - OEM Preinstallation Kit (probably more restrictive )...
see links below - I think mostly ddg.gg results - AnandTech - HP envy
[...]

I guess that I should find an ARM64 computer that is already working on Linux to get things better (haha, and I'm stuck at grub). Because here, I'm trying to build something that would execute on a x86_64 computer, in order to create a bootaa64.efi file for ARM64, and clearly the grub guys who worked on this part are delivering something that is not working, despite the fact that ./configure options are proposing it.

That was my thought as well, but it looks to me like the same issue Debian had with EFI and secure boot when windows first started pushing the secure boot key in EFI - maybe looking up Secure Boot could offer some possible results.
Some comments I've read indicate the evil empire is at it again with releasing FUD concerning win s boot process.... you should see those comments in some of the ddg.gg search results linked below.

If you've ever loaded debian onto a chromebook you might have other ideas about how the bootloader on your Asus is locked down... but only relativly casue android boots different than win (s)

I haven't noticed anything related in the debian arm mailing list either...

here are a few pages that might give you more ideas
ARM64
https://linux-sunxi.org/Arm64

Qualcomm SnapDragon 835
https://www.qualcomm.com/products/snapd ... e-platform

OEM stuff on Anandtech
https://www.anandtech.com/show/11477/qu ... dragon-835

Linus git ARM64
https://github.com/torvalds/linux/tree/ ... /allwinner
just to double check that everything you need to boot your Asus is in Buster 4.18 arm64

Busters ARM64 kernel (current)
https://packages.debian.org/search?keyw ... 1-rt-arm64
that's not even that easy to find if you don't use it much.

HP envy support for their phonebooktab
https://h30434.www3.hp.com/t5/Notebook- ... -p/6644724

boot linux on arm64 snapdragon 835 - ddg.gg results
https://duckduckgo.com/?q=boot+linux+on ... 835&ia=web

that about does it for me today

[jrobin28260]

Hi llivv

In fact I'm more lucky than you guessed :
Windows 10 S Bootloader (it's Windows 10 Pro now, I did the update) is just an EFI System Partition (it is the exact same disk content that the one you can find on a x86_64 computer running Windows trough EFI, I verified, the files are just built for aarch64 instead of x86_64) with Secure Boot enabled.
ESP Content from Windows : http://image.noelshack.com/fichiers/201 ... ontent.png


-> The internal hard disk (eMMC) has already been completely erased (diskpart -> clean equals dd if=/dev/zero of=/dev/sda). No more Windows but I'm able to boot the re-installation media (trough UEFI)
-> Secure boot can be disabled
-> I already ran UEFI files on it, including uefi-simple which is not Windows or Windows Installer... but does not do a lot of things

The problem here, is that GRUB developpers, in there Makefiles, manually disabled some options that are enabled by default : -fpic and/or -fpie and ensured they are not enabled by -fno-PIE and -fno-pie.
But those options are mandatory for having an EFI file that this computer would run without remaining stuck / frozen when trying to execute those files.

And re-enabling those options into GRUB build process without having build errors isn't a fairly simple task but I'm in the way to succeed it At least, I expect so !

[llivv]

Nice rom ....
Hi JR

Hi llivv
Windows 10 S Bootloader (it's Windows 10 Pro now, I did the update) is just an EFI System Partition (it is the exact same disk content that the one you can find on a x86_64 computer running Windows trough EFI, I verified, the files are just built for aarch64 instead of x86_64) with Secure Boot enabled.

That's what win 10 s is win10 compiled for armv8 it ain't anything like win10 x86_64 even if they may look the same in explorer.... although I'm sure you'll figure that out eventually

-> The internal hard disk (eMMC) has already been completely erased (diskpart -> clean equals dd if=/dev/zero of=/dev/sda). No more Windows but I'm able to boot the re-installation media (through UEFI)

smart move

-> Secure boot can be disabled

I see - nice

-> I already ran UEFI files on it, including uefi-simple which is not Windows or Windows Installer... but does not do a lot of things

The problem here, is that GRUB developpers, in there Makefiles, manually disabled some options that are enabled by default

: -fpic and/or -fpie and ensured they are not enabled by -fno-PIE and -fno-pie.

I wonder why they did that

But those options are mandatory for having an EFI file that this computer would run without remaining stuck / frozen when trying to execute those files.

And re-enabling those options into GRUB build process without having build errors isn't a fairly simple task but I'm in the way to succeed it At least, I expect so !

Good luck with that.

I'm just curious why you are putting all that work into grub instead of doing it the normal way?

[jrobin28260]

The "normal way" could be something interesting to me ! But I'm not sure to know what is the normal way, if you have some tip for starting the Debian Installer (and then, the Installed Debian) without having to deal with grub, it would be great I think it would have to deal with UEFI anyway ?

I'm not very strong at bootloader things.

All I know it that the kernel (vmlinuz) and an initramfs should be extracted and loaded to RAM, then a kernel command line should be executed (giving informations about where is the root file system, what is the command to play once kernel is initialized)...
GRUB advantage is being able to browse disk, partitions, (ext4, fat32...) in order to find those files and extract them in an easy and configurable way

The reason why I'm putting all that work to grub is that I want to do the same with this arm64 computer, than with my others computers (running on x86_64), if not I will be frustrated

[llivv]

if not I will be frustrated

I think so..
It's basically a big phonebooktab that $$ is trying to sell as a computer. Don't be fooled by what $$ tries to get you to believe... unless you really really want to.

try to think of the novago as a big phone that phones home using 10 protocols.

[jrobin28260]

You're right, this is a big phone but with Windows 10 and UEFI on it it gives me a lot of ideas to explore

Anyway, I think I'm stuck.

At the time of ./configure, I have :

Code: Select all

checking whether `gcc' has `-fPIE' as default... yes
checking whether linker accepts -no-pie... yes
checking whether linker needs disabling of PIE to work... no
checking whether `gcc' has `-fPIC' as default... yes

But the configure script is written in a way that it applies -fno-PIE, -fno-pie, and -fno-PIC when building files that are going to finish as "*.mod" files once building process is terminated.
I managed to disable those 3 problematic options.

Disabling -fno_PIC, -fno-PIE and -fno-pie, drives to a failure :
lib/disk.c:1:0: sorry, unimplemented: code model ‘large’ with -fPIC
It means that disabling -mcmodel=large is mandatory in my case, because experience shown me that I won't be able to boot if -fno-PIC or -fno-pic option is present.
That is not a surprise because I saw few days ago, on "uefi-simple" that it is impossible to use the -mcmodel=large option when -fpic or -fPIC is enabled.

But just the fact of disabling -mcmodel=large (alone, letting all the rest of the configuration untouched) already drives to a failure at the end of the building process :

Code: Select all

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.

I think this should be corrected but I don't know how. It's like GRUB is designed in a way that make -mcmodel=large mandatory...

Disabling -mcmodel=large, disabling -fno_PIC, -fno-PIE and -fno-pie, drives to another failure :

Code: Select all

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 -fPIE and/or -fPIC, gives the same error, since if not manually disabled, it's enabled by default.

I guess I will have to understand a lot of new things in order to be able to deal with this