Tido

MicroUSB power connector !?!
Why didn't you go for any other H3 SBC ?

More about NanoPi M3 - USB ports are behind USB hub...
 
Very specific board with high enough price, "Applications" tab on their site tells enough use cases where this price is OK. Unless you need FPGA  or RISC co-processor and you know how to work with this stuff, you don't need this board.
 
Using as headless server: NAS with 2 HDD drives for storing stuff (Samba, rsync, syncthing), headless music server (mpd controlled via IR remote or Android app).
 
Waiting for Ethernet and USB support in mainline kernel, meanwhile it's useful for testing intermediate Armbian releases.
 
Waiting for the bright future (at least mainline u-boot with SPL and basic support in mainline kernel).
 
Turn lights on and off with IR remote using connected IR sensor and nRF24L01+ module
Display stuff (weather forecast, date&time, new e-mail notifications and some other things) on HD44780-compatible LCD display.

Yes, return it.
No 5GHz and other technical limitations.

Except that BCM2835 in RPI Zero isn't ARMv7, it's ARMv6 (@0:40 in video) 
But it's hard to compare to the board that you can't buy for its price (without additional "starter kit" crap): http://whereismypizero.com/

This guy knows his business 1min 26 sec:
Unfortunately, you cannot power OPi  with Micro USB :D

You should try to adopt our new dvfs settings manually unless we roll out next Armbian version where this is fixed: https://github.com/igorpecovnik/lib/issues/284#issuecomment-216655399
 
And I still don't get it why people don't get it that they bought Orange Pi One only for one single reason: Since it's dirt cheap! Do you really want lowest price possible combined with as much components as possible?
 
Selling cheap while delivering hardware quality seems to be Xunlong's selling point (at least software/support clearly aren't). So you end up with compromises. You could complain that there aren't mounting holes for some sort of a 'standard heatsink' (which does not even exists) but where's the point demanding a part that increases cost of the board by 5% when the board's only selling point is the price and you can add this stuff yourself pretty easy?
 
BTW: We're still talking about dirt cheap SBCs equipped with dirt cheap SoCs that were made for Android OTT boxes (read as: Not designed to run CPU intensive stuff anyway since HW acceleration helps with video encoding/decoding and 3D acceleration). No one knows what to expect regarding longevity if H3 runs constantly under full load. No one knows whether higher temperatures decrease the SoC's lifespan more or higher VDD_CPUX voltage. It's simply unknown since it would take months/years and at least 100 devices to test through.
 
But it might be possible that your device without heatsink and with the new THS settings applied lives longer at 90°C (and 816MHz or 1008MHz @ 1.1V) then at 70°C (and 1200MHz @ 1.3V). No one knows and it's currently all about feelings (read as: most likely wrong assumptions).
 
If I would care about longevity (which I don't do) and use OPi One for such purposes (which I never would since OPi PC is the better device due to better voltage regulator there) then I would immediately try to explore the highest stable clockspeed at 1.1V VDD_CPUX (might be 1008MHz or even more), adjust the dvfs table and limit maximum cpufreq to this. Since http://asic-soc.blogspot.de/2008/03/process-variations-and-static-timing.html

Thank you. 

Our approach is to provide a stable base system, not to maintain wizards for everything. We provide some basic system configurations - for setting display, to install into NAND / eMMC / USB / SATA, to install Rpi monitor etc ... by default. The rest ...
 
I maintain one after-install script for installing various services: 

https://github.com/igorpecovnik/Debian-micro-home-server
 
This is similar but it is a separate project since you can install this virtually on anything that runs Debian / Ubuntu and clones.

Also as an addition the CNX announcement (on CNX in the comments section from time to time real information will be added/collected).
 
It should be noted that the count of solder points on the PCB varies compared to Orange Pi One (obviously since Lite exposes one more USB port and IR and mic) and that currently no one knows whether Xunlong took the opportunity to expose Ethernet RX/TX to solder/test points.

In addition to this (just to have all useful info available here), compared to OPi One it has built-in microphone, 2 USB A sockets and IR Receiver.
Wi-Fi module is Realtek b/g/n of some sort with external antenna (u.FL socket), no "onboard" antenna.

Don't forget Zador's great work and everybody else of course :-)
 
retro games machine; I prefer something with Bluetooth to connect my PlayStation 3 controller for the Pi you find working images:

1. Select your images ( attach files -> button : choose files ) and upload them to the forum 
 

 

 
2. Insert the displayed attachments into the forum text (Add to Post)
 

 
 
