[U-Boot] [PATCH] 85xx: Add support for not releasing secondary cores via 'mp_holdoff'

[Scott Wood]

On Wed, 29 Sep 2010 14:50:17 -0500
Peter Tyser <ptyser at 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 at xes-inc.com> wrote:
> > 
> > > From: Aaron Sierra <asierra at 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 at xes-inc.com>
> > > Signed-off-by: Peter Tyser <ptyser at 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