https://forum.armbian.com/forum/26-research-guides-tutorials/enRemote Desktop Fun with Armbianhttps://forum.armbian.com/topic/1044-remote-desktop-fun-with-armbian/
Is OPI ONE a toy or a toy ? Yes and yes and a fun one too ! The following experiment shows the OPI ONE in use as a Virtual Desktop Server AND Virtual Desktop Client.

I'll link from the README there to this thread for further discussion about the tool and proper benchmark methodology.

]]>7819Sat, 28 Jul 2018 14:35:46 +0000SD card performancehttps://forum.armbian.com/topic/954-sd-card-performance/Warning: This whole thread is only about historical information now since it's 2018 and we can buy inexpensive and great performing A1 rated SD cards in the meantime. Buying anything else is a mistake so directly jump to the end of the thread for performance numbers and recommendations.

Kernel version matters (since with Allwinner's 3.4 kernel sequential throughput is limited to ~16MB/s, with mainline kernel we get close to Banana Pi SDIO implementation's max: ~23MB/s) and filesystem settings matter too (enabled journal for example slows down 4K writes a lot).

Sequential speeds:

Random I/O:

The 4 Samsung cards were bought within the last 3 weeks and manufactured between 09/2015 and 12/2015 according to the card's metadata. Interesting observation: I used three of these cards the first time and they all show identical behaviour especially regarding writes with small record sizes: pretty slow in the beginning and getting faster over time (the Samsung Pro for example started with only 1400KB/s 4K writes and 3 runs later the same test showed 3270KB/s -- maybe an indication that some sort of calibration happened. Anyway: I know why I always repeat tests and do not rely on a single test run)

The SanDisk Extreme Pro has been bought nearly 3 years ago. This card shows superior sequential read/write performance compared to the three Samsung EVOs. But only when used in combination with a host that can make use of these speeds. My MacBook writes 4 times faster an OS image to the Extreme Pro compared to the EVOs. But this doesn't matter at all since the SDIO implementation of the board in question is limited to ~23MB/s (50MHz @ 4 bit). The same sequential write/read speed limitation applies to most SBCs since to be able to exceed this slow mode the voltage the SD/TF card is fed with would've to be adjusted (default 3.3V, the faster modes require a dynamic switch to 1.8V instead which some/most SoCs can perform but if the SBC vendor doesn't implement this you're limited to ~23MB/s).

Therefore cards labeled as being capable of "up to 90MB/s" do not perform different than those that can only do "up to 20MB/s" as long as we're talking about sequential transfers since the SD card interface is already the bottleneck. But since we're using SD/TF cards not in cameras but as storage media for the rootfs of an SBC something different is more important: Random I/O. And here performance of cards that are labeled identical ('class 10' for example) differs a lot.

All 4 Samsungs outperform the other cards easily in this area. The SanDisk Extreme Pro can not compete regarding random I/O compared to superiour (but mostly irrelevant) sequential transfer speeds. And funnily the 3 other cards show horribly slow random write performance, especially with 16k record size. According to card metadata the 2 Intenso are oemid 0x5048 / manfid: 0x000027 (cheap crap known to die way too early) and I would believe the SanDisk 'class 10' card is a fake or at least uses the same controller as the 2 Intenso since 16K random writes are also way slower than 4K writes.

Detailed results (summary table also available as .ods, .xlsx or .txt):

If the board's SD card interface is the bottleneck since it's not supporting the faster SDIO modes using expensive cards that exceed the interface's maximum sequential bandwidth is useless. An expensive Samsung Pro Plus won't be faster than a way more cheap EVO when it's about sequential transfer speeds since you will stay at ~22MB/s anyway

Sequential read and especially write speeds are all the SD association's speed ratings are about (to ensure reliable recording of videos/images in cameras/recorders)

When an SD card is used in an SBC sequential speeds aren't that important. It's all about random I/O, especially with small block sizes (reading and writing small random chunks of data from/to the card)

No commonly used 'random I/O' speed ratings exist so you have to check the card in question prior to usage or rely on appropriate benchmarks (see the two links directly above). Again: the 'speed class' won't tell you anything. You can get two different 'class 10' cards that differ by 500% or even more regarding real world storage performance (again: random I/O matters). In the example above the Intenso 'class 10' card is 385 slower compared to the EVOs when it's about 16K random writes (good luck if you have a database running that uses this page size)

Interestingly more expensive cards are outperformed by cheaper ones (the EVOs show a better overall performance compared to the Samsung Pro since sequential speeds are limited by the interface)

One extreme example: Using an identical cloned installation that was somewhat outdated on the small 4GB Intenso card and on the 64GB EVO resulted in the following times for an 'apt-get upgrade' (+200 packages): EVO less than 6 minutes vs. 390 minutes (yes, ~6.5 hours) with the Intenso. The time to finish depends largely on fast random writes.

It's easy to test the card in question when running Armbian since we ship with iozone. Therefore simply execute the iozone call from the first paragraph after logging in as a normal user. Starting with Armbian 5.06 a even better method exists that also tests the whole card for errors: armbianmonitor -c will report precisely both performance and health state of your card

the last documented results on an orange pi one H3 running at 1.2ghz is 2389.49Mflops ~ 2.39Gflops

the sources attached is 'optimised', the means of optimization is unrolling of the innermost loop to take advantage of platforms that could do quad sp fp simultaneous execute

i think those neon enabled platforms would be able to do that. the other optimization is that it spawn off 4 threads so that it could utilise 4 simultaneous threads for the matrix multiplication

could try to run this and let us know what is the 'mflops' you get on your sbc? what is the sbc , the soc and the frequency it is running at?

note that this is not necessarily the most optimised for your sbc / soc

the parameters you could try to tune includes the THREADS_NUMBER for the number of concurrent threads in the source code

in addition those who have more powerful soc could try to unroll the loops further, e.g. try to compile with additional options like -funroll-loops or even -funroll-all-loops

you could also manually update the codes e.g. to double the set of manually unrolled codes in the loop so that it become 8 sets of computations instead of 4, but you would need to review the codes such as using MATRIX_SIZE/8; i+= 8 in in the loop if you unroll the loop into 8 sets of variables, you'd need to update the summation after the loop as well result.elements[row][col] = r1+r2+r3+r4; to add the other r variables that you unrolled into

the original 'unoptimised' codes can be found in references in the original post.

strictly speaking this is not really a good test of computational prowess unlike those of linpack etc. linpack actually solves a matrix, and this is purely a square matrix multiply.

in addition, this does not explicitly use neon etc and those usage depends on the compiler optimization (i think gcc / g++ has a build in vectorizer, hence you may like to experiment with the options)

but nevertheless seeing mflops, gflops is fun, mflops, gflops is also normally a function of the frequency the core executes at, hence you could try to overclock your soc to get more gflops

]]>8287Tue, 25 Sep 2018 00:11:31 +0000ZFS on Armbianhttps://forum.armbian.com/topic/5172-zfs-on-armbian/
Not just after Oracle killed Solaris few weeks ago the question arose how to continue with ZFS (me being an absolute ZFS fanboi). After reading ZoL (ZFS on Linux) 0.7 release notes it was just a matter of time to give it a try. On an energy efficient x64 board supporting Intel's QuickAssist (QTA) and also on the most appropriate ARM platform we support for these use cases: Clearfog Pro or Helios4 soon. Release notes state to implement a lot of performance improvements (check the performance section above yourself) so let's give it a try:

Getting ZFS to work is basically the following: After booting the OMV image ('next' images from dl.armbian.com might work too -- not tested) install headers and kernel package from last link above (you'll be then on kernel 4.12.13), then run armbian-config --> Armbian --> 'Hold -- Freeze kernel and board support packages' to prevent up-/downgrading kernel with 'apt upgrade'. And then simply follow https://github.com/zfsonlinux/zfs/wiki/Building-ZFS

Then follow the instructions above. I did in both directories also a 'make install' and finally executed 'ldconfig' to get the libraries that are installed below /usr/local/lib/ working (see here for details). A final 'echo zfs >> /etc/modules' followed by a reboot and ZFS is ready:

These are 3 different 120 GB SSDs (SMART output for all of them) as RAIDZ behind 3 different SATA controllers (Transcend in M.2 slot served by Armada 38x directly, Samsung EVO840 attached to an ASM1062 and the Intel 540 behind a Marvell 88SE9215). Armbianmonitor -u: http://sprunge.us/CUHS

Focus of the following tests/research is performance and reliability since it's just a shame that in 2017 users still want to use mdraid/RAID5. A first quick test with 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' failed, without the '-I' iozone is running but results are discouraging (as expected):

The second Picture is only for orientation on an Orangepi PC, the red Wire is 5V ! Be aware that the Header is rotated by 180Â°on the One!

ThatÂ´s all .

Regards

]]>759Mon, 29 Feb 2016 14:19:41 +0000Debian-installer for OrangePi Zero/R1 Buster/Sidhttps://forum.armbian.com/topic/8418-debian-installer-for-orangepi-zeror1-bustersid/
There is no official sdcard image but the attached script will create a image for the OrangePi Zero/R1. It uses daily generated files from Debian daily-images and considered testing/unstable.

SDcard image creation:
You will need basic Linux/Debian and dosfs utils. No su/root needed. Run the script to generate sdcard image for writing to sdcard. Optionally, if you want ssh network-console access, add preseed.cfg to same directory as script. See attached preseed.cfg and example-preseed.txt.

Basic installation:
Once the installer is started, it runs completely in RAM and no longer needs files from the sdcard. You can delete all partitions on the sdcard and install Debian. Guided partitioning is recommended. When using ssh network-console installer, allow time for the installer to download files before logging in using ssh installer@IPAddress.

Basic SDcard image script guide:
Two parts are needed, the device-specific firmware.img.gz and partition.img.gz. Concatenate both to get full sdcard image. There is no firmware for the Zero/R1 but can easily be created by using gen-hd-image and extracted u-boot binary from deb file. For more info, see attached opz-sd-gen.sh script and wiki.debian.org.

Notice:
Posted for anyone interested in testing and experimental purposes.

]]>7395Tue, 05 Jun 2018 09:19:24 +0000Wi-Fi performance and known issues on SBChttps://forum.armbian.com/topic/3739-wi-fi-performance-and-known-issues-on-sbc/
As already done with other topics this will be the start of a new thread collecting more information over time.

Since we had a lot of annoying discussions recently regarding Wi-Fi on Orange Pi Zero and in general I thought let's give it a try a few days ago. I did some preparations in the meantime (monitoring 24/7 Wi-Fi throughput in 2.4 GHz band for example) and then started to test in a not too crowded environment here.

As a start some quick Wi-Fi tests with a random 'quality' USB Wi-Fi dongle and 3 different Wi-Fi chipsets that can be found an a few boards Armbian supports:

RTL8192CU (used on a lot of cheap USB dongles and even on Lamobo R1)

Ampak AP6212 (based on Broadcom's BCM43438 module also used on RPi 3 and Zero W, nearly all Wi-Fi equipped NanoPi and Banana Pi)

RealTek RTL8723BS (used on Pine64+ and on CHIP for example)

RealTek 8189FTV (used on the more recent Wi-Fi equipped Orange Pi)

The usual Wi-Fi performance 'benchmark' results available here and there most of the time ignore a lot of important bits, eg.

Environment (Wi-Fi means shared media so in crowded areas with a lot of other Wi-Fis around you fight for free slots on the media, even USB3 peripherals or microwave ovens happily interfere with your Wi-Fi performance)

Environment (yeah, again: This time aerial/antenna used, position of antenna in relation to AP, distance, free sight or not, walls/stuff that filter or reflect signals)

Settings (Wi-Fi powermanagement enabled or not? Which cpufreq governor used? Performance results can vary based on at which clockspeed CPU cores run)

So for the test I chose to let all boards run with performance governor and Wi-Fi powermanagement disabled. All are equipped with the same el cheapo Xunlong aerial (sent with all Orange Pi that are Wi-Fi capable). Position of antenna is always the same, distance from AP (Fritzbox 7390) to board approx 50 cm, AP in cabinet (20mm MDF). Almost same environmental conditions (due to some testing delays I could not guarantee that Wi-Fi channel utilization was always the same but since I let a constant iperf3 monitoring run for the last couple of days I chose time slots where maximum throughput seemed to be possible).

Also no Ethernet connected (since it's easy to f*ck up performance tests in this scenario when wired and wireless interfaces of both device and router/AP are somehow all connected since some kernels then send packets over the wrong interface) and Wi-Fi connection established the usual way (nmtui --> 'Activate connection' --> done) with /etc/network/interfaces being empty (to let network-manager control all devices for smooth networking).

The test setup is stupid for any real world consideration (if distance between device and AP is just 50 cm then use a cable instead! ) But this set of tests was about identifying the maximum you can get under perfect or at least pretty good conditions (no interference, rather good signal/noise ratio and so on)

The only reason the TP-Link Wi-Fi dongle could outperform the onboard Wi-Fi chips is called MIMO. This is available with 802.11n and makes use of more than one antenna (2 in this dongle's case). Now we're talking about 130 Mbps bit rate resulting in almost 80 Mbit/sec TCP/IP throughput

Next steps:

Let's have a look how worse environmental conditions affect performance. This means increasing distance between AP and device, put a few walls in between, use a more crappy antenna. To save some time I will continue the testing solely with the TP-Link Wi-Fi dongle (connected to the ODROID but here the board doesn't matter at all, it's just about the driver variant/version used) and Orange Pi Lite since this is the cheapest 'general purpose Wi-Fi' enabled board Armbian supports and the same chip is also used on OPi PC Plus and OPi Plus 2E (which are both also priced very competitively for their feature set).

But I will add also results from Raspberry Zero W if this board ever arrives (if not I'll take RPi 3 instead, both use same BCM43438 chip that is also contained in Ampak's AP6212 which is the solution present on most Wi-Fi enabled Armbian boards)

]]>3739Tue, 07 Mar 2017 17:23:11 +0000(Serial) console access via 'USB-UART/Gadget mode' on Linux/Windows/OSXhttps://forum.armbian.com/topic/8237-serial-console-access-via-usb-uartgadget-mode-on-linuxwindowsosx/
Access to a console can be mandatory when you SBC doesn't work as expected (e.g Network or HDMI output doesn't work). When SSH/Display access isn't possible access to console via UART is the best way to get a clue where your SBC hangs. This short tutorial should give you an introduction how this works. For some boards, armbian implements an USB gadget mode (a 'fake' serial console over microUSB) describen below. As a reminder an USB-UART bridge is always prefered over USB gadget mode whenever possible (UART get's initialized before the gadget driver and also before HDMI, means even if you don't get a proper output from HDMI or gadget mode console, it is possible that UART will give you the needed information).

Prerequisites:

We need an Terminal program to access the console. If you use Linux on your host system I prefer picocom (something like minicom will also do the job) which can be installed:

There are various USB-UART bridges e.g FT232 (and fakes of them, cause FDTI is expensive ), CH340/1,PL2303 or CP2102

Normally it doesn't matter which one you use. I prefer the (probably fake) FDTI on the right side, but the CH341 does also a good job:

The only thing which is needed is that the signal-level matches with your SBCs needs (this is mostly 3.3V expect some Odroids e.g HC1 which has only 1.8V!). Most of these USB-UART bridges have jumpers for 5V and 3.3V, make sure that you use the 3.3V.

You've to figure out which pins on your SBC are debug UART (they've mostly a own 3 pin header, sometimes it's on the large pin header e.g. Tinkerboard) and then connect:

GND --> GND
RX --> TX
TX --> RX

You've to check dmesg (linux) or run devmgmt.msc (windows) to know which device you use.

Open the Device Manager window by right-clicking the Windows 10start button in the lower left of the screen and then selecting Device Manager on the menu that pops up. In Device Manager, expandPorts (COM & LPT) and you should see a COM port which will be your Arduino as shown in the image below.

Something like the picture in USB Gadget Mode part of the tutorial should show up)

Armbians default settings are (expect some RK devices):

For Picocom:

picocom -b 115200 -r -l /dev/ttyUSB0

and for some RK devices:

picocom -b 1500000 -r -l /dev/ttyUSB0

For PuTTY:

You've to set configuration in 'Serial'. COM11 is just an example and needs to be checked first, Speed (baud) needs to be changed when you deal with the few RK boards which need 1500000.

Normally you connect the USB-UART bridge to your host computer (and the SBC) and start picocom/putty before you power the board to ensure you get the full bootlog and not only parts of it.

USB Gadget Mode

Several board (see list) for which official armbian images exist (or csc images can be built) have no HDMI display. On those boards there's USB gadget mode driver activated so that you can have console access to them via USB connection. The following short tutorial describes how you can access to console from Linux (don't have a windows machine here at the moment, I may check it later):

install picocom

connect your board via USB to your host computer (it should be one which is able to power an SBC via its USB port)

I assume if you use the same settings in something like putty on windows and you check which 'serial' device shows up in *where windows shows connected devices - I forgot it* you should be able to access it from windows (someone motivated may confirm this).

For Windows:

run devmgmt.msc and search for the serial device (in this case COM3) and connect to it via PuTTY (thanks to @hjc):

Open the Device Manager window by right-clicking the Windows 10start button in the lower left of the screen and then selecting Device Manager on the menu that pops up. In Device Manager, expandPorts (COM & LPT) and you should see a COM port which will be your Arduino as shown in the image below.

(even the tutorial is for arduinos, it should be similar for every 'COM device')

Currently boards with USB gadget mode:

bananapim2plus

bananapim2zero

nanopifire3

nanopim3

nanopineo2

nanopineocore2

nanopineoplus2

orangepizeroplus

nanopiair

nanopiduo

nanopineo

olimex-som204-a20

orangepilite

orangepi-r1

orangepizero

orangepizeroplus2-h3

orangepizeroplus2-h5

tritium-h3

The silly approach

For those, who want to save 1$ for an USB-UART bridge, you can spend 10$ for an OrangePi Zero and use its spare UARTs to log into an other SBC... SSH --> opi, ttl --> Tinkerboard

For those loving text more than videos:

SSH to your SBC

sudo armbian-config --> system --> hardware to activate an spare UART (in this case it was UART2, will give you ttyS2)

]]>8237Wed, 19 Sep 2018 12:13:04 +0000Swap on SBChttps://forum.armbian.com/topic/8161-swap-on-sbc/
This is some more research based on prior efforts.

The goal is to make more efficient use of available RAM. If the system runs low on memory only two options are possible: either the kernel invokes the oom-killer to quit tasks to free memory (oom --> out of memory) or starting to swap.

Swap is a problem if it happens on slow media. 'Slow' media usually describes the situation on SBC. 'Average' SD cards (not A1 rated) are slow as hell when it's about random IO performance. So swapping is usually something that should be avoided. But... technology improves over time.

In Linux we're able to swap not only to physical storage but since a few years also to compressed memory. If you want to get the details simply do a web search for zram or check Wikipedia first..

Test setup is a NanoPC-T4 equipped with 4 GB RAM (RK3399 based so a big.LITTLE design with 2xA72 and 4xA53). I crippled the board down to being a quad-core A53 running at 800 MHz where I can easily switch between 4GB RAM and lower numbers: Adding 'mem=1110M maxcpus=4' to kernel cmdline results in the A72 cores being inactive, the kernel only using 1 GB DRAM and for whatever reasons cpufreq scaling not working so the RK3399 statically being clocked at 808 MHz. All tests done with RK's 4.4 (4.4.152).

This test setup is meant as 'worst case possible'. A quad-core A53 at 800 MHz is more or less equivalent to a quad-core A7 running at ~1000-1100 MHz. So we're trying to test with the lower limit.

I used a compile job that requires up to 2.6 GB RAM to be built (based on this blog post). The task is to build ARM's Compute Library which involves swapping on systems with less than 3 GB memory. Let's have a look:

In the following I tried a couple of different scenarios: Swap on physical media and also two different zram algorithms:

w/o: no swapping happened since board booted with full 4GB RAM active

nvme: Transcend TS128GMTE110S SSD in M.2 slot, link is established at x4 Gen2

You need to look at the 1st row: that's the time the whole job took. For more details consult the 'time' manual page.

In other words: When limiting the RK3399 on NanoPC-T4 to just the four A53 cores running at 800 MHz the compile job takes 100 minutes with 4 GB RAM. As soon as we limit the available RAM to 1 GB swapping has to occur so it gets interesting how efficient the various approaches are:

NVMe SSD is the fastest option. Performance drop only 18%. That's due to NVMe being a modern storage protocol suited for modern (multi-core) CPUs. Problem: there's no PCIe and therefore no NVMe on the majority of SBC

Zram with both lzo and lz4 algorithms performs more or less the same (interestingly lzo slightly faster)

Using a HDD for swap is BS (and was BS already the last 4 decades but we had no alternative until SSDs appeared). The compile job needs almost 5 times longer to complete since all HDD suck at random IO

Using an average SD card for swap is just horrible. The job that finished within 100 minutes with 4 GB DRAM available took over 19 HOURS with swap on an average SD card (please note that today usual A1 rated SD cards are magnitudes faster and easily outperform HDDs)

Summarizing: NVMe SSDs are no general option (since only available on some RK3399 boards). Swap on HDD or SD card is insane. Swap on USB connected SSDs performs ok-ish (~1.5 times slower) so the best option is to use compressed DRAM. We get a performance drop of just 25% at no additional cost. That's amazing.

The above numbers were 'worst case'. That's why I crippled the RK3399 to a slow performing quad-core A53. You get the idea how 'worse' zram might be on the slowest SBCs Armbian runs on (I know that there are still the boring Allwinner A20 boards around -- yep, they're too slow for this).

When I did all this boring test stuff I always recorded the environment using 'iostat 1800' (reports every 30 minutes what really happened and shows in detail how much data has been transferred and on which the CPU cores spent time). Quite interesting to compare %user, %sys and especially %iowait percentages:

]]>8161Sun, 09 Sep 2018 21:59:38 +0000SD communication electrical considerationshttps://forum.armbian.com/topic/8153-sd-communication-electrical-considerations/*** This is educational material only concerning current limits and their effects on things like rise and fall times, and how they can theoretically impact SD cards. The correlation with reality is purely theoretical and has not been empirically proven, the concept is correct but any specific values may be/ probably are off by some factor***

A lot of boards from various vendors inevitably have some difficulties with electrical signalling. You see it in delay values, phase correction in software, etc. The general prevailing theory is almost always "get it close and fix it in software". But, the software team is not always clued in, or the physical reality is simply not able to be fixed that way. Today I'll go into SD cards and the need for proper signal paths, limited capacitance along the way, and proper drive levels at the SoC.

