qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] PowerPC reset vector?


From: Blue Swirl
Subject: Re: [Qemu-devel] PowerPC reset vector?
Date: Sun, 7 Dec 2008 18:02:56 +0200

On 12/7/08, Hollis Blanchard <address@hidden> wrote:
> On Sun, Dec 7, 2008 at 8:02 AM, Aurelien Jarno <address@hidden> wrote:
>  > On Sun, Dec 07, 2008 at 02:58:40PM +0200, Blue Swirl wrote:
>  >> Hi,
>  > Hi!
>  >
>  >> Currently PPC hard reset vector is 0xfffffffc for most cases. I can't
>  >> find this vector in the few PPC docs I have. Instead all docs point to
>  >> 0x00100 + base, where base can be 0xfff00000 or zero. Is the vector
>  >> correct?
>  >
>  > According to the PowerISA manual, the reset exception vector is the one
>  > you define. However on power-up, the CPU does not jump to the reset
>  > exception vector but instead:
>  > - initialize msr
>  > - empty all TLB
>  > - create a boot TLB that maps the last 4kB page in the implemented
>  >  effective storage address space that maps to the last 4kB page of the
>  >  physical address space
>  > - start execution of instruction at the last word address of the page
>  >  mapped by the boot TLB entry.
>
>
> Hang on, that's not the whole story.
>
>  There are a number of supervisor-level difference between server (now
>  called "Book III-S") and embedded ("Book III-E") PowerPC, and this is
>  one of them. The behavior you describe is true for Book E, and also
>  happens to be true for 405 (which predates Book E and is not similar
>  in other respects).
>
>  However, it is *not* true for "classic" or "server" PowerPC, such as
>  604 or 970. Those processors reset as Blue described, with the NIP at
>  0xfff00100. (Actually, I think some may do even different things, like
>  start at 0xfff00000, but I'm not sure.)

PowerISA actually only mentions zero-based reset vector. This is also
possible (Sparc32 boots at address 0 with only boot ROM visible), but
then there should be a way to switch to RAM early (like before PCI
probe).

>  Since qemu emulates both types of PowerPC, the reset vector must not
>  be hardcoded.

It should be possible to handle all three cases (0xfff00100,
0xfffffffc, 0x00000100) with one ROM image.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]