From owner-freebsd-arch@FreeBSD.ORG Fri May 14 11:21:47 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B58C106566B for ; Fri, 14 May 2010 11:21:47 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 030F48FC19 for ; Fri, 14 May 2010 11:21:46 +0000 (UTC) Received: by fxm17 with SMTP id 17so1501547fxm.13 for ; Fri, 14 May 2010 04:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=YmTmCbcSNLwBHQZjf9i/i9ZUx/nfZupuIjmWOsnAERE=; b=x2zDoht3TYOaRF1NXf4WJxPDijh78jfTGRQCs2obXukwSNdxJO+EeDtIFuCU7mGXTn bEwxaRZ+tncqT/ZLF/PK6H9no98B/MHv3FQwatIH3G+8kRyFyaltVOxGvA/IN6A6gOqS Fn5NzDMA9FOs1OilLBC5u9IH58HQWyYyYGp2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=lvAuph8FYDbaWWzy9es1Qevrd9vrPCGy+TNeFmLeyJTiooWCaQ8yXRf7Yzyd7sZOoD KZZGNz3PSz8FlFZSACD+QAP5ib9dUwa7pBBY57SQ0XrMRpBOJkGVjMCxPk0dMCZ8Vy5p bbMmwtPcAPwLgaGd3G6yj5IdvCjGGJL8YR/x0= Received: by 10.223.99.78 with SMTP id t14mr1419854fan.85.1273836104619; Fri, 14 May 2010 04:21:44 -0700 (PDT) Received: from ernst.jennejohn.org (p57AE4DB2.dip.t-dialin.net [87.174.77.178]) by mx.google.com with ESMTPS id u12sm10495549fah.4.2010.05.14.04.21.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 May 2010 04:21:43 -0700 (PDT) Date: Fri, 14 May 2010 13:21:42 +0200 From: Gary Jennejohn To: Vladimir =?UTF-8?Q?'=CF=86-coder/phcoder'?= Serbinenko 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> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: The development of GRUB 2 , freebsd-arch@freebsd.org Subject: Re: [RFC] Multiboot2 drafting X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 11:21:47 -0000 On Fri, 14 May 2010 08:31:13 +0200 Vladimir '__-coder/phcoder' Serbinenko 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