From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LvedA-0004Tp-QS for qemu-devel@nongnu.org; Sun, 19 Apr 2009 17:32:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lved5-0004TJ-7Q for qemu-devel@nongnu.org; Sun, 19 Apr 2009 17:32:51 -0400 Received: from [199.232.76.173] (port=40864 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lved5-0004TG-1m for qemu-devel@nongnu.org; Sun, 19 Apr 2009 17:32:47 -0400 Received: from mail-gx0-f176.google.com ([209.85.217.176]:46998) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lved4-0000PC-LA for qemu-devel@nongnu.org; Sun, 19 Apr 2009 17:32:46 -0400 Received: by gxk24 with SMTP id 24so3522416gxk.10 for ; Sun, 19 Apr 2009 14:32:45 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1240171720.5659.11.camel@Quad> <1240172642.5659.25.camel@Quad> <1240174112.5659.40.camel@Quad> Date: Sun, 19 Apr 2009 14:32:45 -0700 Message-ID: From: Steven Noonan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting? Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: The OpenBIOS Mailinglist , Laurent Vivier Cc: Alexander Graf , qemu-devel@nongnu.org On Sun, Apr 19, 2009 at 2:02 PM, Steven Noonan wrot= e: > On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier wrote= : >> Le dimanche 19 avril 2009 =E0 13:33 -0700, Steven Noonan a =E9crit : >>> On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier wro= te: >>> > Le dimanche 19 avril 2009 =E0 13:14 -0700, Steven Noonan a =E9crit : >>> > The problem is in OpenBios: I put some structures in memory without >>> > knowing this... but this is not part of openfirmware specification. >>> >>> Agreed, this seems to be an undocumented Apple-ism. But since OSes >>> other than Mac OS X run on PowerPC macs (i.e. BSD, Linux), I must >> >> AIX is also using OpenFirmware / PPC / CHRP, and I think they don't care >> of Apple-ism. >> >>> assume that they are aware of these quirks and don't hammer those >>> memory locations. Since that's the case, it may be wise to conform to >>> what Apple's Open Firmware does, even if it _is_ undocumented. >> >> 'Yes, we can' (R). >> >>> How easy would it be to get OpenBIOS to load to the position Mac OS X >>> and BootX expect it to be? Based on what the book says, there are 8MB >>> of memory available to the Open Firmware, would that be enough for the >>> OpenBIOS executable image and any allocations it would need to >>> perform? >>> >>> > >>> >> the wrong location. From the book "Mac OS X Internals: A Systems >>> >> Approach": >>> >> >>> >> Table 45. BootX Logical Memory Map >>> >> >>> >> Starting Address =A0 Ending Address =A0 =A0Purpose >>> >> 0x00000000 =A0 =A00x00003FFF =A0 =A0Exception vectors. >>> >> 0x00004000 =A0 =A00x03FFFFFF =A0 =A0Kernel image, boot structures, a= nd drivers. >>> > >>> > I put there some memory allocation information. >>> > >>> >> 0x04000000 =A0 =A00x04FFFFFF =A0 =A0File load area. >>> >> 0x05000000 =A0 =A00x053FFFFF =A0 =A0Simple read-time cache for file = system >>> >> metadata. Cache hits are serviced from memory, whereas cache misses >>> >> result in disk access. >>> >> 0x05400000 =A0 =A00x055FFFFF =A0 =A0Malloc zone: a simple memory all= ocator is >>> >> implemented in BootX's libclite subproject. The starting and ending >>> >> addresses of this range define the block of memory used by the >>> >> allocator. >>> > >>> > BootX should use openBIOS functions to allocate memory (as Yaboot >>> > does...) >>> >>> Apparently BootX is tricky that way. I don't have the BootX source >>> code, so I can't verify the author's statement, but I would guess he >>> knows what he's talking about. >> >> Look here: >> >> http://www.opensource.apple.com/darwinsource/tarballs/apsl/BootX-81.tar.= gz >> >> (You need an Apple Developer ID) >> > > Aha. From sl.h: > > /* > > Memory Map: =A0assumed 96 MB (temporarily bumping to 112 MB for 4359362) > > Physical Address > > Open Firmware Version =A0 =A03x, 4x, ... > 00000000 - 00003FFF =A0: =A0 Exception Vectors > 00004000 - 057FFFFF =A0: =A0 Free Memory > // 05800000 - 05FFFFFF =A0: =A0 OF Image (top 8 MB reserved) [96 MB map] > 06800000 - 06FFFFFF =A0: =A0 OF Image (top 8 MB reserved) [112 MB map] > > > Logical Address > > // 96 MB map (currently unused - 4363357 tracks re-adoption) > 00000000 - 00003FFF =A0: Exception Vectors > 00004000 - 03FFFFFF =A0: Kernel Image, Boot Struct and Drivers (~64 MB) > 04000000 - 04FFFFFF =A0: File Load Area (16 MB) =A0 [80 MB] > 05000000 - 053FFFFF =A0: FS Cache =A0 =A0(4 MB) =A0 =A0 =A0 [84 MB] > 05400000 - 055FFFFF =A0: Malloc Zone (2 MB) =A0 =A0 =A0 [86 MB] > 05600000 - 057FFFFF =A0: BootX Image (2 MB) =A0 =A0 =A0 [88 MB] > 05800000 - 05FFFFFF =A0: Unused/OF =A0 (8 MB) =A0 =A0 =A0 [96 MB] > > // 112 MB map (per 4359362) > 00000000 - 00003FFF =A0: Exception Vectors > 00004000 - 03FFFFFF =A0: Kernel Image, Boot Struct and Drivers (~64 MB) > 04000000 - 05FFFFFF =A0: File Load Area (32 MB) =A0 [96 MB] > 06000000 - 063FFFFF =A0: FS Cache =A0 =A0(4 MB) =A0 =A0 =A0 [100 MB] > 06400000 - 065FFFFF =A0: Malloc Zone (2 MB) =A0 =A0 =A0 [102 MB] > 06600000 - 067FFFFF =A0: BootX Image (2 MB) =A0 =A0 =A0 [104 MB] > 06800000 - 06FFFFFF =A0: Unused/OF =A0 (8 MB) =A0 =A0 =A0 [112 MB] > */ > > > The 96MB map looks like what we're trying to conform to. I wonder what > this "4359362" they refer to is? An internal bug number or document > number? > OK, so I guess we should use the 112MB map, since the other one says "currently unused", which reads to me as "deprecated". So I'm looking into changing it to load to the position Apple's Open Firmware would. Do these values seem right to you? (it's intentionally space-smashed to prevent someone applying this to mainline) diff --git a/arch/ppc/qemu/ldscript b/arch/ppc/qemu/ldscript index 66fcbcd..8fdf654 100644 --- a/arch/ppc/qemu/ldscript +++ b/arch/ppc/qemu/ldscript @@ -3,15 +3,15 @@ OUTPUT_ARCH(powerpc) =09 /* Initial load address */ -BASE_ADDR =3D 0xfff00000; +BASE_ADDR =3D 0x06800000; =09 -/* As NVRAM is at 0xfff04000, the .text needs to be after that +/* As NVRAM is at 0x06804000, the .text needs to be after that */ -TEXT_ADDR =3D 0xfff08000; +TEXT_ADDR =3D 0x06808000; =09 /* Hard reset vector address */ -HRESET_ADDR =3D 0xfffffffc; +HRESET_ADDR =3D 0x06ffffff; =09 CSTACK_SIZE =3D 32768; /* client stack size */ The only issue with doing things this way is now to figure out what to change this to: #define FREE_BASE 0x00004000 My first thought was to utilize all 8MB of the space that Apple says we can have, and use any space after the OpenBIOS image. My second thought was: how do we know where the OpenBIOS executable image ends? Any ideas?