What my Rock64 4G is doing (w/ setup guide).

[rmbusy]

I purchased the Rock64 4G for a single purpose: To monitor cheap IP based network cameras bought off eBay, running a program called Motion 4.0.1.

I attached a external self powered USB 3.0 8TB hard drive, and currently monitor 5 cameras via the GB Ethernet interface.  The camera configurations are 3x 1080P 2MP cameras, and 2x 720P 1MP cameras. 

For the 1080P cams, a JPEG picture is downloaded 5 times per second.  The 720P cams are streaming 640x360 video at 30 frames per second.  This setup is dictated by the FW presently on the cameras, which I hope to change soon.  All pictures, videos, and log files are written to the HD, to reduce wear on the SD card.

I previously had this setup running on a Raspberry Pi 2B, and found the CPU was always running around 98%.  I also had continuous frame corruption recordings from the 720P cameras.  Once I moved to the Rock64, I see CPU usage varying from 70% to occasionally near 200%.  Average is typically between 70% and 90%.  Also, I have seen no frame corruption since moving to the Rock64.

I found some valuable info on this forum, that helped get everything set up.  However, what I don't ever see, is a complete list of instructions on how to go from a blank SD card, to a running system.  I thought I would post that here, in case the various bits of information might help someone get their project up and running sooner.

Much of the procedure below is carried forward from the RPi, but some steps have been picked or deduced from info found on this forum.  This is what I did.  I know there are different ways to do things, but this worked for me.  I did everything using a Linux laptop (w/ built in SD card reader), running Ubuntu 12.04.  The image I started with was jessie-minimal-rock64-0.5.7-101-arm64.img.

*******************************************************
Copy image to SD Card :
> dd if=<image name> of=/dev/mmcblk0 bs=30M

Make following edits before putting card in Rock64 (mount locally, paths need mount point pre-pended) :

Allow root login over SSH (personal preference) :
Change 'PermitRootLogin' to 'yes' in /etc/ssh/sshd_config

