From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LvfVJ-0003I2-Px for qemu-devel@nongnu.org; Sun, 19 Apr 2009 18:28:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LvfVE-0003HC-58 for qemu-devel@nongnu.org; Sun, 19 Apr 2009 18:28:48 -0400 Received: from [199.232.76.173] (port=35680 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LvfVE-0003H9-1q for qemu-devel@nongnu.org; Sun, 19 Apr 2009 18:28:44 -0400 Received: from mail-gx0-f176.google.com ([209.85.217.176]:43574) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LvfVD-0000cd-Gg for qemu-devel@nongnu.org; Sun, 19 Apr 2009 18:28:43 -0400 Received: by gxk24 with SMTP id 24so3551668gxk.10 for ; Sun, 19 Apr 2009 15:28:42 -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 15:28:42 -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:32 PM, Steven Noonan wrot= e: > On Sun, Apr 19, 2009 at 2:02 PM, Steven Noonan wr= ote: >> On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier wrot= e: >>> Le dimanche 19 avril 2009 =E0 13:33 -0700, Steven Noonan a =E9crit : >>>> On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier wr= ote: >>>> > 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 car= e >>> 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, = and 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 al= locator 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) > > =A0 =A0 =A0 =A0diff --git a/arch/ppc/qemu/ldscript b/arch/ppc/qemu/ldscri= pt > =A0 =A0 =A0 =A0index 66fcbcd..8fdf654 100644 > =A0 =A0 =A0 =A0--- a/arch/ppc/qemu/ldscript > =A0 =A0 =A0 =A0+++ b/arch/ppc/qemu/ldscript > =A0 =A0 =A0 =A0@@ -3,15 +3,15 @@ OUTPUT_ARCH(powerpc) > > =A0 =A0 =A0 =A0 /* Initial load address > =A0 =A0 =A0 =A0 =A0*/ > =A0 =A0 =A0 =A0-BASE_ADDR =3D 0xfff00000; > =A0 =A0 =A0 =A0+BASE_ADDR =3D 0x06800000; > > =A0 =A0 =A0 =A0-/* As NVRAM is at 0xfff04000, the .text needs to be after= that > =A0 =A0 =A0 =A0+/* As NVRAM is at 0x06804000, the .text needs to be after= that > =A0 =A0 =A0 =A0 =A0*/ > =A0 =A0 =A0 =A0-TEXT_ADDR =3D 0xfff08000; > =A0 =A0 =A0 =A0+TEXT_ADDR =3D 0x06808000; > > =A0 =A0 =A0 =A0 /* Hard reset vector address > =A0 =A0 =A0 =A0 =A0*/ > =A0 =A0 =A0 =A0-HRESET_ADDR =3D 0xfffffffc; > =A0 =A0 =A0 =A0+HRESET_ADDR =3D 0x06ffffff; > > =A0 =A0 =A0 =A0 CSTACK_SIZE =3D 32768; =A0 /* client stack size */ With the above numbers, I get linker problems: target/arch/ppc/qemu/start.o: In function `vector__0x300': (.text.vectors+0x384): relocation truncated to fit: R_PPC_ADDR24 against `.text.vectors'+c target/arch/ppc/qemu/start.o: In function `vector__0x400': (.text.vectors+0x484): relocation truncated to fit: R_PPC_ADDR24 against `.text.vectors'+c I don't see why it'd do that. > > The only issue with doing things this way is now to figure out what to > change this to: > > #define FREE_BASE =A0 =A0 =A0 =A0 =A0 =A0 =A0 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? >