From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXlyT-0003Uu-K0 for qemu-devel@nongnu.org; Thu, 12 Feb 2009 19:32:09 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXlyS-0003Ue-3b for qemu-devel@nongnu.org; Thu, 12 Feb 2009 19:32:09 -0500 Received: from [199.232.76.173] (port=38178 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXlyR-0003Ub-UK for qemu-devel@nongnu.org; Thu, 12 Feb 2009 19:32:07 -0500 Received: from mail.gmx.net ([213.165.64.20]:48360) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1LXlyR-0001i7-7j for qemu-devel@nongnu.org; Thu, 12 Feb 2009 19:32:07 -0500 Message-ID: <4994BF93.2070409@gmx.net> Date: Fri, 13 Feb 2009 01:32:19 +0100 From: Carl-Daniel Hailfinger MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] Machine description as data References: <20090212040138.GD31142@yookeroo.seuss> <20090212.094613.514366467.imp@bsdimp.com> <4994B22E.6060608@gmx.net> <200902122358.25864.paul@codesourcery.com> In-Reply-To: <200902122358.25864.paul@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: devicetree-discuss@ozlabs.org, qemu-devel@nongnu.org, hollisb@us.ibm.com 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? > 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? Regards, Carl-Daniel -- http://www.hailfinger.org/