• Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    manuti reacted to lanefu in Docker on H3 Armbian   
    i did a 4.6.4 kernel armbian build for my opi one yesterday. I was delighted. Ethernet worked. Docker worked after only an apt-get install. i launched a basic ubuntu xenial arm container and it held together. nothing like a 512 meg docker host
    Tapatalk thinks its important to tell you im using tapatalk from a phone.
  2. Like
    manuti reacted to tkaiser in Beelink X2 with armbian possible?   
    That means a new hardware revision is out since the older Beelink X2 are equipped with AP6181: device I have also has AP6181 but different DRAM modules compared to the wiki picture)
    Did you check which hardware revision you have?
  3. Like
    manuti got a reaction from slinde in Beelink X2 with armbian possible?   
    Finally I discover my Beelin X2 have a `8189es` so applying same firmware but change the bcmhd part by the 8189es all the tings go up.
    manuti@beelinkx2:~$ sudo modprobe 8189es firmware_path=/lib/firmware/ap6210/8189es.bin nvram_path=/lib/firmware/ap6210/nvram.txt manuti@beelinkx2:~$ lsmod Module Size Used by 8189es 1076034 0 mali_drm 2732 1 drm 178255 2 mali_drm mali 123208 0 ump 29379 3 mali sunxi_spdma 3703 1 sunxi_spdif 7037 1 sunxi_sndspdif 3885 0 sndspdif 2743 1 hid_logitech_dj 10040 0 manuti@beelinkx2:~$ sudo ifconfig wlan0 up manuti@beelinkx2:~$ sudo iwlist wlan0 scan wlan0 Scan completed : Cell 01 - Address: xx:xx:xx:xx:xx:xx ESSID:"xxx" Thanks a lot to everybody.
  4. Like
    manuti reacted to Wazou in NanoPI NEO / AIR   
    Got my NEO's this morning ! So far so good, the form factor is excellent and there is still some place to screw in M3 spacers without shorts on SMDs (was afraid of this being an issue when reviewing the dxf schematic) 
    I'm currently running the version of Snappy Ubuntu while waiting for the ARMbian to come out
    I'll be happy to run some test if you guys need anything; I have currently 10 of them running on my desk.
    Bonus : picture of the NEO hooked up with my proto POE module (PCB hat on it's way !)

  5. Like
    manuti reacted to tkaiser in Marriage between A20 and H3, UPS mode, sunxi-pio utility   
    Yesterday I showed in the first post above how on some AXP209 equipped boards like Lime2 the 5V provided through the USB host ports can be switched on/off using the sunxi-pio utility. So if we use a battery equipped A10/A20 board we can use this also to power other consumers through the USB ports, can switch them off and on and provide an 'uninterruptable power supply' (UPS) mode.
    The same way we can also cut power to on-board components that are controlled through AXP209, for example a connected SATA disk. The following graph shows Lime2 powered through USB OTG (to get the 'big picture' regarding consumption -- see the post before for reasons when to choose which powering mode). On the left the 2TB Samsung is in 'active/idle' state (spinning but doing nothing -- ~480 mA consumption), then my power management settings in /etc/rc.local let the disk switch to 'standby' mode after 5 minutes of inactivity (340 mA) and then I switched off power to the disk completely using sunxi-pio (230 mA):

    How to know which pin has to be toggled? I just looked into the fex file again:
    sata_power_en = port:PC03<1><default><default><0> So by using the following we can physically power off the disk after unmounting the filesystems of course (not available as device later until we power it on with sunxi-pio again or reboot the board):
    sunxi-pio -m PC03'<default><default<default><0>' # off sunxi-pio -m PC03'<default><default<default><1>' # on Unfortunately from all our AXP209 equipped boards only a few support powering the disk through AXP209:
    But what about other onboard components that might not be used but are by default in 'powered on' state and add to the board's consumption while not needed. Let's search for the magical word '_power' inside the fex files:
    Would be interesting to play around with LCD and CSI power settings and to have a look whether switching those pins off where defined as on by default makes any difference regarding consumption (or for example the GBit Ethernet PHY on some boards when they do not need network connectivity). But this is stuff I leave for others to test and get back to this thread with results.
    Since we're talking about disks. These are the two lines I add to /etc/rc.local to spin-down Samsung/Seagate SATA disks on A20 boards after 5 minutes of inactivity:
    hdparm -B 254 /dev/sda hdparm -S 60 /dev/sda And to manually send SATA disks to sleep 'hdparm -Y /dev/sdX' can be used. Please keep in mind that this is SATA stuff and not every USB-to-SATA bridge contained in USB disk enclosures supports this. Also some disks ignore sleep and power management settings and then scripted approaches like are needed (as we can see above physically powering off a disk leads to further energy savings but without switching power on the disk won't come back when needed -- unlike sleeping since then the disk's controller simply wakes it up when a new disk access happens)
  6. Like
    manuti reacted to 7profy in [Orange Pi One] How to enable UART?   
    Here is solution (for H3):
    1. Convert script.bin to FEX:
    cd /boot bin2fex script.bin script.fex 2. Edit script.fex to enable UART3:
    sudo nano script.fex Find section [uart0] and set the next to disable uart0-2 and enable uart3 only with 2-pin mode on pin 8/10:
    [uart0] uart_used = 0 uart_port = 0 uart_type = 2 uart_tx = port:PA04<2><1><default><default> uart_rx = port:PA05<2><1><default><default> [uart1] uart_used = 0 uart_port = 1 uart_type = 4 uart_tx = port:PG06<2><1><default><default> uart_rx = port:PG07<2><1><default><default> uart_rts = port:PG08<2><1><default><default> uart_cts = port:PG09<2><1><default><default> [uart2] uart_used = 0 uart_port = 2 uart_type = 4 uart_tx = port:PA00<2><1><default><default> uart_rx = port:PA01<2><1><default><default> uart_rts = port:PA02<2><1><default><default> uart_cts = port:PA03<2><1><default><default> [uart3] uart_used = 1 uart_port = 3 uart_type = 2 uart_tx = port:PA13<2><1><default><default> uart_rx = port:PA14<2><1><default><default> ;uart_rts = port:PA15<3><1><default><default> ;uart_cts = port:PA16<3><1><default><default> Remark: I don't find description for value <2> in PA13<2> but it works as expected.
    3. Save changes.
    4. Convert FEX to bin
    fex2bin script.fex script.bin 5. Reboot.
    6. Device name is ttyS3. Default speed = 57600. To test it type "echo TEST > /dev/ttyS3"
    PS. Some times after 
    apt-get upgrade script.bin replaces to default values, so it need to repeat all steps.
  7. Like
    manuti reacted to tkaiser in UART (TXD & RXD) x 2 on GPIO of BPI-M2, is possible?   
    Be very very careful. There exist no correct specification regarding GPIO pin layout for the Banana Pi M2:
    All the glorious 'Team BPi' (that provided so much crappy software and wrong informations and is responsible for missing informations and support) did, is to steal the above picture from and remove their logo. Don't expect that any pin mapping is correct, it's just a manipulated picture stolen from somewhere else.
    Please crawl through the two most horrible forums ever to get a clue how much of this stuff simply is wrong: (this is 'Team BPi's former official Banana Pi forum abandoned a few months ago) (this is the current official forum -- maybe they already prepare to abandon this and start over with a fresh one somewhere else? At least the most moronic marketing person ever that normally floods the forum with useless crap is quiet. Not a single @sinovoip post the last days!) The best thing you can do with a M2 is to use it as headless server or throw it into the bin.
    Ok, to be a bit more constructive: UART pin mappings depend on the device tree definitions when using Armbian (mainline kernel only available for M2). Maybe others can assist you. I won't waste my time with any of 'Team BPi's products any more (R1, M2, M3 -- I'm sure they already develop an M4 and M5).
  8. Like
    manuti reacted to tkaiser in 5 Node Cluster of Orange Pi Plus 2Es   
    There's no need to benchmark this. I tested with mainline kernel and 3 external USB disks half a year ago (back then no SMP was working so H3 was running on a single CPU core at 1008 MHz) and could saturate all three host ports. Performance of the OTG port when used as host port is also known, so when H3 is running on all 4 cores it's no problem to exceed 150 MB/s while using all 4 USB ports in parallel. Network performance is also already known and since H3 is powerful enough it's also not a problem to saturate USB lines and GbE in parallel. You find some numbers in this thread:
    Performance might vary depending on kernel version (GbE with mainline kernel is currently slower compared to legacy kernel, regarding USB storage it's the other way around) but the important thing here is: 4 USB ports and 1 GbE network port that do neither have to share bandwidth nor block each other when used in parallel. And this is the most important differentiation to any RPi where everything is limited by the single USB 2.0 connection. Any data that has to be transferred between a disk connected to RPi (USB) and a client behind the network (also USB) has to pass this bottleneck twice. It's really not comparable and RPi suffers a lot when it's about transferring data.
    But to be honest: Since we're talking about clustering it's all about the use case. Do cluster nodes need high network bandwidth? Then forget about any RPi and choose SoCs with true GbE networking. Do they need high local storage throughput? If so forget about any RPi and maybe also about any non-SATA SoC. And so on.
    Clustering with cheap ARM boards looks nice and might be a useful tinkering excercise doing some things right (eg. an intelligent cooling approach instead of the brain-dead ones mostly seen). But there are only a few reasonable use cases for such stuff (eg. an automated build/test farm for ARM installations since testing stuff natively might be 20 times faster than using QEMU) and especially when people start thinking about HPC stuff then choosing ARM boards that aren't OpenCL capable and can compute stuff on powerful GPU cores is laughable (since you would need a few hundred boards, an insane amount of networking equipment and cabling and the whole cluster would still be outperformed by any middle class GPGPU capable cheap PC)
  9. Like
    manuti reacted to jernej in Beelink X2 with armbian possible?   
    Yeah, bcmdhd driver has some strange things inside the code. It seems mandatory to have some file specified, but later on it gets replaced with correct FW name based on chip id. If you check driver source, you can see a lot of different FW file names.
  10. Like
    manuti reacted to tkaiser in Orange Pi ONE GPIO Pin Layout
  11. Like
    manuti reacted to tkaiser in Running H3 boards with minimal consumption   
  12. Like
    manuti got a reaction from Igor in Beelink X2 with armbian possible?   
    Thanks a million Igor.
  13. Like
    manuti reacted to onlinespending in How to improve Desktop web browser experinece on Banana PRO?   
    I'm wondering the same thing. I was able to install Chromium using the latest Ubuntu Trusty (which is based on Debian Jessie) armhf packages on my Debian Jessie Armbian build running on a Banana Pi M1. I had to install libgcrypt11, chromium-codecs-ffmpeg-extra, and chromium-browser Ubuntu .deb files. The rest of the dependencies were found from the Debian apt sources.
    But the performance is unbearably slow. I figured with 1GB and a dual-core ARMv7 processor, that web browsing would be at least decent and on par with the experience you get with smartphones. It's not even close. Since Armbian is a bare bones installation, is it possible that I'd need to install other packages to improve web browsing performance? I'm even running everything off a speedier SSD drive on the SATA port, rather than off of the SD card. I tried Midori and that consistently freezes after loading virtually any webpage. Thanks for any suggestions.
    UPDATE: I'm starting to suspect this has a lot to do with the fact that I'm on the mainline kernel without any GPU acceleration. So all of the X11 rendering is handled by the CPU, which naturally is going to be unbearably slow for any graphics intensive programs, like a web browser. This is just an assumption on my part, so I could be wrong. Sadly it looks like I'll have to back off to the legacy kernel until GPU support is added to the mainline kernel.
  14. Like
    manuti reacted to Igor in Update 5.15 - fixed IP gone --> solved   
    It was already fixed and an update will be issued ASAP to minimize the problem. This was simple overlooked so it could not appear in the changelog. We are overloaded. Sorry. 
  15. Like
    manuti reacted to slinde in Beelink X2 with armbian possible?   
    I put the firmware file on my webserver
  16. Like
    manuti reacted to tkaiser in Beelink X2 with armbian possible?   
    Thx for the reminder. But fortunately the same pin mapping is used. I just did this
    root@beelinkx2:/home/tk# modprobe sunxi-cir root@beelinkx2:/home/tk# ir-keytable -p NEC,RC-5,RC-6,JVC,SONY,LIRC,OTHER ; ir-keytable -c ; ir-keytable -t Invalid parameter(s) ir-keytable: -p: (PROGRAM ERROR) Option should have been recognized!? Try `ir-keytable --help' or `ir-keytable --usage' for more information. Old keytable cleared Testing events. Please, press CTRL-C to abort. 1466427392.393181: event type EV_MSC(0x04): scancode = 0x03 1466427392.393209: event type EV_SYN(0x00). 1466427392.837740: event type EV_MSC(0x04): scancode = 0x03 1466427392.837767: event type EV_SYN(0x00). 1466427393.983779: event type EV_MSC(0x04): scancode = 0x02 1466427393.983808: event type EV_SYN(0x00). 1466427397.780964: event type EV_MSC(0x04): scancode = 0x48 1466427397.780994: event type EV_SYN(0x00). 1466427398.716936: event type EV_MSC(0x04): scancode = 0x48 1466427398.716964: event type EV_SYN(0x00). 1466427401.090401: event type EV_MSC(0x04): scancode = 0x14 1466427401.090431: event type EV_SYN(0x00). 1466427402.939626: event type EV_MSC(0x04): scancode = 0x5c 1466427402.939656: event type EV_SYN(0x00). 1466427403.581513: event type EV_MSC(0x04): scancode = 0x5c 1466427403.581539: event type EV_SYN(0x00). 1466427407.404387: event type EV_MSC(0x04): scancode = 0x0b 1466427407.404416: event type EV_SYN(0x00). 1466427411.510339: event type EV_MSC(0x04): scancode = 0x58 1466427411.510367: event type EV_SYN(0x00). 1466427412.160997: event type EV_MSC(0x04): scancode = 0x58 1466427412.161022: event type EV_SYN(0x00). So IR also works. Since Beelink X2 ships with a remote someone a bit familiar with this stuff could start now (read as: before we release Armbian 5.15) to add an appropriate config file we could then integrate into the build (but I have to admit that I'm such a NOOB regarding IR that I don't know how to deal with the information from this thread where I found how to check the scancodes)
    On a related note. The on/off button on Beelink X2 also uses the correct pin mapping. After installation of the acpid package this is possible:
    root@beelinkx2:/home/tk# acpi_listen button/power PBTN 00000080 00000000 So all we need to do is to define a shutdown action for the 'button/power' event, in the most simple form as follows:
    echo -e 'event=button/power\naction=/etc/acpi/' >/etc/acpi/events/powerbtn echo -e '#!/bin/bash\nshutdown -h now' >/etc/acpi/ chmod 755 /etc/acpi/ Then the simple press of the power button executes the script code in /etc/acpi/ (in the aforementioned example without a check -- but on an Orange Pi Lite I currently use as a backup device I added some code to check whether a backup is currently running delaying the shutdown until the task is finished). Of course anything else can also happen when the power button is pressed, it's just the execution of some script code (and the same applies to each and every Orange Pi out there too)
  17. Like
    manuti reacted to tkaiser in 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)   Low end   3 weeks ago I ordered 2 cheap USB3-Ethernet dongles (Realtek RTL8153 based and recommended by @Rodolfo):   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: Bus 001 Device 002: ID 0bda:8153 Realtek Semiconductor Corp.   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.
  18. Like
    manuti reacted to tkaiser in opi pc hangs file transfer to usb hdd   
    Me too. Please stop using Armbian now and use any of the other available OS images:
  19. Like
    manuti reacted to dimag0g in OpenGL on Mali GPU (BananaPi, OrangePi PC, etc)   
    I wish to share my research on getting OpenGL to work on Mali GPU. I realize Armbian focuses on server images, but I suppose many people would be interested nevertheless. I have a Banana Pi Pro and an Orange Pi PC, which both have a compatible GPU. Perhaps it will work on other boards as well.
    Here are the commands I used to get OpenGL to work.
    1. Install:
    # install GLX Gears, mesa GL and GLU libraries apt-get -y install mesa-utils # install development tools apt-get -y install build-essential automake pkg-config libtool ca-certificates git cmake subversion # install required libraries apt-get install libx11-dev libxext-dev xutils-dev libdrm-dev x11proto-xf86dri-dev libxfixes-dev # get source code git clone git clone git clone git clone git clone # install mali driver cd sunxi-mali                                                                    git submodule init                                                               git submodule update                                                             git pull                                                                         wget -O ./include/GLES2/gl2.h             wget -O ./include/GLES2/gl2ext.h    make config ABI=armhf VERSION=r3p0                                               mkdir /usr/lib/mali                                                              echo "/usr/lib/mali" > /etc/                             make -C include install                                                          make -C lib/mali prefix=/usr libdir='$(prefix)/lib/mali/' install            cd .. 2. Build
    # Step 1: build and install helper libraries cd libdri2 autoreconf -i ./configure --prefix=/usr make make install cd .. cd libump autoreconf -i ./configure --prefix=/usr make make install cd .. # Step 2: build video driver cd xf86-video-fbturbo autoreconf -i ./configure --prefix=/usr make make install cd .. # Step 3: build GL wrapper cd glshim cmake . make cp lib/ /usr/lib/ # replace the software GL library with the wrapper cd .. 3. Configure your system
    - configure your kernel to allocate memory for the GPU
    - make sure mali and mali_drm kernel modules are loaded
    - give your user permissions to access /dev/ump and /dev/mali
    - configure Xorg to use fbturbo driver
    4. Test:
    # run a basic test glxgears # install and run a GL benchmark apt-get -y install globs /usr/lib/globs/benchmarks/GL_pointz/gl_pointz # try to run a real game apt-get -y install billard-gl billard-gl This all worked out for me rather nicely. The only issue I have encountered is a segfault that many GL programs get when they shut down. I'm currently debugging this issue, but it would be helpful to know others experience it as well, and perhaps get some advice from people experienced in GLX or SDL.
    Edit: I know glxgears is not a real benchmark, but let me give you some numbers to make it clear what I'm talking about. Results are from Orange Pi PC clocked at 1296000 Hz (and are CPU-bound):
    user@bananapi:~$ glxgears LIBGL: Initialising glshim libGL: built on Jun 12 2016 06:12:01 LIBGL: Current folder is:/home/user libGL:loaded: libGL:loaded: 2074 frames in 5.0 seconds = 414.688 FPS 2071 frames in 5.0 seconds = 414.085 FPS 2070 frames in 5.0 seconds = 413.915 FPS ^C
  20. Like
    manuti reacted to tkaiser in Finishing vanilla kernel support for H3?   
    Hi all,
    since we're currently collecting tasks to be done by community to get a nice board (OPi Plus 2E) in return I thought I sum up where we currently are regarding working H3 OS images with mainline kernel:
    Our main showstoppers for releasing H3 images with mainline kernel are still: missing/non-working THS stuff (see explanation here), native Ethernet driver not finished and a few minor bits.
    My last attempt to check situation has been a few days ago. Since megi rebased his THS stuff (also containing the various USB and Ethernet patches) I chose his 4.6 branch to give it a try (see commit 224550b). Unfortunately I ran into kernel panics when testing on my OPi PC Plus and so I gave up again.
    But since we got another report (see below, issue #360) trying out the stuff on both OPi One and PC and reporting different/interesting results in the meantime I believe this THS stuff should be solveable quite easily and it's just one missing bit here or there. So this would be a great opportunity for someone claiming a task to finish:
    Get kernel 4.6 (or even better 4.7-rc) up and running including the following:
    Ethernet (required) USB, leds, serial and so on (required and works already since this is just .dts stuff) THS (required -- please also see issue #360)) WiFi (nice to have but then please both 8189ETV/8189FTV -- both patches for our legacy kernel are backported from mainline versions so it should be rather simple) HDMI (nice to have) SPI, I2C (nice to have, IIRC @martinayotte has everything up and running with 4.x already?) Anyone?   Edit: THS update:;
  21. Like
    manuti reacted to tkaiser in H3 board buyer's 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   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 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: Count of available USB ports:   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.   We have a nice sortable table in linux-sunxi wiki showing most of the important details:   Camera modules:   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.   Regarding current state of available camera modules for Oranges, BPi M2+ and NanoPi M1 please look through this thread:
  22. Like
    manuti reacted to tkaiser in H3 board buyer's guide   
    Since we're now dealing with a few more H3 devices and some vendors also provide OS images and users get confused a small note regarding kernel situation with H3 at the moment and also an update regarding performance relevant settings (by tweaking these intelligently H3 devices might run multiple times faster!).
      Mainline kernel:   The linux-sunxi guys are doing a great job writing all the stuff necessary from scratch and sending it upstream so that H3 and boards are more and more supported by the stock linux kernel available from For us at Armbian the missing Ethernet driver for H3 was the showstopper that prevented us releasing Armbian images with kernel 4.x so far.    In the meantime or since we had to realize how horribly some H3 boards might overheat (BPi M2+ is currently the worst example but it turned out that NanoPi M1 and Beelink X2 behave the same) missing THS support in mainline kernel is another important reason that prevents Armbian releases for H3 boards. We tried to run the boards downclocked to just 816 MHz just to realize recently that BPi M2+ with specific test workloads has to throttle down to 240 MHz (and needs to kill CPU cores so under worst case conditions we could drive the M2+ only with 2 cores at 240 MHz which is a really bad joke -- so we need throttling working with mainline kernel to release Armbian vanilla images to the public)   BSP kernel:   So while we're testing with mainine kernel stuff from time to time all we now have to release to endusers are some variants of Allwinner's Android kernel for H3 devices (called BSP kernel -- BSP is for 'board support package', that's an ugly tarball with an 3.4.39 kernel Allwinner throws at manufacturers who want to create H3 devices).   Allwinner's 1st BSP kernel variant:   Allwinner published 3.4.39 Android kernel sources last year here. All the official OS images for Orange Pis rely on this stuff (still version 3.4.39 and not even a fix for the rootmydevice security issue). This BSP variant also shows somewhat strange throttling settings (not throttling down while still running on all 4 CPU cores but killing CPU cores one after another without bringing them ever back without a reboot). So be prepared that you get horrible performance results with these settings (that explains the horribly low performance scores that are published on for various H3 based Orange Pi boards)   Loboris' kernel:   The aforementioned kernel sources are basically the stuff Boris Lovosevic (loboris) used to provide the first useable OS images for Orange Pis. He did a really great job fixing tons of issues (eg. enabling GBit Ethernet on OPi Plus or 1-Wire, camera support and so on). Unfortunately he was member of team overclocking so with his so called dvfs settings (dynamic voltage frequency scaling) the Oranges were overvolted (to be able to provide overclocking) and showed all sorts of strange symptoms (insanely high temperatures and stability issues). But this wasn't related to kernel functionality, just settings influencing power supply to the SoC/CPU and enabled overclocking.   Yann Dirrson's fork:   When we at Armbian started supporting H3 boards we relied on different kernel sources (ssvb, one member of the linux-sunxi community used Allwinner's original BSP sources, patched Mali support in to create a small OS image being able to test DRAM reliability. Another linux-sunxi guy forked this kernel tree and patched in a few more stuff (also some of loboris' great work) so we started using this fork as our basis.   1st Armbian legacy kernel:   Igor immediately started to patch the horribly outdated 3.4.39 kernel up to the most recent 3.4.y version (3.4.110 back then IIRC) and we threw in a bunch of other patches to improve this and that. Also as the result of still ongoing efforts to maximize performance/throttling settings Armbian shipped with totally different thermal settings which led in the end to pretty good performance of the boards (since we refrained from overvolting and developed sane settings)   Alwinner's 2nd BSP kernel variant:   When FriendlyARM announced their H3 based NanoPi M1 they also released a newer H3 user manual and also a new BSP kernel variant they obviously both got from Allwinner in the meantime. Jernej maintaining the unofficial H3 OpenELEC fork looked immediately through and spotted a lot of changes.    2nd Armbian legacy kernel:   So we (Armbian and jernej/OpenELEC) decided to switch to this newer BSP kernel, Igor cleaned up some stuff and again rebased all patches (up to 3.4.112 IIRC) to the new kernel sources and we adopted all other patches that were still relevant (we could drop a few). This way we could solve the ugly kswapd bug that plagued us before (one CPU core 100% active and eating up memory) and if I understood correctly also some HDMI/display area improved a lot.   Currently only Armbian and Jernej's unofficial OpenELEC fork use this kernel with all our many patches on top (maybe a few hundred security relevant and also a lot of functionality improvements): exactly 112 rather large patches that add support for various hardware, new features, many fixes)   The SinoVoip experience:   While all this happened Foxconn/SinoVoip released their BPi M2+ (a close clone of Orange Pi PC/Plus) and decided to rely on loboris' unmaintained and outdated 3.4.39 kernel for whatever reasons. Since BPi M2+ doesn't use the superiour voltage regulator used on the bigger Oranges at least no overvolting/overclocking is possible here. But for yet unknown reasons this board overheats terribly so we at Armbian adjusted our throttling settings very very low so be prepared that with official SinoVoip OS images strange things might happen when you put some load on this board.   Further improvements:   In the meantime we further improved thermal/performance behaviour and patched also the kernel so that when the board recovers from heavy overheating killed CPU cores are brought back when temperatures are normal again. In addition to that we provide way more cpufreq steps to allow finetuning throttling behaviour based on environmental conditions (as example: when you're running your device in a small enclosure more throttling will occur and you will benefit from more cpufreq steps in lower regions around 900-1000 MHz. If you go the other route and add a good heatsink and some airflow through a fan Armbian will provide you with a tool able to unlook higher cpufreq steps later this year on supported boards)   Summary:   Now a short overview about kernel situation combined with thermal/performance settings: Official Orange Pi images from Xunlong: 3.4.39, no rootmydevice fix, tons of security fixes missing, performance issues after medium load due to killed CPU cores Orange Pi images from loboris: 3.4.39, no rootmydevice fix, tons of security fixes missing, thermal/stability problems due to overvolting, missing sane cpufreq steps (not possible to use 1.3GHz for example) Official Banana Pi M2+ images from SinoVoip: 3.4.39, rootmydevice fixed, tons of security fixes missing, performance issues after higher load due to killed CPU cores Official NanoPi M1 images from FriendlyARM: 3.4.39, still no rootmydevice fix, tons of security fixes missing, unknown status regarding thermal/performance settings Armbian/OpenELEC: 3.4.112, rootmydevice fixed within hours (not an issue on OpenELEC), applied all available fixes from 3.4.y LTS release, constantly improving thermal settings (which means: performance)
  23. Like
    manuti reacted to tkaiser in Armbian SD card backup   
    Just as an addition since as usual stuff already exists on the internet:
    Regarding the combination of rsync with btrfs: And in case mainline kernel is used and a custom Armbian image not using ext4 but btrfs instead the whole approach will be even more efficient since then 'btrfs send/receive' could be used between SBC and backup host:
  24. Like
    manuti reacted to Igor in How to add a program to the repository?   
    For private projects consider or similar. Those services are reliable and usually free for such usage.
  25. Like
    manuti reacted to tkaiser in Orange Pi Lite - now available   
    Now information collection regarding OPi Lite is almost done. I tried to enhance the wiki article for Orange Pi One combining it with Lite and also tried to add everything that's known/relevant now:
    Please help improve state of information/documentation since I made mistakes for sure (as usual ). Get a linux-sunxi account please and correct what's wrong. Thx.