cubietruck: 3.17.x unable to do SMP (CPU1 does not start)

[connaisseur]

Hi!

On kernel 3.17.[23] the SMP seems to be broken. I see messages in dmesg like this:
$this->bbcode_second_pass_code('', '
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] RCU dyntick-idle grace-period acceleration is enabled.
[ 0.004007] CPU: Testing write buffer coherency: ok
[ 0.004056] ftrace: allocating 34787 entries in 103 pages
[ 0.058912] /cpus/cpu@0 missing clock-frequency property
[ 0.058943] /cpus/cpu@1 missing clock-frequency property
[ 0.058958] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.059042] Setting up static identity map for 0x488984d8 - 0x48898570
[ 0.066042] CPU1: failed to boot: -38
[ 0.066091] Brought up 1 CPUs
[ 0.066100] SMP: Total of 1 processors activated.
[ 0.066108] CPU: All CPU(s) started in SVC mode.
')
pacman packages that were used: linux-armv7-* and linux-armv7-headers-*

u-boot version used: U-Boot 2014.04 (Oct 04 2014 - 12:34:11) Arch Linux ARM

Same applies to linux-armv7-3.16.3, which I was able to retrieve over http://armrollback.archassault.org/ .

Going back to the old linux-sun7i-3.4.90-5-armv7h kernel everything's back to normal.

Am I doing something wrong or is something wrong?

CU,
--connaisseur

[pepedog]

I don't know if there is a right dtb, but you altered uboot to pick up that dtb, didn't you?
If you don't kno what I'm talking about, this may not be straight forward.

[connaisseur]

On the dtb-File: I haven't modified /exchanged / tampered with any dtb-stuff.

Everythings is plain straight as from the pacman's xz-archive-file. Even u-boot...

[krabat]

Running linux-armv7 on a Cubietruck myself I can assure you that SMP is supported.

But it takes a U-Boot version supporting Power State Coordination Interface (PSCI). This applies e. g. for the so called sunxi Custodian.

Nevertheless what pepedog said is true in addition - you've got to make sure the DTB gets loaded. Using the said "Custodian" this can be achieved by a boot.cmd / boot.scr like this
$this->bbcode_second_pass_code('', '
env set bootargs console=ttyS0,115200 consoleblank=0 rootwait panic=10 root=/dev/mmcblk0p1 rw init=/usr/lib/systemd/systemd
env set fdt_high 0xffffffff
env set initrd_high 0x70000000
ext4load mmc 0:1 0x46000000 boot/zImage
ext4load mmc 0:1 0x40000000 boot/uInitrd
ext4load mmc 0:1 0x49000000 boot/dtbs/sun7i-a20-cubietruck.dtb
bootz 0x46000000 0x40000000 0x49000000
')This expects / on partition one of an SD card, paths have to be adjusted otherwise. Without an initrd just omit the two corresponding lines and replace '0x40000000' with '-' in bootz line.

[WarheadsSE]

Would this updated u-boot remain fully functional for the other sun7i's?

[krabat]

@WarheadsSE

Recent Git versions of both mainline and Custodian u-boot-sunxi seem to fail booting linux-sunxi kernel as they insist on using a DTB. During the regular boot procedure I got
$this->bbcode_second_pass_code('', '
U-Boot 2015.01-rc1-02154-g4de8eaa-dirty (Nov 22 2014 - 20:31:19) Allwinner Technology
[...]
mmc0 is current device
Scanning mmc 0...
Found U-Boot script /boot.scr
436 bytes read in 126 ms (2.9 KiB/s)
## Executing script at 43100000
3321528 bytes read in 246 ms (12.9 MiB/s)
46240 bytes read in 72 ms (627 KiB/s)
2545986 bytes read in 195 ms (12.5 MiB/s)
## Booting kernel from Legacy Image at 48000000 ...
Image Name: Linux-3.4.90-5-ARCH
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3321464 Bytes = 3.2 MiB
Load Address: 40008000
Entry Point: 40008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 55000000 ...
Image Name: uInitrd
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size: 2545922 Bytes = 2.4 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Could not find a valid device tree
SCRIPT FAILED: continuing...
')Next attempts were made to scan all kinds of storage devices and the network. Similar results when this was done and I tried to start manually from HUSH, omitting the initrd (blank lines inserted here to ease reading)
$this->bbcode_second_pass_code('', '
sun7i# env set bootargs console=ttyS0,115200 consoleblank=0 rootwait panic=10 net.ifnames=0 root=/dev/mmcblk0p3 rw init=/usr/lib/systemd/systemd hdmi.audio=EDID:0 disp.screen0_output_mode=EDID:1920x1080i60

sun7i# ext4load mmc 0:1 0x48000000 uImage
3321528 bytes read in 246 ms (12.9 MiB/s)

sun7i# ext4load mmc 0:1 0x43000000 script.bin
46240 bytes read in 73 ms (618.2 KiB/s)

sun7i# bootm 0x48000000
## Booting kernel from Legacy Image at 48000000 ...
Image Name: Linux-3.4.90-5-ARCH
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3321464 Bytes = 3.2 MiB
Load Address: 40008000
Entry Point: 40008000
Verifying Checksum ... OK
Could not find a valid device tree
sun7i#
')
Kconfig options related to FEX don't seem to exist. What's odd is the fact that Mainline_U-boot on linux-sunxi.org is recommending quite similar proceeding.
Maybe faulty or outdated documentation? Something else I missed?

[WarheadsSE]

Did you base your builds on our configurations and patches?

[krabat]

No, it was some kind of vanilla build using the git repo on denx.de, cross-compiled on an x86_64 Arch box and copied manually.

But your question got me surprised: I thought the Arch Linux ARM U-Boot version for sunxi was based upon the fork from linux-sunxi which supports FEX anyway and not because of additional patches? alarm.patch can't be applied as is to Custodian u-boot-sunxi, btw.