Re: [0/16] Preliminary Ebony (440GP) support for arch/powerpc

[Josh Boyer <jwboyer@linux.vnet.ibm.com>]

On Fri, Feb 16, 2007 at 01:53:02PM +1100, David Gibson wrote:
> On Thu, Feb 15, 2007 at 08:19:56PM -0600, Josh Boyer wrote:
> > On Thu, Feb 15, 2007 at 10:12:04AM +1100, David Gibson wrote:
> > > > I still have this issue, just haven't had a chance to figure out why
> > > > yet.  Likely because the openbios code is leaving garbage somewhere.
> > > 
> > > More likely simply because openbios just puts different things in the
> > > registers on entry, and we're assuming it uses the same method OF
> > > does.  Need to fix the entry path, and get rid of the hardcoded a1 and
> > > a2 junk.
> > 
> > I looked a the openbios code this morning.  For all intents and purposes
> > the values it pases in r3 and r4 to the zImage wrapper really are
> > garbage.  However, you're right in that we need to fix the boot wrapper
> > to not assume all firmwares will follow similar conventions for the entry
> > path.
> 
> Yes.
> 
> > Is there a compat property or something similar that could be defined in
> > the DTS that the wrapper could look at to determine what to expect?
> 
> I think that's getting way too keen on generality.  I'm almost ready
> to send out a patch which alters the entry path to the zImage code to
> let the platform code handle the entry parameters.  Then we can just
> make the Ebony platform_init() ignore the r3 and r4 values.

Oh good.  I thought about that first, but was afraid of the bootwrapper
generality police ;)

> Err... except, are they really both junk?  I thought at least one gave
> an address for the openbios callback to grab the board info structure.

Not from what I can see.  r3 is used to ensure the data cache is flushed
before jumping to the application, and r4 is used to determine if the
openbios debugger flag is set.  If that flag is set, then control returns
to openbios.  If not, then nothing else is loaded there and it just puts
the entry address of the application in srr0 along with the msr into srr1
and does an rfi.  Neither register is set to something other than that
prior to doing the rfi.

There's also this comment at the top:

"Note that (in the first case) the application is getting
 control for the first time since being loaded, so no
 GPR/SPR values need to be restored (though we do enable
 machine check exceptions in the MSR before returning from
 the interrupt)."

I can look again more closely tomorrow though.  Right now I need to sleep
:)

josh