From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXnfX-0001VX-8I for qemu-devel@nongnu.org; Thu, 12 Feb 2009 21:20:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXnfU-0001V5-3H for qemu-devel@nongnu.org; Thu, 12 Feb 2009 21:20:41 -0500 Received: from [199.232.76.173] (port=36191 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXnfT-0001Uv-Fx for qemu-devel@nongnu.org; Thu, 12 Feb 2009 21:20:39 -0500 Received: from [202.81.31.146] (port=46046 helo=e23smtp04.au.ibm.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LXnfS-00044e-PY for qemu-devel@nongnu.org; Thu, 12 Feb 2009 21:20:39 -0500 Received: from d23relay01.au.ibm.com (d23relay01.au.ibm.com [202.81.31.243]) by e23smtp04.au.ibm.com (8.13.1/8.13.1) with ESMTP id n1D1k65a028544 for ; Fri, 13 Feb 2009 12:46:06 +1100 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay01.au.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n1D1lrN7368960 for ; Fri, 13 Feb 2009 12:47:53 +1100 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n1D1lqhF016234 for ; Fri, 13 Feb 2009 12:47:53 +1100 Date: Fri, 13 Feb 2009 12:46:32 +1100 From: David Gibson Subject: Re: [Qemu-devel] [RFC] Machine description as data Message-ID: <20090213014632.GF8104@yookeroo.seuss> References: <20090212040138.GD31142@yookeroo.seuss> <20090212.094613.514366467.imp@bsdimp.com> <4994B22E.6060608@gmx.net> <200902122358.25864.paul@codesourcery.com> <4994BF93.2070409@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4994BF93.2070409@gmx.net> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Carl-Daniel Hailfinger Cc: devicetree-discuss@ozlabs.org, Paul Brook , hollisb@us.ibm.com, qemu-devel@nongnu.org On Fri, Feb 13, 2009 at 01:32:19AM +0100, Carl-Daniel Hailfinger wrote: > On 13.02.2009 00:58, Paul Brook wrote: > >> Unless I'm mistaken, Linux is able to probe most hardware properties. > > > > You are badly mistaken. > > Point taken. > > > > On x86 workstation/server class hardware you might get away with it because > > everything interesting is either standard legacy ports or PCI, and your > > firmware/bios already took care of the really hairy bits. > > If the firmware doesn't set up the things which can't be probed, can it > even be called firmware or is it more like a glorified bootloader? A bootloader, not even much glorified, is often all there is on embedded systems. > > On embedded systems there's often very little that can be automatically > > detected, much less functionality provided by the firmware (You're lucky if > > all your RAM is even turned on!) and you just have to know where stuff is. > > Ouch. I always thought turning on all the RAM was either a hardware (old > x86) or firmware (modern x86) task. > > I'm a bit surprised by the lack of automatically detectable features in > embedded systems. Wouldn't automatic detection allow reusing whole OS > images on slighly different systems and thus lower development cost? Automatic detection requires protocols between hardware, firmware and OS to implement it. The ones that exist for full systems are too heavyweight for embedded systems, or assume things about the hardware setup that don't suit what embedded systems want to include. Typically it's just been easier for embedded vendors to hack their kernels to know the hardware directly. The tradeoffs we've made for use of flattened device trees represent an effort to achieve lower development cost precisely as you describe here. Inherently probably hardware (e.g. PCI, USB) is mostly omitted from the tree, leaving a minimal blob of almost static information which the firmware/bootloader can include to tell the OS about the hardware setup while still having almost no "moving parts". The kernel can still neatly support systems which don't provide a flattened tree by being built with a wrapper. The wrapper, which is specific to a particular hardware/firmware combination contains a flattened tree, plus some code to tweak it with what little information the embedded firmware / hardware does provide (ram size and flash size are common examples). This way we have a kernel which can run unmodified on many systems which do provide a flattened tree, and we're no worse off for systems which don't (a hardware specific kernel is replaced by a hardware specific kernel+wrapper combination). -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson