On Wed, 2010-09-29 at 14:22 -0500, Scott Wood wrote: > On Wed, 29 Sep 2010 13:44:07 -0500 > Peter Tyser <pty...@xes-inc.com> wrote: > > > From: Aaron Sierra <asie...@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 <asie...@xes-inc.com> > > Signed-off-by: Peter Tyser <pty...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot