[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?
From: |
Steven Noonan |
Subject: |
[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting? |
Date: |
Sun, 19 Apr 2009 15:36:14 -0700 |
On Sun, Apr 19, 2009 at 3:28 PM, Steven Noonan <address@hidden> wrote:
> On Sun, Apr 19, 2009 at 2:32 PM, Steven Noonan <address@hidden> wrote:
>> On Sun, Apr 19, 2009 at 2:02 PM, Steven Noonan <address@hidden> wrote:
>>> On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier <address@hidden> wrote:
>>>> Le dimanche 19 avril 2009 à 13:33 -0700, Steven Noonan a écrit :
>>>>> On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier <address@hidden> 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.
>
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
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
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 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?
>>
>
- [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?, (continued)
- [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?, Blue Swirl, 2009/04/19
- [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?, Steven Noonan, 2009/04/19
- [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?, Laurent Vivier, 2009/04/19
- [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?, Steven Noonan, 2009/04/19
- [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?, Laurent Vivier, 2009/04/19
- [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?, Steven Noonan, 2009/04/19
- [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?, Laurent Vivier, 2009/04/19
- [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?, Steven Noonan, 2009/04/19
- [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?, Steven Noonan, 2009/04/19
- [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?, Steven Noonan, 2009/04/19
- [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?,
Steven Noonan <=
- Re: [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?, malc, 2009/04/19
- [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?, Steven Noonan, 2009/04/19
- [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?, Steven Noonan, 2009/04/19
- [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?, Alexander Graf, 2009/04/26
[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?, Laurent Vivier, 2009/04/19