david at gibson.dropbear.id.au
Fri Jan 10 11:42:43 EST 2003
On Thu, Jan 09, 2003 at 09:55:40AM -0600, Hollis Blanchard wrote:
> On Wed, 2003-01-08 at 20:33, David Gibson wrote:
> > Hmm... what's the reason that wakeup_info needs to be reserved in
> > head_4xx.S, rather than just being a normal variable in the data area
> > (which should be writable anyway)? Its not obvious to me from the
> > patch.
> Sorry, I was hoping the Documentation file explained it well enough. On
> wake the firmware needs to transfer control back to Linux, so the
> firmware needs to know where to jump to. The only way I could think of
> communicating that information was with a fixed memory location known to
> both the firmware and to Linux. In future processors there will be a
> scratch register (whose contents are saved during sleep) to solve this
Ah, ok - I only skimmed the patch I'm afraid, so I didn't notice that.
> > Actually, skimming through the patch I noticed a minor nit: you only
> > have one .long in head_4xx.S reserving space for the wakeup_info
> > struct which is 3 words long. In practice the . = in the exception
> > handlers will give you plenty of space, but I think it would be good
> > form to explicitly reserve the right amount of space.
> It's just a (physical) pointer to the structure which is elsewhere in
> memory (actually on the stack).
Hmm... in that case, why does the pointer need to be updated at
runtime: could you just statically allocate the real structure (in the
data segment), and have the value at 0xc00000fc filled in constant at
David Gibson | For every complex problem there is a
david at gibson.dropbear.id.au | solution which is simple, neat and
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-dev