grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Multiboot2 drafting


From: Gary Jennejohn
Subject: Re: [RFC] Multiboot2 drafting
Date: Fri, 14 May 2010 13:21:42 +0200

On Fri, 14 May 2010 08:31:13 +0200
Vladimir '__-coder/phcoder' Serbinenko <address@hidden> wrote:

> > Hi there,
> >
> > I know next to nothing about GRUB, and have not yet read the
> > multiboot spec, but I wonder if you could comment on how or
> > whether this is related to either the Open Firmware Device Tree
> > or the Flattened Device Tree used in various embedded OS ports.
> > It would be cool if there were some convergence going on...
> >
> >
> Yes and No. multiboot2 describes some aspects of the host system
> hardware but I've never heard of device trees outside of IEEE1275 or
> xnu, where it's probably a historical leftover. If this specification is
> clear and share some of our goals we can think of collaboration. Our
> goals in this direction:
> 1) Allow the same kernel load on all machines implementing the same ISA.
> This will require supplying info about machine.
> 2) Keep the things as advanced as they need to but not more advanced.
> E.g. when you supply an info about serial port you tell: it's at I/O
> port N rather than: it's in PCI bar X of device Y offset F. Since if OS
> doesn't support PCI this info is useless and if it does it will find out
> that this address is actually a part of PCI bar. This can be discussed
> though.
> 3) Firmware independency. Ideally OS shouldn't care at all which
> firmware it's running on. In some cases we may add pointers to firmware
> interfaces if there are good reasons for it but it's not the goal
>
> So if it's something clean and nice we should try integrating it. If
> it's however yet another firmware-dependant overkill interface it should
> be avoided.
>

As an example of what I think Andrew was addressing, U-Boot can pass a
Flattened Device Tree to the Linux kernel.  This basically allows a
Linux kernel to handle variants of a board without having to custom
compile Linux for each board.  At the moment I think only powerpc-based
boards can be handled in this way.

--
Gary Jennejohn



reply via email to

[Prev in Thread] Current Thread [Next in Thread]