On Fri, 2013-02-01 at 15:31 +0000, Russell King - ARM Linux wrote:

On Fri, Feb 01, 2013 at 07:27:46AM -0800, Dinh Nguyen wrote:

quoted

Hi Olof,
On Fri, 2013-02-01 at 11:46 +0100, ZY - pavel wrote:

quoted

Hi!

quoted

quoted

Because the CPU1 start address is different for socfpga-vt and
socfpga-cyclone5, we add code to use the correct CPU1 start addr.

quoted

quoted

@@ -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).

Point taken...thanks Russell.

Dinh