I've been working on booting FreeBSD on the SOPINE on a Clusterboard. One issue I've run into is using the micro-usb port. I have a USB OTG cable, however FreeBSD is unable to detect when I plug a device in through it. On closer inspection of the schematic it appears the D+ and D- pins are backwards. I've modified a cable to swap these and found FreeBSD can now detect there is a device, although it is unable to talk to it, most likely due to the quality of my soldering.

Am I correct in thinking these pins are backwards on the Clusterboard?

There was new Raspberry model presented.
https://www.raspberrypi.org/products/ras...el-b-plus/

Not going into details but there is 4 core 1.4ghz CPU, WI-Fi 5ghz supported and 1gb LAN.
...BUUUUUUUUUT LAN is still throttled by USB 2.0 so peed is up to 300mb/s and I assume only IF you won't connect anything else (like HDD).
Throttled LAN and lack of USB 3.0 was main reason I first bought Delock 1gb LAN USB 3.0 adapter and eventually switched to Rock64. It looks then don't learn on their mistakes. 

Rock64 is still way beefier than RPI
5ghz Wi-FI can always be connected via USB.

I have bought Rock64 mainly as media server but I couldn't stream 4K content to my Xbox that is my main media client especially now when there is VLC and Kodi available in M$ Store.


Microsoft recently fixed 4K playback @ Xbox One S/X.
Until now, console crashed when the same 4K movie was loaded via any player.
Yesterday, I was able to run 2160p x265 movie streamed form my Rock64.
I don't own 4K TV so it was purely for testing purposes and console has to do even more heavy lifting to run UHD image and downscale it to FHD  
...but for 4K TV owners this is good news!

My Setup:
4GB RAM ROck64
64GB eMMC
stretch-openmediavault-rock64-0.6.25-193-armhf
1gb LAN

VLC + SMB  = works OK 
Kodi + NFS = still unwatchable (not sure if it's due to codecs or transfer as NFS works way slower than SMB for Windows shares).
Will test other resources and codecs soon.

Guys,

I have combined 2 tutorials and managed to run hotspot that connects me via OpenVPN.

Pro Tips 
- verify Wi-Fi interface name as ROCK64 USB WIFI 802.11B/G/N (RTL8188EU) instead of default wlan0 gets wlx0013ef801932 so any references have to be changed.
- make sure your IP address pool do not collide with your regular DHCP - you don't want to get IP addresses collision. 

Sometimes I have to run my Xbox via VPN. I prefer to use Rock64 instead of Windows laptop. 
I don't take any credit for the tutorials content. I just confirm it works like a charm 

How to create Wi-Fi HotSpot:
https://forum.pine64.org/showthread.php?tid=4383

OpenVPN (profiles for VyprVPN I use) + IP tables config:
https://thepi.io/how-to-use-your-raspber...pn-router/

I have a SOPINE module on a Baseboard Model A Rev. B that I am trying to get working with a LCD display.  All components have been purchased from PINE64's store, including power supply.

Using Android 5.1.1 I am able to flash an image to a SD card and run it with HDMI output.  The LCD stays blank.  The backlight doesn't even come on.

Using Android 6.0.1, which states that it supports dual display, I am able to run the board just fine with HDMI output.  However, as soon as I plug in the LCD the system won't boot.  The power light comes on for a couple of seconds and then it goes off.  This can be repeated by asserting the power button.  After asserting the power button, the power light comes on for a couple seconds and then shuts off.  It would seem to me that something is forcing the SOPINE to power down when it tries to power the LCD and I'm not convinced that it is hardware related.

My initial thought would be that the LCD is bad.  This theory seems to be disproved when Android 7.1 is loaded on the SD card.

Using the Android 7.1 image for A64-LTS/SOPINE everything, again, works just fine with the HDMI output.  The LCD screen, however, has its backlight turned on during initial bootup and there are a couple of flickers of the screen, but as soon as Android starts the LCD screen is turned off.  I have tried manipulating the uEnv.txt file, but to no avail.

Does anyone else here have experience with a similar setup that you were able to get working?  If so, what image did you use?

I'm not yet convinced that there is something wrong with the LCD, but I am open to the possibility that there is.  The issue that baffles me the most is why it just shuts off when using Android 6.0.1.

If anyone has any insights into why it is behaving in any of the ways listed above I would greatly appreciate hearing them.  Thanks.

Ivon

Hi

I am trying to install Andorid on my Rock64 but no matter what image i pick, i get the same error. I have downloaded the installer and created my SD Card using that.
This is the error i am getting when i turn on the Rock64. It shows the boot logo and then i get this
https://imgur.com/UStltls

Anyone know what i am doing wrong?

I had a number of unsuccessful attempts to load Android onto the eMMC card. 

When I boot into Debian, the card shows up as two drives as "system" and "Volumn" 

What my intention is to use the card to store media for KODI use on either Debian or Android.

Any ideas on how to format it in place running Debian? I'd rather not get an adapter.

Many thanks in advance

I couldn't find one anywhere else on this forum; maybe it's a good idea to have a feature request topic since I believe it is a prototype and thus still in development?

Things I'd love to see changed:

- A second ethernet switch, to serve as an ethernet backbone between the SOPine modules, for inter-module traffic (cluster/config sync/HA traffic, front/backend separation, etc).
- A physical connection to that backbone switch so you could connect multiple clusterboards and have modules from different boards directly interact without using up bandwidth on the main switch
- A different placement of the pin headers for the modules, these aren't accessible when a heatsink is applied.
- A step-up converter to 12V and Pin header for a cooling fan (so you can simply use one powersupply and don't need a seperate one for the fan).
- Some form of individual remote control; remote power/reset functions, serial over ethernet type functionality


If this kind of feedback is unwanted, go ahead and close the topic

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

Can anybody recently bought Rock64 share the hardware revision that is printed on the board ?

I bought one on Taobao (cannot order in China), and the PCB is printed with the following info:
ROCK64_V2.0
2017-0713

I guess it probably is not the latest build.
Also, anyone knows the hardware revision change history, or where I could find that information ?