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/HiKeyDxe/InstallFdt.c
> >
>
> 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