I think the best way is to define Shell.efi as the default boot entry and then to provide startup.nsh on a boot device.
startup.nsh then contains a command to boot the kernel, eg:
Image dtb=file.dtb initrd=ramdisk.img <kernel commandline>
But if you want a default BDS option to boot the kernel directly, you can also do this with type 0 device, set PcdDefaultBootDevicePath to be the path to your kernel image, then set PcdDefaultBootArgument to something like:
dtb=file.dtb initrd=ramdisk.img <kernel commandline>
i.e the same as before, only leave out the filename of the Image file.
I wouldn't use all that other stuff.
On 2 June 2015 at 09:21, Haojian Zhuang haojian.zhuang@linaro.org wrote:
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
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi