[OpenBIOS] PPC: QEMU breaks static variables in OpenBIOS

[Alexander Graf]

On 02.01.2013, at 22:35, Mark Cave-Ayland wrote:

> On 02/01/13 21:07, Benjamin Herrenschmidt wrote:
> 
>> Just relocate .data, that's trivial.
>> 
>> Use the .lds to specify a different load address from link address, put
>> the link address in memory along with the bss and in your early startup
>> code, copy them from the load address to the link address.
>> 
>> No need to process ELF relocs or anything like that.
>> 
>> I'm sure you can find examples of how to do that all over the place
>> (uboot would be a place to look if you don't know the .lds syntax for
>> this, off the top of my head you look for the AT() directive).
>> 
>> Cheers,
>> Ben.
> 
> Hi Ben,
> 
> Thanks for the response. The existing comments in arch/ppc/qemu/start.S suggest that we have a 1MB space at the top of (physical) RAM which we could use for this:
> 
>        /* Memory map:
>         *
>         * Top +-------------------------+
>         *     |                         |
>         *     | ROM into RAM (1 MB)     |
>         *     |                         |
>         *     +-------------------------+
>         *     |                         |
>         *     | MMU Hash Table (64 kB)  |
>         *     |                         |
>         *     +-------------------------+
>         *     |                         |
>         *     | Exception Stack (32 kB) |
>         *     |                         |
>         *     +-------------------------+
>         *     |                         |
>         *     | Stack (64 kB)           |
>         *     |                         |
>         *     +-------------------------+
>         *     |                         |
>         *     | Client Stack (64 kB)    |
>         *     |                         |
>         *     +-------------------------+
>         *     |                         |
>         *     | Malloc Zone (2 MiB)     |
>         *     |                         |
>         *     +-------------------------+
>         *     :                         :
>         * Bottom
>         */
> 
> The comments in arch/ppc/ofmem.c suggest that virtual memory looks like this:
> 
> /****************************************************************
> * Memory usage (before of_quiesce is called)
> *
> *                      Physical
> *
> *      0x00000000      Exception vectors
> *      0x00004000      Free space
> *      0x01e00000      Open Firmware (us)
> *      0x01f00000      OF allocations
> *      0x01ff0000      PTE Hash
> *      0x02000000-     Free space
> *
> * Allocations grow downwards from 0x01e00000
> *
> ****************************************************************/
> 
> So could we stash .data somewhere beneath the Open Firmware virtual mapping, e.g. at 0x01d00000?
> 
> Ben: is this a suitable location for the data section? AFAICT the Open Firmware load base is set to 0x4000 so we shouldn't in theory clash with any boot loaders/kernels. (Disclaimer: I've mainly worked on the SPARC side of OpenBIOS to date, so a lot of the PPC stuff is new to me)
> 
> Alex/Andreas: is this something that you would be able to help with as PPC maintainers? In particular, I have no way to test PPC64. I could probably make an attempt at something for PPC32, with the minor caveat that I would have to learn PPC assembler first...

Well, .bss is easy as we can just move that down to a r/w memory location. .data is slightly more tricky, as we need to copy data early on. Do we need any global preassigned (.data) variables before we get into C? I highly doubt so :).

Thus, I'd be very inclined to believe that we don't need any asm code at all, making this an all-arch solution.


Alex