Adding Dennis for a distro perspective.
On Wed, Sep 4, 2013 at 3:44 AM, Ian Campbell Ian.Campbell@citrix.com wrote:
On Tue, 2013-09-03 at 17:00 -0500, Rob Herring wrote:
On Tue, Sep 3, 2013 at 10:53 AM, Andre Przywara andre.przywara@linaro.org wrote:
Hi,
a normal Linux kernel currently supports reading the start and end address of a single binary blob via the FDT's /chosen node. This will be interpreted as the location of an initial RAM disk.
The Xen hypervisor itself is a kernel, but needs up to _two_ binaries for proper operation: a Dom0 Linux kernel and it's associated initrd. On x86 this is solved via the multiboot protocol used by the Grub bootloader, which supports to pass an arbitrary number of binary modules to any kernel.
Since in the ARM world we have the versatile device tree, we don't need to implement the mulitboot protocol.
But surely there would be some advantage of reuse by using the multi-boot protocol since Xen, grub, and OS tools already support it for x86.
Multiboot is pretty x86 specific (although MB2 has a MIPS port) and covers more stuff than we strictly require (e.g. on x86 it has requirements around which processor mode you enter in, has paging enabled etc).
So I'd like to propose a new binding which denotes binary modules a kernel can use at it's own discretion. The need is triggered by the Xen hypervisor (which already uses a very similar scheme), but the approach is deliberately chosen to be as generic as possible to allow future uses (like passing firmware blobs for devices or the like). Credits for this go to Ian Campbell, who started something very similar [1] for the Xen hypervisor. The intention of this proposal is to make this generic and publicly documented.
Can you describe how you see the boot flow working starting with OS installer writes kernel, initrd, xen and ??? to disk.
Kernel and initrd are written to /boot in the usual way (probably from kernel.deb or whatever). Xen would also normally come from a distro package (also in /boot).
How does the bootloader know what to load?
It's in the bootloader config, e.g. boot.scr or grub.cfg, which are either hand written or produced by the distros tooling.
grub on ARM could consume the same stanzas as are used by grub on x86 to boot Xen (which are produced by update-grub): echo 'Loading Xen 4.1-amd64 ...' multiboot /xen-4.1-amd64.gz placeholder echo 'Loading Linux 3.10-2-amd64 ...' module /vmlinuz-3.10-2-amd64 placeholder root=/dev/mapper/disks-root ro resume=/dev/mapper/disks-swap quiet echo 'Loading initial ramdisk ...' module /initrd.img-3.10-2-amd64
Since there is no multiboot on ARM (and never will be) this is safe.
If multiboot ever does come to ARM it will necessarily be multiboot2 which uses a different keyword.
Right, this is just a text file with a list of binaries. It is not really the multiboot spec. There is no reason for this part to be different for grub on ARM. There is a big advantage to reusing the distro side tooling. If there isn't really much reuse on the bootloader side, then I'm fine with a different bootloader to Xen interface. I would like to hear that from folks working on grub though.
For u-boot Andre has proposed some syntactic sugar over the "fdt" command to make boot.scr more trivial to use. We would of course need to implement support for using it in the relevant distro tools (but they tend to be very distro/machine specific already, e.g. Debian's flash-kernel)
And being machine specific is a PITA. flash-kernel is certainly not something we want to expand on. There is not much love for boot.scr either. There is work to address what are not really machine differences, but largely vendor u-boot differences:
http://www.mail-archive.com/u-boot@lists.denx.de/msg119025.html
One option for u-boot which already supports syslinux style menu files is to adopt the syslinux multiboot parsing support:
http://www.syslinux.org/wiki/index.php/Doc/mboot
We need to back-up and consider what this looks like in the end for all the pieces and get input from folks on grub, UEFI, and armv8. The UEFI answer may be this is a grub problem. For armv8, this proposal does match up well as the kernel boot interface for v8 is DT. Despite some claims, ACPI will not completely replace DT because of this.
Rob
On Wed, Sep 4, 2013 at 5:41 PM, Rob Herring robherring2@gmail.com wrote:
For u-boot Andre has proposed some syntactic sugar over the "fdt" command to make boot.scr more trivial to use. We would of course need to implement support for using it in the relevant distro tools (but they tend to be very distro/machine specific already, e.g. Debian's flash-kernel)
And being machine specific is a PITA. flash-kernel is certainly not something we want to expand on. There is not much love for boot.scr either. There is work to address what are not really machine differences, but largely vendor u-boot differences:
http://www.mail-archive.com/u-boot@lists.denx.de/msg119025.html
One option for u-boot which already supports syslinux style menu files is to adopt the syslinux multiboot parsing support:
Even building it into U-Boot is problematic because it leaves older machines out in the cold. Leif's port of Grub to U-Boot is far more interesting since the distro can now be in control of the code that loads the images and jumps into the kernel/hypervisor.
We need to back-up and consider what this looks like in the end for all the pieces and get input from folks on grub, UEFI, and armv8. The UEFI answer may be this is a grub problem. For armv8, this proposal does match up well as the kernel boot interface for v8 is DT. Despite some claims, ACPI will not completely replace DT because of this.
Yes, for UEFI it is absolutely an OS loader problem. UEFI provides an API and runtime environment. Grub is in general moving towards a boot menu system and a tool for loading images. Actual booting however should be done by a separate OS loader application. For Linux, this will be an in-kernel UEFI Stub. For Xen I would recommend taking the Linux EFI stub code and doing the same thing. There really isn't a need for a multiboot spec when you can rely on a runtime execution environment for setting things up exactly as you want them.
Multiboot only makes sense to me when you need to rely on firmware or something else out of your control to load the images in a particular way.
g.
On Fri, Sep 13, 2013 at 5:13 AM, Grant Likely grant.likely@secretlab.ca wrote:
On Wed, Sep 4, 2013 at 5:41 PM, Rob Herring robherring2@gmail.com wrote:
For u-boot Andre has proposed some syntactic sugar over the "fdt" command to make boot.scr more trivial to use. We would of course need to implement support for using it in the relevant distro tools (but they tend to be very distro/machine specific already, e.g. Debian's flash-kernel)
And being machine specific is a PITA. flash-kernel is certainly not something we want to expand on. There is not much love for boot.scr either. There is work to address what are not really machine differences, but largely vendor u-boot differences:
http://www.mail-archive.com/u-boot@lists.denx.de/msg119025.html
One option for u-boot which already supports syslinux style menu files is to adopt the syslinux multiboot parsing support:
Even building it into U-Boot is problematic because it leaves older machines out in the cold. Leif's port of Grub to U-Boot is far more interesting since the distro can now be in control of the code that loads the images and jumps into the kernel/hypervisor.
Considering there is no distro support for grub on ARM yet, it may be more interesting in the long run, but it is not for the short term. So there needs to be something that is supportable on both u-boot and grub (or any other bootloader).
We need to back-up and consider what this looks like in the end for all the pieces and get input from folks on grub, UEFI, and armv8. The UEFI answer may be this is a grub problem. For armv8, this proposal does match up well as the kernel boot interface for v8 is DT. Despite some claims, ACPI will not completely replace DT because of this.
Yes, for UEFI it is absolutely an OS loader problem. UEFI provides an API and runtime environment. Grub is in general moving towards a boot menu system and a tool for loading images. Actual booting however should be done by a separate OS loader application. For Linux, this will be an in-kernel UEFI Stub. For Xen I would recommend taking the Linux EFI stub code and doing the same thing. There really isn't a need for a multiboot spec when you can rely on a runtime execution environment for setting things up exactly as you want them.
You've lost me as well. How do you see the flow working with UEFI for a user running bare metal OS, installing Xen, and rebooting running Xen.
Rob
On Fri, 13 Sep 2013 20:40:54 -0500, Rob Herring robherring2@gmail.com wrote:
On Fri, Sep 13, 2013 at 5:13 AM, Grant Likely grant.likely@secretlab.ca wrote:
On Wed, Sep 4, 2013 at 5:41 PM, Rob Herring robherring2@gmail.com wrote:
For u-boot Andre has proposed some syntactic sugar over the "fdt" command to make boot.scr more trivial to use. We would of course need to implement support for using it in the relevant distro tools (but they tend to be very distro/machine specific already, e.g. Debian's flash-kernel)
And being machine specific is a PITA. flash-kernel is certainly not something we want to expand on. There is not much love for boot.scr either. There is work to address what are not really machine differences, but largely vendor u-boot differences:
http://www.mail-archive.com/u-boot@lists.denx.de/msg119025.html
One option for u-boot which already supports syslinux style menu files is to adopt the syslinux multiboot parsing support:
Even building it into U-Boot is problematic because it leaves older machines out in the cold. Leif's port of Grub to U-Boot is far more interesting since the distro can now be in control of the code that loads the images and jumps into the kernel/hypervisor.
Considering there is no distro support for grub on ARM yet, it may be more interesting in the long run, but it is not for the short term. So there needs to be something that is supportable on both u-boot and grub (or any other bootloader)
True.
We need to back-up and consider what this looks like in the end for all the pieces and get input from folks on grub, UEFI, and armv8. The UEFI answer may be this is a grub problem. For armv8, this proposal does match up well as the kernel boot interface for v8 is DT. Despite some claims, ACPI will not completely replace DT because of this.
Yes, for UEFI it is absolutely an OS loader problem. UEFI provides an API and runtime environment. Grub is in general moving towards a boot menu system and a tool for loading images. Actual booting however should be done by a separate OS loader application. For Linux, this will be an in-kernel UEFI Stub. For Xen I would recommend taking the Linux EFI stub code and doing the same thing. There really isn't a need for a multiboot spec when you can rely on a runtime execution environment for setting things up exactly as you want them.
You've lost me as well. How do you see the flow working with UEFI for a user running bare metal OS, installing Xen, and rebooting running Xen.
I see I've caused confusion. I wasn't disputing the proposed binding, but rather stating that none of the Xen or Linux specific boot code should be built directly into UEFI. It should be contained in a separate UEFI OS Loader applications (GRUB + stub).
As for the question above, I see the Xen installer adding stanzas to the Grub configuration to boo the xen kernel instead of the Linux kernel. Here there are two options (the Xen folks can decide which is best) a) The Xen kernel has an EFI stub which uses a "linux=" argument to specify the Linux kernel image to load. b) GRUB is Xen-aware and adds the extra images to the dtb.
In either case, the Xen loader is completely separate from UEFI and therefore under our own control.
g.
boot-architecture@lists.linaro.org
-
Grant Likely -
Rob Herring