Date: Fri, 14 May 2010 13:21:42 +0200 From: Gary Jennejohn <gljennjohn@googlemail.com> To: Vladimir =?UTF-8?Q?'=CF=86-coder/phcoder'?= Serbinenko <phcoder@gmail.com> Cc: The development of GRUB 2 <grub-devel@gnu.org>, freebsd-arch@freebsd.org Subject: Re: [RFC] Multiboot2 drafting Message-ID: <20100514132142.252b092d@ernst.jennejohn.org> In-Reply-To: <4BECEE31.3060004@gmail.com> References: <4BE98FB5.3060906@gmail.com> <20100514020055.GB89230@duncan.reilly.home> <4BECEE31.3060004@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 May 2010 08:31:13 +0200 Vladimir '__-coder/phcoder' Serbinenko <phcoder@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100514132142.252b092d>