I think this patchset is in good shape, with the exception of the usage of
the EFI memory map, which I am looking for some suggestions on. The current
implementation populates the bootinfo memory bank list from the EFI memory map,
rather than from the device tree, and doesn't use any reserved ranges. This
works, however the EFI memory map can contain a lot of entries, many of which
are small. Depending on the layout, this could trigger the code that sets
up the frametable to discard most of memory. Also, as a side effect of some
memory being ignored to manage the frametable size, the EFI stub needs to
ensure that it loads modules into memory that XEN is going to map. The
FVP model has 2GBytes of DRAM at 0x80000000 and another 2 at 0x800000000,
so the disjoint case is common.
It seems that both these problems go largely away if sparse frametable mappings are
supported, but I'm not sure how much effort that would be. I think most
of the work done to handle things robustly with the non-sparse frametable
would not apply once a sparse frametable is supported. Does adding support
for a sparse frametable mapping seem like a reasonable way forward on this?
This patch series adds EFI support for arm64 in the form of a EFI stub in
similar fashion to the linux kernel EFI support. A PE/COFF header is created
in head.S, as there is no toolchain support for PE/COFF on arm64. This also
has the advantage that the file is both an "Image" file and a PE/COFF
executable - the same binary can be loaded and run either way. The EFI 'stub'
code is a shim layer that serves as the loader for the XEN kernel in the EFI
environment. The stub loads the dom0 kernel and initrd if required, and adds
entries for them as well as for the EFI data structures into the device tree
passed to XEN. Once the device tree is constructed, EFI boot services are
exited, and the stub transfers control to the normal XEN entry point. The only
indication XEN has that it was loaded via the stub is that the device tree
contains EFI properties. This is all very similar to the arm/arm64 Linux
kernel EFI stubs.
This patchset is based on the staging branch to get Ian's multiboot/device
tree patches.
This series is also available at:
git://git.linaro.org/people/roy.franz/xen.git arm64-efi-stub-v2
Changes since v1:
(I have tried to address all feedback on v1)
* Added common/efi directory for shared EFI code, and arch/arm/efi for
arm-specfic code. Global build hacking of -fshort-wchar removed.
arm32, arm64, and x86 with/without EFI enabled toolchain all build.
The x86 build previously autodetected whether the EFI version should
be built or not based on toolchain support. I couldn't get this working
nicely with the common code, so for x86 I have the common code always
build, and the EFI autodection works as normal for building the EFI
version.
* Basic use of the EFI memory map instead of FDT based memory description.
More work needed to resolve differences between FDT description of
a small number of large memory banks with reserved regions, and EFI's
potentially long list of available regions, which can be long.
* More refactoring of common EFI code to not directly exit using blexit(),
as this broke the pre-linking targets. All shared code returns status,
and it is up to the caller to exit and clean up.
* Reduced the number of patches. Refactoring of x86 code first, then moving
all code to efi-shared.c in one patch.
* Fixed formatting/tab issues in new files, added Emacs footer.
* Fixed efi_get_memory_map to return NULL map pointer on error in addition
to failed status.
* Added comments in head.S regarding PE/COFF specification, and 1:1
mapping used by EFI code.
* Updated device tree bindings to use new multiboot bindings. Since the stub
is always built into XEN, we don't have to support older bindings.
Roy Franz (12):
Create efi-shared.[ch], and move string functions
rename printErrMsg to PrintErrMesgExit
Refactor get_parent_handle for sharing
Refactor read_file() so it can be shared.
replace split_value() with truncate_string()
add read_config_file() function for XEN EFI config file
create handle_cmdline() function
Refactor get_argv() for sharing
Move shared EFI functions to efi-shared.c
add arm64 cache flushing code from linux
Add fdt_create_empty_tree() function.
Add EFI stub for arm64
xen/arch/arm/Makefile | 5 +
xen/arch/arm/Rules.mk | 1 +
xen/arch/arm/arm64/Makefile | 1 +
xen/arch/arm/arm64/cache.S | 100 +++++
xen/arch/arm/arm64/head.S | 185 +++++++++-
xen/arch/arm/efi/Makefile | 2 +
xen/arch/arm/efi/efi.c | 714 ++++++++++++++++++++++++++++++++++++
xen/arch/arm/xen.lds.S | 1 +
xen/arch/x86/Rules.mk | 1 +
xen/arch/x86/efi/boot.c | 625 ++++---------------------------
xen/common/Makefile | 2 +
xen/common/efi/Makefile | 3 +
xen/common/efi/efi-shared.c | 648 ++++++++++++++++++++++++++++++++
xen/common/libfdt/Makefile.libfdt | 2 +-
xen/common/libfdt/fdt_empty_tree.c | 84 +++++
xen/include/asm-arm/arm64/efibind.h | 216 +++++++++++
xen/include/asm-arm/efibind.h | 2 +
xen/include/asm-arm/setup.h | 2 +-
xen/include/efi/efi-shared.h | 72 ++++
xen/include/xen/libfdt/libfdt.h | 1 +
20 files changed, 2101 insertions(+), 566 deletions(-)
create mode 100644 xen/arch/arm/arm64/cache.S
create mode 100644 xen/arch/arm/efi/Makefile
create mode 100644 xen/arch/arm/efi/efi.c
create mode 100644 xen/common/efi/Makefile
create mode 100644 xen/common/efi/efi-shared.c
create mode 100644 xen/common/libfdt/fdt_empty_tree.c
create mode 100644 xen/include/asm-arm/arm64/efibind.h
create mode 100644 xen/include/asm-arm/efibind.h
create mode 100644 xen/include/efi/efi-shared.h
--
2.0.0
On Tue, Jul 29, 2014 at 3:34 PM, Olivier Martin <olivier.martin(a)arm.com>
wrote:
> $
/work/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin/arm-linux-gnueabihf-objdump
-S -D
Build/BeagleBoard/DEBUG_GCC48/ARM/ArmPlatformPkg/PrePi/PeiUniCore/DEBUG/ArmPlatformPrePiUniCore.dll
>
>
>
> FdTop = (EFI_PHYSICAL_ADDRESS)PcdGet32(PcdFdBaseAddress) +
(EFI_PHYSICAL_ADDRESS)PcdGet32(PcdFdSize);
>
> 705c: 4b90 ldr r3, [pc, #576] ;
(72a0 <MemoryPeim+0x2a4>)
>
> 705e: 681b ldr r3, [r3, #0]
>
> 7060: 4618 mov r0, r3
>
> 7062: f04f 0100 mov.w r1, #0
>
> 7066: 4b8f ldr r3, [pc, #572] ; (72a4
<MemoryPeim+0x2a8>)
>
> 7068: 681b ldr r3, [r3, #0]
>
> 706a: 461a mov r2, r3
>
> 706c: f04f 0300 mov.w r3, #0
>
> (...)
>
> 72a0: 0000b4ec andeq fp, r0, ip, ror #9
>
> 72a4: 0000b4f0 strdeq fp, [r0], -r0
>
> (...)
>
> 0000b4ec <_gPcd_FixedAtBuild_PcdFdBaseAddress>:
>
> b4ec: 80008000 andhi r8, r0, r0
>
> 0000b4f0 <_gPcd_FixedAtBuild_PcdFdSize>:
>
> b4f0: 000b0000 andeq r0, fp, r0
>
> I noticed in an earlier email you mentioned ArmPlatformPrePiUniCore.lib.
If you want to look at the final ELF file, you should have a look at
‘.dll’. I know the name is confusing... But ‘.dll’ is actually a ELF file!
Thanks Olivier! The '.dll' dump looks similar to ^ and contains proper PCD
values
at the right address. The '.lib' however shows all the PCDs to be at
00000000:
Disassembly of section .rodata._gPcd_FixedAtBuild_PcdFvBaseAddress:
00000000 <_gPcd_FixedAtBuild_PcdFvBaseAddress>:
0: 80008000 andhi r8, r0, r0
Is it all right that these two addresses are different? If so, what else
sould I check
to trace the fault?
Thanks,
Varad
Hi, I am working on the BeagleBoneBlack port for EDK2 and am facing an
issue with
PcdGet(): it always returns `0` no matter what the PCD is set to. However,
FixedPcdGet() works fine (I've had to patch edk2 to replace all PcdGet
calls with
FixedPcdGet to get PrePi working which is a bad idea).
The build report too shows the PCDs being set to their proper values,
and so do the
AutoGen.i file macros like `const UINT32 _gPcd_FixedAtBuild_PcdFvBaseAddress
= 0x80008000U;`
I've come up with two reasons to this,
* Is there a build flag I'm missing to enable PcdGet support?
* `_gPcd_FixedAtBuild_PcdFvBaseAddress` is declared with
`GLOBAL_REMOVE_IF_UNREFERENCED` in AutoGen.c and gets removed before
I can use it. This also explains why FixedPcdGet would work, since
`_PCD_VALUE_PcdFvBaseAddress` is correctly #defined to be 0x80008000U.
This happens for all fixed-at-build type PCDs. Also, I'm linked to
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf for the buid. What could
I try to fix it?
Thanks,
Varad
Hi Leif,
I have make a new multiboot support patch V3.6, because Roy has made stub-xen support.
Compared with V3.6, I added the stub-kernel boot support:
Support stub-kernel and raw kernle image at the same time:
If kernel image is stub-kernel, multiboot will reload alignment from stub header.
To Ian:
Now, Xen can boot up all the CPUs of FVP base model, it's cool, I have tested it.
Once Xen can support multiple blanks of RAM, please let me know, then I can test the latest linaro-edk2 with GRUB and Xen.
To Roy:
I can't boot your stub-xen directly.
I checked the code, I guess your stub code always want to get cmdline, dtb file info the make a new dtb, the installed dtb checking in your code is a little late. so I add a temporary patch on your patches.
My patch is NOT a fix, just for locate the problem. Could we discuss and figure out this issue, when you come back? :-)
Some pending change:
(1)delete "grub_arm64_disable_caches_mmu" and the relevant code(misc.c and misc_irq.S)(If we don't want to support raw kernel anymore)
(2)grub coding style (I have checked the patch, but maybe I need to improve it in somewhere)
(3)integrate multiboot_fdt.c back to multiboot.c (will make a new patch/branch for it, but I think multiboot_fdt.c make multiboot.c more generic)
Will update the wiki patch, in case someone want to try it.
Notice: This patch bases on master branch of upstream grub
This patch only can works with the GRUB_multiboot_test branch of my xen repo(git://git.linaro.org/people/fu.wei/xen.git), because I have added a little patch on Roy's stub support code.
--
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
have now been tagged pushed and built. Images available in:
http://snapshots.linaro.org/components/kernel/linaro-edk2-prep/26
Changes since -a1:
- D01 platform now builds.
- Arndale dropped.
Unless anyone screams within the next few hours, this will become the
July release.
(Testing would still be appreciated, but I realise it is late in the day.)
Hi Leif,
I have make a new multiboot support patch V3.5, because Ian has fixed the bugs in his branch.
To Ian:
Once Xen can support multiple blanks of RAM, please let me know, then I can test the latest linaro-edk2 with GRUB and Xen.
Some pending change:
(1)delete "grub_arm64_disable_caches_mmu" and the relevant code(misc.c and misc_irq.S)(waiting for stub-xen)
(2)non-stub xen boot switch to stub-xen boot (waiting for stub-xen)
(3)grub coding style (maybe I need to improve it in somewhere)
(6)integrate multiboot_fdt.c back to multiboot.c (will make a new patch/branch for it, but I think multiboot_fdt.c make multiboot.c more generic)
Will update the wiki patch, in case someone want to try it.
Notice: This patch bases on master branch of upstream grub
This patch only can works with the multiboot-improvements-v2 branch of Ian's xen repo(git://xenbits.xen.org/people/ianc/xen.git), because the compatible streams have changed.
--
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
has now been pushed and built. Images available in:
http://snapshots.linaro.org/components/kernel/linaro-edk2-prep/25
Modifications to upstream code caused some minor issues this time
around - refactoring of GIC code and removal of -Wno-missing-braces
from GCC command line parameters.
- Arndale no longer builds, and I'm considering retiring it (it has
not been tested for ages).
- D01 will require some changes to the GIC code in order to build and
be included with the 2014.07
release - but is still actively maintained by the Hisilicon landing
team, so will not be dropped.
/
Leif
Hello all,
This branch
https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/he…
contains the minimal changes to boot AArch64 FVP with Secure Boot enabled.
Look at the commit logs for some instructions: you need to enable the
embedded OpenSSL build and generate some certificates and sign your
kernel.
This uses the non-volatile flash to store the certificates, so once
the certificates are installed, secure boot remains enabled until you
delete your nor.dat file.
Note that this includes the embedded DTB patches, as you won't be able
to load a device tree using dtb=
--
Ard.
This patch series is an RFC series that adds EFI support for arm64 in the
form of a EFI stub in similar fashion to the linux kernel EFI support.
A PE/COFF header is created in head.S, as there is no toolchain support
for PE/COFF on arm64. This also has the advantage that the file is both
an "Image" file and a PE/COFF executable - the same binary can be loaded
and run either way. The EFI 'stub' code is a shim layer that serves as
the loader for the XEN kernel in the EFI environment. The stub loads
the dom0 kernel and initrd if required, and adds entries for them as well
as for the EFI data structures into the device tree passed to XEN. Once
the device tree is constructed, EFI boot services are exited, and the stub
transfers control to the normal XEN entry point. The only indication
XEN has that it was loaded via the stub is that the device tree contains
EFI properties. This is all very similar to the arm/arm64 Linux kernel
EFI stubs.
The first 14 patches refactor and move x86 EFI code so that it can be
shared with the arm64 EFI stub. The remaining 5 patches add the new
arm64 EFI stub.
One significant omission from this series is proper EFI memory map
handling in XEN itself. This patch instead creates FDT memory nodes based
on the EFI memory map. This is functional, but not how we want to do
it long term. The XEN kernel updates for this will be largely
disjoint from this series, and I will be starting on that next. I wanted
to get this portion out for review without waiting for that portion of the
code to be done. The ADD_EFI_MEMORY_TO_FDT macro isolates code that will
change when the proper EFI memory map handling is added to XEN.
I have some some simple tests booting from the EFI shell on arm64 (FVP
base model) and x86_64 (vmware.)
This patch series is available on my git tree:
git://git.linaro.org/people/roy.franz/xen.git
tag: xen-efi-stub-rfc-20140627
There are a few open issues in this patch series that I would appreciate
feedback/suggestions on:
1) Build system changes. The 'efi-shared.c' file should be properly
shared, rather than symbolicly linked. One complication is that the EFI
code (for both archs) needs to be compiled with "-fshort-wchar". I also
likely need to create an efi subdir for arm64.
2) Is it valid to start XEN with a device tree that only contains
multi-boot and EFI info? (As would be the case if the stub doesn't get a
device tree as input.) Currently this isn't supported, some libfdt
functions are missing, so I'm checking if this is desired before I add
that.
3) I'm not sure arm64 needs it's own copy of efibind.h. The x86_64
version worked fine as is, but has some Microsoft related defines in
there. The arm64 version I created is a proper subset with the exception
of the EFI_STUB_ERROR define.
(I am on vacation the week of June 30th-July 4th, so my responses will be
delayed.)
Roy Franz (19):
HACK: Add -fshort-wchar to global build
Create efi-shared.[ch], and move string functions
Move more functions from boot.c to efi-shared.c
rename printErrMsg to PrintErrMesgExit
Add PrintErrMesg function that doesn't exit
Refactor read_file() so it can be shared.
move read_file() to efi-shared.c
Move removal of leading spaces from split_value to get_value()
replace split_value() with truncate_string()
move truncate_string() to efi-shared.c
add read_config_file() function for XEN EFI config file
create handle_cmdline() function
Refactor get_argv() for sharing
Move get_argv() and handle_cmdline() to efi-shared.c
Add PE/COFF header in head.S
create ARM EFI headers, based on x86
Remove x86 specific defintions from efibind.h
Add assembler use support for efibind.h
Add EFI stub for ARM64
Config.mk | 2 +
xen/arch/arm/Makefile | 2 +
xen/arch/arm/arm64/head.S | 178 +++++++++-
xen/arch/arm/efi-shared.c | 1 +
xen/arch/arm/efi.c | 686 ++++++++++++++++++++++++++++++++++++
xen/arch/arm/efi.h | 11 +
xen/arch/arm/xen.lds.S | 1 +
xen/arch/x86/Makefile | 4 +-
xen/arch/x86/efi/Makefile | 2 +-
xen/arch/x86/efi/boot.c | 614 +++-----------------------------
xen/arch/x86/efi/efi-shared.c | 620 ++++++++++++++++++++++++++++++++
xen/include/asm-arm/arm64/efibind.h | 206 +++++++++++
xen/include/asm-arm/efibind.h | 2 +
xen/include/efi/efi-shared.h | 71 ++++
14 files changed, 1832 insertions(+), 568 deletions(-)
create mode 120000 xen/arch/arm/efi-shared.c
create mode 100644 xen/arch/arm/efi.c
create mode 100644 xen/arch/arm/efi.h
create mode 100644 xen/arch/x86/efi/efi-shared.c
create mode 100644 xen/include/asm-arm/arm64/efibind.h
create mode 100644 xen/include/asm-arm/efibind.h
create mode 100644 xen/include/efi/efi-shared.h
--
2.0.0
