On Wed, 29 Sep 2010 14:50:17 -0500 Peter Tyser ptyser@xes-inc.com wrote:
On Wed, 2010-09-29 at 14:22 -0500, Scott Wood wrote:
On Wed, 29 Sep 2010 13:44:07 -0500 Peter Tyser ptyser@xes-inc.com wrote:
From: Aaron Sierra asierra@xes-inc.com
Some OSes require that secondary cores not be initialized when they are booted (eg VxWorks). By default when U-Boot is compiled with the CONFIG_MP option all secondary cores are brought out of reset and held in spinloops. Setting the "mp_holdoff" environment variable to a non-null value will cause U-Boot to leave secondary cores in their default state.
Signed-off-by: Aaron Sierra asierra@xes-inc.com Signed-off-by: Peter Tyser ptyser@xes-inc.com
While this may not be relevant to VxWorks, we should update the device tree's enable-method if mp_holdoff is set.
I just looked at the ePAPR spec and it says valid values for enable-method are:
- "spin-table" The CPU is enabled with the spin table method defined in
the ePAPR.
- "[vendor],[method]" An implementation-dependent string
that describes the method by which a CPU is released from a "disabled" state. The required format is: vendor,method,. where vendor is a string describing the name of the manufacturer and method is a string describing the vendor-specific mechanism. Example: "fsl,MPC8572DS"
Note: Other methods may be added to later revisions of the ePAPR specification.
Any preference on what enable-method should be set to? "fsl,holdoff"?
Possibly fsl,eebpcr-holdoff (8572, p1020, etc) or fsl,brr-holdoff (p4080, etc), depending on which register is present.
-Scott