From: "Blue Swirl" <blauwirbel@gmail.com>
To: Hollis Blanchard <hollis@penguinppc.org>
Cc: Laurent Vivier <laurent@lvivier.info>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] PowerPC reset vector?
Date: Sun, 7 Dec 2008 18:02:56 +0200 [thread overview]
Message-ID: <f43fc5580812070802hc6d7d58ibd8dff06da6952b6@mail.gmail.com> (raw)
In-Reply-To: <fb412d760812070743o2707c3ddle4f66858309e66d2@mail.gmail.com>
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.
prev parent reply other threads:[~2008-12-07 16:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-07 12:58 [Qemu-devel] PowerPC reset vector? Blue Swirl
2008-12-07 14:02 ` Aurelien Jarno
2008-12-07 14:39 ` Blue Swirl
2008-12-07 15:02 ` Laurent Vivier
2008-12-07 15:43 ` Hollis Blanchard
2008-12-07 16:02 ` Blue Swirl [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f43fc5580812070802hc6d7d58ibd8dff06da6952b6@mail.gmail.com \
--to=blauwirbel@gmail.com \
--cc=hollis@penguinppc.org \
--cc=laurent@lvivier.info \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).