Hi,
I was reading https://www.kernel.org/doc/Documentation/arm/uefi.txt and it looks like I should have everything needed to get EFI stuff in linux, but instead I get:
root@hikey:~# dmesg | grep -i efi
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: UEFI not found.
[ 0.079367] EFI services will not be available.
Double checking:
root@hikey:~# uname -a
Linux hikey 4.0.0-rc3 #19 SMP Sun Mar 15 10:57:36 CET 2015 aarch64 GNU/Linux
root@hikey:~# zcat /proc/config.gz | grep -i efi
CONFIG_EFI_PARTITION=y
CONFIG_EFI_STUB=y
CONFIG_EFI=y
CONFIG_RTC_DRV_EFI=y
# EFI (Extensible Firmware Interface) Support
CONFIG_EFI_VARS=y
CONFIG_EFI_PARAMS_FROM_FDT=y
CONFIG_EFI_RUNTIME_WRAPPERS=y
CONFIG_EFI_ARMSTUB=y
CONFIG_EFIVAR_FS=y
So it has everything mentioned in the kernel doc, which goes on to say "The stub populates the FDT /chosen node with (and the kernel scans for) the following parameters: [linux,uefi-system-table and more]". On hikey I get this:
root@hikey:~# dtc -I fs -O dts -o ~/effective.dts /proc/device-tree/
root@hikey:~# grep chosen -A4 effective.dts
chosen {
linux,initrd-end = <0x0 0x7fff200>;
bootargs = "console=ttyAMA0,115200 earlycon=pl011,0xf8015000 root=/dev/sda1 rootwait ro ";
linux,initrd-start = <0x0 0x7fff000>;
};
This is an UEFI I built myself using https://github.com/96boards/edk2/commits/hikey with a change to use /dev/sda1 as root in bootargs, nothing more.
What is needed to get linux to notice UEFI? It looks like all the bits are in place (bootloader, kernelstub, kernel config).
On Sun, Mar 15, 2015 at 11:16:04AM +0100, Koen Kooi wrote:
Hi,
I was reading https://www.kernel.org/doc/Documentation/arm/uefi.txt and it looks like I should have everything needed to get EFI stuff in linux, but instead I get:
root@hikey:~# dmesg | grep -i efi [ 0.000000] efi: Getting EFI parameters from FDT: [ 0.000000] efi: UEFI not found. [ 0.079367] EFI services will not be available.
So, most likely the kernel has been invoked by the world's most tedious and least useful U-Boot emulator, also known as the "built-in Linux loader".
I am unfortunately completely unfamiliar with the HiKey UEFI port.
It would have been useful to get the UEFI team involved in the HiKey work somewhere along the line, to ensure mix-ups like this did not happen.
Double checking:
root@hikey:~# uname -a Linux hikey 4.0.0-rc3 #19 SMP Sun Mar 15 10:57:36 CET 2015 aarch64 GNU/Linux root@hikey:~# zcat /proc/config.gz | grep -i efi CONFIG_EFI_PARTITION=y CONFIG_EFI_STUB=y CONFIG_EFI=y CONFIG_RTC_DRV_EFI=y # EFI (Extensible Firmware Interface) Support CONFIG_EFI_VARS=y CONFIG_EFI_PARAMS_FROM_FDT=y CONFIG_EFI_RUNTIME_WRAPPERS=y CONFIG_EFI_ARMSTUB=y CONFIG_EFIVAR_FS=y
Yeah, all good there.
So it has everything mentioned in the kernel doc, which goes on to say "The stub populates the FDT /chosen node with (and the kernel scans for) the following parameters: [linux,uefi-system-table and more]". On hikey I get this:
root@hikey:~# dtc -I fs -O dts -o ~/effective.dts /proc/device-tree/
root@hikey:~# grep chosen -A4 effective.dts
chosen {
linux,initrd-end = <0x0 0x7fff200>;
bootargs = "console=ttyAMA0,115200 earlycon=pl011,0xf8015000 root=/dev/sda1 rootwait ro ";
linux,initrd-start = <0x0 0x7fff000>;
};
This is an UEFI I built myself using https://github.com/96boards/edk2/commits/hikey with a change to use /dev/sda1 as root in bootargs, nothing more.
What is needed to get linux to notice UEFI? It looks like all the bits are in place (bootloader, kernelstub, kernel config).
Booting the kernel as a stub.
How is the kernel actually invoked in this HiKey build-UEFI-but-don't-use-it firmware?
/ Leif
On 15 March 2015 at 14:09, Leif Lindholm leif.lindholm@linaro.org wrote:
On Sun, Mar 15, 2015 at 11:16:04AM +0100, Koen Kooi wrote:
Hi,
I was reading https://www.kernel.org/doc/Documentation/arm/uefi.txt and it looks like I should have everything needed to get EFI stuff in linux, but instead I get:
root@hikey:~# dmesg | grep -i efi [ 0.000000] efi: Getting EFI parameters from FDT: [ 0.000000] efi: UEFI not found. [ 0.079367] EFI services will not be available.
~$ dmesg|grep -i efi [ 0.000000] efi: Getting EFI parameters from FDT: [ 0.000000] EFI v2.40 by Linaro HiKey EFI Mar 9 2015 15:25:34 [ 0.000000] efi: [ 0.137729] Remapping and enabling EFI services. [ 0.144124] Freed 0xbf2000 bytes of EFI boot services memory [ 4.153810] rtc-efi rtc-efi: can't read time [ 4.158218] rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0 [ 4.950297] rtc-efi rtc-efi: can't read time [ 4.974951] rtc-efi rtc-efi: hctosys: unable to read the hardware clock [ 81.484828] rtc-efi rtc-efi: can't read time [ 82.484885] rtc-efi rtc-efi: can't read time [ 83.485007] rtc-efi rtc-efi: can't read time [ 84.485119] rtc-efi rtc-efi: can't read time
This is with 3.18+, but I get similar results with 4.0+
root@hikey:~# dtc -I fs -O dts -o ~/effective.dts /proc/device-tree/
root@hikey:~# grep chosen -A4 effective.dts
chosen {
linux,initrd-end = <0x0 0x7fff200>;
bootargs = "console=ttyAMA0,115200 earlycon=pl011,0xf8015000 root=/dev/sda1 rootwait ro ";
linux,initrd-start = <0x0 0x7fff000>;
};
Mine looks ok:
chosen { linux,uefi-mmap-desc-size = <0x30>; linux,uefi-mmap-size = <0x3f0>; linux,initrd-end = <0x0 0xb600000>; linux,uefi-system-table = <0x0 0x3fcdbf18>; linux,uefi-stub-kern-ver = "Linux version 3.18.0+ ..."; linux,uefi-mmap-start = <0x0 0x39f67598>; linux,uefi-mmap-desc-ver = <0x1>; bootargs = "fs0:\vmlinux-3.18.0+ dtb=hikey-new.dtb nfsroot=192.168.1.6:/data/..."; linux,initrd-start = <0x0 0xae00000>; };
This is an UEFI I built myself using https://github.com/96boards/edk2/commits/hikey with a change to use /dev/sda1 as root in bootargs, nothing more.
What is needed to get linux to notice UEFI? It looks like all the bits are in place (bootloader, kernelstub, kernel config).
Booting the kernel as a stub.
How is the kernel actually invoked in this HiKey build-UEFI-but-don't-use-it firmware?
Koen is probably using a .bat^W.nsh script like me:
https://lists.96boards.org/pipermail/dev/2015-March/000058.html
I think the uBoot emulator could only be problem if Koen as expliclty converted the Image/vmlinux to an uImage?
Riku
On Mon, Mar 16, 2015 at 08:27:07AM +0200, Riku Voipio wrote:
Koen is probably using a .bat^W.nsh script like me:
https://lists.96boards.org/pipermail/dev/2015-March/000058.html
I think the uBoot emulator could only be problem if Koen as expliclty converted the Image/vmlinux to an uImage?
My snarky comment was referring to the "copy image and jump to it" aspect rather then the presence or not of a special U-Boot header. The UEFI Stub kernel image is still a valid Image.
The built-in Linux Loader ignores the stub and does a copy-and-jump, discarding all information required to get runtime services going.
/ Leif
On 15 March 2015 at 13:09, Leif Lindholm leif.lindholm@linaro.org wrote:
On Sun, Mar 15, 2015 at 11:16:04AM +0100, Koen Kooi wrote:
Hi,
I was reading https://www.kernel.org/doc/Documentation/arm/uefi.txt and it looks like I should have everything needed to get EFI stuff in linux, but instead I get:
root@hikey:~# dmesg | grep -i efi [ 0.000000] efi: Getting EFI parameters from FDT: [ 0.000000] efi: UEFI not found. [ 0.079367] EFI services will not be available.
So, most likely the kernel has been invoked by the world's most tedious and least useful U-Boot emulator, also known as the "built-in Linux loader".
I am unfortunately completely unfamiliar with the HiKey UEFI port.
It would have been useful to get the UEFI team involved in the HiKey work somewhere along the line, to ensure mix-ups like this did not happen.
[snip kernel config]
This is an UEFI I built myself using https://github.com/96boards/edk2/commits/hikey with a change to use /dev/sda1 as root in bootargs, nothing more.
What is needed to get linux to notice UEFI? It looks like all the bits are in place (bootloader, kernelstub, kernel config).
Booting the kernel as a stub.
How is the kernel actually invoked in this HiKey build-UEFI-but-don't-use-it firmware?
I'm still unfamiliar with EDK2, so I'm going to take a stab at answering your question without knowning what I'm doing :)
HisiPkg/HiKeyPkg/HiKey.dsc sets:
gArmPlatformTokenSpaceGuid.PcdDefaultBootType|2
Which seems to imply it's not loaded in EFI mode:
# PcdDefaultBootType define the type of the binary pointed by PcdDefaultBootDevicePath: \r # - 0 = an EFI application\r # - 1 = a Linux kernel with ATAG support\r # - 2 = a Linux kernel with FDT support\r
Would entering the shell and doing
./Image dtb=hi6220-hikey.dtb console=ttyAMA0,115200 earlycon=pl011,0xf8015000 root=/dev/sda1 r0 quiet
Should launch it in uefi mode, right?
On 16 March 2015 at 07:35, Koen Kooi koen.kooi@linaro.org wrote:
On 15 March 2015 at 13:09, Leif Lindholm leif.lindholm@linaro.org wrote:
On Sun, Mar 15, 2015 at 11:16:04AM +0100, Koen Kooi wrote:
Hi,
I was reading https://www.kernel.org/doc/Documentation/arm/uefi.txt and it looks like I should have everything needed to get EFI stuff in linux, but instead I get:
root@hikey:~# dmesg | grep -i efi [ 0.000000] efi: Getting EFI parameters from FDT: [ 0.000000] efi: UEFI not found. [ 0.079367] EFI services will not be available.
So, most likely the kernel has been invoked by the world's most tedious and least useful U-Boot emulator, also known as the "built-in Linux loader".
I am unfortunately completely unfamiliar with the HiKey UEFI port.
It would have been useful to get the UEFI team involved in the HiKey work somewhere along the line, to ensure mix-ups like this did not happen.
[snip kernel config]
This is an UEFI I built myself using https://github.com/96boards/edk2/commits/hikey with a change to use /dev/sda1 as root in bootargs, nothing more.
What is needed to get linux to notice UEFI? It looks like all the bits are in place (bootloader, kernelstub, kernel config).
Booting the kernel as a stub.
How is the kernel actually invoked in this HiKey build-UEFI-but-don't-use-it firmware?
I'm still unfamiliar with EDK2, so I'm going to take a stab at answering your question without knowning what I'm doing :)
HisiPkg/HiKeyPkg/HiKey.dsc sets:
gArmPlatformTokenSpaceGuid.PcdDefaultBootType|2Which seems to imply it's not loaded in EFI mode:
# PcdDefaultBootType define the type of the binary pointed byPcdDefaultBootDevicePath: \r # - 0 = an EFI application\r # - 1 = a Linux kernel with ATAG support\r # - 2 = a Linux kernel with FDT support\r
Would entering the shell and doing
./Image dtb=hi6220-hikey.dtb console=ttyAMA0,115200earlycon=pl011,0xf8015000 root=/dev/sda1 r0 quiet
Should launch it in uefi mode, right?
Thanks to the hint from Riku:
root@hikey:~# dmesg | grep -i efi
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] EFI v2.40 by Linaro HiKey EFI Mar 10 2015 11:06:19
[ 0.000000] efi:
[ 0.079378] Remapping and enabling EFI services.
[ 0.084093] EFI remap 0x000000003fc50000 => 0000000040000000
[ 0.090067] EFI remap 0x000000003fc91000 => 0000000040051000
[ 0.096026] EFI remap 0x00000000f8003000 => 00000000400b3000
[ 3.916651] rtc-efi rtc-efi: can't read time
[ 3.925562] rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0
[ 4.380505] EFI Variables Facility v0.08 2004-May-17
[ 4.683551] rtc-efi rtc-efi: can't read time
[ 4.704381] rtc-efi rtc-efi: hctosys: unable to read the hardware clock
The trick is to boot using the bootmenu and have the shell (auto)execute startup.nsh. A bit annoying to need to use serial every (re)boot, but that should be fixed in the hikey uefi port: https://github.com/96boards/bugs/issues/27
On Mon, Mar 16, 2015 at 07:35:52AM +0100, Koen Kooi wrote:
This is an UEFI I built myself using https://github.com/96boards/edk2/commits/hikey with a change to use /dev/sda1 as root in bootargs, nothing more.
What is needed to get linux to notice UEFI? It looks like all the bits are in place (bootloader, kernelstub, kernel config).
Booting the kernel as a stub.
How is the kernel actually invoked in this HiKey build-UEFI-but-don't-use-it firmware?
I'm still unfamiliar with EDK2, so I'm going to take a stab at answering your question without knowning what I'm doing :)
HisiPkg/HiKeyPkg/HiKey.dsc sets:
gArmPlatformTokenSpaceGuid.PcdDefaultBootType|2Which seems to imply it's not loaded in EFI mode:
# PcdDefaultBootType define the type of the binary pointed byPcdDefaultBootDevicePath: \r # - 0 = an EFI application\r # - 1 = a Linux kernel with ATAG support\r # - 2 = a Linux kernel with FDT support\r
Flipping the DefaultBootType to 0 (the only method that has any business existing in UEFI) would probably do the trick without getting into the unfortunate habit of using a startup.nsh.
Would entering the shell and doing
./Image dtb=hi6220-hikey.dtb console=ttyAMA0,115200earlycon=pl011,0xf8015000 root=/dev/sda1 r0 quiet
Should launch it in uefi mode, right?
Yes. Only with '' instead :)
/ Leif
On 16 March 2015 at 09:36, Leif Lindholm leif.lindholm@linaro.org wrote:
On Mon, Mar 16, 2015 at 07:35:52AM +0100, Koen Kooi wrote:
This is an UEFI I built myself using https://github.com/96boards/edk2/commits/hikey with a change to use /dev/sda1 as root in bootargs, nothing more.
What is needed to get linux to notice UEFI? It looks like all the bits are in place (bootloader, kernelstub, kernel config).
Booting the kernel as a stub.
How is the kernel actually invoked in this HiKey build-UEFI-but-don't-use-it firmware?
I'm still unfamiliar with EDK2, so I'm going to take a stab at answering your question without knowning what I'm doing :)
HisiPkg/HiKeyPkg/HiKey.dsc sets:
gArmPlatformTokenSpaceGuid.PcdDefaultBootType|2Which seems to imply it's not loaded in EFI mode:
# PcdDefaultBootType define the type of the binary pointed byPcdDefaultBootDevicePath: \r # - 0 = an EFI application\r # - 1 = a Linux kernel with ATAG support\r # - 2 = a Linux kernel with FDT support\r
Flipping the DefaultBootType to 0 (the only method that has any business existing in UEFI) would probably do the trick without getting into the unfortunate habit of using a startup.nsh.
I tested that and it works -> https://github.com/96boards/edk2/pull/2
Would entering the shell and doing
./Image dtb=hi6220-hikey.dtb console=ttyAMA0,115200earlycon=pl011,0xf8015000 root=/dev/sda1 r0 quiet
Should launch it in uefi mode, right?
Yes. Only with '' instead :)
Right :)
-
Koen Kooi -
Leif Lindholm -
Riku Voipio