2nd processor not coming up

I’ve been following the basic instructions found at

seems to function fine
& I have gone farther / tried different kernels (some newer some older )
I have added the cpu start address in the DTS file,
I have complied SMP into the kernel,
I have tried this on De0-nano-soc & De1-soc

but only CPU0 is ever brought up …
what else can i look for ?

I ran into a similar issue. I needed to add “enable-method = “altr,socfpga-smp”;” into the CPUs node in the device tree.


1 Like

exactly the issue … thankyou

If I add this line into the soc_system.dts file in the cpu section CPU1 couldn’t be started.

Thats the output of my DE0-Nano:
[ 0.091881] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.092131] Setting up static identity map for 0x8280 - 0x82d8
[ 1.090248] CPU1: failed to come online
[ 1.090287] Brought up 1 CPUs
[ 1.090295] SMP: Total of 1 processors activated (1836.64 BogoMIPS).
[ 1.090302] CPU: All CPU(s) started in SVC mode.

I’m using the 15.1 version of Quartus in a Debian 8 environment and DS-5.

The only Kernel running the NIC in my opinion is the 4.4.0
I’ve tried also different versions but the only time I’ve seen CPU1 running was with the installed Atlas-Image.

Can somebody point me to the right direction?

I added it in this section:

cpus {
         #address-cells = <1>;
         #size-cells = <0>;
**enable-method = "altr,socfpga-smp";**
                hps_0_arm_a9_0: cpu@0x0 {
                        device_type = "cpu";
                        compatible = "arm,cortex-a9-15.1", "arm,cortex-a9";
                        reg = <0x00000000>;
                        next-level-cache = <&hps_0_L2>; /* appended from boardinfo */
                }; //end cpu@0x0 (hps_0_arm_a9_0)
                hps_0_arm_a9_1: cpu@0x1 {
                        device_type = "cpu";
                        compatible = "arm,cortex-a9-15.1", "arm,cortex-a9";
                        reg = <0x00000001>;
                        next-level-cache = <&hps_0_L2>; /* appended from boardinfo */
                }; //end cpu@0x1 (hps_0_arm_a9_1)
        }; //end cpus

I’ve tried it, but same result.

Can you tell me witch git versions you are using? Maybe I’m using a faulty one.

nothing to do with git / have compiles across multiple platforms at this point
is curious though my
BogoMIPS is always == 200.0 even with 2 processors …

SMP: Total of 1 processors activated (200.0 BogoMIPS).

I’ve figured out, some older kernel-versions don’t work with my device-tree-files, so the NIC wasn’t running.

The value of BogoMIPS is the same amount as in the pre installed image.



I am seeing the same thing the op saw running a 4.7 Linux kernel. I have been over and over the kernel config without success. I am running on the Cyclone5 DK with pcie reference design. I am just changing the Linux kernel from a 3.10 version to the 4.7 version. I have tried the device tree change mentioned above. As shown, I only see one cpu and is only getting 200 BogoMIPS?? Any suggestions welcomed?

cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 0 (v7l)
BogoMIPS : 200.00
Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc09
CPU revision : 0

Hardware : Altera SOCFPGA
Revision : 0000
Serial : 0000000000000000


I’ve rebuild the kernel according to the beginners tutorial, I’m using the rel_socfpga-4.1-ltsi_16.04.01_pr git branch. As compiler version I’ve used the same as in the tutorial. Now the additional parameter in the dts-File has done the trick.

1 Like

I found that in kernel 4.11 (and early) has CONFIG_ARCH_CLOCKSOURCE_DATA=y definition. In arch/arm/Kconfig file.
This leads to wrong? calculation of the BogoMIPS.
In cosole you can see “Switching to timer-based delay loop, resolution 10ns”

Can this lead to wrong delay()?

I’m wondering if the missing BogoMIPS is about missing a timer config. In recent kernels (tested on 4.12 and 4.11), I get

[    0.000006] sched_clock: 32 bits at 100MHz, resolution 10ns, wraps every 21474836475ns
[    0.000017] Switching to timer-based delay loop, resolution 10ns
[    0.000223] GIC: PPI13 is secure or misconfigured
[    0.000256] GIC: PPI13 is secure or misconfigured
[    0.000445] Calibrating delay loop (skipped), value calculated using timer frequency.. 200.00 BogoMIPS (lpj=1000000)

In 4.1.33 ltsi the BogoMIPS calculation is working and I don’t get any complaints about PPI13

[    0.000006] sched_clock: 32 bits at 100MHz, resolution 10ns, wraps every 21474836475ns
[    0.000399] Calibrating delay loop... 1836.64 BogoMIPS (lpj=9183232)

If I check the DT, I find that PPI13 is interrupt 13 which happens to be hps_0_timer. I am starting to suspect that there is a missing DTAppend statement here. Anyone can sched a light on this?