> >> + cpus { > >> + #address-cells = <1>; > >> + #size-cells = <0>; > >> + > >> + CPU0: cpu@0 { > >> + device_type = "cpu"; > >> + compatible = "arm,cortex-a53", "arm,armv8"; > >> + reg = <0x0>; > >> + }; > >> + > >> + CPU1: cpu@1 { > >> + device_type = "cpu"; > >> + compatible = "arm,cortex-a53", "arm,armv8"; > >> + reg = <0x1>; > >> + }; > >> + > >> + CPU2: cpu@2 { > >> + device_type = "cpu"; > >> + compatible = "arm,cortex-a53", "arm,armv8"; > >> + reg = <0x2>; > >> + }; > >> + > >> + CPU3: cpu@3 { > >> + device_type = "cpu"; > >> + compatible = "arm,cortex-a53", "arm,armv8"; > >> + reg = <0x3>; > >> + }; > >> + }; > > > > The secondary CPUs need an enable-method. Are you using PSCI or > > spin-table? > > This is on purpose. We aren’t using either PSCI or spin-table. Right > now the dts is for booting on a single core. I can drop CPU1..CPU3 if > that helps. We won't poke the CPUs without an enable-method, so personally I'm not too worried either way about having the CPUs listed. Which of spin-table/psci are you planning on using for SMP support, and when would that be likely to appear? Which exception level do CPUs enter the kernel? Even without a virt-capable GIC booting at EL2 is less work for the FW and gives the kernel a better chance of fixing things up (e.g. CNTVOFF). Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html