On Tue, 2015-06-02 at 10:17 +0200, Ard Biesheuvel wrote:
On 2 June 2015 at 10:01, Haojian Zhuang haojian.zhuang@linaro.org wrote:
On Tue, 2015-06-02 at 16:00 +0800, Haojian Zhuang wrote:
On Tue, 2015-06-02 at 09:53 +0200, Ard Biesheuvel wrote:
On 2 June 2015 at 08:20, Haojian Zhuang haojian.zhuang@linaro.org wrote:
Hi Fathi,
As we discussed yesterday, you mentioned that both "FDT support" and "Initrd support" should not be included in default boot args.
But the problem is at here. https://github.com/96boards/bugs/issues/40
Fathi & Leif, Since PcdDefaultBootType is set to 0 by default, the kernel image is recognized as an EFI application. So we can't set any FDT path and Initrd path when it creates the default boot entry in UEFI. And we also can't set them even when we create a new boot entry from the boot image. We have to specify them in boot args.
So I want to know what's the expected behavior in UEFI. Do we need to enhance the Bds to find FDT path & Initrd path even the kernel is recognized as an EFI application?
Unfortunately, there is no 'expected behavior' in the UEFI specification when it comes to initrd and FDT images. These are mostly implementation details of the ARM BDS, which itself does not comply with the UEFI spec in features like discovery of boot images on removable media (\EFI\BOOT\BOOTAA64.EFI) and will therefore be deprecated in favor of the Intel BDS at some point.
For the kernel to be able to interoperate with UEFI, PcdDefaultBootType needs to be 0, so it is really a matter of making the other things work in that case.
For the FDT, you can use the recently added support for FDT paths, both embedded and in the file system. Look at FdtPlatformDxe for details, and my recent changes to the ArmVExpress-FVP-AARCH64 target that embeds FDTs into the UEFI image.
I refered to Juno's implementation, and added InstallFdt driver. It'll load Fdt variable to compose Fdt path. Is it same as the FdtPlatformDxe that you're talking about?
Sorry. I missed to copy the link. Here it is. https://github.com/96boards/edk2/blob/hikey/HisiPkg/HiKeyPkg/Drivers/HiKeyDx...
OK, it works around the issue but I think there should be better ways to accomplish that.
Your code registers as a UEFI_DRIVER that checks every gEfiSimpleFileSystemProtocolGuid handle whether it happens to refer to a specific file system you already know should exist, and then proceeds to load a file form it that goes by a fixed name L"hi6220-hikey.dtb"
The FdtPlatformDxe also has its issues and limitations, but it allows for a lot more flexibility: you could embed a default FDT image, and allow the operator to override it in various ways, and load it from any supported file system (it still uses fixed names though)
Thanks. I'll try to move to FdtPlatformDxe driver.
But, in the context of this particular issue, I think it is fine, and it is in fact the initrd= you need to worry about.
OK. I have to append it into the bootargs.
Best Regards Haojian