This came to my attention while reviewing failures to boot on RK3328 devices, and while this particular issue may still be independent (no root cause confirmed as yet), I have a suspicion it is at least a contributing factor.

GPIO's on SoC's have, typically, current limiting on each pin or bank of pins. For Rockchip, this limit defaults to 4mA, with 8 and 12 being available as optional settings. This includes the SD card bus, clock, output, etc. These current limits are exactly that, limits. If the interface only needs 1 mA, it will only pull 1 mA, regardless of the GPIO drive setting. if it needs more, however, it will only get what the drive setting allows.

SD card interface standards have 3 voltage signalling modes, SBC's only make use of 1 or 2 of them. Many boards supply only 3.3V to the card, limiting to frequencies of 25 or 50 MHz. Those that support UHS-I modes allow 1.8V signalling, and the range of speeds there include the original 25 and 50 MHz, but add higher speeds as well (100 and 208). The higher speeds absolutely require the lower voltage, though the 25 and 50 Mhz speeds benefit from it as well due to improvements in rise/fall time with the smaller voltage transitions.

The SD standard requires a total line capacitance of 40 pF or less on each line, including the internals of the card. I will simply assume 40 pF for the simulations, as it's likely few if any of these boards are "optimal" in that regard.

I'll be using LTSpice as an aid to show the effects of the current limitations, measuring voltage across the capacitance. In reality there would be a complex impedance with the resistance I'm not modelling and the capacitance distributed throughout the system, which would cause some slightly different behavior. This is mostly an educational introduction to the scary universe of high-frequency switching, so I'll skip the really gory details for the sake of readability. In this circuit the LimiterDiode does exactly that, it limits current.

With a 4 mA limit into a 40 pF load at 3.3 Volts, 50 MHz, the signal is unusable. Top in blue is the current sourced by the supply, stuck at the 4 mA limit at all times, below in red is the desired waveform, in green the result.

The board will crash if it attempts this. Now, you might say, what if the board is extremely well made and the capacitance is lower?

Well, it looks like this (assuming 20 pF, which may not really be possible):

Still, no hope of operating properly. Dropping to 25 MHz has roughly the same effect. As I said, this is worst case, so don't jump down my throat about your board with the limits working at 4mA. I am also assuming 4 mA source and sink limits, it may not be symmetrical, in which case the shape goes from triangle to shark fin. Cutting the voltage almost in half by going to UHS-I signalling levels has the same effect (ratio wise vs the V_High value) as cutting the capacitance down.

On the ASUS tinker board this was discovered at some point, and the current limits increased to 8 mA. I have not tried a card with no UHS support at 50 MHz (at least to my knowledge), the results at 3.3V/50MHz still look bad in my oversimplification, much like cutting voltage in half or capacitance or frequency, again, they all play into the same charge rate/time constant

At 25 MHz, however, 8 mA is far more reasonable:

Now to the big reason for 1.8 V signalling:

50 MHz, 1.8V, 40 pF, 8 mA drive.

Assumptions: source/sink values both controlled. It's possible this is not the case. If there is no "sink" limit, or if you assume 20 mA sink limit:

3.3V signalling, 50 MHz, 40 pF load, 8 mA source, 20 mA sink:

Now, as a final bit, assume there were no current limits of any kind, and let's measure what the system would need to supply at 50 MHz 3.3V:

So 120 mA or so to create the exact waveform, assuming some sort of simulated resistance somewhere in the system (in reality there would be a measurable resistance and therefor a current lower than 120, but also a longer rise and fall time) Needless to say, a lot more than 4.

This is mostly important for boards that do not implement the 1.8V signalling modes, but do have aggressive current limiting on the SD card I/O's. 50 MHz is a bad place to live at 3.3 volts given a mechanical connector with wide flat terminals, and routing that doesn't always get as much care as maybe it deserves. RPI, a board with these issues, seems able to source/sink 16 mA, most likely accounting for it's ability (when not starving itself for power, cooking itself, etc) to be "overclocked" in highspeed 3.3V mode. Rockchip can only push 12 mA, I haven't read up on Amlogic yet, so you can't expect to have the same performance if you're not willing to add the necessary support for 1.8V signalling.

]]>8153Sat, 08 Sep 2018 20:08:28 +0000Orange Pi One - adding USB, analog audio out, TV out, mic and IR receiverhttps://forum.armbian.com/topic/755-orange-pi-one-adding-usb-analog-audio-out-tv-out-mic-and-ir-receiver/
Orange Pi One PCB is designed to easy add almost all removed features from Orange Pi PC. Currently only RAM expansion is unprofitable.

To add 2 removed USB ports just solder wires to solder points as shown below on the photo:

Data lines for USB #3: points 1,2

Data lines for USB #2: points 3,4

Power can be taken directly from GPIO header or DC socket. OPiOne has no separate voltage regulators for USB ports like previous boards used to have.

This way I want to solder mini WiFi dongle (after removing the case and USB port) directly to the PCB.

]]>755Sun, 28 Feb 2016 17:35:26 +0000Benchmarking CPUs (not yet a research article)https://forum.armbian.com/topic/7776-benchmarking-cpus-not-yet-a-research-article/
With this commit I added 7-zip benchmark reporting to Armbian now. Will be available after next updates and with next batch of new images.

Why not recommending to just do an 'apt install p7zip ; 7zr b'? Since 'fire and forget' benchmarking is always BS. You need some monitoring in parallel to know whether your system was really idle and at which clockspeeds the CPU cores were operating (throttling occuring or not?).

Most recent 7-zip contains an own routine to 'pre-heat' the system prior to starting the benchmark (to let cpufreq scaling switch from low clockspeeds to highest ones and e.g. on Intel systems let the system enter TurboBoost modes). This 7-zip code runs single threaded so based on the kernel's scheduler sometimes ending up on the 'wrong' CPU core (e.g. a little core on big.LITTLE SoCs)

On a NanoPC T4 with conservative settings (limiting big CPU cores to 1.8 GHz and little cores to 1.4 GHz) this looks like this:

We get an overall score of above 6100 and 7-zip's 'CPU Freq' line reports CPU0 (a little core) being clocked at 1.4 GHz. But since this is a big.LITTLE design we need the monitoring output that gets displayed below 7-zip benchmark numbers.

By looking at the 2nd line we see that the system was totally idle prior to starting the benchmark (I implemented a 10 second sleep between starting monitoring and firing up the benchmark for this reason -- to control whether the system was already busy or not). As a comparison 7-zip numbers of another RK3399 board that allowed the CPU cores to clock slightly higher (2.0/1.5 GHz): ODROID-N1 scored 6500.

Please keep in mind that benchmarks that run fully multi threaded are NOT representative for most workloads running on computers (they're single threaded). Also please keep in mind that while 7-zip is not that much affected by different compiler settings (like the infamous sysbench) of course it is somewhat. So when you see 7-zip benchmark numbers generated few years ago when the 7z binary has been built with a GCC 4.x most probably with today's software and a binary built by GCC 7.x you see higher scores.

]]>7776Sun, 22 Jul 2018 10:28:19 +0000Kerberos.io video surveillance installation on Armbianhttps://forum.armbian.com/topic/3303-kerberosio-video-surveillance-installation-on-armbian/UPDATE 11-FEB-2017: Version 2.2.0 is released: now including video recording in stead of only images and also a privacy option to black out areas that may not be filmed.

UPDATE 09-FEB-2017: Version 2.2.1 is released: memory leak(s) fixed and in some cases video stopped recording. This should be fixed now. Download via this page.

Kerberos.io (link) is a relative new video surveillance program focusing mainly on the Raspberry Pi. In collaboration with the owner of the github project I managed to get it working on my Orange Pi Plus and PCDuino3 nano using Armbian (Debian Jessie) and a Logitech UVC compatible USB webcam. It consists of 2 modules: the Machinery module and Web module. The machinery module was very Raspberry Pi specific, but is now updated and can also run with very little extra effort on Armbian. The Web module runs without any modification.

Follow the instructions below and you should be able to install or compile it. Kerberos.io is very fast and has a modern interface. Furthermore it is (IMHO) a very nice alternative for zoneminder and motion.It also provides a videostream on a webpage.

Follow the instructions below and share your comments, ideas etc.

Method 1 (easy) - Install on Armbian Debian Jessie.

Follow the instructions on the dedicated Armbian page (link). Here you will find an Armbian precompiled .deb armhf package. Further installation / configuration options can be found on the Kerberios.io webpages.

This tutorial provides detailed, step-by-step instructions for setting up full root filesystem encryption on an Armbian/Orange Pi PC2 system. With minor changes, it can be adapted to other Armbian-supported boards. The disk is unlocked remotely via ssh, permitting unattended bootup.

Requirements:

Linux host system

One Orange Pi PC 2

Two blank Micro-SD cards

USB Micro-SD card reader

Ability to edit text files and do simple administrative tasks on the Linux command line

Now you're ready to copy Armbian to the SD cards. Note that for the remainder of this section, the first SD card will be referred to as '/dev/sdX' and the second as '/dev/sdY'. You'll replace these with the SD cards' true device filenames. The device names can be discovered using the command 'dmesg' or 'lsblk'. If you remove the first card before inserting the second, it's possible (but not guaranteed) that the cards will have the same device name.

The first SD card will hold an ordinary unencrypted Armbian system used for the setup process. Insert the card and copy the image to it:

$ sudo dd if=$(echo *.img) of=/dev/sdX bs=4M

After the command exits, you may remove the first SD card.

Now insert the second SD card, which will hold a small unencrypted boot partition plus your encrypted Armbian system. Copy the image's boot loader to it:

$ sudo dd if=$(echo *.img) of=/dev/sdY bs=512 count=4096

Now partition the second SD card:

$ sudo fdisk /dev/sdY

Within fdisk, create a new DOS disklabel with 'o' command. Use the 'n' command to create a primary partition of size +100M beginning at sector 4096. Type 'p' to view the partition table. Note the end sector. Now create a second primary partition beginning one sector after the first partition's end sector and filling the remainder of the card. When you're finished, your partition table will look something like this:

Create the encrypted root partition (for this the 'cryptsetup' package must be installed on the host). You'll be prompted for a passphrase. It's recommended to choose an easy one like 'abc' for now. The passphrase can easily be changed later (consult the 'cryptsetup' man page for details):

$ sudo cryptsetup luksFormat /dev/sdY2

Activate the encrypted root partition, create a filesystem on it and mount it:

Insert the first (unencrypted) SD card into the Pi's Micro-SD card slot. Insert the USB card reader with the second SD card inserted into a USB port on the Pi. Boot the Pi, log in as root with password '1234' and follow the password update instructions. Stay logged in as root.

Add the following lines to '/etc/initramfs-tools/initramfs.conf'. If the Orange Pi's IP address will be statically configured, substitute the correct static IP address after 'IP='. If it will be configured via DHCP, omit the IP line entirely:

Swap the SD cards and start the Pi. Unlock the disk by executing the following command on your remote machine. Substitute the Pi's correct static or DHCP-configured IP address for the one below. If necessary, also substitute the correct password in place of 'abc':

If you choose to unlock the disk from the tty, ignore the garbage printed by dropbear to the screen after the password prompt. Just enter your password and hit ENTER.