Update NTP to use my local network NPT server (skip if you don't have one) :
Edit /etc/ntp.conf, and add (change x.y to your NTP server) :
> server 192.168.x.y iburst

Set fixed IP address (my AP doesn't handle this) :
Edit /etc/network/interfaces/eth0
Change line "iface eth0 inet dhcp" to :
iface eth0 inet static
    address 192.168.x.y  (change x.y to your IP address)
    netmask 255.255.255.0
    gateway 192.168.x.z  (change x.y to your gateway address)
Also update routing info, since DHCP would do that :
> rm -f /etc/resolv.conf
> vim /etc/resolv.conf
Insert : (change to the nameserver of your choice)
nameserver 75.75.75.75
nameserver 75.75.76.76
search hsd1.or.comcast.net

Add any external drives to auto mount (/video is the USB HD) :
Edit /etc/fstab, adding
/dev/sda1 /video ext4 defaults,noatime,nofail 0 0

Add to /etc/profile (before last "if" (personal preferences)) :
alias l='ls -ahl'
alias lc='ls -aCF'
alias cls='tput clear'

Set Default Locale (these are mine, change to match yours) :
vim /etc/default/locale and add :
LANG=en_US.UTF-8
LC_ALL=en_US.UTF-8
LANGUAGE=en_US.UTF-8

I have a Serial to USB adapter connected to the Rock64 UART, and use it for console messages and initial setup login, in case ssh doesn't work.

Put SD Card in Rock64, and boot with it.

Login to user account, and change password (rock64/rock64 for my image) :
> passwd (follow prompts for directions)
Login to root :
> sudo su - root (user account password).
Set root password (it's my preference to have a root login, and use it).
> passwd
From here on, everything is done as root.  Prepend 'sudo' if using a user account.
If first boot of Rock64, fix random MAC address changing on Ethernet port :
> dd if=/dev/zero of=/dev/mtd3 (writes zero to SPI Flash)
reboot twice (once to write new MAC, second to boot with it?)

> reboot

Expand file system so /root has all available space : (not needed after 0.5.9, as it's done automatically)  - Thanks for the tip jl_678!

If exists /usr/local/sbin/resize_rootfs.sh, execute it (that should work).
Otherwise, manual method is as follows :
> parted -l  (It should ask to Fix GPT, enter F to fix)
> fdisk /dev/mmcblk1
   d (delete root partition, should be last one)
   n (new root partition), select defaults for size
   w (write new partition table)
> partprobe /dev/mmcblk1 (force kernel to re-read partition table)
> resize2fs /dev/mmcblk1p7 (where 7 is the root partition number)
> df -h (to print out new sizes)

Set correct Time Zone :
> dpkg-reconfigure tzdata

If using USB3.0 HD, disable UAS mode unti drivers get fixed.  To check, do :
lsusb -t
If device is listed as using uas driver ("driver=uas"), edit :
> vim /etc/modprobe.d/rk3328-usb-storage-quirks.conf
Add to end of line :
options usb-storage quirks=0x2537:0x1066:u,0x2537:0x1068:u,0x0bc2:0xa013:u,0x0bc2:0x2101:u,0x2109:0x0715:u,0x<HD VID>:0x<HD PID>:u
Substitute HD VID/ HD PID with actual USB device VID/PID
Then reboot twice.  Once done, lsusb -t should show "driver=usb-storage"
Downside is speed is reduced, but makes it stable.

Get latest packages :
> apt-get update
> apt-get upgrade

Install zip/unzip :
> apt-get install zip

Install NFS server & tools, for sharing HD to Linux network :
> apt-get install nfs-kernel-server nfs-common
After installing NFS, add shares to /etc/exports (change x to subnet number) :
> vim /etc/exports
Add : /video   192.168.x.0/255.255.255.0(rw,sync,no_subtree_check)
Next, enable RPC bind :
> systemctl enable rpcbind
Restart NFS Kernel server :
> service nfs-kernel-server restart
> exportfs -ra (to re-read exports file)
On Client, mount using mount.nfs4 or 'mount -t nfs4'

Install build tools :
> apt-get install autoconf automake pkgconf libtool build-essential libzip-dev

Install Motion 4.0 application :
> apt-get install motion (installs 3.3, but use it to get all dependencies and expedite setup)
Install FFMPEG/Libav packages :
> apt-get install libjpeg62-turbo-dev libavformat-dev libavcodec-dev libavutil-dev libswscale-dev libavdevice-dev
Now download, build, and install the actual 4.0.1 version :
> cd /usr/local/src
> wget https://github.com/Motion-Project/motion...master.zip
> unzip master.zip
> cd motion-master
> autoreconf -fiv
> ./configure
> make
> make install
When done, remove version 3.3 installed by apt-get :
> apt-get remove motion
Move config files and log file to HD, to reduce SDCard wear.  Update paths so startup finds correct config files :
> cp /usr/local/etc/motion /video/motion
> mv /etc/motion /etc/motion.bak
> ln -s /video/motion /etc/motion
> mv /usr/local/etc/motion /usr/local/etc/motion.bak
> ln -s /video/motion /usr/local/etc/motion
Make sure all config files are owned by user motion :
> chown -R motion /video
> chgrp -R motion /video
> chown -R motion /run/motion
> chgrp -R motion /run/motion
Update startup script with new paths :
> vim /etc/init.d/motion
Add ':/usr/local/bin' to the end of the PATH_BIN variable
Change variable 'DAEMON= to point to new motion binary (/usr/local/bin)
Change 'status_of_proc' path (in 'status' case) to /usr/local/bin
Change 'start' case, to add " -c /video/motion/motion.conf" after "--exec $DAEMON"
Update Unit file :
> systemctl daemon-reload
Install latest ffmpeg from source :
> cd /usr/local/src
> wget http://ffmpeg.org/releases/ffmpeg-3.3.4.tar.bz2
> tar -xjf ffmpeg-3.3.4.tar.bz2
> cd ffmpeg-3.3.4
> ./configure
> make -j4
> make install
If starting motion automatically at boot, enable daemon mode :
> vim /etc/default/motion
Change "start_motion_daemon=no" to yes
Start motion manually first time (should auto-start at boot going forward) :
> service motion start
Check log file /video/motion.log to see if everything worked.
*************************************************************


I documented these steps for my own use, in case I ever need to rebuild the system from scratch.  I figured someone else might find it helpful, hence posting it here.  I have no interest in debating different ways of doing things, but if you have helpful suggestions, please share them.

I would also suggest moving any actively written directories to the HD, to help reduce SD card wear.  One might even go so far as to make the HD the root file system, and boot to it (did this on one of my RPis, and will do it here soon).

So what's your Rock64 doing?

[skipper]

In the "Also update routing info.." I would think you have a couple of typos with resolv.conf
Also, I'd be interested to know what those aliases in /etc/profile are doing, but that's probably a google item?
I'm asking because I'm currently tinkering with changing my SSH (Putty) terminal look/feel with various prompt colors for various users/machines, and AFAI have googled that can/should be done in profile? Is that what your aliases are doing?

edit: OK I found out about the aliases stuff

[jl_678]

Hi,

I think that from 0.5.9 forward that Ayufun's image automatically expand the root filesystem on first boot and so those steps are not needed. Check it out on the change log on the page below.

https://github.com/ayufan-rock64/linux-build/releases

JL

[hecpilot]

I purchased the Rock64 4G for a single purpose: To monitor cheap IP based network cameras bought off eBay, running a program called Motion 4.0.1.

I attached a external self powered USB 3.0 8TB hard drive, and currently monitor 5 cameras via the GB Ethernet interface.  The camera configurations are 3x 1080P 2MP cameras, and 2x 720P 1MP cameras. 

Great write up!  Would you mind please telling us which cameras you ended up using?  I'm interested in setting up something similar.

[rmbusy]

I purchased the Rock64 4G for a single purpose: To monitor cheap IP based network cameras bought off eBay, running a program called Motion 4.0.1.

I attached a external self powered USB 3.0 8TB hard drive, and currently monitor 5 cameras via the GB Ethernet interface.  The camera configurations are 3x 1080P 2MP cameras, and 2x 720P 1MP cameras. 

Great write up!  Would you mind please telling us which cameras you ended up using?  I'm interested in setting up something similar.

Thanks!  Sorry for the delay, but although I checked the "Subscribe to this thread" button when I created it, it didn't subscribe me to it, and didn't send me email when someone replied.  I've been busy, and haven't checked back here for quite awhile.

The cameras I'm using were the cheapest I found on eBay at the time.  All of the cameras are IP based network cameras.  I bought 5 1080P 2MP H.View cameras w/ IR night vision.  These turned out to be really nice cameras, and I wish I had bought more at the time.  I also bought a pile of 720P 1MP cameras, of 2 different types.  Of these, the first ones were usable out of the box, but the FW on them limits configurability to I.E., with a plug in downloaded from the camera.  This seemed like a great way to get a Chinese hacker virus, so I would only use it in a disposable Virtual Machine.  The second batch had such bad FW, they were basically unusable out of the box.  I made a project out of them, to replace the crappy FW with something usable.

If you're shopping for cheap IP cameras, finding ones that allow configuration from *any* web browser is desirable.  However, most of the sellers in the lower price ranges really don't know anything about what they're selling.  Also, with the cameras I bought, I found the microprocessor they used was different.  The H.View cameras use a HiSilicon micro, which has full documentation available, including a SDK.  These micros run cool to the touch.  The other cameras all use a Goke 7102 micro.  This chip runs very hot, even when doing nothing.  I'm concerned about it's long term reliability.  Also, they are completely closed off as far as documentation.  There is a rumor they sell their SDK for $10K, and I could find no datasheet or other information about it.  Given all that, if you have a choice, go for a camera with a HiSilicon processor.

The nice thing about the H.View camera is their FW is relatively clean.  After a little digging through the FW on the camera, I found the 1080P stream URL, the 720P stream URL, and a snapshot URL.  When dealing with cheap eBay cameras, those addresses are typically not known.  Having the snapshot URL is the most important for setting it up with Motion, because even the Rock64 can't handle decoding live streams for more than a few low resolution cameras, without dropping frames (at least in the current configuration).  I still haven't found a snapshot URL for the 720P cameras, so I'm monitoring them in 640x360 mode.  The Pi2 couldn't keep up with the decoding of 2 cameras in this mode, which is why I moved up to the Rock64 (that and the faster disk / network interfaces).

I clicked the "Subscribe" button again, so hopefully I'll start getting messages when someone posts to the thread now.

One other warning about IP cameras : Be sure to firewall them off from the internet, else you'll be contributing to the population of Minions out there.  All of these cameras have so many embedded IP addresses, URLs, and open ports, it's downright scary.  So far, they all run embedded Linux, w/ Busybox.  All of them I have looked at have open telnet ports, and the last batch I bought had no root password!  You could log into one of these cameras by telnetting to it, type "root", and a carriage return for the password.  I set up static IP addresses for all my cameras in a fixed range, then on my AP, blocked all internet access for all ports for the range.  The last batch of cameras spend all of their time trying to look up a IP address from a URL, so they can "phone home".  These addresses are all in China or Hong Kong.

---

---

Hi,

I think that from 0.5.9 forward that Ayufun's image automatically expand the root filesystem on first boot and so those steps are not needed.  Check it out on the change log on the page below.

https://github.com/ayufan-rock64/linux-build/releases

JL

Thanks for the tip!  I added a note to that affect in the procedure.  Since I hadn't looked at anything that new yet, I wasn't aware it was being done automatically.

[gregb49]

/dev/sda1 /video ext4 defaults,noatime,nofail 0 0

Thanks for your post. I might get back to it and the useful advice on cameras, but meanwhile I just wanted to thank you for that simple line. Every time I use some website's advice on editing fstab, I end up with a non booting rock64. Your line worked, with suitable modifications. All I'm trying to do is auto-mount an external hard drive and am hitting all sorts of problems. I think the secret was the:

Code:

noatime,nofail 0 0

I answer to you question, I'm trying to use mine as a small, low power consuming desktop replacement. Not there yet, but hopefully, making progress, in between corrupting the eMMC card, somehow.