On 02/01/13 21:58, Alexander Graf wrote:
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.
Okay, I spent some time looking at the PPC MMU code in detail last night and my current thinking is that this might be a QEMU bug.
The initial physical memory map (before MMU is enabled on startup) looks like this:
0x0000000 - 0x8000000 RAM 0xfff00000 - 0xffffffff OpenBIOS image
In setup_mmu(), just before the MMU is enabled, the entire image is memcpy()'d from the OpenBIOS image area to the top area of RAM so we now have this:
0x0000000 - 0x7efffff Free RAM 0x7f00000 - 0x7ffffff OpenBIOS RAM image 0xfff00000 - 0xffffffff OpenBIOS ROM image
Now the reason that OpenBIOS actually executes from RAM is because of this section of code in the MMU fault handler code:
if (ea >= OF_CODE_START && ea <= 0xffffffffUL) { /* ROM into RAM */ ea -= OF_CODE_START; phys = get_rom_base() + ea; *mode = 0x02; return phys; }
Given that OF_CODE_START is 0xfff00000 and get_rom_base() returns 0x7f00000, it's fairly easy to see that accesses to the virtual address range from 0xfff00000 - 0xffffffff are mapped to the OpenBIOS RAM image physical addresses 0x7f00000 - 0x7ffffff. Hence I would expect OpenBIOS to be running from RAM.
I wonder if what is happening is that QEMU is not only marking the *physical* range 0xfff00000 - 0xffffffff as read-only, but also the *virtual* range 0xfff00000 - 0xffffffff when the MMU is enabled? If so, I think this may be a QEMU bug since after these addresses have been remapped into RAM then they should be writeable.
ATB,
Mark.