Hi Roy,
Thank you for this series. I haven't look closely to this series but I've tried to compile it for arm32 and it's fails.
It looks like the EFI stub is also included for arm32, which you don't plan to support right?
I would use your CONFIG_EFI_STUB you've hardcoded in arm64/head.s to know if we need to include the EFI stub or not in the compilation.
On 28/06/14 02:25, Roy Franz wrote:
There are a few open issues in this patch series that I would appreciate feedback/suggestions on:
- 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.
I would create a directly xen/drivers/efi so you can move efi code in there.
Hence, you will be able to use -fshort-wchar only for this directory.
- 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.
- 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.
Maybe you can create a new header in include/efi and use asm/efi.h for architectural bindings.
Regards,