SOPine modules stay off at reboot?

[PeterKeuning]

Hi,


I've received my clusterboard with a total of 4 SOPine modules, which all seem to work just fine.
However, on rebooting a module from the Armbian CLI (either by using 'reboot now' or 'telinit 6'), the module power off and just won't turn on again until I either hit the reset button on the board or power down the PSU entirely. They just remain in a powered off state (with the LED next to the USB port very dimly lit).

I'm using the server version of Armbian 5.38 / Ubuntu xential 3.10.107.

What am I missing here? Why aren't the modules powering on?


Peter

[pfeerick]

Same here... I have a serial console attached to slot #0, and see that the kernel messages that it is intending to reboot, but as you say, it just seems to halt. 

I'm running ayufan's sopine build (xenial-minimal-sopine-bspkernel-0.7.19-118.img.xz) and apart from that, and for some odd reason the slot #1 NIC seeming to go to sleep one or two times even though the sopine is still running (as indicated by a heartbeat script regularly blinking the PB7 led). 

Hopefully, xalius or maya will be able to shed some light on this...

[DVS_Dee]

Did anyone ever find a solution to this? I notice the same behaviour when running ARMBIAN 5.35.

[paradise]

Did anyone ever find a solution to this? I notice the same behaviour when running ARMBIAN 5.35.

I also had this problem with Linux but since I'm using FreeBSD on the nodes and fixed the dts rebooting is no problem except if I try it from the kernel debugger..
Personally I really hate Linux because it always does weird things after a while and it's not consistent, every distro is different and stuff breaks all the time (even within minor versions) and the documentation sucks even more. -- I'll just stick to FreeBSD myself! Even if I need to write my own drivers for stuff.
But you could try a few dtb files from different distro's, maybe that will solve the problem.

B.t.w. I think i saw FreeBSD using the WDT to reboot the CPU but not 100% sure about it.

Ps. I'm in the process of building an ILO module with an Arduino so I can manage my clusterboard remotely in case of a panic or something.

[PigLover]

@aww posted a build with the right modifications to avoid the soPine reboot problems on a clusterboard.

See here: https://forum.pine64.org/showthread.php?...4#pid36724

The problem is that this kernel is not in the repos and anytime you do “apt upgrade” to update other things on the devices it gets overwritten and - poof - your back to being broken.

It is possible to hold the update of these certain files but eventually even this breaks down.

We really need a proper build that supports soPine/Clusterboard correctly.  Right now pine64 does not seem very interested development of this product.

For me the whole project associated with Clusterboard is mothballed until this is resolved.  I am not (and don’t really want to become) a kernel developer/packager just to get a small builder project off the ground.

[paradise]

I could give you the FreeBSD patches and you could try that.. it's way faster then any Linux I've tested on the sopine atm and I'm holding back on the frequency. (didn't try above 1.2Ghz yet)

Getting FreeBSD running perfect on the a64 is a challenge.. haha
* Fixed the clocks
* Fixed thermal sensor
* Fixed speedstepping
* Fixed the DMA controller
and the list goes on and on.. haha..

I'm currently building a driver to use the msgbox function in FreeBSD

While at it I have solved the kernel debugger can't reboot issue by changing the dtb psci node!

psci {
compatible = "arm,psci-0.2";
method = "smc";
psci_version = <0x84000000>;
cpu_suspend = <0xc4000001>;
cpu_off = <0x84000002>;
cpu_on = <0xc4000003>;
affinity_info = <0xc4000004>;
migrate = <0xc4000005>;
migrate_info_type = <0x84000006>;
migrate_info_up_cpu = <0xc4000007>;
system_off = <0x84000008>;
system_reset = <0x84000009>;
};



Here is a table of a speed-test I did with calculating PI on a single core/thread for a fixed amount of point.
Compiled the same code on NetBSD, Linux and FreeBSD and cpux is with all my patches. (lower number is better)

7591796 - FreeBSD (i7 3400M)
58593851 - FreeBSD (cpux 1248M)
60941405 - FreeBSD (cpux 1200M)
72580118 - FreeBSD (cpux 1008M)
71281516 - Linux ( 1200M)
84679846 - NetBSD ( 1200M) [doubt clocks]
89687124 - FreeBSD (without patch) [doubt clocks]
89697022 - FreeBSD (cpux 816M)
123330162 - FreeBSD (PI - 1200M+Turbo) [doubt clocks]
124400506 - FreeBSD (PI - 1200M) [doubt clocks]
127154669 - FreeBSD (PI - 600M) [doubt clocks]
138784442 - FreeBSD (cpux 528M)

[nemunaire]

@aww posted a build with the right modifications to avoid the soPine reboot problems on a clusterboard.

See here: https://forum.pine64.org/showthread.php?...4#pid36724

Is the reboot issue solved for you?

I tried a lot of images: the aww's one, the latest (at time of writing) Armbian (both Ubuntu and Debian), with a mainline kernel (4.19 from armbian, and 4.19 I compiled myself) or with a legacy one. I also tried to build my own image, with the most recent AFT and u-boot. But NEVER, the board succeed to perform a reboot: even through reboot, reboot -f, shutdown -r now or via a watchdog timeout (the later is by the way the only way I need). I also tried to alter some dtb settings (like the ones suggested by paradise). I tried with different SD cards, with different soPine, at different position on the clusterboard, ...

In any case, it's end up with:

Code:

# reboot -f
Rebooting.
[  221.132662] reboot: Restarting system

And then nothing. In a previous revision of ATF, I got:

Code:

# reboot -f
Rebooting.
[  221.132662] reboot: Restarting system
INFO:    PSCI Affinity Map:
INFO:      AffInst: Level 0, MPID 0x0, State ON
INFO:      AffInst: Level 0, MPID 0x1, State ON
INFO:      AffInst: Level 0, MPID 0x2, State ON
INFO:      AffInst: Level 0, MPID 0x3, State ON

But no reboot occurs neither.

How does it work for you?
What item can I debug to understand what's going so wrong?

[PigLover]

No, it is not resolved. I mis-posed about aww's build - I was referencing fixing a different issue. I have not been able to achieve a load with reliable reboots - and because of that have pretty much shelved the so-pines and clusterboard.

Sadly, expensive paperweights.

[nemunaire]

I tried to find the cause of this issue.

This is not a kernel problem as: a reset in u-boot doesn't work neither, and both calls from u-boot or linux arrived in the ATF function sunxi_system_reset (I was able to print debug messages in this function).

The things that's quite interesting is that the sunxi_system_reset (https://github.com/ARM-software/arm-trus...i_pm.c#L72) makes use of the watchdog to perform a reboot. As we are unable to use the watchdog with the clusterboard, this is coherent with the reboot issue.

Watchdog's registers are correctly set: values are the good ones, given by the A64 user manual, and the instructions flow is stopped after the requested delay (whether asked by the Linux driver or by ATF). Most probably, something went wrong during the reset, perhaps the boot sequence skip the SD/MMC or select FEL mode?

But, this is the same code that is used for Pine64, SOPine, ...

I'm wondering if this also happen on the SOPine baseboard; it could help to know if there is something weird only on the clusterboard side or if it's on the SOPine module.

[mdmbc]

Reboots fine on the baseboard for me, but not the clusterboard.