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
Hello all,
This is an attempt to get some clarification on the requirement for
the kernel to preserve the state of the NEON register file before
calling into UEFI runtime services.
According to the generic Procedure Call Standard for AArch64, only the
lower 64-bits of registers q8 .. q15 need to be preserved by the
callee. There are further constraints in the UEFI spec which are
defined as:
2.3.6.4 Detailed Calling Convention
The base calling convention for the AArch64 binding is defined in the
document Procedure Call
Standard for the ARM 64-bit Architecture Version A-0.06 (or later):
http://infocenter.arm.com/
This binding further constrains the calling convention in these ways:
. The AArch64 execution state must not be modified by the callee.
. All code exits, normal and exceptional, must be from the A64 instruction set.
. Floating point and SIMD instructions may be used.
. Optional vector operations and other instruction set extensions may
only be used:
- After dynamically checking for their existence.
- Saving and then later restoring any additional execution state context.
- Additional feature enablement or control, such as power, must be
explicitly managed.
. Only little endian operation is supported.
. The stack will maintain 16 byte alignment.
. Structures (or other types larger than 64-bits) must be passed by
reference and not by value.
. The EFI AArch64 platform binding defines the platform register (r18)
as “do not use”. Avoiding
use of r18 in firmware makes the code compatible with both a fixed
role for r18 defined by the
OS platform ABI and the use of r18 by the OS and its applications as a
temporary register.
IIUC floating point is mandatory in the v8 spec, which would imply
that they should not be considered to be 'optional vector operations
and other instruction set extensions', which would mean that the
normal AAPCS rules apply, i.e., that the callee can clobber q0 .. q7
and q16 .. q31.
Any thoughts?
--
Ard.
Hi Leif,
I have make a new multiboot support patch V3.4 following Ian's suggestion for V3.1
But I met some problem on the latest xen for multiboot development branch, so I am still using the staging branch of xen repo.
To Ian:
Could we just work together to figure them out next week?
Can Xen support two blanks of RAM for now?
it seems the new linaro-edk2 (2014.06) will allocate memory from the high end of ram, that cause the failure.
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)align info (need more info from Ian, or do we need --align ?)
(4)the compatibility strings: "xen,*" ---> "multiboot,*" (need Ian's multiboot branch)
(5)grub coding style (will do in next patch)
(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)
Now this patch works fine with the staging branch of xen.
Will update the wiki patch, in case someone want to try it. :-)
Notice: This patch bases on master branch of upstream grub
--
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 am trying to boot GRUB present at HARD-DISK connected over PCI and in
AHCI mode.
I am able to boot by setting default boot path as below.
gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|L"PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x0,0x0,0x0)/HD(1,GPT,E3AE6975-BACE-464E-91E1-BB4FE9954047,0x800,0x31801)/\EFI\BOOT\BOOTAA64.EFI"
however, i see the Partition GUID(Partition unique GUID:
E3AE6975-BACE-464E-91E1-BB4FE9954047) which is part of path changes when
ever hard disk is repartitioned or created with partition.
are there any other way to set the default boot path which is consistent
and not depends on GUID.
thanks
Ganapat
This patch contains what is required to enable efistub-as-a-static-lib on ARM.
Baseline is Leif's topic-leg-uefi branch c4881777cb4d, with the following
patches applied (all sent to the linux-efi and linux-arm-kernel lists over the
past couple of days). They should all apply cleanly.
efi: efistub: convert into static library
efi: efistub: refactor stub components
efi/arm64: efistub: move shared dependencies to <asm/efi.h>
efi/x86: efistub: move shared dependencies to <asm/efi.h>
efi/arm64: efistub: remove local copy of linux_banner
ARM: use linux_banner from init/version.o
---
arch/arm/Kconfig | 1 +
arch/arm/boot/compressed/Makefile | 2 +-
arch/arm/boot/compressed/efi-stub.c | 67 +++++----------------------------
arch/arm/include/asm/efi.h | 21 +++++++++++
drivers/firmware/efi/libstub/arm-stub.c | 14 +++----
5 files changed, 40 insertions(+), 65 deletions(-)
create mode 100644 arch/arm/include/asm/efi.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fa1f3e7c8499..5adc84b66be7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1903,6 +1903,7 @@ config EFI
select UCS2_STRING
select EARLY_IOREMAP
select EFI_PARAMS_FROM_FDT
+ select EFI_ARMSTUB
---help---
This enables the kernel to use UEFI runtime services that are
available (such as the UEFI variable services).
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 37abdc31cc3f..364ddfd5da26 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -109,7 +109,7 @@ endif
ifeq ($(CONFIG_EFI_STUB),y)
CFLAGS_efi-stub.o += -DTEXT_OFFSET=$(TEXT_OFFSET)
-OBJS += efi-stub.o banner.o
+OBJS += efi-stub.o banner.o ../../../../drivers/firmware/efi/libstub/lib.a
USE_LIBFDT = y
$(obj)/banner.o: OBJCOPYFLAGS = -j .rodata
diff --git a/arch/arm/boot/compressed/efi-stub.c b/arch/arm/boot/compressed/efi-stub.c
index 3b029d7eb5a8..4e8082508eb2 100644
--- a/arch/arm/boot/compressed/efi-stub.c
+++ b/arch/arm/boot/compressed/efi-stub.c
@@ -11,62 +11,15 @@
*
*/
#include <linux/efi.h>
-#include <libfdt.h>
-#include <generated/compile.h>
-#include <generated/utsrelease.h>
-#include "efi-stub.h"
+#include <asm/efi.h>
-
-/* Wrapper macro for compatability with x86 mixed mode shared code. */
-#define efi_call_early(f, ...) sys_table_arg->boottime->f(__VA_ARGS__)
-
-
-/*
- * The maximum uncompressed kernel size is 32 MBytes, so we will reserve
- * that for the decompressed kernel. We have no easy way to tell what
- * the actuall size of code + data the uncompressed kernel will use.
- */
-#define MAX_UNCOMP_KERNEL_SIZE 0x02000000
-
-/*
- * The kernel zImage should be located between 32 Mbytes
- * and 128 MBytes from the base of DRAM. The min
- * address leaves space for a maximal size uncompressed image,
- * and the max address is due to how the zImage decompressor
- * picks a destination address.
- */
-#define ZIMAGE_OFFSET_LIMIT 0x08000000
-#define MIN_ZIMAGE_OFFSET MAX_UNCOMP_KERNEL_SIZE
-#define MAX_FDT_OFFSET ZIMAGE_OFFSET_LIMIT
-
-/*
- * Prototypes for shared code used in efi-stub-helper.c, but
- * provided in arm-stub.c
- */
-static void efi_char16_printk(efi_system_table_t *sys_table_arg,
- efi_char16_t *str);
-static efi_status_t efi_open_volume(efi_system_table_t *sys_table,
- void *__image, void **__fh);
-static efi_status_t efi_file_close(void *handle);
-static efi_status_t
-efi_file_read(void *handle, unsigned long *size, void *addr);
-static efi_status_t
-efi_file_size(efi_system_table_t *sys_table, void *__fh,
- efi_char16_t *filename_16, void **handle, u64 *file_sz);
-
-
-/* Include shared EFI stub code, and required headers. */
-#include "../../../../drivers/firmware/efi/efi-stub-helper.c"
-#include "../../../../drivers/firmware/efi/fdt.c"
-#include "../../../drivers/firmware/efi/arm-stub.c"
-
-static efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
- unsigned long *image_addr,
- unsigned long *image_size,
- unsigned long *reserve_addr,
- unsigned long *reserve_size,
- unsigned long dram_base,
- efi_loaded_image_t *image)
+efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
+ unsigned long *image_addr,
+ unsigned long *image_size,
+ unsigned long *reserve_addr,
+ unsigned long *reserve_size,
+ unsigned long dram_base,
+ efi_loaded_image_t *image)
{
unsigned long nr_pages;
efi_status_t status;
@@ -82,7 +35,7 @@ static efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
*/
if (dram_base & (ZIMAGE_OFFSET_LIMIT - 1)) {
pr_efi_err(sys_table, "Invalid DRAM base address alignment.\n");
- return EFI_ERROR;
+ return EFI_LOAD_ERROR;
}
/*
@@ -133,7 +86,7 @@ static efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
*reserve_size = 0;
efi_free(sys_table, *image_size, *image_addr);
*image_size = 0;
- return EFI_ERROR;
+ return EFI_LOAD_ERROR;
}
return EFI_SUCCESS;
}
diff --git a/arch/arm/include/asm/efi.h b/arch/arm/include/asm/efi.h
new file mode 100644
index 000000000000..9171f9a1c14a
--- /dev/null
+++ b/arch/arm/include/asm/efi.h
@@ -0,0 +1,21 @@
+
+#define efi_call_early(f, ...) sys_table_arg->boottime->f(__VA_ARGS__)
+
+/*
+ * The maximum uncompressed kernel size is 32 MBytes, so we will reserve
+ * that for the decompressed kernel. We have no easy way to tell what
+ * the actuall size of code + data the uncompressed kernel will use.
+ */
+#define MAX_UNCOMP_KERNEL_SIZE 0x02000000
+
+/*
+ * The kernel zImage should be located between 32 Mbytes
+ * and 128 MBytes from the base of DRAM. The min
+ * address leaves space for a maximal size uncompressed image,
+ * and the max address is due to how the zImage decompressor
+ * picks a destination address.
+ */
+#define ZIMAGE_OFFSET_LIMIT 0x08000000
+#define MIN_ZIMAGE_OFFSET MAX_UNCOMP_KERNEL_SIZE
+#define MAX_FDT_OFFSET ZIMAGE_OFFSET_LIMIT
+
diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c
index 34614d6f9698..480339b6b110 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -151,13 +151,13 @@ void efi_char16_printk(efi_system_table_t *sys_table_arg,
* must be reserved. On failure it is required to free all
* all allocations it has made.
*/
-static efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
- unsigned long *image_addr,
- unsigned long *image_size,
- unsigned long *reserve_addr,
- unsigned long *reserve_size,
- unsigned long dram_base,
- efi_loaded_image_t *image);
+efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
+ unsigned long *image_addr,
+ unsigned long *image_size,
+ unsigned long *reserve_addr,
+ unsigned long *reserve_size,
+ unsigned long dram_base,
+ efi_loaded_image_t *image);
/*
* EFI entry point for the arm/arm64 EFI stubs. This is the entrypoint
* that is described in the PE/COFF header. Most of the code is the same
--
1.8.3.2
