Booting UEFI for our 64 bit models/platforms has become more complex due to
upstream changes.
You can build UEFI as per usual, however, before you can boot the .fd file,
you will have to wrap it into a Firmware Image Package (aka FIP).
You will not be able to mix "old " and "new" versions of UEFI and TF.
--------------------------------------------------------------------------------
- Get the UEFI build tools
--------------------------------------------------------------------------------
git clone git.linaro.org/arm/uefi/uefi-tools.git
PATH=$PATH:`pwd`/uefi-tools
You can also download a pre-built binary from a release or snapshot build
place such as:
http://releases.linaro.org/14.04/components/kernel/uefi-linarohttp://snapshots.linaro.org/components/kernel/linaro-edk2/latesthttp://snapshots.linaro.org/components/kernel/linaro-edk2-release-prep/late…http://snapshots.linaro.org/components/kernel/fvp-pre-boot/latest
--------------------------------------------------------------------------------
- Build UEFI for the FVP models
--------------------------------------------------------------------------------
git clone git://git.linaro.org/uefi/linaro-edk2.git
cd linaro-edk2
uefi-build fvp_minimal
This will give you a .fd file, such as:
./Build/ArmVExpress-FVP-AArch64/RELEASE_GCC48/FV/FVP_AARCH64_EFI.fd
You will then need to point the "BL33" environment variable to this file,
eg:
export
BL33=`pwd`/Build/ArmVExpress-FVP-AArch64/RELEASE_GCC48/FV/FVP_AARCH64_EFI.fd
--------------------------------------------------------------------------------
- Build the Trusted Firmware for FVP models
--------------------------------------------------------------------------------
git clone git://git.linaro.org/arm/arm-trusted-firmware.git
CROSS_COMPILE=aarch64-linux-gnu- make PLAT=fvp all fip
You will then have two important files:
./build/fvp/release/bl1.bin
./build/fvp/release/fip.bin
--------------------------------------------------------------------------------
- Boot the model
--------------------------------------------------------------------------------
Pass the bl1.bin and fip.bin files as parameters to the model. Eg, this is
how I booted my model:
/linaro/fastmodels/FVP_Base_AEMv8A-AEMv8A/models/Linux64_GCC-4.1/FVP_Base_AEMv8A-AEMv8A
-C pctl.startup=0.0.0.0 -C bp.secure_memory=0 -C cluster0.NUM_CORES=1 -C
cluster1.NUM_CORES=1 -C cache_state_modelled=0 -C
bp.pl011_uart0.untimed_fifos=1 -C
bp.secureflashloader.fname=./build/fvp/release/bl1.bin -C
bp.flashloader0.fname=./build/fvp/release/fip.bin -C
bp.virtioblockdevice.image_path=/linaro/releases/oe/14.04/fastmodel/sd.img
-C bp.hostbridge.interfaceName=ARMryan -C bp.smsc_91c111.enabled=true -C
bp.smsc_91c111.mac_address=00:02:f7:ef:67:e6
Of course, your installation path to the models and the location of your
disk image will vary.
Hope this all helps,
Regards,
Ryan.
Hi Leif,
I have make a multiboot support patch V3 following all your suggestion
The main change are :
(1)separate all the xen specific code to multiboot_xen.c and multiboot_xen.h
(2)support for ramdisk and xsm
(3)fully support http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot
and xen/docs/misc/arm/device-tree/booting.txt in Xen source code.
(4)there is not limit in the module's number
For the test log, please check :
https://staging.validation.linaro.org/scheduler/job/46542/log_file
I have tested it locally, it works fine for me.
Please check the patch, and provide some suggestions.
Thank you very much!
--
Best regards,
Fu Wei
Enterprise Server Engineer From Red Hat
LEG Team
Linaro.org | Open source software for ARM SoCs
Ph: +86 186 2020 4684 (mobile)
IRC: fuwei
Skype: tekkamanninja
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
Hi all,
I have a problem,can you please help me out?
We want boot zImage(zImage is comprised of EFI stub and Linux kernel) by Tftp in Bootmanager,but we found an error:
D01 >exit
unload symbols_only c:\uefi_linaro_workspace\binary_give\uefi-next-d95896d\Build
\D01\DEBUG_RVCT\ARM\HisiPkg\D01BoardPkg\Application\Ebl\Ebl\DEBUG\Ebl.dll
[1] Ramdisk
- VenMsg(06ED4DD0-FF78-11D3-BDC4-00A0C94053D1,0000000000000000)/uImage
- Initrd: VenMsg(06ED4DD0-FF78-11D3-BDC4-00A0C94053D1,0000000000000000)/
initrd
- Arguments: mem=256M console=ttyAMA0,9600
- LoaderType: Linux kernel with ATAG data
-----------------------
Global FDT Config
- not configured
-----------------------
[a] Boot Manager
[b] EBL
[c] GO
Start: a
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Update FDT path
[5] Return to main menu
Choice: 1
[1] (29 MB)
- VenMsg(06ED4DD0-FF78-11D3-BDC4-00A0C94053D1,0000000000000000)
[2] (978 MB)
- Pci(0x0,0x0)/Sata(0x0,0x0,0x0)/HD(1,MBR,0x00000000,0x3F,0x1EA3FE)
[3] (978 MB)
- Pci(0x0,0x0)/Sata(0x0,0x0,0x0)/HD(2,MBR,0x00000000,0x1EA43D,0x1EA43D)
[4] (978 MB)
- Pci(0x0,0x0)/Sata(0x0,0x0,0x0)/HD(3,MBR,0x00000000,0x3D487A,0x1EA43D)
[5] VenMsg(06ED4DD0-FF78-11D3-BDC4-00A0C94053D1,0000000000000000)
- VenMsg(06ED4DD0-FF78-11D3-BDC4-00A0C94053D1,0000000000000000)
[6] PXE on MAC Address: 0E:00:FF:0C:FF:FE
- MAC(0E00FF0CFFFE,0x1)
[7] TFTP on MAC Address: 0E:00:FF:0C:FF:FE
- MAC(0E00FF0CFFFE,0x1)
Select the Boot Device: 7
Get the IP address from DHCP: [y/n] y
Get the TFTP server IP address: 192.168.10.100
File path of the EFI Application or the kernel : zImage
Is an EFI Application? [y/n] y
Is your application is an OS loader? [y/n] n
Description for this new Entry: OS
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Update FDT path
[5] Return to main menu
Choice: 5
[1] Ramdisk
- VenMsg(06ED4DD0-FF78-11D3-BDC4-00A0C94053D1,0000000000000000)/uImage
- Initrd: VenMsg(06ED4DD0-FF78-11D3-BDC4-00A0C94053D1,0000000000000000)/
initrd
- Arguments: mem=256M console=ttyAMA0,9600
- LoaderType: Linux kernel with ATAG data
[2] OS
- MAC(0E00FF0CFFFE,0x1)/IPv4(192.168.10.100)
- LoaderType: EFI Application
-----------------------
Global FDT Config
- not configured
-----------------------
[a] Boot Manager
[b] EBL
[c] GO
Start: 2
AllocatePoolPages: failed to allocate 322561 pages
AllocatePool: failed to allocate 1321205792 bytes
AllocatePoolPages: failed to allocate 322561 pages
AllocatePool: failed to allocate 1321205792 bytes
The error happened in BdsLoadImage-> BdsConnectDevicePath.Actually, Handle is no use in BdsTftpLoadImage,so I modify BdsLoadImage for test,then we can download zImage,but we still cannot boot it;
(We can boot linux by Grub)
Can you give me some advice?
Hi, experts:
I want to test booting an AARCH32 UEFI bin.
I have downloaded a free licenced FVP model.
I used ATF(Arm Trusted Firmware) to boot UEFI.bin .
So, how to compile a AARCH32 UEFI bin?
Could current UEFI code be compiled as a 32bit bin?
Best wishes,
Hi Leif,
I have tested the linaro-edk2 and grub-install in latest leg image, report is below:
For linaro-edk2(http://snapshots.linaro.org/components/kernel/linaro-edk2/12)
Because this version of uefi need to work with Turstzone Firmware0.3, so we need to wrap it, can not test directly in LAVA.
I wrap it locally, and upload to linaro for testing:
http://people.linaro.org/~fu.wei/LAVA/test/UEFI/Bug-1281123/
Test:
https://staging.validation.linaro.org/scheduler/job/46616
But in local test, I found some problems:
(1)I can not execute the grub stored in /EFI/grub/grubaa64, but once I copy it to / or /EFI/BOOT/, that can be executed either by FS1:/EFI/grub/grubaa64.efi and EFI\BOOT\grubaa64.efi , the log is below:
------------------
Shell> FS1:/EFI/grub/grubaa64.efi
'FS1:/EFI/grub/grubaa64.efi' is not recognized as an internal or external command, operable program, or script file.
Shell> FS1:
FS1:\> ls EFI/grub/*
04/17/2014 14:43 <DIR> 2,048 .
04/17/2014 14:43 <DIR> 2,048 ..
04/17/2014 14:50 124,416 grubaa64.efi
1 File(s) 124,416 bytes grub
2 Dir(s)) 0 bytes
FS1:\> EFI/grub/grubaa64.efi
'EFI/grub/grubaa64.efi' is not recognized as an internal or external command, operable program, or script file.
FS1:\> cp EFI/grub/grubaa64.efi EFI/BOOT/
Copying FS1:\EFI\grub\grubaa64.efi -> FS1:\EFI\BOOT\grubaa64.efi
- [ok]
FS1:\> EFI\BOOT\grubaa64.efi
Welcome to GRUB!
GNU GRUB version 2.02~beta2
Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists possible
device or file completions.
grub> exit
FS1:\> FS1:\EFI\grub\grubaa64.efi
Welcome to GRUB!
GNU GRUB version 2.02~beta2
Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists possible
device or file completions.
grub> exit
FS1:\> EFI/grub/grubaa64.efi
'EFI/grub/grubaa64.efi' is not recognized as an internal or external command, operable program, or script file.
FS1:\> rm EFI/BOOT/grubaa64.efi
Deleting 'FS1:\EFI\BOOT\grubaa64.efi'
Delete successful
FS1:\> FS1:\EFI\grub\grubaa64.efi
Welcome to GRUB!
GNU GRUB version 2.02~beta2
Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists possible
device or file completions.
grub> exit
FS1:\> grubaa64.efi
'grubaa64.efi' is not recognized as an internal or external command, operable program, or script file.
FS1:\> grubaa64
'grubaa64' is not recognized as an internal or external command, operable program, or script file.
FS1:\> FS1:\EFI\grub\grubaa64.efi
Welcome to GRUB!
GNU GRUB version 2.02~beta2
Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists possible
device or file completions.
grub> exit
FS1:\> cp EFI/grub/grubaa64.efi .
Copying FS1:\EFI\grub\grubaa64.efi -> FS1:\grubaa64.efi
- [ok]
FS1:\> grubaa64.efi
Welcome to GRUB!
GNU GRUB version 2.02~beta2
Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists possible
device or file completions.
grub>
------------------
*Is that the normal behavior???*
(2)Got "Synchronous Exception:", once I exit from uefi shell and reenter the shell, the log is below:
------------------
FS1:\> exit
[1] Linaro disk image on virtio
- VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/Image
- Arguments: console=ttyAMA0 earlyprintk=pl011,0x1c090000 debug user_debug=31 loglevel=9 root=/dev/vda2
- FDT: VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/fvp-base-gicv2-psci.dtb
- LoaderType: Linux kernel with Local FDT
[2] pxe
- MAC(201201041000,0x1)
- LoaderType: EFI Application
-----------------------
Global FDT Config
- VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/fdt.dtb
-----------------------
[a] Boot Manager
[b] Shell
[c] Reboot
[d] Shutdown
Start: b
Synchronous Exception:
Synchronous Exception:
......
------------------
(3)grub did not get the config file in /grub/grub.cfg
Test log:
https://staging.validation.linaro.org/scheduler/job/46613/log_file#L_131_0https://staging.validation.linaro.org/scheduler/job/46613/log_file#L_155_2
Could you help me, Thanks!
--
Best regards,
Fu Wei
Enterprise Server Engineer From Red Hat
LEG Team
Linaro.org | Open source software for ARM SoCs
Ph: +86 186 2020 4684 (mobile)
IRC: fuwei
Skype: tekkamanninja
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
Hi guys,
There was some complaints about shortcomings of EDK2 build system, like
"make clean" doesn't work correct, dependency checking is lame, etc. It
would be really great to collect here all inputs with explanations (or
steps how to reproduce). So if you happened to notice that something is
wrong with EDK2 build system -- please provide this information here. I
also don't really understand what is wrong with clean scripts and
dependency checking (just heard complaints without explanations), so if you
know any details -- please provide it here as well.
Once I have enough inputs I will solicit feedback from the community and
will try to upstream fixes.
Thanks!
Hi all,
I have a problem,can you please help me out?
We want boot zImage(zImage is comprised of EFI stub and Linux kernel) by Tftp in Bootmanager,but we found an error:
D01 >exit
unload symbols_only c:\uefi_linaro_workspace\binary_give\uefi-next-d95896d\Build
\D01\DEBUG_RVCT\ARM\HisiPkg\D01BoardPkg\Application\Ebl\Ebl\DEBUG\Ebl.dll
[1] Ramdisk
- VenMsg(06ED4DD0-FF78-11D3-BDC4-00A0C94053D1,0000000000000000)/uImage
- Initrd: VenMsg(06ED4DD0-FF78-11D3-BDC4-00A0C94053D1,0000000000000000)/
initrd
- Arguments: mem=256M console=ttyAMA0,9600
- LoaderType: Linux kernel with ATAG data
-----------------------
Global FDT Config
- not configured
-----------------------
[a] Boot Manager
[b] EBL
[c] GO
Start: a
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Update FDT path
[5] Return to main menu
Choice: 1
[1] (29 MB)
- VenMsg(06ED4DD0-FF78-11D3-BDC4-00A0C94053D1,0000000000000000)
[2] (978 MB)
- Pci(0x0,0x0)/Sata(0x0,0x0,0x0)/HD(1,MBR,0x00000000,0x3F,0x1EA3FE)
[3] (978 MB)
- Pci(0x0,0x0)/Sata(0x0,0x0,0x0)/HD(2,MBR,0x00000000,0x1EA43D,0x1EA43D)
[4] (978 MB)
- Pci(0x0,0x0)/Sata(0x0,0x0,0x0)/HD(3,MBR,0x00000000,0x3D487A,0x1EA43D)
[5] VenMsg(06ED4DD0-FF78-11D3-BDC4-00A0C94053D1,0000000000000000)
- VenMsg(06ED4DD0-FF78-11D3-BDC4-00A0C94053D1,0000000000000000)
[6] PXE on MAC Address: 0E:00:FF:0C:FF:FE
- MAC(0E00FF0CFFFE,0x1)
[7] TFTP on MAC Address: 0E:00:FF:0C:FF:FE
- MAC(0E00FF0CFFFE,0x1)
Select the Boot Device: 7
Get the IP address from DHCP: [y/n] y
Get the TFTP server IP address: 192.168.10.100
File path of the EFI Application or the kernel : zImage
Is an EFI Application? [y/n] y
Is your application is an OS loader? [y/n] n
Description for this new Entry: OS
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Update FDT path
[5] Return to main menu
Choice: 5
[1] Ramdisk
- VenMsg(06ED4DD0-FF78-11D3-BDC4-00A0C94053D1,0000000000000000)/uImage
- Initrd: VenMsg(06ED4DD0-FF78-11D3-BDC4-00A0C94053D1,0000000000000000)/
initrd
- Arguments: mem=256M console=ttyAMA0,9600
- LoaderType: Linux kernel with ATAG data
[2] OS
- MAC(0E00FF0CFFFE,0x1)/IPv4(192.168.10.100)
- LoaderType: EFI Application
-----------------------
Global FDT Config
- not configured
-----------------------
[a] Boot Manager
[b] EBL
[c] GO
Start: 2
AllocatePoolPages: failed to allocate 322561 pages
AllocatePool: failed to allocate 1321205792 bytes
AllocatePoolPages: failed to allocate 322561 pages
AllocatePool: failed to allocate 1321205792 bytes
The error happened in BdsLoadImage-> BdsConnectDevicePath.Actually, Handle is no use in BdsTftpLoadImage,so I modify BdsLoadImage for test,then we can download zImage,but we still cannot boot it;
(We can boot linux by Grub)
Can you give me some advice?
I'll be changing uefi-build.sh soon so that it uses the bare-metal
toolchains. I haven't pushed the change yet because I'm still testing
stuff.
Once I make the change, you will need to have the bare-metal toolchain
installed or you won't be able to build any more.
So let me know if this will be a problem!
I think I'll also put a check into the script to test if you actually have
the toolchain on your path and give an error if not. At the moment, it
will just try to build and fail later on.
Where do you get the bare metal toolchain from?
http://releases.linaro.org/14.03/components/toolchain/binarieshttp://releases.linaro.org/14.03/components/toolchain/binaries/gcc-linaro-a…http://releases.linaro.org/14.03/components/toolchain/binaries/gcc-linaro-a…
I believe the latest version that ARM have used/tested is 13.11. I am yet
to find out if 14.03 works or not...
Some background:
OK, so I have to confess that I've been using the wrong toolchain for quite
some time now.
I already have the linux-gnu- toolchain installed and it's always worked,
so I've been generally happy to keep using it. Whenever I get something
new from ARM (UEFI, TF, ...), it usually tells me to use the bare-metal
toolchain. I follow the instructions first time, then repeat with my
"normal" toolchain.
However, I've now come across a problem where building for an AArch64
platform with the linux-gnu- platform toolchain doesn't boot, whereas using
the bare-metal toolchain is fine.
Of course, I have never really known what the difference between the two
is. Enter the toolchain FAQ:
https://wiki.linaro.org/WorkingGroups/ToolChain/FAQ
"The bare-metal ABI will assume a different C library (newlib for example)
- or even no C library to the Linux ABI (which assumes glibc). Therefore,
the compiler may make different function calls depending on what it
believes is available above and beyond the Standard C library.
Also the bare-metal ABI and Linux ABI for the 32-bit Instruction sets make
different assumptions about the storage size of enums and wchar_t which you
have to be careful of (not a complete list). And the difference between the
32-bit and 64-bit ABIs are also numerous and subtle (the obvious example
being pointer sizes)."
... ooops!