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?
Best Regards Haojian
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.
For the initrd, you could either add the initrd= command line option, or boot via GRUB. Making changes to the ARM BDS to accommodate this is not recommended since it is going away anyway.
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?
For the initrd, you could either add the initrd= command line option, or boot via GRUB. Making changes to the ARM BDS to accommodate this is not recommended since it is going away anyway.
We don't have GRUB on hikey yet.
Fathi, Is it necessary to use GRUB on hikey?
Best Regards Haojian
On 2 June 2015 at 10:00, Haojian Zhuang haojian.zhuang@linaro.org 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?
For the initrd, you could either add the initrd= command line option, or boot via GRUB. Making changes to the ARM BDS to accommodate this is not recommended since it is going away anyway.
We don't have GRUB on hikey yet.
Fathi, Is it necessary to use GRUB on hikey?
No, it is not necessary, since you can also pass initrd= I just offered it as an alternative.
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...
For the initrd, you could either add the initrd= command line option, or boot via GRUB. Making changes to the ARM BDS to accommodate this is not recommended since it is going away anyway.
We don't have GRUB on hikey yet.
Fathi, Is it necessary to use GRUB on hikey?
Best Regards Haojian
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)
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.
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
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
On Tue, 2015-06-02 at 11:59 +0100, Ryan Harkin wrote:
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>
The only one issue is that there's no UART0 console on product HiKey board. So user has no chance to input anything.
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.
Could I create some boot entries by BootOptionCreate() in platform driver? (https://github.com/96boards/edk2/blob/hikey/HisiPkg/HiKeyPkg/Drivers/HiKeyDx...)
On Tue, 2015-06-02 at 20:03 +0800, Haojian Zhuang wrote:
On Tue, 2015-06-02 at 11:59 +0100, Ryan Harkin wrote:
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>The only one issue is that there's no UART0 console on product HiKey board. So user has no chance to input anything.
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.
Could I create some boot entries by BootOptionCreate() in platform driver? (https://github.com/96boards/edk2/blob/hikey/HisiPkg/HiKeyPkg/Drivers/HiKeyDx...)
Hi all,
I implemented the multiple boot entries in this driver. https://github.com/hzhuang1/edk2/blob/bootentry/HisiPkg/HiKeyPkg/Drivers/HiK...
This driver create multiple boot entries successfully. At here, you'll get the "fastboot" and "debian on emmc" entries. It's based on whether "BootNext" is created. If "BootNext" variable is created by the driver, BDS won't create default boot entry by PCD values.
At last, the whole scenarios are in below. 1. After flushing the initial images in factory. System would try to load debian from eMMC directly if pin 5-6 isn't connected in J15 on HiKey board. Or system would try to run fastboot directly if pin 5-6 is connected in J15.
2. User select whether boot debian or android. Or boot from emmc or sd. (Use additional oem command in fastboot protocol.) $fastboot oem bootorder {index number} 0 -- fastboot 1 -- debian on emmc 2 -- debian on sd 3 -- android on emmc 4 -- android on sd 5 -- openembed on emmc 6 -- openembed on sd
When the boot order is specified, UEFI will always try the selected boot order.
3. User select whether uart0 or uart2 is the serial console. $fastboot oem serialconsole {console string} console string could be either "uart0" or "uart2". It'll only change the serial console of linux kernel. And it won't change the serial console in ATF or UEFI. By default, uart0 is the default serial console of linux kernel.
Do you have any opinion on these scenarios? If not, I'll continue on enabling these scenarios. Since we don't have serial port on hikey board, we have to create these scenarios to make it work.
By the way, do you support two different GPIO controllers in UEFI? PL061 gpio driver is only initialized with PCD value. It means that I can only enable 8 GPIO pins on hikey. It's the very strong limitation in design.
Best Regards Haojian
On 15 June 2015 at 15:52, Haojian Zhuang haojian.zhuang@linaro.org wrote: [...]
Hi all,
I implemented the multiple boot entries in this driver. https://github.com/hzhuang1/edk2/blob/bootentry/HisiPkg/HiKeyPkg/Drivers/HiK...
This driver create multiple boot entries successfully. At here, you'll get the "fastboot" and "debian on emmc" entries. It's based on whether "BootNext" is created. If "BootNext" variable is created by the driver, BDS won't create default boot entry by PCD values.
At last, the whole scenarios are in below.
- After flushing the initial images in factory. System would try to
load debian from eMMC directly if pin 5-6 isn't connected in J15 on HiKey board. Or system would try to run fastboot directly if pin 5-6 is connected in J15.
- User select whether boot debian or android. Or boot from emmc or sd.
(Use additional oem command in fastboot protocol.) $fastboot oem bootorder {index number} 0 -- fastboot 1 -- debian on emmc 2 -- debian on sd 3 -- android on emmc 4 -- android on sd 5 -- openembed on emmc 6 -- openembed on sd
When the boot order is specified, UEFI will always try the selected boot order.
- User select whether uart0 or uart2 is the serial console.
$fastboot oem serialconsole {console string} console string could be either "uart0" or "uart2". It'll only change the serial console of linux kernel. And it won't change the serial console in ATF or UEFI. By default, uart0 is the default serial console of linux kernel.
Do you have any opinion on these scenarios? If not, I'll continue on enabling these scenarios. Since we don't have serial port on hikey board, we have to create these scenarios to make it work.
Hello Haojian,
I am a bit lost here: how do these changes have anything to do with the original problem that started this thread? You were asking about how to load the FDT and initrd when booting in true UEFI mode (PcdDefaultBootType == 0) How did you address that issue?
On Tue, 2015-06-16 at 15:56 +0200, Ard Biesheuvel wrote:
On 15 June 2015 at 15:52, Haojian Zhuang haojian.zhuang@linaro.org wrote: [...]
Hi all,
I implemented the multiple boot entries in this driver. https://github.com/hzhuang1/edk2/blob/bootentry/HisiPkg/HiKeyPkg/Drivers/HiK...
This driver create multiple boot entries successfully. At here, you'll get the "fastboot" and "debian on emmc" entries. It's based on whether "BootNext" is created. If "BootNext" variable is created by the driver, BDS won't create default boot entry by PCD values.
At last, the whole scenarios are in below.
- After flushing the initial images in factory. System would try to
load debian from eMMC directly if pin 5-6 isn't connected in J15 on HiKey board. Or system would try to run fastboot directly if pin 5-6 is connected in J15.
- User select whether boot debian or android. Or boot from emmc or sd.
(Use additional oem command in fastboot protocol.) $fastboot oem bootorder {index number} 0 -- fastboot 1 -- debian on emmc 2 -- debian on sd 3 -- android on emmc 4 -- android on sd 5 -- openembed on emmc 6 -- openembed on sd
When the boot order is specified, UEFI will always try the selected boot order.
- User select whether uart0 or uart2 is the serial console.
$fastboot oem serialconsole {console string} console string could be either "uart0" or "uart2". It'll only change the serial console of linux kernel. And it won't change the serial console in ATF or UEFI. By default, uart0 is the default serial console of linux kernel.
Do you have any opinion on these scenarios? If not, I'll continue on enabling these scenarios. Since we don't have serial port on hikey board, we have to create these scenarios to make it work.
Hello Haojian,
I am a bit lost here: how do these changes have anything to do with the original problem that started this thread? You were asking about how to load the FDT and initrd when booting in true UEFI mode (PcdDefaultBootType == 0) How did you address that issue?
Hi Ard,
Since we could get FDT path from "FDT" variable. The only problem is how to load initrd.
According to Ryan & Leif's comments. It's better to load initrd from the commandline. Now I add a driver to create multiple boot entries automatically. Different initrd setting are embedded in different boot entries. User just need to select the boot entry. Then we could avoid the issue on missing initrd when PcdDefaultBootType is 0.
Best Regards Haojian
On Tue, Jun 02, 2015 at 11:59:09AM +0100, Ryan Harkin wrote:
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.
I would very strongly advise against this.
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>
Specifying dtb= on the command line is not supported when enabling Secure Boot. Which may not be a problem now, but will be in the future if we build our infrastructure around this.
i.e the same as before, only leave out the filename of the Image file.
I wouldn't use all that other stuff.
"That other stuff" is also known as the UEFI boot mechanism. If we are not using it, we should not be calling it UEFI.
/ Leif
On 2 June 2015 at 13:20, Leif Lindholm leif.lindholm@linaro.org wrote:
On Tue, Jun 02, 2015 at 11:59:09AM +0100, Ryan Harkin wrote:
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.
I would very strongly advise against this.
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>Specifying dtb= on the command line is not supported when enabling Secure Boot. Which may not be a problem now, but will be in the future if we build our infrastructure around this.
i.e the same as before, only leave out the filename of the Image file.
I wouldn't use all that other stuff.
"That other stuff" is also known as the UEFI boot mechanism.
And it's not suitable for use, so we should not be using it ;-)
If we are not using it, we should not be calling it UEFI.
/ Leif
-
Ard Biesheuvel -
Haojian Zhuang -
Leif Lindholm -
Ryan Harkin