[U-Boot-Users] [RFC/PATCH] 85xx: Initial multicore boot support

[Andy Fleming]

On Jan 22, 2008 3:31 AM, Kumar Gala <galak at kernel.crashing.org> wrote:
>
> On Jan 22, 2008, at 2:59 AM, Wolfgang Denk wrote:
>
> > In message <Pine.LNX.
> > 4.64.0801220214120.31981 at blarg.am.freescale.net> you wrote:
> >> I was hoping to get some feed back on this patch that will add
> >> support for
> >> booting the multiprocessor 85xx chips.  The boot mechanism is based
> >> on the
> >> forth coming ePAPR spec (based on how device tree, linux
> >> booting-without-of spec).
> >>
> >> The biggest feedback I'm hoping for is related to the command set
> >> and its
> >> name:
> >>
> >> "cpu     - CPU boot table manipulation and release\n",
> >>    "<num> reset          - Reset cpu <num>\n"
> >> "cpu <num> status         - Status of cpu <num>\n"
> >> "cpu <num> release <addr> - Release cpu <num> and start at <addr>\n"
> >

> I should have explained further how this works on 85xx/ppc.  We end up
> having a table.  Each processor has an entry in the table with the
> following fields:
> * boot addr
> * pir (processor id)
> * r3
> * r4
> * r7
>
> when a value other than '1' is written to the 'boot addr' field that
> processor will come out of spin and load up r3, r4, r5, r6, r7 based
> on the ePAPR calling convention (which pretty much says r3, r4, r7 are
> passed in via FW, r5 is 0, and r6 is a magic #)

What are r3,r4,r5,r6,and r7?  Rather than calling them out by
register, is there some more generic way we could set up the
arguments?

cpu <num> release [addr] [args]

Then, for PPC, you would just say:

cpu <num> release <addr> <pir> <r3> <r4> <r7>

The generic code could invoke an arch-defined handler which can parse
the "args" part, and take the appropriate action.

Andy