From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXz5z-0004RA-0T for qemu-devel@nongnu.org; Fri, 13 Feb 2009 09:32:47 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXz5y-0004Qq-4b for qemu-devel@nongnu.org; Fri, 13 Feb 2009 09:32:46 -0500 Received: from [199.232.76.173] (port=52469 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXz5x-0004Qg-Uy for qemu-devel@nongnu.org; Fri, 13 Feb 2009 09:32:46 -0500 Received: from caffeine.csclub.uwaterloo.ca ([129.97.134.17]:35028) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LXz5x-00024I-NE for qemu-devel@nongnu.org; Fri, 13 Feb 2009 09:32:45 -0500 Date: Fri, 13 Feb 2009 09:32:45 -0500 Subject: Re: [Qemu-devel] [RFC] Machine description as data Message-ID: <20090213143244.GL15807@csclub.uwaterloo.ca> 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> From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen) Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: devicetree-discuss@ozlabs.org, Paul Brook , hollisb@us.ibm.com On Fri, Feb 13, 2009 at 01:32:19AM +0100, Carl-Daniel Hailfinger wrote: > Point taken. > > 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? > > Ouch. I always thought turning on all the RAM was either a hardware (old > x86) or firmware (modern x86) task. Certainly a lot of embedded systems, the bootloader is the firmware and is responsible for a lot of hardwre configuration, although often the operating system also does a lot. Most x86 systems configure devices on the PCI bus fairly sensible at power on before the OS starts. On an arm system, the linux kernel has to do all the PCI bus enumeration and configuration since there is generally no PCI handling in the firmware/boot laoder on such a system. Of course embedded x86 systems sometimes also don't do everything you want, in which case fixing it in the boot loader is handy to avoid messing too much with the kernel. > 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? There is the problem of detecting what a given GPIO line does. Use of GPIO lines is very common on embedded systems, and the use is almost always custom to each device. -- Len Sorensen