[Qemu-devel] PowerPC reset vector?

[Qemu-devel] PowerPC reset vector?

[Blue Swirl]

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?

OHW seems to depend on this extra vector, so if we change it, there
may need to be some kind of compatibility hacks to let it work.

Background: Laurent Vivier and I are trying to get OpenBIOS to work on PPC.

Re: [Qemu-devel] PowerPC reset vector?

[Aurelien Jarno]

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.

> OHW seems to depend on this extra vector, so if we change it, there
> may need to be some kind of compatibility hacks to let it work.

OHW seems to follow exactly what is mapped in a real processor. OTOH, as
qemu and the firmware are coupled, we can probably decide that the
processor starts at the reset exception vector.

> Background: Laurent Vivier and I are trying to get OpenBIOS to work on PPC.

Nice work. I am following the progress on openbios-devel. How close are
you to have a basic version working?

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] PowerPC reset vector?

[Blue Swirl]

On 12/7/08, Aurelien Jarno <aurelien@aurel32.net> 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.

OK, I missed that part (Book III E, chapter 6.3 in PowerISA 2.05).

>  > OHW seems to depend on this extra vector, so if we change it, there
>  > may need to be some kind of compatibility hacks to let it work.
>
>
> OHW seems to follow exactly what is mapped in a real processor. OTOH, as
>  qemu and the firmware are coupled, we can probably decide that the
>  processor starts at the reset exception vector.
>
>
>  > Background: Laurent Vivier and I are trying to get OpenBIOS to work on PPC.
>
>
> Nice work. I am following the progress on openbios-devel. How close are
>  you to have a basic version working?

I get some output in the console in some cases ;-), Laurent has better versions.

Re: [Qemu-devel] PowerPC reset vector?

[Laurent Vivier]

Le 7 déc. 08 à 15:39, Blue Swirl a écrit :

> On 12/7/08, Aurelien Jarno <aurelien@aurel32.net> wrote:
>> On Sun, Dec 07, 2008 at 02:58:40PM +0200, Blue Swirl wrote:
>>>
>>> Background: Laurent Vivier and I are trying to get OpenBIOS to  
>>> work on PPC.
>>
>>
>> Nice work. I am following the progress on openbios-devel. How close  
>> are
>> you to have a basic version working?
>
> I get some output in the console in some cases ;-), Laurent has  
> better versions.


I 've a very messy patch that allows me to load yaboot and then to  
load and start a linux kernel.
But kernel hangs immediately when it tries to create the flattened  
device tree (OF memory management is broken with qemu)

Laurent
----------------------- Laurent Vivier ----------------------
"The best way to predict the future is to invent it."
- Alan Kay

Re: [Qemu-devel] PowerPC reset vector?

[Hollis Blanchard]

On Sun, Dec 7, 2008 at 8:02 AM, Aurelien Jarno <aurelien@aurel32.net> 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.)

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

-Hollis

Re: [Qemu-devel] PowerPC reset vector?

[Blue Swirl]

On 12/7/08, Hollis Blanchard <hollis@penguinppc.org> wrote:
> On Sun, Dec 7, 2008 at 8:02 AM, Aurelien Jarno <aurelien@aurel32.net> 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.