[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Steven Noonan <steven@uplinklabs.net>]

On Sun, Apr 19, 2009 at 2:32 PM, Steven Noonan <steven@uplinklabs.net> wrote:
> On Sun, Apr 19, 2009 at 2:02 PM, Steven Noonan <steven@uplinklabs.net> wrote:
>> On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier <Laurent@vivier.eu> wrote:
>>> Le dimanche 19 avril 2009 à 13:33 -0700, Steven Noonan a écrit :
>>>> On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier <Laurent@vivier.eu> wrote:
>>>> > Le dimanche 19 avril 2009 à 13:14 -0700, Steven Noonan a écrit :
>>>> > 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   Ending Address    Purpose
>>>> >> 0x00000000    0x00003FFF    Exception vectors.
>>>> >> 0x00004000    0x03FFFFFF    Kernel image, boot structures, and drivers.
>>>> >
>>>> > I put there some memory allocation information.
>>>> >
>>>> >> 0x04000000    0x04FFFFFF    File load area.
>>>> >> 0x05000000    0x053FFFFF    Simple read-time cache for file system
>>>> >> metadata. Cache hits are serviced from memory, whereas cache misses
>>>> >> result in disk access.
>>>> >> 0x05400000    0x055FFFFF    Malloc zone: a simple memory allocator 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:  assumed 96 MB (temporarily bumping to 112 MB for 4359362)
>>
>> Physical Address
>>
>> Open Firmware Version    3x, 4x, ...
>> 00000000 - 00003FFF  :   Exception Vectors
>> 00004000 - 057FFFFF  :   Free Memory
>> // 05800000 - 05FFFFFF  :   OF Image (top 8 MB reserved) [96 MB map]
>> 06800000 - 06FFFFFF  :   OF Image (top 8 MB reserved) [112 MB map]
>>
>>
>> Logical Address
>>
>> // 96 MB map (currently unused - 4363357 tracks re-adoption)
>> 00000000 - 00003FFF  : Exception Vectors
>> 00004000 - 03FFFFFF  : Kernel Image, Boot Struct and Drivers (~64 MB)
>> 04000000 - 04FFFFFF  : File Load Area (16 MB)   [80 MB]
>> 05000000 - 053FFFFF  : FS Cache    (4 MB)       [84 MB]
>> 05400000 - 055FFFFF  : Malloc Zone (2 MB)       [86 MB]
>> 05600000 - 057FFFFF  : BootX Image (2 MB)       [88 MB]
>> 05800000 - 05FFFFFF  : Unused/OF   (8 MB)       [96 MB]
>>
>> // 112 MB map (per 4359362)
>> 00000000 - 00003FFF  : Exception Vectors
>> 00004000 - 03FFFFFF  : Kernel Image, Boot Struct and Drivers (~64 MB)
>> 04000000 - 05FFFFFF  : File Load Area (32 MB)   [96 MB]
>> 06000000 - 063FFFFF  : FS Cache    (4 MB)       [100 MB]
>> 06400000 - 065FFFFF  : Malloc Zone (2 MB)       [102 MB]
>> 06600000 - 067FFFFF  : BootX Image (2 MB)       [104 MB]
>> 06800000 - 06FFFFFF  : Unused/OF   (8 MB)       [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)
>
>         /* Initial load address
>          */
>        -BASE_ADDR = 0xfff00000;
>        +BASE_ADDR = 0x06800000;
>
>        -/* 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 = 0xfff08000;
>        +TEXT_ADDR = 0x06808000;
>
>         /* Hard reset vector address
>          */
>        -HRESET_ADDR = 0xfffffffc;
>        +HRESET_ADDR = 0x06ffffff;
>
>         CSTACK_SIZE = 32768;   /* 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               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?
>