On Wed, 29 Sep 2010 14:50:17 -0500 Peter Tyser <pty...@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 <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"? Possibly fsl,eebpcr-holdoff (8572, p1020, etc) or fsl,brr-holdoff (p4080, etc), depending on which register is present. -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot