[PROPOSAL] ARM/FDT: passing multiple binaries to a kernel

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El Wed, 4 Sep 2013 11:41:01 -0500
Rob Herring <robherring2 at gmail.com> escribió:
> Adding Dennis for a distro perspective.
> 
> On Wed, Sep 4, 2013 at 3:44 AM, Ian Campbell
> <Ian.Campbell at 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 at 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

u-boot still has quite a bit of work that needs to be done to make
things standard across the board. I hope we will get there. but it will
require vendors to update their u-boot builds. even for grub to be a
viable option u-boot needs updated.

> 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

I would like to have u-boot support more of syslinux than it does today.

> 
> 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

grub on arm still needs a bit of work. as does u-boot. ultimately
having things look the same between x86 and arm for the user is the
best option. so if u-boot supported syslinux's mboot spec and grub
supported the same syntax in both cases, regardless of if the
implementation varied wildly, the API for lack of a better word should
be consistent.

Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)

iEYEARECAAYFAlIz4NMACgkQkSxm47BaWffX8QCgtSFFHfgHongecz9AESG43RsW
/48An131lBoSmjwcJOlWNkQUxI3LXC5f
=fQqh
-----END PGP SIGNATURE-----