From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lvfcb-0004Ol-LH for qemu-devel@nongnu.org; Sun, 19 Apr 2009 18:36:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LvfcX-0004OG-3m for qemu-devel@nongnu.org; Sun, 19 Apr 2009 18:36:21 -0400 Received: from [199.232.76.173] (port=52382 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LvfcW-0004OA-VD for qemu-devel@nongnu.org; Sun, 19 Apr 2009 18:36:16 -0400 Received: from mail-gx0-f176.google.com ([209.85.217.176]:64720) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LvfcW-0001vT-IX for qemu-devel@nongnu.org; Sun, 19 Apr 2009 18:36:16 -0400 Received: by gxk24 with SMTP id 24so3555605gxk.10 for ; Sun, 19 Apr 2009 15:36:15 -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:36:14 -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 3:28 PM, Steven Noonan wrot= e: > On Sun, Apr 19, 2009 at 2:32 PM, Steven Noonan wr= ote: >> On Sun, Apr 19, 2009 at 2:02 PM, Steven Noonan w= rote: >>> On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier wro= te: >>>> Le dimanche 19 avril 2009 =E0 13:33 -0700, Steven Noonan a =E9crit : >>>>> On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier w= rote: >>>>> > 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 ca= re >>>> 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 th= e >>>>> 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 fil= e system >>>>> >> metadata. Cache hits are serviced from memory, whereas cache misse= s >>>>> >> result in disk access. >>>>> >> 0x05400000 =A0 =A00x055FFFFF =A0 =A0Malloc zone: a simple memory a= llocator is >>>>> >> implemented in BootX's libclite subproject. The starting and endin= g >>>>> >> 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.ta= r.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/ldscr= ipt >> =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 afte= r that >> =A0 =A0 =A0 =A0+/* As NVRAM is at 0x06804000, the .text needs to be afte= r 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. > What the hell? Why would this change resolve it? diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S index 66df9a2..108fd9b 100644 --- a/arch/ppc/qemu/start.S +++ b/arch/ppc/qemu/start.S @@ -206,7 +206,7 @@ VECTOR( 0x300, "DSI" ): addi r3,r3,LO(dsi_exception) mtctr r3 bctrl - ba exception_return + b exception_return =09 VECTOR( 0x400, "ISI" ): EXCEPTION_PREAMBLE @@ -214,7 +214,7 @@ VECTOR( 0x400, "ISI" ): addi r3,r3,LO(isi_exception) mtctr r3 bctrl - ba exception_return + b exception_return =09 ILLEGAL_VECTOR( 0x500 ) ILLEGAL_VECTOR( 0x600 ) >> >> 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? >> >