Moklev

Yes, for CSI camera you must stay on legacy (Jessie dafault).
CSI on mainline is on WIP stage.
Main difference is Motion 3.2.12 (instead of 4.01). Next kernel 4.14.18 is more stable than 3.x (uptime: weeks vs few days). On Jessie may need "deb multimedia" packages for a recent ffmpeg version.
I recommend you a good USB camera H264/MJPEG capable.

@Moklev i'd suggest monitoring and tracking down the root cause of the ssh woes, one of those ways is to connect via a serial console when ssh fails
https://forum.armbian.com/topic/8237-serial-console-access-via-usb-uartgadget-mode-on-linuxwindowsosx/
 
try to connect a cable via the micro usb OTG port to see if you get a linux console presented. if that works when ssh fails you could then 'get into' the board and do some checks like a armbianmonitor -u
(if network fails you may need to run armbian monitor -U and saving the logs to a file)
 
among the things check /sbin/sysctl -a |grep vm.swappiness
vm.swappiness = 100
 
check in /etc/sysctl.conf if it is defined there you may like to reduce that value to 50 (or even for tests 0) to see if it made a difference
 
there could also be other ways like hacking up a script to say ping the router every 5 minutes and if ping fails to capture a log like armbianmonitor -U > logfile
 
------
on a side note, i'd think 5.60 is still a useful 'milestone' to have
 
 

Wrong way since we implemented an own zram-control mechanism in the meantime already available in nightlies and supposed to be rolled out with next major update.
 
For anyone coming across this: do NOT follow the above recipe, it's deprecated in Armbian and causes more harm than any good.
 
@Igor: IMO we need to make the amount of zram configurable. Currently it's set as 'half of available RAM' in line 35 of the initialization routine. But since updates will overwrite this users who want to benefit from massive zram overcommitment (since it just works brilliant) are forced to edit this script over and over again.
 
I propose to define the amount used as $ZRAM_PERCENTAGE that defaults to 50 and can be defined in a yet not created /etc/defaults/armbian-zram-config file. Any opinions?

Normal. Board can't really power off properly due to ... cheap design. The only way is to make it into sleep mode with use of the AR100 coprocessor inside H2/H3 chip which support is in this state: http://linux-sunxi.org/AR100

Me too... with an old HP z400 Workstation (Xeon W3530, 12GB ECC DDR3 and a SSD Crucial MX300) build process is quite fast.

That's interesting.
And then the fun begins, i gave it a try using r8p1 with kernel 4.4 on A64 and it works... a bit slow but works, though i don't know for how long. Framebuffer only.
 