If all went well, your root-filesystem encrypted Armbian system is now up and running!

]]>4174Tue, 02 May 2017 12:00:06 +0000Clone/backup bootable microsd card - make as small as possible imagehttps://forum.armbian.com/topic/5513-clonebackup-bootable-microsd-card-make-as-small-as-possible-image/
Hi there, this very short tutorial is a solution when you need to backup/clone/save as small *.img file as possible of your whole fully bootable system (e.g. you have 8GB card but you want to make smaller system image for 2GB card). And another reason why I created this tutorial - I need to burn the same image to many microsd cards.

I am using Windows (yup, hate me know) and Debian in these steps:

Put your microsd card to Windows machine and make image of card with Win32diskimager. If your card is e.g. 8GB, you get *.img file with the same size (my name backup.img).

Now in linux maxine (in my case Debian virtual machine) we are going to work with backup.img file.

Run these commands in terminal (if you are not root use sudo at the start of each line)

Run gparted with this command and move slider of main partition to the left to make partition smaller (leave some space, e.g. I left 400MB free space)

gparted /dev/loop0

Click on Apply once you are happy with it.

We can unload loopback device now

losetup -d /dev/loop0

With fdisk find out end of last block

fdisk -l backup.img

In my case last block is 3571711 so I run command

truncate --size=$[(3571711+1)*512] backup.img

Done! Size of your backup.img file should be now about 1.5GB.

You can burn this new backup.img file to another (or the same) card/s now. In my case I dramatically reduced time needed for burning data to many many cards (it saves hours/days when you need to burn a lot of microsd cards). Enjoy!

P.S. this can be done also with just Debian, so no need for Windows, in this case you just need to make first step with backup.img with linux command (e.g. dd). And of course you can set up a script on your newly burned card to expand system partition to the whole microsd size during first boot, if needed.

Attention!
Kernel version 4.14.XX still had problems with the shutdown.
When the patches were made for the LCD, the board did not shut down completely during a shutdown (LCD still had voltage and the red LED on the board did not go out).

With the kernel 4.17.XX (4.17.13) the problem is solved.

Furthermore, with this kernel version the kworker problem (kworker needs 10% CPU) is solved.

Now we could use a switch connected to a GPIO-IN to control the backlight.

Steffen

]]>7233Tue, 15 May 2018 19:19:51 +0000Some storage benchmarks on SBCshttps://forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/
Since I've seen some really weird disk/IO benchmarks made on SBCs the last days and both a new SBC and a new SSD arrived in the meantime I thought let's give it a try with a slightly better test setup.

I tested with 4 different SoC/SBC: NanoPi M3 with an octa-core S5P6818 Samsung/Nexell SoC, ODROID-C2 featuring a quad-core Amlogic S905, Orange Pi PC with a quad-core Allwinner H3 and an old Banana Pi Pro with a dual-core A20. The device considered the slowest (dual-core A20 with just 960 MHz clockspeed) is the fastest in reality when it's about disk IO.

Since most if not all storage 'benchmarks' for SBC moronically focus on sequential transfer speeds only and completely forget that random IO is way more important on any SBC (it's not a digital camera or video recorder!) I tested this also. Since it's also somewhat moronically when you want to test the storage implementation of a computer to choose a disk that is limited the main test device is a brand new Samsung SSD 750 EVO 120GB I tested first on a PC whether the SSD is ok and to get a baseline what to expect.

Since NanoPi M3, ODROID-C2 and Orange Pi PC only feature USB 2.0 I tested with 2 different USB enclosures that are known to be USB Attached SCSI (UAS) capable. The nice thing with UAS is that while it's an optional USB feature that came together with USB 3.0 we can use it with more recent sunxi SoCs also when running mainline kernel (A20, H3, A64 -- all only USB 2.0 capable).

When clicking on the link you can also see how different USB enclosures (to be more precise: the included USB-to-SATA bridges used) perform. Keep that in mind when you see 'disk performance' numbers somewhere and people write SBC A would be 2MB/s faster than SBC B -- for the variation in numbers not only the SBC might be responsible but this is for sure also influenced by both the disk used and enclosure / USB-SATA bridge inside! The same applies to the kernel the SBC is running. So never trust in any numbers you find on the internet that are the results of tests at different times, with different disks or different enclosures. The numbers presented are just BS.

The two enclosures I tested with are equipped with JMicron JMS567 and ASMedia ASM1153. With sunxi SBCs running mainline kernel UAS will be used, with other SoCs/SBC or running legacy kernels it will be USB Mass Storage instead. Banana Pi Pro is an exception since its SoC features true SATA (with limited sequential write speeds) which will outperform every USB implementation. And I also used a rather fast SD card and also a normal HDD with this device connected to USB with a non UASP capable disk enclosure to show how badly this affects the important performance factors (again: random IO!)

The variation in results is interesting. If 4K results between 1 and 100 MB test size differ you know that your benchmark is not testing disk througput but instead the (pretty small) disk cache. Using 4GB for sequential transfer speeds ensures that the whole amount of data exceeds DRAM size.

The results:

NanoPi M3 @ 1400 MHz / 3.4.39-s5p6818 / jessie / USB Mass Storage:

Sequential transfer speeds with USB: 30MB/s with 1MB record size and just 7.5MB/s at 4K/100MB, lowest random IO numbers of all. All USB ports are behind an USB hub and it's already known that performance on the USB OTG port is higher. Unfortunately my SSD with both enclosures prevented negotiating an USB connection on the OTG port since each time I connected the SSD the following happened: WARN::dwc_otg_hcd_hub_control:2544: Overcurrent change detected )

Sequential transfer speeds with USB: ~40MB/s with 1MB record size and ~9MB/s at 4K/100MB, best random IO with very small files. All USB ports are independant (just like on Orange Pi Plus 2E where identical results will be achieved since same SoC and same settings when running Armbian)

This test setup is totally different since the SSD will be connected through SATA and I use a normal HDD in an UAS incapable disk enclosure to show how huge the performance differences are.

SATA sequential transfer speeds are unbalanced for still unknown reasons: write/read ~40/170MB/s with 1MB record size, 16/44MB/s with 4K/100MB (that's huge compared to all the USB numbers above!). Best random IO numbers (magnitudes faster since no USB-to-SATA bottleneck as with every USB disk is present).

The HDD test shows the worst numbers: Just 29MB/s sequential speeds at 1MB record size and only ~5MB/s with 4K/100MB. Also the huge difference between the tests with 1MB vs. 100MB data size with 4K record size shows clearly that with 1MB test size only the HDD's internal DRAM cache has been tested (no disk involved): this was not a disk test but a disk cache test only.

HDDs are slow. Even that slow that they are the bottleneck and invalidate every performance test when you want to test the performance of the host (the SBC in question)

With HDDs data size matters since you get different results depending on whether the benchmark runs inside the HDD's internal caches or not. SSDs behave here differently since they do not contain ultra-slow rotating platters but their different types of internal storage (DRAM cache and flash) do not perform that different

When you have both USB and SATA not using the latter is almost all the time simply stupid (even if sequential write performance looks identical. Sequential read speeds are way higher, random IO will always be superiour and this is more important)

It always depends on the use case in question. Imagine you want to set up a lightweight web server dealing with static contents on any SBC that features only USB. Most of the accessed files are rather small especially when you configure your web server to deliver all content already pre-compressed. So if you compare random reads with 4k and 16k record size and 100MB data size you'll notice that a good SD card will perform magnitudes faster! For small files (4k) it's ~110 IOPS (447 KB/s) vs. 1950 IOPS (7812 KB/s) so SD card is ~18 times faster, for 16k size it's ~110 IOPS (1716 KB/s) vs. 830 IOPS (13329 KB/s) so SD card is still 7.5 times faster than USB disk. File size has to reach 512K to let USB disk perform as good as the SD card! Please note that I used a Samsung Pro 64GB for this test. The cheaper EVO/EVO+ with 32 and 64GB show identical sequential transfer speeds while being a lot faster when it's about random IO with small files. So you save money and get better performance by choosing the cards that look worse by specs!

Record size always matters. Most fs accesses on an SBC are not large data that will be streamed but small chunks of randomly read/written data. Therefore check random IO results with small record sizes since this is important and have a look at the comparison of 1MB vs. 100 MB data size to get the idea when you're only testing your disk's caches and when your disk in reality.

If you compare random IO numbers from crap SD cards (Kingston, noname, Verbatim, noname, PNY, noname, Intenso, noname and so on) with the results above then even the slow HDD connected through USB can shine. But better SD cards exist and some pretty fast eMMC implementations on some boards (ODROID-C2 being the best performer here). By comparing with the SSD results you get the idea how to improve performance when your workload depends on that (desktop Linux, web server, database server). Even a simple 'apt-get upgrade' when done after months without upgrades heavily depends on fast random IO (especially writes).

So by relying on the usual bullshit benchmarks only showing sequential transfer speeds a HDD (30 MB/s) and a SD card (23 MB/s) seem to perform nearly identical while in reality the way more important random IO performance might differ a lot. And this solely depends on the SD card you bought and not on the SBC you use! For many server use cases when small file accesses happen good SD cards or eMMC will be magnitudes faster than HDDs (again, it's mostly about random IO and not sequential transfer speeds).

I personally used/tested SD cards that show only 37 KB/s when running the 16K random write test (some cheap Intenso crap). Compared to the same test when combining A20 with a SATA SSD this is 'just' over 800 times slower (31000 KB/s). Compared to the best performer we currently know (EVO/EVO+ with 32/64GB) this is still 325 times slower (12000 KB/s). And this speed difference (again: random IO) will be responsible for an 'apt-get upgrade' with 200 packages on the Intenso card taking hours while finishing in less than a minute on the SATA disk and in 2 minutes with the good Samsung cards given your Internet connection is fast enough.

]]>1925Tue, 30 Aug 2016 23:08:54 +0000Running H3 boards with minimal consumptionhttps://forum.armbian.com/topic/1614-running-h3-boards-with-minimal-consumption/
Since I wondered why FriendlyARM chose just 432MHz DRAM clock for their new NanoPi NEO (said to be an IoT node for lightweight stuff) and I also wondered how low consumption could be configured with a H3 device I decided to simply try it out.

Since I have no NanoPi NEO lying around (and FriendlyARM seems not to ship developer samples) I used Orange Pi Lite instead. Same amount of DRAM (but dual bank configuration therefore somewhat faster), same voltage regulator but Wi-Fi instead of Ethernet. I adjusted the fex file to stay always on the lower VDD_CPUX voltage (1.1V), disabled all unnecessary stuff (Wi-Fi, HDMI/Mali400 and so on, please see modified fex settings), also adjusted /etc/defaults/cpufreq-utils to jump between 240-912MHz cpufreq and added the following to /etc/rc.local to make H3 as slow as an RPi Zero:

With this single core setup OPi Lite remains at 800mW when idling at 912MHz, when running a 'sysbench --test=cpu --num-threads=1 --cpu-max-prime=20000 run' consumption increases by 300mW (and H3 is still a bit faster at 912MHz compared to a RPi Zero at 900 MHz: 808 seconds vs. 930 seconds). Further reducing CPU clockspeed or disabling leds doesn't help that much or at least my powermeter isn't that precise.

I find it already pretty nice to be able to limit consumption down to 160mA (800mW) by disabling 3 CPU cores (easy to bring back when needed!), downclocking DRAM and limiting VDD_CPUX voltage to 1.1V. That means that on H3 devices featuring the more flexible SY8106A voltage regulator even lower consumption values could be achieved since VDD_CPUX voltage could be lowered even more. And consumption might be reduced further by disabling more stuff. But that's something someone else with a multimeter has to test since my equipment isn't precise enough.

To sum it up: By simply tweaking software settings (most of them not even needing a reboot but accessible from user space) average idle consumption of an H3 device can be reduced from 1.5W (300mA) to almost the half. In this mode (one single CPU core active at 912MHz and DRAM downclocked to 408MHz) a H3 device is still faster than an RPi Zero while providing way more IO and network bandwidth. And if settings are chosen wisely performance can be increased a lot from userspace (transforming a single core H3 @ 912MHz to a quad-core H3 @ 1200/1296 MHz with faster DRAM which translates to roughly 6 times the performance)

]]>1614Tue, 12 Jul 2016 18:59:20 +0000OPi Zero GPS ntpserverhttps://forum.armbian.com/topic/4944-opi-zero-gps-ntpserver/
I use the OrangePi Zero. But it is similar to other model.

