[OpenBIOS] PPC: QEMU breaks static variables in OpenBIOS

[Mark Cave-Ayland]

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.