On Jan 22, 2008, at 2:47 PM, Andy Fleming wrote:
On Jan 22, 2008 3:31 AM, Kumar Gala galak@kernel.crashing.org wrote:
On Jan 22, 2008, at 2:59 AM, Wolfgang Denk wrote:
In message <Pine.LNX. 4.64.0801220214120.31981@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.
That's an idea. I'd remove <pir> from the list and probably still have it explicitly set since not all PPCs might want to do that (right now its more of a FSL thing). Or do something like:
cpu <num> release <addr> <pir or '-'> <r3> <r4> <r7>
- k
- k