It's very simple:

1) use the mainline 4.11.x kernel

2) enable the uart1 and pps-gpio in /boot/armbianEnv.txt like this :

overlays=uart1 pps-gpio
param_pps_pin=PA7

3) edit /etc/default/gpsd to use ttyS1 as gps device

# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES="/dev/ttyS1"
# Other options you want to pass to gpsd
GPSD_OPTIONS="-G -n "

]]>4944Thu, 17 Aug 2017 02:30:58 +0000Motioneye (OPI)https://forum.armbian.com/topic/2168-motioneye-opi/
There have been several disjointed tutorials on making a raspberrypi or orangepi into a surveillance camera. So I threw this together to maybe help someone out there with any issues.

I used the orangepipc+ but any orangepi board should work as long as it has the basics, internet connectivity, storage, and a camera. (I highly suggest heatsinks as well)

any feedback or enhancements to this tutorial are greatly appreciated.

After having successfully followed the installation instructions, the motionEye server should be running on your system and listening on port 8765. Fire up your favorite web browser and visit the following URL (replacing [your_ip] with... well, your system's IP address):

http://[your_ip]:8765/

Use admin with empty password when prompted for credentials. For further details on how to configure motionEye, see Configuration.

In case that somebody is interested, I recently bought couple those displays from here

Few basic informations:

1. OrangePiZero has two SPI buses. First one is usually occupied by build in memory. So we can only use bus1

2. tsc2046 chip is fully compatible with ads7846, and we have drivers for it since years now

3. Maximum clock frequency for ads7846 is 3.25Mhz, but don't expect that it will work with that. Reasonable value is something beetween 0.5-2Mhz. Lower frequency, if you observing misbehavior.

4. Probably most important information ili9431 and tsc2046 poorly cooperate on shared bus. I don't know exactly why, because I don't have access to logic analyzer, but it's proven fact (at least on my equipment). You have to lower bus frequency to 2MHz (highest common value), and even then it work very unstable. My educated guess is that, missed interrupt from touchscreen (when SPI is busy with sending data to LCD) makes it stop making further attempts to communicate. Or maybe there is some incompatibility on electrical level, I really don't know.

5. My electrical setup (keep in mind it's 3.3V)

OPIZ - LCD (ili9431)

PA13 - CS

PA14 - SCK

PA16 - SDO

PA15 - SDI

PA03 - DC

PA00 - RESET

PA06 - controls transistor which is driving current to LCD pin. You may also connect LCD pin to VCC, and leave PA06 floating.

And here is part for touchscreen. We are going to use emulated spi bus with bitbang. At this point bitbang isn't compiled in armbian kernel - we will take care of this later.

]]>4845Tue, 01 Aug 2017 12:58:22 +0000h3disp: change display settings on H3 deviceshttps://forum.armbian.com/topic/752-h3disp-change-display-settings-on-h3-devices/
We included in Armbian a small utility called h3disp. If called without arguments it displays just a usage information:

tk@orangepipc:~$ sudo h3disp
[sudo] password for tk:
Usage: h3disp [-h/-H] -m [video mode] [-d] [-c [0-2]]
############################################################################
This is a tool to set the display resolution of your Orange
Pi by patching script.bin.
In case you use an HDMI-to-DVI converter please use the -d switch.
The resolution can be set using the -m switch. The following resolutions
are currently supported:
480i use "-m 480i" or "-m 0"
576i use "-m 576i" or "-m 1"
480p use "-m 480p" or "-m 2"
576p use "-m 576p" or "-m 3"
720p50 use "-m 720p50" or "-m 4"
720p60 use "-m 720p60" or "-m 5"
1080i50 use "-m 1080i50" or "-m 6"
1080i60 use "-m 1080i60" or "-m 7"
1080p24 use "-m 1080p24" or "-m 8"
1080p50 use "-m 1080p50" or "-m 9"
1080p60 use "-m 1080p60" or "-m 10"
Two examples:
'h3disp -m 1080p60 -d' (1920x1080@60Hz DVI)
'h3disp -m 720i' (1280x720@30Hz HDMI)
You can also specify the colour-range for your HDMI-display with the -c switch.
The following values for -c are currently supported:
0 -- RGB range 16-255 (Default, use "-c 0")
1 -- RGB range 0-255 (Full range, use "-c 1")
2 -- RGB range 16-235 (Limited video, "-c 2")
############################################################################

This tool tries to patch script.bin (adjusts the display settings there) and requires a reboot afterwards. While it is not useable with vanilla kernel (script.bin doesn't play any role there and a display driver is also still not ready) it might be also useful for H3 users that rely on other OS images (Debian/Ubuntu based from Xunlong or from loboris). Our h3disp tries also to patch script.bin there with your settings so it should be useful for non Armbian users too

BTW: It could also be used with Debian based Linux OS images for A83T/H8 (Cubietruck Plus, pcDuino8 Uno or Banana Pi M3) but unfortunately these vendors fail to provide OS images that use a patched u-boot version that could deal with script.bin. At least 'Team BPi' got it finally after being told since months where/how to copy&paste this stuff but since they only update their sources and provide no updates for their OS images, Banana Pi M3 customers are still lost

In case you're an Android user you'll have to go the extra mile since the Android OS image for H3 Orange Pi's doesn't support script.bin. You could apply the changes h3disp offers to one of our provided fex files but have then to overwrite a few sectors on your SD card to get this stuff working (by choosing our fex files you could also 'patch' the Android image to run better on the Orange Pi One or get all USB ports and Ethernet on the other models and improve realiability and decrease SoC temperature)

]]>752Sun, 28 Feb 2016 13:54:36 +0000Different take on armbian-confighttps://forum.armbian.com/topic/6303-different-take-on-armbian-config/
I'm familiar with the armbian-config tool and while I think its cool, it may not be the best thing for the beginner. The hardest part of beginning anything is not knowing what you don't know. I've begun writing a simple tool using curses and python which hopefully disambiguates some of the features of each board. I'm currently focusing on H3 boards, since thats what I have and I'm most familiar with them. Currently I have the ascii art and setup for the Orangepi PC, One, Zero, and Nanopi Neo.

The idea is to use the arrow keys to navigate, spacebar to select, 'b' for back, and (most importantly) 'h' for help. The help menu should have enough information to get a beginner going.

I'm currently working on the USB OTG section, and I'm trying to get all the configfs information on the internet into one place. Having the option to have any amount of USB OTG gadgets selected is really cool, and I'm not sure a lot people know about it. I'm hoping to make the configuration easy, like selecting radio buttons.

If anyone thinks this is cool (or that it sucks), let me know. Its still in development.

]]>6303Tue, 30 Jan 2018 01:12:05 +0000IoT with an OrangePi Zero: Node-Red + Mosquitto + ESP8266/NRF24l01https://forum.armbian.com/topic/4434-iot-with-an-orangepi-zero-node-red-mosquitto-esp8266nrf24l01/
For those of you who are interested in using a OPI zero as a small IoT-Server. I have some hints to get it working. It's more or less a lmgtfy How To plus some arduino code to test if it works.

Hardware:

OrangePi 0 with Armbian 5.25 connected over lan to my router

DHT11 Module on a Wemos D1 mini (a small cheap wlan MCU for ~3$ which can be programmed via the Arduino IDE)

Installation:

First of all we install node-red on the OPI. Instead of rewrite how to do that again I just give you the link who to do that: Node-Red on armbian
Second we install Mosquitto as a mqtt broker. If I have it right in mind I followed this instructable (I'm not shure, it's more than 2 weeks ago and I didn't save the link then): Mosquitto

To represent the data of our DHT sensor-node graphically we install the node red dashboard module in: /usr/lib/node_modules/
with npm i node-red-dashboard

If everything goes right you should have access to node-red via browser on port 1880:
192.168.1.xx:1880
and to the UI of dashboard:
192.168.1.xx:1880/ui/

The code is more or less a combination of the examples which comes with the PubSubClient & DHT libraries + throw away all the stuff that we don't need (I had also a version of code where the Wemos D1 mini subscribe to the mqtt broker and gets a timestamp injected from node-red which was then added to the published sensor data).
Humidity data is stored in the "hum" topic, temperature in "temp". Keep in mind that if you plan use more than one senor-node, you should name the topics properly (see: MQTT topics best practices for more information about proper topic nameing)

We can now generate our test-flow on the node-red webpage (See printscreen). Subscribe to the mqtt topics and publish it on the chart and gauge (more information about Dashboard can be found on: Node-Red & Dashboard).

Powering the Wemos and deploy the created flow shoud show us the graphs on 192.168.1.xx:1880/ui/ (see picture)

To call me an IoT expert is like someone calling tkaiser a fan of micro USB powered SBCs. According to the MIT licence this HowTo is provided "as is", without warranty etc.

]]>4434Sun, 04 Jun 2017 20:20:11 +0000H3 board buyer's guidehttps://forum.armbian.com/topic/1351-h3-board-buyers-guide/TL;DR: All available H3 boards do not differ that much. But the few differences sometimes really matter!

The following is an attempt to compare the different available H3 SBC that are supported by Armbian. The majority of boards is made by Xunlong but in the meantime two more vendors started cloning the Xunlong boards (and also Olimex is preparing H3 boards as OSHW). Both Foxconn/SinoVoip with their Banana Pi M2+ and FriendlyARM with their NanoPi M1 tried really hard to copy everything as exact as possible (the so called pin mappings -- how the many contacts the used H3 SoC is providing are routed to the outside).

All the boards share the same 40 pin GPIO header (trying to be compatible to the newer RPi boards) and since all the other pin mappings are also 99 percent identical you can for example boot a NanoPi M1 with an Armbian image for Orange Pi PC without loosing any functionality (except of camera module) and the same applies to BPi M2+ that will boot happily an Armbian image for Orange Pi Plus 2E (except of camera module and WiFi/BT)

In fact all the various H3 boards just differ in a few details:

Amount of DRAM

No, Fast or GBit Ethernet

Voltage regulator and 'thermal design' (responsible for performance in full load situations)

Storage capabilities (pseudo SATA and eMMC or not)

Count of available USB ports (with or w/o internal USB hub)

