解决relocation truncated to fit: R_PPC_ADDR24 的问题

Mon Apr 20 00:36:14 CEST 2009 · relocation

On Sun, Apr 19, 2009 at 3:28 PM, Steven Noonan <steven at uplinklabs.net> wrote:
> On Sun, Apr 19, 2009 at 2:32 PM, Steven Noonan <steven at uplinklabs.net> wrote:
>> On Sun, Apr 19, 2009 at 2:02 PM, Steven Noonan <steven at uplinklabs.net> wrote:
>>> On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier <Laurent at 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 at 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.
>

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?
>>
>

解决relocation truncated to fit: R_PPC_ADDR24 的问题

[OpenBIOS] QEMU OpenBIOS booting?