Issues with first start, what do the different LED states mean?

[Botagar]

Hi all!

I partook in the baseboard + 1 free SOPine offer a few months back but only just got around to having a play around with it.
I've attempted to get the module up and running with the xenial-minimal-sopine-bspkernel-0.7.19-118.img.xz image found here (https://github.com/ayufan-pine64/linux-build/releases). I loaded it up on a 64GB SD card through Etcher, but nothing gets registered on the network. I tried enabling emcc_compat=on after a fresh etch.

Basically debugging is rather hard because there is very little information about the default behavior of the baseboard. I've linked a gif of what the board is doing. The (power?) LED's just blink in near enough unison and the orange LEDS (Net Activity?) blink together semi frequently. Nothing lights up on the SOPine board itself.

I'm powering the system up through the barrel jack connector with the PSU sold on the official site. I've confirmed with a voltmeter that the voltage levels are correct.


https://imgur.com/UdidCZU

Can anyone point out what might be happening? And what steps I could take to further debug what might be going on?

Cheers~!

[aww]

Folks have been having a ton of issues using Clusterboard when it comes to networking, could you try one of the armbian builds that are linked in this subforum?

[pfeerick]

Basically debugging is rather hard because there is very little information about the default behavior of the baseboard. I've linked a gif of what the board is doing. The (power?) LED's just blink in near enough unison and the orange LEDS (Net Activity?) blink together semi frequently. Nothing lights up on the SOPine board itself.

The green and orange leds are the two indicators from the ethernet chips, as they are dedicated chips so continue to do *something* even with no sopine connected to them.

The power leds are on the sopine modules themselves. There is also a user controllable LED on the clusterboard for the sopine module near the USB sockets of each module.

As aww said, try the Armbian images if you haven't already and let us know how you go with them. To work with the clusterboard (or indeed most ARM SBC boards), you'll also want some way to access the serial console - some sort of 3.3v USB to serial adapter or serial console cable would be the easiest way to do it, and they're cheap!.

[Botagar]

Thanks for the replies. I was hoping that ssh would be pre-enabled so I could scan down the device on the network and ssh into it. I loaded up Armbian but if I need to initially access the SOPine over serial, I'm going to have to wait quite a few weeks. I'm unfortunately travelling a bit at the moment due to work so taking deliveries is impossible

Cheers~!

[paradise]

Thanks for the replies. I was hoping that ssh would be pre-enabled so I could scan down the device on the network and ssh into it. I loaded up Armbian but if I need to initially access the SOPine over serial, I'm going to have to wait quite a few weeks. I'm unfortunately travelling a bit at the moment due to work so taking deliveries is impossible

Cheers~!

NetBSD boots with SSH enabled, you could at least try that.

ps. Checking your DHCP server log is faster then scanning your subnet (depending on the tool you use).. 

---

Folks have been having a ton of issues using Clusterboard when it comes to networking, could you try one of the armbian builds that are linked in this subforum?

Most issues are resolved with a few commands in the bootloader (you can automate that).
I flashed the SPI with my own u-boot version that has patches for some stuff and fixes the ethernet issue. (configures the rx-timer)


short version of the patch code u-boot: mi w 1c30000 1f 7; mi w 1c30000 1e a4 ; mi w 1c30000 1c b573 ; mi w 1c30000 1f 0

mii write 0x1c30000 0x1f 0x7            // select reg-page
mii write 0x1c30000 0x1e 0xa4         // ext-reg (rx)
mii write 0x1c30000 0x1c 0xb573     // disable RX delay via undocumented magic numbers :-(
mii write 0x1c30000 1f 0                   // Restore the page