-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El Wed, 4 Sep 2013 11:41:01 -0500 Rob Herring <robherring2@xxxxxxxxx> escribió: > Adding Dennis for a distro perspective. > > On Wed, Sep 4, 2013 at 3:44 AM, Ian Campbell > <Ian.Campbell@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxx/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----- ÿôèº{.nÇ+?·?®??+%?Ëÿ±éݶ¥?wÿº{.nÇ+?·?zø?zÚÞ{ø§¶?¡Ü¨}©?²Æ zÚ&j:+v?¨þø ¯ù ®w¥þ?à2?Þ?¨èÚ&¢)ß¡«a¶Úÿÿûàz¿äz¹Þ?ú+?ù???Ý¢jÿ?wèþf