3. Preview and upload the post

Hmm... I'm a bit lost why you post news related to 'Windows 10 on Intel' in a forum that's known for 'Linux on ARM'? At least one thing is clear: Many many of their users will get in serious trouble since just another vendor made the mistake to use the most crappy connector for DC-IN: Micro-USB. At least they were smart enough to use a LED as 'insufficient power' indicator unlike the Pine64 people for example...
 
Me personally would not buy anything that needs more than a few mA and misuses the Micro USB plug for DC-IN (and I also have the UP board with a slower Atom but focus on Linux instead).

hi,
 
only for info:
The DPO_RT5572_LinuxSTA_2.6.1.3_20121022.tar.gz / rt5572sta.ko -stuff does not work with sunxi-3.4.10x-kernel.
 
 
I got this "ralink rt5572" on kernel 3.4.10x to work with driver backports:
echo "see:https://backports.wi....php/Main_Page"
wget https://www.kernel.o....11.8-1.tar.bz2
tar xvf backports-3.12.8-1.tar.xz
cd backports-3.12.8-1
make defconfig-wifi
time make -J2
echo "BACKUP YOUR old 3.4.10x-modules in /lib/modules/3.4.10xy /lib/modules/3.4.10xy_backup to  if you want to switch back...ok?"
read
make install
reboot
 
...............................................................................................
root@Dev:~# modinfo rt2800usb | grep "version\|5572"
version:        backported from Linux (v3.12.8-0-g97f15f1) using backports v3.12.8-1-0-geb41fad
version:        2.3.0
srcversion:     D0035750636933A8C0E52C5
alias:          usb:v148Fp5572d*dc*dsc*dp*ic*isc*ip*
vermagic:       3.4.108schaschr1+ SMP preempt mod_unload modversions ARMv7 p2v8
 
 
regards

C.H.I.P. is like RPi Zero
You buy it, just because it is soooo cheap.
Than you find out that it is worthless and it sits on a shelf and collects dust.

If I understand correctly, the implications of a fixed voltage regulator is that the BPi M2+ will need a fan to achieve the same CPU performance under load as the OPI PC AND it won't support a low power 'idle'.  I would consider that a FATAL FLAW for most ARM board use-cases.

I have just received cheap WiFi dongle (paid $1.6 in Aliexpress). I don't know yet if I will solder it directly to Orange Pi One extra USB exposed solder points.
Currently I want to share how to disassemble this dongle without damaging anything.
Watch my short tutorial video:

Using this module without the case significantly improves WiFi signal quality and range. Finally it would be possible to solder external antenna socket.
Some photos:

Why do you ask such moronic questions instead of starting to think about what you're doing?! If you don't want to spend a bit of brain on this stuff then use a spinning disk and waste your time with fatrace.
 