Some additional features like camera modules, WiFi/BT and additional/optional connectors (here it's important to check for driver functionality/availability. If there's no driver providing the necessary functionality then these 'additional features' are pretty much useless -- camera connector for example)

Why focussing on the H3 SoC for this comparison?

Since some of these boards are priced pretty competitive

Mainlining support for H3 SoC and these boards is progressing really nicely so we'll be able to run these boards with mainline kernel pretty soon (thanks to the great linux-sunxi community)

2D/3D/video HW acceleration is available with legacy kernels (again thanks to the great linux-sunxi community)

The feature set is nice for many use cases (quad core SoC, GBit Ethernet and 4 useable USB ports on some boards make a really nice low cost/power server)

It got somewhat confusing regarding the many available Oranges and now also the cloned Banana and NanoPi

This is also in preparation of a broader overview of the capabilities of all the boards Armbian currently supports now focussing on the H3 family. So let's get into details:

Amount of DRAM

That's an easy one. The H3 SoC supports up to 2 GB DRAM. The available and announced boards use either 512MB, 1 GB or 2 GB DRAM (low-power DDR3L on the bigger Oranges and DDR3 on OPi One/Lite, BPi M2+ and NanoPi M1). In case you're using Armbian it simply depends on the use case. And also it's necessary to understand that Linux tries to use all your RAM for a reason: Since unused RAM is bad RAM. So don't be surprised that Armbian will eat up all your RAM to cache stuff which improves performance of some tasks but the kernel will immediately release it when other tasks have a demand for it. If still in doubt please enjoy http://www.linuxatemyram.com.

If you want to use your boards with the unofficial H3 OpenELEC fork too please be aware that OpenELEC benefits from at least 1 GB RAM since then the whole filesystem remains in memory and no accesses to a probably slow SD card happen. Prior to jernej/OpenELEC and Armbian resolving the kswapd bug a few weeks ago the 512 MB equipped boards performed rather poor. But now it seems that the unofficial OpenELEC fork runs pretty well also on the boards with less available RAM.

Whether 1 vs. 2 GB RAM make a difference absolutely depends on the use case and no general recommendations can be made.

Since OpenELEC has been mentioned it should be noted that the current implementation of the unofficial OpenELEC port for H3 boards makes use of the cedarx-license-issues-library (no clear license preventing the use if you care about legal issues -- please have a look at http://linux-sunxi.org/Kodi for further details)

Networking:

The H3 SoC contains an Ethernet implementation that is capable of 10/100 MBits/sec Ethernet and also GBit Ethernet. A PHY (that handles the physical interconnection stuff) for Fast Ethernet is already integrated into the H3 SoC but to be able to use GBit Ethernet an external GbE capable PHY is needed (the RTL8211E used on all boards adds approx 1.2$ to the costs of the board in question).

Most H3 boards use the internal Fast Ethernet PHY so wired networking maxes out at ~95 Mbits/sec. Orange Pi Plus, Plus 2, Plus 2E and BPi M2+ provide GBit Ethernet (+600 Mbits/sec with legacy and exactly 462 Mbits/sec with mainline kernel) while Orange Pi Lite saves an Ethernet jack at all. The good news: Even with the Lite you can use wired network adding a cheap RealTek USB3-Ethernet dongle like this which is confirmed to exceed 300 Mbits/sec in a single direction.

The currently available boards have either no WiFi (NanoPi M1, OPi 2 Mini, One and PC), rely on RealTek 8189ETV (OPi 2, Plus, Plus 2), the newer RealTek 8189FTV (OPi Plus 2E, Lite, PC Plus) or a WiFi/BT combination: AP6181 is used on the BPi M2+ but the vendor didn't manage to get BT working at the time of this writing. Currently only jernej's OpenELEC fork and Armbian have a working driver included for the new 8189FTV chip on the fresh Orange boards that seems to perform quite ok and provides client/AP/monitor mode. Can't say that much about that since in my very personal opinion all these 2.4GHz onboard WiFi solutions are simply crap

Voltage regulator and 'thermal design':

This is a very important differentation: All Orange Pi boards use a programmable voltage regulator to adjust the voltage the SoC is fed with. The SY8106A used on every Orange except of One and Lite can be controlled though I2C and adjusts the so called VDD_CPUX voltage in 20mV steps. This is important since 'dynamic voltage frequency scaling' relies on the principle of providing less voltage to the SoC/CPU when it clocks lower. So when the board is idle also the supplied voltage will be reduced resulting in less consumption and also less temperature.

Since H3 is somewhat prone to overheating being able to adjust VDD_CPUX is also important when we're talking about the opposite of being idle. The SY8106A equipped Oranges reduce very fine grained the core voltage when they start to throttle down in case overheating occurs under constant heavy load. As a direct result they will automagically perform better since reducing VDD_CPUX voltage also reduces temperature/consumption so both CPU and GPU cores in H3 due not have to throttle down that much.

Quite the opposite with BPi M2+. For whatever reasons SinoVoip saved put a the same programmable voltage regulator on their board as OPi One, Lite and NanoPi have but does not implement voltage switching so H3 there will always be fed with 1.3V. In addition it seems 'Team BPi' didn't take care of heat dissipation through PCB design (it seems Xunlong added a copper layer to the PCB that helps dramatically spreading the SoC's heat) and so with BPi M2+ (and NanoPi M1 too) you have to be prepared that you need both a heatsink and a fan to let this board perform under full load since otherwise heavy throttling occurs or when you use a kernel that does not implement throttling (4.6/4.7 right now for example) be prepared that H3 gets either destroyed or will crash through overheating if you run something heavy on BPi M2+ or NanoPi M1. We're still investigating whether this crappy thermal behaviour might be related to DRAM also (DDR3 vs. low power DDR3L on the Oranges) It seems this thermal behaviour is not that much related to the DRAM type used but more to PCB design (maybe using large internal ground/vcc planes optimizing heat dissipation on Oranges.

NanoPi M1 and Orange Pi One/Lite use a rather primitive GPIO driven voltage regulator that is able to just switch between 1.1V and 1.3V VDD_CPUX which already helps somewhat with throttling.

A rather demanding benchmark using cpuminer (a bitcoin miner making heavy use of NEON optimizations and assembler instructions) that knows a benchmark mode where it outputs the khash/s rate. On the left OPI+ 2E with the superiour SY8106A voltage regulator switching CPU frequency between 1200 and 1296 MHz. On the right little OPi Lite with the SY8113B voltage generator able to switch between 1.1V and 1.3V and with slightly lower performance since throttling prevents clocking that high. And in the middle as only board with applied heatsink on H3 poor Banana Pi M2+ using the same SY8113B voltage regulator but always feeding the H3 SoC with 1.3V (for whatever reasons!).

Storage capabilities:

The H3 SoC doesn't feature native SATA capabilities so the 2 boards that have a SATA connector (Orange Pi Plus and Plus 2) implement that using an onboard USB-to-SATA bridge. Unfortunately the chip used there -- a Genesys Logic GL830 -- is horribly slow limiting sequential transfer speeds to 15 MB/s write and 30 MB/s read. It also does not support the USB Attached SCSI Protocol (UASP) so when using mainline kernel attached disks an especially SSDs couldn't show their full random I/O performance.

Given that common USB-to-SATA bridges used in external USB enclosures show way better sequential performance (35 MB/s in both directions and close to 40 MB/s when using an UASP capable bridge together with mainline kernel) the SATA port on these 2 SBC can not be considered a feature worth a buy.

Every H3 board has a TF card slot (Micro SD card) and some of the boards feature onboard eMMC storage. The H3 can cope with TF cards that are compliant to the SD, SDHC and SDXC standards so rather large cards with more than 64 GB capacity can also be used (be aware that there do not exist that much cards with a capacity larger than 128 GB. Chances are pretty high to get a counterfeit card especially when the price looks too good to be true ). You should also be aware that all H3 boards show the same sequential speed limitations (maxing out at ~23 MB/s) so choosing cards that are rated way faster aren't worth a buy. Better have a look at random I/O performance that is more important in most use cases.

The eMMC used on various boards is pretty fast (sequential speeds maxing out at ~75 MB/s and especially random IO way faster than the fastest tested SD cards which is important for desktop useage and databases for example) so you don't make a mistake choosing any of the eMMC equipped H3 boards (BPi M2+, Orange Pi Plus, Plus 2, Plus 2E or PC Plus). You find detailed test results of current SD/TF cards as well as all the eMMC variants used in these two threads:

The H3 SoC features 3 USB2.0 host ports and one USB OTG port. With Armbian we configure the OTG port as a host port that shows pretty similar performance so on some H3 boards (Orange Pi PC, PC Plus and Plus 2E) you can benefit from 4 USB2 ports that do not have to share bandwidth.

Some other boards use an internal USB hub (Orange Pi 2, Plus, Plus 2) so the available USB ports have to share bandwidth in reality. Please keep that in mind when you compare the 4 USB Type A jacks OPi 2, Plus or Plus 2 feature (all being connected to a USB hub so having to share the bandwidth of a single USB 2.0 host port) with the 3 you can count on OPi PC, Plus 2E or NanoPi M1. On the latter boards you get full USB 2.0 bandwidth on each USB receptacle without the need to share bandwidth.

