[PATCHv2 for soc 4/4] arm: socfpga: Add SMP support for actual socfpga harware

Russell King - ARM Linux linux at arm.linux.org.uk
Fri Feb 1 10:31:52 EST 2013


On Fri, Feb 01, 2013 at 07:27:46AM -0800, Dinh Nguyen wrote:
> Hi Olof,
> On Fri, 2013-02-01 at 11:46 +0100, ZY - pavel wrote:
> > Hi!
> >
> > > > Because the CPU1 start address is different for socfpga-vt and
> > > > socfpga-cyclone5, we add code to use the correct CPU1 start addr.
> >
> > > > @@ -72,6 +73,13 @@ void __init socfpga_sysmgr_init(void)
> > > >   struct device_node *np;
> > > >
> > > >   np = of_find_compatible_node(NULL, NULL, "altr,sys-mgr");
> > > > +
> > > > + if (of_property_read_u32(np, "cpu1-start-addr",
> > > > +                 (u32 *) &cpu1start_addr)) {
> > > > +         early_printk("Need cpu1-start-addr in device tree.\n");
> > > > +         panic("Need cpu1-start-addr in device tree.\n");
> > > > + }
> > > > +
> > > >   sys_manager_base_addr = of_iomap(np, 0);
> > >
> > > Wouldn't it be easier to diagnose this failure if you just printed the error
> > > and continued booting without the second CPU? An early panic is usually really
> > > hard to debug since you might not get early console without extra work.
> >
> > I actually thought about that... but could not think of non-ugly way
> > of doing that. I hope dts will normally be "right" for any production
> > system...
> 
> I think a panic is better just for the reason that if someone is
> expecting SMP, but missed the warning message, and later finds out that
> the secondary core never came up, it would save some debugging time.
> 
> Since I have to send out a v3 from the 1st patch anyways, let me verify
> that I can get the early warning.

The choice is between a panic() at a point where the only way to find
out is to throw in printascii() or a working printk, and ending up with
an unbootable kernel, vs continuing the boot and having an almost
working system which can be logged into and the messages viewed.

If you have an application which relies on the second CPU coming up,
why not have it verify that the second CPU came up (it's quite easy
to do - there's POSIX standard libc calls to get the number of online
CPUs).



More information about the linux-arm-kernel mailing list