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