BPi M2+ does also not use an internal USB hub but only exposes 2 USB host ports on type A receptacles and the 3rd host port only without ESC protection via soldering (but since this board shows such a terrible thermal design and is relatively overpriced compared to other H3 boards that doesn't matter that much)

Additional features:

The only board featuring a Bluetooth capable chip from BroadCom is the BPi M2+. Currently the vendor admits that BT is not working so better don't count on this feature to be ever available.

Update: Jernej got BT already working in his OpenELEC fork so it's just a matter of time until it works with Armbian too.

The H3 SoC is able to output/intercept additional signals, eg. analog audio, Composite video (TV out), IrDA that are present on most of the boards. On the Orange Pi One many of those interfaces are only present as solder points (a bit too tiny to be used by the average maker) and on some other boards they are not present at all (BPi M2+ for example has neither composite video nor analog audio) so always check first what you need or want to use.

Xunlong provides a pretty cheap 2MP camera module that should work with every H3 Orange Pi out there (they all have the necessary connector but for OPi One, Lite, PC and PC Plus you have to tell Xunlong that you also need a so called 'expansion board' that they ship free of charge if you add to your order that you need it. Starting with Armbian release 5.15 we also include an improved driver for this camera.

I recently bought an Orange PI PC and the best thing I ever did was install Armbian straight away (and donate). Now that I have a bit of spare time, I wanted to configure my Orange PI PC to do something ridiculous like play Rick Ashley 'Never going to give you up' upon pressing the 'red button' on some generic Chinese IR remote for an LED light strip I have in my living room.

Thanks to Armbian, most of the pieces are in place (such as the SunXI IR package) with the distribution, you just need to glue it all together.

However there are few configuration issues with the default Armbian install on the Orange PI PC that need to be adjusted, otherwise you'll encounter infuriating issues such as:

No IR device existing or being detected (root cause: sunxi-cir module not loaded)

I should also note that this guide on the terrible Orange PI forums, helped me with my issues.

Step 1) Adjust /etc/lirc/hardware.conf

Updated: This guide was originally written for Armbian based on Debian 'Jessie'. The latest Armbian (as at September 2017) is now based on Ubuntu Xenial. This introduces a new lirc package which yet again comes with a broken hardware.conf

For Ubuntu Xenial (September 2017):

The default hardware.conf that comes with Armbian is broken. It's assigning the 'remote' and 'transmitter' to the same device, this breaks everything. Ensure the TRANSMITTER_MODULES="" and TRANSMITTER_DEVICE = ""

# /etc/lirc/hardware.conf##Chosen Remote Control
REMOTE="None"
REMOTE_MODULES="sunxi_cir"
REMOTE_DRIVER="default"
REMOTE_DEVICE="/dev/lirc0"
REMOTE_SOCKET=""# FYI - /run/lirc/lircd will probably be the socket that the system uses
REMOTE_LIRCD_CONF=""
REMOTE_LIRCD_ARGS=""#Chosen IR Transmitter
TRANSMITTER="None"
TRANSMITTER_MODULES=""
TRANSMITTER_DRIVER=""
TRANSMITTER_DEVICE="/dev/null"
TRANSMITTER_SOCKET=""
TRANSMITTER_LIRCD_CONF=""
TRANSMITTER_LIRCD_ARGS=""#Disable kernel support.#Typically, lirc will disable in-kernel support for ir devices in order to#handle them internally. Set to false to prevent lirc from disabling this#in-kernel support.#DISABLE_KERNEL_SUPPORT="true"#Enable lircd
START_LIRCD="true"#Don't start lircmd even if there seems to be a good config file#START_LIRCMD="false"#Try to load appropriate kernel modules
LOAD_MODULES="true"# Default configuration files for your hardware if any
LIRCMD_CONF=""#Forcing noninteractive reconfiguration#If lirc is to be reconfigured by an external application#that doesn't have a debconf frontend available, the noninteractive#frontend can be invoked and set to parse REMOTE and TRANSMITTER#It will then populate all other variables without any user input#If you would like to configure lirc via standard methods, be sure#to leave this set to "false"
FORCE_NONINTERACTIVE_RECONFIGURATION="false"
START_LIRCMD=""

For Debian Jessie (~year 2016):

By default Armbian doesn't have the suxi-cir module enabled at boot-up, but it is available, so you will need to edit hardware.conf to enable this, as well as correct the DRIVER= line and the DEVICE= line, as the defaults in there are WRONG.

Also I suggest commenting out Igor's code in the top five lines. A hardware.conf that works:

# Cubietruck automatic lirc device detection by Igor Pecovnik#str=$(cat /proc/bus/input/devices | grep "H: Handlers=sysrq rfkill kbd event" | awk '{print $(NF)}')#sed -i 's/DEVICE="\/dev\/input.*/DEVICE="\/dev\/input\/'$str'"/g' /etc/lirc/hardware.conf# /etc/lirc/hardware.conf## Arguments which will be used when launching lircd
LIRCD_ARGS=""#Don't start lircmd even if there seems to be a good config file#START_LIRCMD=false#Don't start irexec, even if a good config file seems to exist.#START_IREXEC=false#Try to load appropriate kernel modules
LOAD_MODULES=true# Run "lircd --driver=help" for a list of supported drivers.# 'devinput' driver on Orange PI PC causes NO EVENTS TO OCCUR# via irw for some reason.
DRIVER="default"# usually /dev/lirc0 is the correct setting for systems using udev
DEVICE="/dev/lirc0"
MODULES="sunxi-cir"# Default configuration files for your hardware if any
LIRCD_CONF=""
LIRCMD_CONF=""

Step 2) Restart lircd service

As lirc is actually already running and installed in Armbian, do the following:

For my installation, /dev/input/event3 is the IR receiver, but if you have other devices installed (i.e. USB cameras, keyboards etc.) then the number could be different. For example, executing 'evtest /dev/input/event3' reveals:

Again, Armbian has irrecord installed (great work Igor), but given I'm re-using this remote to configure the output of a LED strip I have, I'll need to map the IR data sent, to something more meaningful. In other use-cases this isn't generally required as lircs provides a database of media remotes which is pre-mapped to Linux commands/keyboard keys.

There's plenty of information on how to use irrecord, command I used was:

/etc/init.d/lirc stop

...to first stop the service, then:

irrecord -H default-d /dev/lirc0 /etc/lirc/lircd.conf

... to record my remote and bind to 'keys'.

Step 6) Test with irw

Now that I recorded my configuration file with irrecord:

/etc/init.d/lirc start

.. to start lird service again

then type 'irw' and check that the key mapping works when I point the remote at the Orange PI PC and press a button:

You could also create a file for each user of the system if you want, eg: /root/.lircrc, /home/userXXX/.lircrc

However if you do this, you will need to start the irexec service manually. If you have a /etc/lirc/lircrc file, the irexec service will start automatically at boot - this service is what actually converts the key press to the command.

So there you go, Rickrolling with a simple press of the red (KEY_R) button :-)

]]>1953Sat, 03 Sep 2016 20:09:47 +0000Orange Pi Zero: Setting up Armbian and SSHhttps://forum.armbian.com/topic/5741-orange-pi-zero-setting-up-armbian-and-ssh/
Hey everyone, I wrote a guide a while back on setting up Armbian on the Orange Pi Zero, with key-based ssh access enabled. Thought I'd share it with this forum; I'd love some feedback.
]]>5741Thu, 23 Nov 2017 15:32:24 +0000CoovaChilli and Freeradius for a Wifi Hotspot with captive portalhttps://forum.armbian.com/topic/5369-coovachilli-and-freeradius-for-a-wifi-hotspot-with-captive-portal/
Hello everyone, today I would like to show you how to compile CoovaChilli and Freeradius for a Wifi Hotspot with captive portal on an Orange Pi PC (or PC Plus). I'm writing this because I couldn't find anything related to this topic on the internet, so I wrote this not very detailed guide.

]]>5369Sun, 08 Oct 2017 15:48:13 +0000H3 devices as NAShttps://forum.armbian.com/topic/1440-h3-devices-as-nas/
The following is a short overview what you can expect from small and big H3 devices when used as a NAS. I chose the least capable device (OPi Lite for $12: not even Ethernet and just 512MB DRAM) and the best possible (OPi Plus 2E for $35: GBit Ethernet, 3 USB host ports exposed that do not have to share bandwidth, 2GB DRAM).

I wanted to test also a H3 device in between with 1GB DRAM but since results are somewhat predictable I dropped the whole idea (the performance bottleneck on all Fast Ethernet equipped devices will be network unless you add the $7.50 for an USB-Ethernet dongle -- see below -- and all other Gbit Ethernet capable H3 devices are not priced competitive)

They arrived in the meantime so I thought: Let's make OPi Lite an Ethernet device. With our current legacy kernel config and network settings you simply connect the adapter and an Ethernet cable, boot and have eth0 up and running (well, this should apply to most available USB-Ethernet adapters since we enabled every device available in kernel config). The dongle according to lsusb:

Since I want Lite's both USB host ports for disks, I used the OTG port and a Micro USB to USB adapter: a simple iperf test against a GbE device showed 270/300 Mbits/sec (depending on direction).

Power requirements when adding Ethernet using this dongle:

Plugging in the dongle without network cable attached: +700mW

Connecting network cable to USB dongle (GbE!): another +400mW

GbE transmission in one direction (limited to ~300 Mbits/sec): another +800mW

So you can calculate with ~2W additional peak consumption per Ethernet adapter (at least 1.1W more if connected to a GbE network -- this is slightly more than the average 0.9W on Gbit Ethernet equipped SBC when the usual RTL8211E PHY establishes a GBit connection)

I connected then a 3.5" Seagate Barracuda with external PSU (ext4 since with a 3.4 kernel we can not use more interesting filesystems like btrfs -- iozone shows ~35MB/s in both directions), compiled Netatalk 3.1.18 and tested NAS performance from my MacBook (no further tuning except 'echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor' -- without this write performance totally sucks):

Read performance is quite ok given that iperf shows just 270-300 Mbits/sec but write performance needs some tuning (not today). By looking at 'iostat 5' output it was obvious that write buffers were flushed only every few seconds so for normal NAS useage with small files the whole problem doesn't exist and it also should be possible to increase performance (not today). Anyway: search the net for correctly measured performance numbers of other SBC used as NAS and you will be already satisfied given that we're talking here about a $12+$7.50 combination

High end

Orange Pi Plus 2E is -- in my very personal opinion -- the best H3 device available if you think about NAS useage. It is equipped with the maximum amount of DRAM H3 can deal with, has Gbit Ethernet, exposes all 3 USB host ports + 1 OTG and comes with 16GB of pretty fast eMMC. At a competitive price (please keep in mind that you can install the OS on eMMC so you don't have to add the price of an SD card here).

You can attach up to 4 USB disks (with mainline kernel and UASP capable enclosures they will show sequential speeds close to 40 MB/s, with legacy kernel it's ~5MB/s less)

What you see here is the result of Gbit Ethernet paired with way more RAM and a test data size too small (only 300 MB fit perfectly into memory) so this is the increase in speed you will benefit from in normal NAS situations (dealing with files that do not exceed a few hundred MB in size). In case you try to write/read files larger 1 GB (or use software that often uses sync calls to ensure data is properly written to disk) be prepared that USB 2.0 becomes the bottleneck. In these situations sequential transfer speeds between NAS and clients will drop down to ~32MB/s without further tuning (applies to legacy kernel, for mainline see new post coming in the next days)

Anyway: Please keep in mind that these are 'single disk' measurements. You can attach up to 4 disks to an OPi Plus 2E (using individual spindown policies to save energy or RAID modes to improve performance and/or availability), with Armbian defaults at least two of them can be accessed concurrently at full speed (USB2 maxing out at ~35MB/s and GbE being able to exceed 70MB/s easily) and with some tuning that might apply even to 3 disks accessed at the same time.

And if I compare these benchmark results based on defaults (burning Armbian to SD card, firing up the NAS software, measuring performance, done) with what had to be done prior to being able to simply use Armbian as 'NAS distro of choice', eg. these one year old results with A20 then choosing OPi Plus 2E is a no-brainer.

Regarding OPi Lite (or One or the smaller NanoPi M1) as NAS: This was more proof of concept than a recommendation. Being able to use as much RAM as possible for buffers is something especially a NAS / fileserver benefits from. So choosing a device with only 512MB is not the best idea. 'Native' Gbit Ethernet as present on a few H3 devices also clearly outperforms USB based solutions (iperf throughput with a recent Armbian without any tuning: 680/930 Mbits/sec). And if you add costs for USB-Gbit-Ethernet adapter and SD card the smaller boards aren't priced that competitive any longer.

After I accomplished my IR Red Key Rick Rolling experiment the other day with much success, and from general end-luser use with Armbian, there were two things which irritated me, which are namely due to the default ALSA configuration that comes with stock Debian and that Armbian inherits. These were:

Update: 11 September 2017. This guide will not work for newer Armbiam (Debian) installations which comes with Pulseaudio by default. If you really want what this tutorial provides, you will need to uninstall pulseaudio first: sudo apt-get remove pulseaudio

1) You can't have simultaneous applications using an Audio device. So, how about if I want to stream Internet Radio with 'Radio Tray' but also get system alert sounds, or anything else? Out of luck, you'll get (for example):

[ao/alsa] Playback open error: Device or resource busy

2) I want to actually have audio going out of the 3.5mm jack (don't really care about video out), better still if it's the same/simultaneous to what is going out via. HDMI. That means if I have a HDMI TV connected then I can get the sound from the TV, if I don't, then I can just use the 3.5mm jack (i.e. If I'm using my Pi to play Rick Astley headless/without a TV). No need to keep editing /etc/asound.conf every time.

