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

Peter Tyser ptyser at xes-inc.com
Wed Sep 29 21:50:17 CEST 2010


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"?
I'll also delete the "cpu-release-addr" node when mp_holdoff is set.

Regards,
Peter



More information about the U-Boot mailing list