Otherwise learn Linux basics (symlinks for example -- they point from here to there -- or fstab where you specify mount points for partitions), think about using mainline kernel (since you will never get video HW acceleration the way you deal with it! Cedrus/vdpau is already working with legacy kernel and OpenELEC is a dedicated minimal distro that can't be mixed with Armbian. So what are you talking about anyway?!) and use transparent filesystem compression.
 
Again: A Samsung EVO TF card with 64GB costs less than $20 bucks and performance can't be much better compared to more expensive cards (since sequential write/read speeds are limited by the board and since random I/O performance benefits from the large capacity of this card). Since it's SDXC I would suspect cards with 128GB/256GB should also work.
 
If I were you I would analyze the storage requirements and put most if not all on the SD card using btrfs with LZO compression. And only non 24/7 stuff on the HDD (the videos you want to watch from time to time and stuff like that). BTW: /var/www on HDD seems to be a very bad idea. Use a card with high IOPS, put all the stuff there and only static content that is not accessed frequently on a HDD that you mount as /var/www/static-content/ for example. It's Linux so you're free to optimize/adjust everything to your needs!

I don't want to argue with either of you, but I enabled fanotify to sun4i and sun7i legacy kernels, so it should be available in new kernel release. 

to repeat wrong information does not make it correct.
 
There are two questionmarks written by me, one you answered, the other I answered by my self, "this is quite obviously".
 
 
WTF, should I care about 8b10b - does it change the number by factor 10? If not I give a BS about it I just want to have +- figure in MB.
(symbol Mbit/s or Mb/s, often abbreviated "Mbps") the / is missing I give you that, but based on the calculation you should actually understand it anyway.
 
 
 
Again wrong. What I was refering to is the fact that with 32-Bit you can easily address RAM upto 3 or 4 GB, no need for 64-bit.
 
If you had listen to the podcast I recommended you - you already knew that it is not their intention to do so (more than1GB & Aarch64).

@KH Goh  I suggest you send a sample to tkaiser - so he can try, but I must warn you: He is brutally honest. So you better attach a heat sink to it before you send it   
 
ROTFL, I just watch the movie on Kickass Krissy the marketing chick has most probably no clue what she is talking about on sec. 0:45 - but she is sweet,
so who cares   
I wonder if Kai Kreuzer (german) knows WTF he is talking about - this is nor Intel or AMD and of course his openHAB will never need to use 4k Video.

Nope, what he ran into is just thermal throttling and different strategies to deal with. The benchmark results he uses show clearly that Allwinner's kernel killed CPU cores (on the Plus more early than on the PC and that's where the 'performance' difference originates from -- it could've been also the other way around and then the PC would be slower than the Plus according to his numbers, this alone disqualifies using these numbers as indicators for hardware performance).
 
And while this finding is useful to be able to blame the software (the throttling strategy encoded into script.bin in this case) it's just weird to use these results as a performance index for the hardware. But that's what happens all the time, as Brendan Gregg calls it:
 
     Casual benchmarking: you benchmark A, but actually measure B, and conclude you've measured C.
 
 
And BTW the stuff end users are interested in (HW accelerated video decoding, GPU acceleration for gaming) isn't covered by these general purpose benchmarks at all. So relying on benchmarks that solve exotic mathematical problems is inappropriate when you try to get an idea how the SBC you want to buy behaves when it's about the real 'use cases'.
 
Good example: switching from Ubuntu Trusty to Debian Jessie with the next Armbian desktop release won't change anything regarding irrelevant Phoronix benchmark tests. But for our users it will make a huge difference since we can now ship with an up-to-date mpv package which allows HW accelerated video decoding. That's all just software, benchmark results remain the same but performance from an end user perspective explodes (no more stuttering video but smoothly even with high bit rates).

It's important to believe blindly in numbers! At least when you try to be mislead as much as possible!
 
Yesterday Michael Larabel from Phoronix fired up his usual set of passive benchmarking tests for the new Raspberry Pi 3 and he still uses rather questionable results for other boards to compare with (he claims that it would be sufficient to use a board with 'factory settings', run a set of synthetic benchmarks, don't analyse the results or even think about whether they could be wrong and treat the results as the truth)
 

 
RPi 3 is 4 times faster than OPi PC and 6 times faster than OPi Plus? Really?
 
If you just try to think about these graphs for a second it's obvious that there must be something wrong: Testing Orange Pi PC and Plus individually already makes no sense at all (same SoC, same settings --> same performance results to be expected) and publishing results that vary that much is alarming: either your benchmark must be wrong or the conditions or the tester. If you just think a second it's obvious that Orange Pi PC and Plus have to be faster than Banana Pi M2 (also an Allwinner ARMv7 SoC clocked a bit slower) and that you should drop any results if you experience a difference of more than 10% between both boards that must perform identical.
 
So I took our Armbian 5.05 release candidate and tested 2 of Phoronix' benchmarks on an H3 based Orange Pi (and then stopped this waste of time):
 
C-Ray: 340 with Armbian vs. 1425 according to Phoronix. Using Armbian increased the performance by over 400% (if you're dumb enough to rely on 'benchmarking gone wrong')
John the Ripper: 558 with Armbian vs. 315 according to Phoronix. Using Armbian increased the performance by 77% (if you're dumb enough to rely on 'benchmarking gone wrong')
 
Confusing! Why is Armbian way faster?! And why does choosing Armbian speeds up your Orange Pi in one case over 4 times and in the other case just by 77%? Let's have a closer look:
 
How does Armbian differ:
We are able to use 1.3GHz as CPU clockspeed (might speed things up) For reliability reasons we clock the DRAM lower (might slow things down) Most importantly: We don't use braindead thermal throttling settings (and I used a heatsink/fan) And the latter is the most important issue that Michael Larabel seems to miss at all when he uses the 'benchmark' results he collected sometimes ago to compare between different hardware. It's 2016 now! Each and every more recent SoC is a throttling candidate. This has to be taken into account if you want to benchmark a SoC or a board. If you ignore this your results are plain bullshit (just like Michael's).
 
When he tried to 'benchmark' Orange Pi PC and Plus he obviously ran into the problem that the vendor's budget cooling settings favoured killing CPU cores instead of thermal throttling so he obviously ended up with just one active CPU core left after some time of testing. And while this was an important finding (OS images for Orange Pis all crap more or less back then and negatively influencing performance) it's also important that this is nothing the hardware has to be blamed for.
 
The very same board running with Armbian performs more than four times faster! Think about. So obviously the benchmarks Phoronix recommends do not test the hardware but something else instead.
 
To be clear: the Phoronix test suite is fantastic when used correctly. That means ACTIVE BENCHMARKING and not collecting meaningless numbers and then relying on these worthless numbers to draw the wrong conclusions. When using the Phoronix test suite correctly you can identify performance bottlenecks and boundary conditions that affect performance easily (wrong cpufreq governor, killed CPU cores, thermal throttling, wrong settings, whatever). And also what to do to increase performance (tweaking compiler/scheduler settings, constantly trying out to optimise things until it works better).
 
The worst thing you could do with the Phoronix test suite is to collect numbers without meaning (passive benchmarking) and then use them to draw the wrong conclusions (that's what most of Phoronix' users including the author of the test suite do all the times).
 
Back to the origin again: We started with the Raspberry Pi 3 and 'benchmarking gone wrong' the Phoronix way. You really should take the numbers Michael/Phoronix published with a grain of salt since he neither mentioned whether throttling happened nor he commented on the consequences for the RPi 3 if the RPi foundation understands that it's necessary to provide a Raspbian version that is ARMv8 optimised.
 
The RPi foundation claimed the new RPi 3 would outperform the RPi 2 by 50% using questionable sysbench results. If they would've optimised their Raspbian code base for ARMv8 they could claim the RPi 3 would be at least 15 times faster. Why? Because benchmarks are always wrong and using sysbench (that calculates prime numbers) can't be used any more to compare between different ARM architectures (or architectures in general): http://forum.odroid.com/viewtopic.php?f=136&t=19158(I'm really curious whether Phoronix gets that when 'benchmarking' ODROID C2)
 
TL;DR: Benchmarking is fine as long as you use it to optimise software and to rule out insufficient hardware. When used wrong it's misleading (unfortunately that happens most of the time)

Hi everyone!
 
I was asked by tkaiser to share something about my PHP control of GPIO pins. I can tell you that I will be happy to do so. Mostly because I'm really extremly good in one thing and that is forgetting how i did something. Now let's cut bulls**t down and start with small introduction of what I'm up to. I'll decsribe what I'm doing and what is working for me so it should all click together as project documentation and tutorial. Also all I'm going to describe is being done on Cubieboard2 (A20) but i guess that it can work almost on any ARM SBC running Debian or Ubuntu.
 
Introduction / Motivation
 
Basically, I'm really interested in connecting low-level hardware to high-level software applications. Why? Why throw some rellays on 8-bit atmega, connect the whole contraption to internet and control your lamp from wherever in the world? Well... because we can and also why not! So with this mindset, all that Raspberry Pi hype and working atmega contraption on my table I decided to buy Cubieboard2 back in 2013. Aaaand it was the most stupid thing I could do. Support absolute zero,community non-existent and bootable images were unusable. But it was nice dust collector running Android! Long story short, few weeks ago I came across Armbian, saw how active and supported it is and how it spans over multiple boards. Bingo, this is what I need for doing another cool thing. Standalone internet connected GPIO device that could be used by multiple devices / apps without any special driver or communication protocol and whatever else.
 
Project description
 
Whole idea is that Cubieboard will run webserver with PHP application. This application will provide API that will allow GPIO control using http protocol and GET requests. Security here is not a concern as all of this will be hidden behind NAT in secured private LAN.
 
Preparations
 
Let's assume that you have clean install of Armbian 5.0 with Legacy kernel 3.4.110 running on your A10 or A20 board. Very first thing to do is to decide how many GPIO pins and which one you want to use. Most if not all pins that you have physically availible have more than one function. UART, eMMC, SPI, I2C, LCD and many other connections. Basically you need to look into documentation of your board and check if you can use your chosen pins as GPIO instead of thier original purpose. When you have this solved you need to modify script.bin located in /boot. I will take this short way. Take script.bin, convert it to fex using sunxi-tool bin2fex, add your chosen pins into [gpio_para] section, convert modified fex back into bin, put it back to /boot, reboot board. More about this can be found here.
 
After you prepared your pins in script.bin it's about time to get things rolling. I recommend to run first this two commands if your install is as clean as holy water
apt-get update apt-get upgrade Apache and PHP5 installation
 
This is easy step as we do not need any configuration and defaults will do just fine. Execute following command
apt-get install apache2 php5 FTP server instalation (optional)
 
This is optional but will help with uploading php files to board. First install ProFTPd as standalone server.
apt-get install proftpd Now we need to configure ftp server. I will save you labor, config you need is attached just replace original one in /etc/proftpd/proftpd.conf with it. After you replace config restart proftpd
service proftpd restart Next you need to create FTP account that will be used for connection to board via FTP. First lets create group named ftpgroup
addgroup ftpgroup Now we add user and add it to the ftpgroup
adduser ftpuser -shell /bin/false -home /var/www/html adduser ftpuser ftpgroup And last thing is to make this ftpuser owner of /var/www/html
chown -R ftpuser:ftpgroup /var/www/html Done. FTP is working now and you can connect and upload PHP files via Total Commander or similar file manager.
 
Link GPIO to web directory
 
If we want control GPIO from PHP we need to make GPIO accessible from web directory. Therefore we have to create symlink from our web directory to GPIO folder
ln -s /sys/class/gpio /var/www/html/gpio Setting permissions
 
Now we need to set permissions to allow our PHP scripts access GPIO in full scale. Let's start with exporting and unexporting pins from PHP. To do so user www-data have to be able to write into /sys/class/gpio/export and /sys/class/gpio/unexport. We can achieve this by making www-data sudoer. Run this command
visudo and in section # User priviledge specification add following line under line with root
www-data ALL=NOPASSWD: ALL Save and exit.
 
Accessing GPIO pins from PHP
 
Here is example code how to access GPIO pin from PHP.
shell_exec("sudo bash -c 'echo 37 > gpio/export'"); shell_exec("sudo bash -c 'echo out > gpio/gpio37/direction'"); shell_exec("sudo bash -c 'echo 1 > gpio/gpio37/value'"); That's all for today. If you are interested I can also write up something about PHP library itself and API possibly too.
new_proftpd.zip

Exactly. There are too many of them ... I also got a Cubieboard 4 (A80) here which actually might work with our sun8i kernel   ... but we don't have u-boot.

Hello,
 
I finally managed to make hardware video acceleration work on latest debian jessie (headless) armbian image.
 
In short, steps were :
0) prepare the bananapro and the jessie image for video.
1) get a working Xorg saver using fbturbo driver with g2d enabled.
2) install libvdpau-sunxi from its source and its dependencies, from some repositories.
3) compile from source the latest mpv.
 
Here is what I do :
 
An hdmi screen is plugged to the bananapro which is itself connected directly to my laptop.
The test console is visible on the screen.
 
I log into the bananapro from my laptop through ssh. I run startx from there.
You need to reconfigure x11-common because access to the X11 service is only accessible to console users.
I then chose to grant access to everyone which is probably not good for security : better ideas are welcome !
 
The hdmi screen gets filled by the X11 server with a default application, builtin xterm I guess. Could be something else more useful, I do not know where to configure that.
Check in the Xorg.0.log that fbturbo works with GED enabled.
 
Then, login again through ssh into the bananapi, modify the DISPLAY variable to point to the local display (should be "export DISPLAY=:0"),
then run "mpv --vo=vdpau --hwdec=vdpau --hwdec-codecs=all big_buck_bunny_1080p_H264_AAC_25fps_7200K.MP4
(put all these options  in ~/.config/mpv/mpv.conf)
 
it should run smoothly on the hdmi screen. you can control the video (backward forward pause) from your laptop with the keyboard shortcut.
 
when displaying the video : mpv takes 15-20% of the cpu power and X11 about the same. I do not know if this is good or bad ??? if it should be more or less.
 
Want to adjust the sound ? Just login again through ssh, do not touch the DISPLAY for that time and launch your sound control application, e.g. pavucontrol for pulseaudio.
As you did not touch the DISPLAY for that ssh session, the application window will be forwarded to your local laptop screen.
 
For the moment, the only issue is that video are displayed a bit too darker  . It is quite visible with the aformentioned test video.
It is not a screen problem, the problem seems to be in  mpv and/or libvdpau-sunxi although I cannot confirm it, I hope there is an mpv option to fix this (not investigated yet).
 
As stated several times in many different places : no need to use the mali sunxi driver. I will try later if it compiles and if it brings something.
 
When you start X11, the mouse is screen centered, there are some options in mpv to hide it, you may also use xdotool (on command line) to put it in one corner.
 
Hopes this helps. I did not mention all steps in details, feel free to ask and comments are welcome.
 
Best regards