Solution?

Step 1) Fix the mute on the analog Line-Out in alsamixer (for a start)

There's a lot of noise out there about people not being able to get any sound our of the analog Line-Out jack even when having changed /etc/asound.conf. The reason for this is likely due to a mute by default on the analog audio line-out (i.e. the 3.5mm headphone jack) in alsa that you would unlikely to be aware of. I only found this out thanks to a comment here, otherwise I would have thrown by Pi PC out the window today.

So to fix, you need to type in the console:

sudo alsamixer

Then F6 select the 'audiocodec', then tap the right arrow key to select the 'Audio lineout [Off]' item.

Press 'm' and you'll get the green 'OO', which means it's now active.

Exit alsamixer, and when you're back at the console type:

sudo alsactl store 0

... to store you mixer settings.

For your information, the mixer settings are stored to the file:

/var/lib/alsa/asound.state

... and if you do a diff of this file after having made the changes in alsamixer, this is what is changed in the alsa asound.state file:

As you might or might not be aware, the default /etc/asound.conf file looks something like this:

pcm.!default {
type hw
card 1
}
ctl.!default {
type hw
card 1
}

All it is configured to do is give applications direct access to the hardware audio device, and pump the sound either out to the analogue line-out ('card 0') or via HDMI ('card 1'). Pretty basic, but does the job.

However, what I wanted was two things:

Software mixing before the resulting PCM/Sound is sent to the hardware audio device - This enables me to listen to Internet Radio and Youtube at the same time...

Simultaneous Output to both HDMI and analog line-out.

If you want only (1) above, and only via HDMI, then the /etc/asound.conf file is this:

There you have it. The only downside is that CPU usage for playing music will increase a bit as ALSA will essentially route inputs from applications to two Software Mixers, which are connected to the HDMI and Analog Line-Out hardware devices separately. For some reason you can't have a single Software Mixer route to two hardware devices (or I couldn't get it to work), but whatever. We're talking 20% CPU usage vs. 10% on one core, to play music.

I recently bought a cheap 16 character, 2 row LCD display from aliexpress.com for use with my Orange Pi PC. I got it to work without too much pain, but I thought I would document it here for the benefit of others. Some good instructions are already available on the internet, but there are some tweaks required for the Orange PI.

Armbian I believe already has the I2C module compiled into the kernel directly. So no Linux Kernal insmod work required, unlike what many Raspberry PI guides seem to imply.

Step 1) Buy the things you will need.

1. You obviously need a 1602 LCD modulewhich also comes with the the I2C converter. You can buy a 1602 LCD and wire it directly to the 16 GPIO pins required if you want, but that isn't the point of this guide.

2. You will need a level shifter. The LCD display works on +5volts. The OrangePI/H3 GPIO pins are 3.3 volts. I have seen guides stating that you don't need a level shifter, but I'm sure you're slowly frying some transistors in your OrangePI over time.

Note, you connect the 1602 I2C module/backpack directly to the 5Volt Pin on the PI (Pin 2 or 4) and Ground (Pin 6) respectively.

Note: For some strange reason the level shifter works if you don't connect the ground pins to either side of it (i.e. Use the LV, LV1, LV2, HV, HV1 and HV2 pins only). No idea why - electrical engineering degree required I think.

If all works well, you should see the LCD module light-up with the top row being a bunch of white bars (you might need to check the contrast setting of the module as well). White bars = uninitialised LCD screen.

I need to adjust the script to reference a 1602 LCD device with address 0x3f, on Orange Pi PC I2C Bus, 0. The script as it is references a device of 0x27 on Bus 1 - it won't work. You might have a LCD device of address 0x27 (you'll know from the previous step), but it seems many of the cheap LCD modules from aliexpress are 0x3f for some reason.

This is a really useful thing to do, otherwise you'll need to run the python script as ROOT (via. sudo etc.) every time. No good if you want to write a python script that runs using your normal user account and sends messages over I2C to the LCD.

]]>4377Sun, 28 May 2017 18:30:02 +0000Django CMS on Armbianhttps://forum.armbian.com/topic/5108-django-cms-on-armbian/
For those of you who're interested in running a CMS on Armbian I've a small tutorial how to get django CMS working. If you're not interested in the 'story' just want a step by step installation guide, scroll to the end of this post, there you find it.

Story:

Following their installation guide it fails during creation of a django project with 'djangocms -f -p . mysite'.

After a brief google search I found that other also had similar problems. It seemed that pillow is the problem while the whole installation failed. Unfortunately pip pillow also failed, and this one helped me to install pillow. After installation of libpq-dev python-dev libjpeg8-dev, pillow could be installed without any issues and 'djangocms -f -p . mysite' too. Starting the CMS with 'python manage.py runserver' worked too but unfortunately wasn't accessible over local network (since all of my armbian devices are running headless, I need access over network to the CMS). Inspired by a next google result, I found out that I should run the CMS on the SBCs network IP not on localhost by using 'python manage.py runserver 192.168.0.44:8000'. Which led in a next error.

Even if you're not a dev and your background is limited, it is possible to get something like this CMS to work if you're able to use google.

By reading through google results and have a look on the output errors during installation you learn much more about your project/SBC than just following the step by step procedure I'll show at the end of this post.

The 'tarzan approach' - Tarzan/me swings from tree/error to tree/error holding on to elastic lianas/error logs works but it makes sense to repeat this installation after get a straight forward approach for the next time you'll use it.

Make your virtualenv folder for all your CMS projects (since django cms is capable to run multiple cms at once it might make sense to have a 'parent folder' where all of them are placed): mkdir CMS --> cd CMS

]]>5108Thu, 07 Sep 2017 20:14:12 +0000https://forum.armbian.com/topic/4805-the-dogafu-experiment-ds18b20-unreliable-sd-card-power-source/
Starting to work on lets call it the "dogafu" experiment (don't give a fuck about recommendations). This would combine my threads about powering & bad SD-Cards. Cause I want do something useful and not just crash armbian on a system, from which I know that it would happen, I decided to do not only stupid tasks on my OPi zero. I could just hammering the SD-Card with a webcam and motion until it crashes and write on this thread 'opi 0 with terrible setup crashes after x days'. But, nobody would read this thread cause it's not interesting for anyone. We know that this would happen and for those users who don't know, there's nothing of interest in this thread.

Since thermal throttling on the opi zero seems to be a real issue and there's a lack of information, that the temperature readouts from the SoC are correct, I decided to connect a DS18b20 to the OPi0 and let it measure the temperature of the SoC. Everything was installed on ARMBIAN 5.31 stable Ubuntu 16.04.2 LTS 3.4.113-sun8i.

Hooking up the DS18b20:

First we edit the configuration file and uncomment the w1 modules with sudo nano /etc/modules-load.d/modules.conf

and cause onewire does not work properly @240 MHz we had also to change MIN_SPEED to 480000 with:

sudo nano /etc/default/cpufrequtils

Spoiler

ENABLE=true
MIN_SPEED=480000
MAX_SPEED=1200000
GOVERNOR=interactive

after a shutdown we can connect the DS18b20 on GPIO10 (Data, physical pin 26), VCC to one of the 3.3V (physical pin 1 or 17) and ground (physical pin 6,9,14,20 or 25) don't forget to have a 4.8kOhm resistor betwenn VCC and Data! If you want to have your data pin not on GPIO10 you have to modify the script.bin with bin2fex /boot/script.bin /tmp/orange.fex followed by nano /tmp/orange.fex and change the GPIO in the [w1_para] section (example for using of GPIO6 for DS18b20):

Spoiler

[w1_para]
w1_used = 1
gpio = 6

sudo fex2bin /tmp/orange.fex /boot/script.bin and a reboot is needed to activate this settings. Im everything works correctly sudo armbianmonitor -m should show that the cpu frequency would not go below 480MHz (otherwise DS18b20 would not run smoothly). Go to cd /sys/bus/w1/devices/ we can see our sensor with ls.

So the actual temperature in my room is 23.562°C (IMO forget about everything behind the °C, proper precise temperature measurement isn't trivial and needs calibration which is not possible without professional equipment).

Send data to an other device:

Cause this setup with bad powering & a corrupt SD card will brick and I do not want to lose the collected data, I decided to send all the data to a second, proper running, OPi 0 via mqtt. This will be done by some bash scripts and crontab (it would be possible to do this only with crontab, but cause I may use this scripts on other devices for other purposes it's easier to have them isolated). For this, I installed a mqqt client with sudo apt-get install mosquitto-clients. After installation, we test if the client can publish on an other device with: mosquitto_pub -h 192.168.x.xx -t test -m "everything works ;-)" (-h ip oft the mqtt broker, -t topic to publish -m msg.payload). On my second OPi 0 with node-red and mosquitto we should see that the message arrived (installation of node-red and mosquitto).

Spoiler

(with #, we subscribe to every topic on the mosquitto broker)

Bash script & crontab:

IMO the easiest way to send data periodically is to generate a small bash script which includes all the tasks and then setup a crontab to start this bash script. The scritp was saved in /home/opi/scripts/ with nano scriptname the script was generated (It might be possible to do this tasks without a bash script but since I'll reuse parts of it i decided it's the lazy way to do it.):

Cause cpu infos are only available as root, crontab must run under root privileges. Add a new crontab with sudo crontab -e (1 for edit with nano). This crontab will start our script every minute:

Spoiler

# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h dom mon dow command
* * * * * bash /home/opi/scripts/scriptname

Cause this script runs now with root privileges, this might be a security risk so make sure that no one has access to your OPi! Now it's time to set up everything in node-red to get our results visible. I added dashboard to node-red to have some nice UI templates (usage of node-red & how to set up can easily learned by google .

Spoiler

FYI: This is an ongoing project. At the moment, everything runs on a reliable SD-Card and the DS18b20 is not properly mounted on the SoC (waiting for thermal paste). As soon as I have everything setted up, I'll put it on the bad SD-Card with a cheap phone charger to see how stable it runs.

]]>4805Thu, 27 Jul 2017 23:07:01 +0000OrangePi as iTunes server with forked-daapdhttps://forum.armbian.com/topic/3254-orangepi-as-itunes-server-with-forked-daapd/
If you follow https://github.com/ejurgensen/forked-daapd you will get a lot of error-messages.

you should see some activity on the log-file. After the scanning is complete, you can see your Orange Pi music-server in iTunes.

Automatic updates for the music-server (e.g. at 4am in the morning, necessary if you use a network-share for the data):

sudo crontab -e

and add the line

0 4 * * * touch /{path to your music}/trigger.init-rescan

]]>3254Tue, 10 Jan 2017 20:23:05 +0000Running 32 bit applications on Aarch64https://forum.armbian.com/topic/4764-running-32-bit-applications-on-aarch64/
Now that there are an increasing number of boards running in 64 bit mode (Aarch64) it might happen that you want/need to run a 32 bit application on a 64 bit OS. I suspect that there is more than one way to do this, but here's what I've been using:

There is a downside to this approach - after adding armhf you have to be careful when installing new packages that you get the right version and don't end up installing 32bit packages that you don't need.