The weird thing (it's  kind of frankenstein):
=======================================================
    glmark2 2012.12
=======================================================
    OpenGL Information
    GL_VENDOR:     ARM
    GL_RENDERER:   Mali-400 MP
    GL_VERSION:    OpenGL ES 2.0 "mali450-r5p1-01rel0-lollipop-233-g52c929d"
=======================================================
[build] use-vbo=false: FPS: 60 FrameTime: 16.667 ms
[build] use-vbo=true: FPS: 60 FrameTime: 16.667 ms
[texture] texture-filter=nearest: FPS: 60 FrameTime: 16.667 ms
[texture] texture-filter=linear: FPS: 60 FrameTime: 16.667 ms
[texture] texture-filter=mipmap: FPS: 60 FrameTime: 16.667 ms
[shading] shading=gouraud: FPS: 60 FrameTime: 16.667 ms
 
Does Anyone one know a complete recipe for building KODI or similar (framebuffer) to check if this is really working?

Still being designed but photos attached. Big enough for you? @tkaiser 

(disclaimer) No itention to make a Frankendebian (https://wiki.debian.org/DontBreakDebian) but ubuntu package "zram-config" works perfectly.
I tested it for two weeks in a: Orange PI Zero 512MB Armbian Stretch 5.40 4.14.18, Orange PI PC2 Armbian Stretch 5.40 4.14.18, AMD Sempron microserver Debian Stretch 9.4 4.9.0-6-amd64.
 
A short tutorial:
 
1. Download zram-config package (it's a universal package, it does not matter the architecture in use)
wget http://de.archive.ubuntu.com/ubuntu/pool/universe/z/zram-config/zram-config_0.5_all.deb
 
2. Install it
sudo dpkg -i zram-config_0.5_all.deb
 
3. Remove the installer
rm zram-config_0.5_all.deb
 
4. Check vm.swappiness
cat /proc/sys/vm/swappiness
(must be 60, default)
 
5. If not (i.e. "cat /proc/sys/vm/swappiness" return "1" ) change it to "60"
sudo nano /etc/sysctl.conf
and add "vm.swappiness=60" at the end of file
... and reboot
 
6. check zRAM service
sudo zramctl

NAME       ALGORITHM DISKSIZE  DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo         437,8M  5,2M  1,4M  1,9M       2 [SWAP]
/dev/zram1 lzo         437,8M  5,2M  1,4M  1,9M       2 [SWAP]
 
7. (optional) change lzo compression to lz4
sudo nano /usr/bin/init-zram-swapping
 
# initialize the devices
for i in $(seq ${NRDEVICES}); do
  DEVNUMBER=$((i - 1))
  echo $mem > /sys/block/zram${DEVNUMBER}/disksize
  mkswap /dev/zram${DEVNUMBER}
  swapon -p 5 /dev/zram${DEVNUMBER}
done
 
to...
 
# initialize the devices
for i in $(seq ${NRDEVICES}); do
  DEVNUMBER=$((i - 1))
  echo lz4 > /sys/block/zram${DEVNUMBER}/comp_algorithm
  echo $mem > /sys/block/zram${DEVNUMBER}/disksize
  mkswap /dev/zram${DEVNUMBER}
  swapon -p 5 /dev/zram${DEVNUMBER}
done
 
8. restart the service
sudo systemctl restart zram-config.service
 
9. check new compression algorithm
sudo zramctl

NAME       ALGORITHM DISKSIZE  DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lz4         437,8M  5,2M  1,4M  1,9M       2 [SWAP]
/dev/zram1 lz4         437,8M  5,2M  1,4M  1,9M       2 [SWAP]
 
10. check the zRAM priority over file swap
cat /proc/swaps
 
zRAM devices must be at priority "5", swap file at "-1" or "-2"
 
11. finish
:-)
 
 
 

Today I had a chance to test OV5640 on mainline kernel 4.17.2 and see the status of OV5640 and CSI drivers, thanks to FE work and the author of the driver (help name here...). I tested on NanoPi K1 Plus (H5) to verify the images in very low light conditions, so don't expect good quality.
I could take some images using fswebcam and you should expect basic v4l2 functionality already works if not all. I think motion (did not test  / had time to test it) can work with current OV5640 on mainline kernel.
Grabbing Image is very fast, currently, Image size I can get are 320x240 and 640x480 pixels, above this i get a dark image. I have not looked at the driver source code to see if it is implemented or not.  
 
Basically, you need to add the sun6i_csi and ov5640 drivers to the kernel and adjust DT to have the endpoint. FE has already done it and left H5 for homework, but is the same as H3.
 
To check the functionality, install v4l2-utils and when the driver sun6i_cs loads, it creates the device node /dev/video0 and you can check that:
 
sudo v4l2-ctl -d /dev/video0 -D Driver Info (not using libv4l2):     Driver name   : sun6i-video     Card type     : sun6i-csi     Bus info      : platform:camera     Driver version: 4.17.2     Capabilities  : 0x84200001         Video Capture         Streaming         Extended Pix Format         Device Capabilities     Device Caps   : 0x04200001         Video Capture         Streaming         Extended Pix Format You should see the modules loaded like this:
lsmod Module                  Size  Used by sun6i_csi              24576  0 videobuf2_dma_contig    20480  1 sun6i_csi videobuf2_memops       16384  1 videobuf2_dma_contig ov5640                 36864  1 videobuf2_v4l2         24576  1 sun6i_csi videobuf2_common       40960  2 videobuf2_v4l2,sun6i_csi v4l2_fwnode            20480  2 ov5640,sun6i_csi v4l2_common            16384  1 ov5640 videodev              196608  6 v4l2_fwnode,v4l2_common,ov5640,videobuf2_v4l2,sun6i_csi,videobuf2_common sunxi_cir              16384  0 media                  36864  3 videodev,ov5640,sun6i_csi rc_core                40960  2 sunxi_cir sch_fq_codel           20480  6 8189es               1118208  0 So time to revisit the camera drivers on mainline.
Here are some images (remember, low light condition!):
 
*update: All possible window sizes are working for streaming!
 
 
 

Just for the record: this package (a simple script in reality) installs and works pretty well in Debian too so it should be purged anywhere as part of an upgrade mechanism.

Not only you tested it but thousands of OpenMediaVault users (the majority on the Raspberry Pi) since I did exactly the same in our OMV images for ARM boards.
 
But this is not the recommended way any more, lz4 for whatever reasons performs not greater than lzo but it would be great if you can join testing efforts.
 

This should fix this problem.
https://github.com/armbian/config/commit/d7b283e7b8af0c64189f47d0765a790767b44e99

First Pine H64/H6 mainline testing images based on @Icenowy patchset https://dl.armbian.com/pineh64/ Boot log: http://ix.io/18DU

2018 SD card update
 
It's 2018 now, SD Association's A1 'performance class' spec is out over a year now and in the meantime we can buy products trying to be compliant to this performance class. SD cards carrying the A1 logo must be able to perform at least 1500 random read input-output operations per second (IOPS) with 4KB block size, 500 random write IOPS and 10 MB/s sustained sequential performance (see here for more details and background info)
 
Why is this important? Since what we do on SBC at least for the rootfs is mostly random IO and not sequential IO as it's common in cameras or video recorders (that's the stuff SD cards have been invented to be used with in the beginning). As an SBC (or Android) user we're mostly interested in high random IO performance with smaller blocksizes since this is how 'real world' IO patterns mostly look like. Prior to A1 and A2 performance classes there was no way to know how SD cards perform in this area prior to buying. Fortunately this has changed now.
 
Last week arrived an ODROID N1 dev sample so I bought two SanDisk A1 cards with 32GB capacity each. An el cheapo 'Ultra A1' for 13€ (~$15) and an 'Extreme A1' for 23€. I wanted to buy a slightly more expensive 'Extreme Plus A1' (since even more performance and especially reliability/longevity) but ordered the wrong one  Please keep in mind that the 'Extreme Plus' numbers shown below are made with an older card missing the A1 logo.
 
Let's look how these things perform, this time on a new platform: RK3399 with an SD card interface that supports higher speed modes (requires kernel support and switching between 3.3V to 1.8V at the hardware layer). So results aren't comparable with the numbers we generated the last two years in this and other threads but that's not important any more... see at the bottom.
 
A1 conformance requires at least 10 MB/s sequential performance and 500/1500 (write/read) IOPS with 4K blocksize. I tested also with 1K and 16K blocksizes for the simple reason to get an idea whether 4K results are useful to determine performance with smaller or larger blocksizes (since we already know that the vast majority of cheap SD cards out there shows a severe 16K random write performance drop which is the real reason so many people consider all SD cards being crap from a performance point of view).
 
I tested with 7 cards, 4 of them SanDisk, two Samsung and the 'Crappy card' being a results mixture of a 4GB Kingston I started to test with and old results from a 4GB Intenso from two years ago (see first post of this thread). The Kingston died when testing with 4K blocksize and the performance of all these crappy 'noname class' cards doesn't vary that much:
1K w/r 4K w/r 16K w/r Crappy card 4GB 32 1854 35 1595 2 603 Samsung EVO+ 128GB 141 1549 160 1471 579 1161 Ultra A1 32GB 456 3171 843 2791 548 1777 Extreme A1 32GB 833 3289 1507 3281 1126 2113 Samsung Pro 64GB 1091 4786 1124 3898 478 2296 Extreme Plus 16GB 566 2998 731 2738 557 2037 Extreme Pro 8GB 304 2779 323 2754 221 1821 (All results in IOPS --> IO operations per second) For A1 compliance we only need to look at the middle column and have to expect at least 500/1500 IOPS minimum here. The 'Crappy card' fails as expected, the Samsung EVO+ too (but we already knew that for whatever reasons newer EVO+ or those with larger capacity perform worse than the 32GB and 64GB variants we tested two years ago), the Samsung Pro shows the best performance here while one of the 4 SanDisk also fails. But my Extreme Pro 8GB is now 3 years old, the other one I had showed signs of data corruption few months ago and when testing 2 years ago (see 1st post in this thread) random write performance was at 800. So most probably this card is about to die soon and the numbers above are partially irrelevant..
 
What about sequential performance? Well, 'Crappy card' also not able to meet specs and all the better cards being 'bottlenecked' by ODROID N1 (some of these cards show 80 MB/s in my MacBook's card reader but Hardkernel chose to use some safety headroom for good reasons and limits the maximum speed for improved reliability)
MB/s write MB/s read Crappy card 4GB 9 15 Samsung EVO+ 128GB 21 65 Ultra A1 32GB 20 66 Extreme A1 32GB 59 68 Samsung Pro 64GB 61 66 Extreme Plus 16GB 63 67 Extreme Pro 8GB 50 67 Well, sequential transfer speeds are close to irrelevant with single board computers or Android but it's good to know that boards that allow for higher SD card speed modes (e.g. almost all ODROIDs and the Tinkerboard) also show an improvement in random IO performance if the card is a good one. The ODROID N1 was limited to DDR50 (slowest SD card mode) until today when Hardkernel unlocked UHS capabilities so that my cards (except of 'Crappy card') could all use SDR104 mode. With DDR50 mode sequential performance is limited to 22.5/23.5MB/s (write/read) but more interestingly random IO performance also differs. See IOPS results with the two SanDisk A1 cards, one time limited to DDR50 and then with SDR104:
1K w/r 4K w/r 16K w/r Ultra A1 DDR50 449 2966 678 2191 445 985 Ultra A1 SDR104 456 3171 843 2791 548 1777 1K w/r 4K w/r 16K w/r Extreme A1 DDR50 740 3049 1039 2408 747 1068 Extreme A1 SDR104 833 3289 1507 3281 1126 2113 We can clearly see that the larger the blocksize the more the interface speed influences also random IO performance (look especially at 16K random reads that double with SDR104)
 
Some conclusions:
When comparing results above the somewhat older Samsung Pro performs pretty similar to the Extreme A1. But great random IO performance is only guaranteed with cards carrying the A1 logo (or A2 soon) so it might happen to you that buying another Samsung Pro today results in way lower random IO performance (see Hardkernel's results with a Samsung Pro Plus showing 224/3023 4k IOPS which is way below the 1124/3898 my old Pro achieves with especially write performance 5 times worse and below A1 criteria) We still need to focus on the correct performance metrics. Sequential performance is more or less irrelevant ('Class 10', 'UHS' and so on), all that matters is random IO (A1 and A2 soon). Please keep in mind that you can buy a nice looking UHS card from 'reputable' brands like Kingston, Verbatim, PNY and the like that might achieve theoretical 80MB/s or even 100MB/s sequential performance (you're not able to benefit from anyway since your board's SD card interface will be the bottleneck) but simply sucks with random IO performance. We're talking about up to 500 times worse performance when trusting in 'renowned' brands and ignoring performance reality (see 16k random writes comparing 'Crappy card' and 'Extreme A1') Only a few vendors on this planet run NAND flash memory fabs, only a few companies produce flash memory controllers and have the necessary know-how in house. And only a few combine their own NAND flash with their own controllers to their own retail products. That's the simple reason why at least I only buy SD cards from these 4 brands: Samsung, SanDisk, Toshiba, Transcend The A1 performance speed class is a great and necessary improvement since now we can rely on getting covenant random IO performance. This also helps in fighting counterfeit flash memory products since even if fraudsters in the meantime produce fake SD cards that look real and show same capacity usually these fakes suck at random IO performance. So after testing new cards with either F3 or H2testw it's now another iozone or CrystalDiskMark test to check for overall performance including random IO (!) and if performance sucks you simply return the cards asking for a refund. TL;DR: If you buy new SD cards choose those carrying an A1 or A2 logo. Buy only good brands (their names start with either S or T). Don't trust in getting genuine products but always expect counterfeit stuff. That's why you should only buy at sellers with a 'no questions asked' return/refund policy and why you have to immediately check your cards directly after purchase. If you also care about reliability/resilience buy more expensive cards (e.g. the twice as expensive Extreme Plus A1 instead of Ultra A1) and choose larger capacities than needed.
 
Finally: All detailed SD card test results can be found here: https://pastebin.com/2wxPWcWr As a comparison performance numbers made with same ODROID N1, same settings but vendor's orange eMMC modules based on Samsung eMMC and varying only in size: https://pastebin.com/ePUCXyg6

Yes, for CSI camera you must stay on legacy (Jessie dafault).
CSI on mainline is on WIP stage.
Main difference is Motion 3.2.12 (instead of 4.01). Next kernel 4.14.18 is more stable than 3.x (uptime: weeks vs few days). On Jessie may need "deb multimedia" packages for a recent ffmpeg version.
I recommend you a good USB camera H264/MJPEG capable.

Image update Armbian 20180323 kernel 4.14.11 .
Works wired network, USB, monitor (you can change the screen resolution on the fly). The images are in the "test"directory.

With Motioneye use ONLY Debian server/headless, best with cabled ethernet. With wifi the performance is reduced.
My setup is: Orange Pi Zero (512MB) with Armbian 5.41/Debian Stretch 4.14.18 (next), MotionEye 0.38.1 and Motion 4.01.
Use H264 for maximum performance and MJPEG for maximum quality.

Yes!!! and now @balbes150 is moving to kernel 4.9.40 
 

With an ELP 2mpx usb camera you can stream at 30+ fps, with streaming only and motion process disabled.
Motion's slow dog process is a problem, you require an i5 cpu for a reasonable performance. With a little OPZ @1GHz Motioneye (Motion 4.01) runs at 15fps/720p but drop below 6-7fps if an event starts saving an image sequence (ca. 10 jpeg images).

You don't need a new guide. Motion 4.1.1 isn't available on Armbian, Mr Dave's build is only for Raspbian.
 
On Armbian (i.e. Orange Pi Zero) download new Stretch build 5.38 next, mainline 4.14.14. Do not use Ubuntu.
 
Follow original installation guideline:
https://github.com/ccrisan/motioneye/wiki/Install-On-Debian
(For Debian Stretch)
 
BEFORE point 4 install pip dependencies:
sudo pip install wheel
sudo pip install setuptools
sudo apt-get install zlibc zlib-gst zlib1g-dev
 
Continue to point 4...
... at the end of installation point to [yourip]:8765 and configure it.
 
et voilà! :-)
 
Now Motioneye 0.38 run on motion 4.01.
New motion version is usefull for new cam h264/rtsp based.
 

 
With little OPZ performance is quite respectable:
15fps (streaming) / 10 fps (analisys and capture) with a HD stream 1280x720px, H264 900 kbit/s
12fps (streaming) / 7 fps (analisys and capture) with a HD stream 1280x720px, mjpeg 2,5 mbit/s
Load:  1.94  1.24  0.53
Temp: 70 °C
(without hardware acceleration...)
 
 
Mk

You don't need a new guide. Motion 4.1.1 isn't available on Armbian, Mr Dave's build is only for Raspbian.
 
On Armbian (i.e. Orange Pi Zero) download new Stretch build 5.38 next, mainline 4.14.14. Do not use Ubuntu.
 
Follow original installation guideline:
https://github.com/ccrisan/motioneye/wiki/Install-On-Debian
(For Debian Stretch)
 
BEFORE point 4 install pip dependencies:
sudo pip install wheel
sudo pip install setuptools
sudo apt-get install zlibc zlib-gst zlib1g-dev
 
Continue to point 4...
... at the end of installation point to [yourip]:8765 and configure it.
 
et voilà! :-)
 
Now Motioneye 0.38 run on motion 4.01.
New motion version is usefull for new cam h264/rtsp based.
 

 
With little OPZ performance is quite respectable:
15fps (streaming) / 10 fps (analisys and capture) with a HD stream 1280x720px, H264 900 kbit/s
12fps (streaming) / 7 fps (analisys and capture) with a HD stream 1280x720px, mjpeg 2,5 mbit/s
Load:  1.94  1.24  0.53
Temp: 70 °C
(without hardware acceleration...)
 
 
Mk

Well it took me longer than i hoped but i have managed to forward port icenowys code for TVE on the H2+/H3 to mainline armbian.  It seems to work totally fine, with a few caveats.
First: Sample images of it in action -> https://imgur.com/a/vXQEM
Second: the patch itself -> https://github.com/stevenj/h3-tve/tree/v0.0.11
Third a prebuilt image for Orange Pi Zero: -> https://github.com/stevenj/h3-tve/releases/tag/v0.0.11
 
Howto:
just put the patch into userpatches for the sunxi-next kernel, and build.  it should apply cleanly. Its for H2+/H3.  I have only tried it on a orange pi zero, but it should work on all H2+/H3 boards.
 
You then need to edit /boot/armbianEnv.txt
add tve to overlays to enable it.  the driver will only run and enable tv out when the tv out devices are specifically enabled, so i created an overlay which does this.  If you want to turn TV out off, just remove tve from the overlays line.
My armbianEnv.txt overlays looks like this:
overlays=usbhost2 usbhost3 tve If you want copious amounts of DRM debug info in your logs, add this as well:
extraargs=drm.debug=0xF Its not needed, unless you really want the debug info.
 
Notes:
1. The default mode is PAL, with 720x576 resolution.  Thats outside of normal PAL displayable area, and so the screen overscans.
I dont know how to correct this, although its mostly just annoying with terminals.
I also don't know how to change the video mode to NTSC.
 
2. The standard font is a bit thin for composite video, and causes slight strobing and color impurity.  Its because PAL needs pixels to be a certain MINIMUM width or color information can not be properly encoded.
A way to resolve this is use :
# apt-get install fbterm ... $ fbterm -s 20 This will run a terminal which is easy to change the font, and pick a bigger one.  its much easier to read.  Look at the help for fbterm to work out everything it can do.
 
3. I used the program "fim" to display the test images.  there are others for doing stuff on the terminal.
 
4. I haven't tried X.  I am not interested in running an X terminal on a TV, but it should probably work fine.
 
Other than that it all seems good.  I originally tested my hardware with the legacy kernel, and the image quality from this patch seems superior to what the legacy kernel produces. (legacy was noisy)
 
The only other thing you need to know is Orange Pi Zero is missing filter circuity from its Composite Output, the most important thing you need to do is put a 50 ohm resistor between the signal and GND.  i soldered one inside my RCA connector, it fits fine and isn't too difficult.  IF you don't do this the image will bloom and look like total crap, so you have been warned.
 
As this patch allows TVE to be enabled/disabled through use of the Device Tree overlays, i think it should be fine if the Armbian devs want to include it.  I am happy to clean out some of the debug messages i added if they are interested in making a standard part of the build.  If not, its easy enough to build your own image, just follow the guides on how to rebuild armbian.
 
EDIT: I need to mention, all props go to Icenowy Zheng who wrote the original driver.  I just tweaked the device tree stuff and got it in a state where it can apply cleanly to the armbian mainline kernel and build system.
Original code is here:
https://github.com/Icenowy/linux/tree/tve-v2

Uhmm... a full system backup with rsync?
 
i.e.
# rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / /path_to_backup_dir/
(as root)

If you wish to restore, use the same command that was executed but with the source and destination reversed. Make you own --exclude list.

No, he can't.
 
For the MXQ Pro 4k (SOC: Amlogic S905X) try first the file "gxl_p212_2g.dtb" (if 2GB... or xxx_1g.dtb if 1GB).
 
In general:
p212: for Amlogic S905X
p200/p201: for Amlogic S905
q200/q201: for Amlogic S912
... and other version for specific hardware (S912 100mbps or 1gpps, Weitek Play, Khadas VIM/VIM2, Realtek wifi, etc...).