tkaiser

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)

Proper benchmarking is a complex issue. Proper presentation too. I sign on this.
 
I was only trying to look from other perspective and emphasize that they don't even try to do it right since people don't even try to doubt or think when see such comparisons. Even compared to other boards. Using of proper scientific method could produce unwanted results so you rather produce results you wanted

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)

For /etc/update-motd.d/30-sysinfo I noticed it likes to say my system is up 6 seconds and then when I check with uptime I notice it's wrong and has been up for hours or over a day.
Just curious if there is a reason for not doing it in a way similar to this?
function displaytime {     # we need dedicated function     local X=$(/usr/bin/uptime -p)     printf "Up time:       "     printf "\x1B[92m%s\x1B[0m\t\t" "$X" }

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

Here are the patches I've prepared for getting I2C and SPI on OrangePiPC under 4.4.4.
 
BTW, Tkaiser, I wouldn't been able to add the last I2C (TWI_R where the PMIC is attached) because lack of PL* pins in the current H3 pinctrl.
I would'nt like start new task for that since the mainline guys already working to have another H3 R_PinCtrl : https://lkml.org/lkml/2016/2/1/150
orangepipc-patches.zip

Igor loves minimalism On the download page the simple ">_" sign for Jessie means "minimal/CLI" and the display symbol for the Trusty image below means "desktop/GUI". So choose the Jessie image but read the FAQ before (you won't find it either, it's the white bar labeled "Questions?" below "Check forum for more info!")
 
If you're the type of guy parsing 'dpkg -l' lists, I would suggest looking better into our build system since we're providing the ability for experienced users to create their distro of choice: default packages can be edited if you know what you're doing (but things will break for sure if you do this the first time).
 
BTW: Before you start with tweaking/tuning defaults better stay with them and only when you experience problems think about tweaking something. There are months of effort contained in Armbian and the key to a more responsive/faster system is not stripping down the package list but reasonable settings. Armbian realises the "work smarter not harder" approach not only for humans but also for their SBC 

The url is here: http://sprunge.us/dFBB
 
I will place this new script in /etc/init.d and report back the behavior.
 
EDIT:
 
For now, with new script re-enabled:
$ sudo systemctl status armhwinfo â— armhwinfo.service - LSB: Armbian gathering informations about hardware    Loaded: loaded (/etc/init.d/armhwinfo)    Active: active (exited) since ven. 2016-03-04 09:12:41 RET; 6s ago   Process: 2854 ExecStart=/etc/init.d/armhwinfo start (code=exited, status=0/SUCCESS) mars 04 09:12:30 xxxxxxxx armhwinfo[2854]: [ ok ] Setting cfg I/O scheduler for sda mars 04 09:12:30 xxxxxxxx armhwinfo[2854]: [ ok ] Setting noop I/O scheduler for mmcblk0 mars 04 09:12:31 xxxxxxxx armhwinfo[2854]: [ ok ] Starting ARM hardware info: Cubieboard mars 04 09:12:41 xxxxxxxx systemd[1]: Started LSB: Armbian gathering informations about hardware.

IIRC this was introduced when we changed the build process of the desktop image. We should either fix that or set /tmp back to 777 automatically when finished.
 
 
Yes, we also tried to introduce 'crash detection' with the next release (enable verbose messages automatically after a crash but unfortubately I messed it up )
 
But in your case you had troubles with loop devices on your build host that are currently ignored by our build system and let then to an image with fs errors.

Definitely. Since adduser faced the same problem due to read-only rootfs it exited != 0 and then a reboot occured.
 
 
Also not nice and it doesn't help in such situations either. We must take care of more things, check /etc/mtab for obvious errors and so on.
 
At least we should soon implement logging verbosity by checking /boot/.verbose from u-boot (who will do this?) and should definitely check for r/o filesystem, present a warning and try to deal reasonable with such a situation in the other involved scripts.
 
When I ran into that issue some time ago it wasn't even possible to change the root pwd on 1st login (authentication error without further notification that the reason was r/o rootfs). This seems to be different in jobenvil's case -- see top of thread (maybe jessie acting differently than wheezy?)
 
EDIT: And maybe a bit more error handling in the build process too -- see below

IIRC this was introduced when we changed the build process of the desktop image. We should either fix that or set /tmp back to 777 automatically when finished.
 
 
Yes, we also tried to introduce 'crash detection' with the next release (enable verbose messages automatically after a crash but unfortubately I messed it up )
 
But in your case you had troubles with loop devices on your build host that are currently ignored by our build system and let then to an image with fs errors.

Yes, that was my intention, but unfortunately, it doesn't seem to be an easy task. I will try to dig further ...

Definitely. Since adduser faced the same problem due to read-only rootfs it exited != 0 and then a reboot occured.
 
 
Also not nice and it doesn't help in such situations either. We must take care of more things, check /etc/mtab for obvious errors and so on.
 
At least we should soon implement logging verbosity by checking /boot/.verbose from u-boot (who will do this?) and should definitely check for r/o filesystem, present a warning and try to deal reasonable with such a situation in the other involved scripts.
 
When I ran into that issue some time ago it wasn't even possible to change the root pwd on 1st login (authentication error without further notification that the reason was r/o rootfs). This seems to be different in jobenvil's case -- see top of thread (maybe jessie acting differently than wheezy?)
 
EDIT: And maybe a bit more error handling in the build process too -- see below

Care to give an example? We tried to eliminate possible illegal characters but maybe this didn't worked out. And then you're in a reboot trap
 
Can you please try to adjust line 8 in lib/scripts/check_first_login.sh with
RealUserName="$(echo "${username}" | tr -d -c '[:alpha:]' | tr '[:upper:]' '[:lower:]')" and try it again using the same username? Or better replace the whole file temporarely with the contents from http://pastebin.com/raw/vdUeXndC then try it again and post /var/log/user-creation.log somewhere? Thx

Might not happen that soon. While we're preparing the new 64-bit architecture (which will take some time) the current state of Linux on A64 permits building OS images for end users
 
BTW: Since people started to take the silly sysbench result above (3.25 seconds on Pine64 vs. 49 on RPi 3 -- only possible conclusion: forget about this 'benchmark' from now on) to compare with the ODROID-C2 I simply unlocked the higher CPU frequencies and measured again: now 2.8 seconds or ~15% better -- all just by modifying thermal throttling behaviour). It should be obvious that any kind of benchmarking for A64 now is plain nonsense. The aforementioned tests are only suited to demonstrate how misleading this sort of pseudo benchmarking is.

Good evening,
 
I am just providing some feedback about orange pi 2:
 
Used git commit: b3489368eededc025d343fd220b022ca08f52338, compiled into ubuntu desktop
orange pi 2 detection: orange pi 2 mini (on Orange pi 2 h3 hardware) - works well
no errors when reboot, boot to desktop without problems (small overscan on my TV - no problem at all). I was also able to enable audio over hdmi.
Wi-Fi works well, system seems to be stable.
 
Thank You for great work.
 
Can I help with something - send logs, make some tests before new version release etc?
 
Have a nice day.
 
JK

What do you really expect if you try to increase max. cpufreq from 1296 to 1536 MHz? 18% more $something?
 
The important steps to get more 'real world' performance happen somewhere else. 'Work smarter not harder' applies not only to humans but also to the combination of hardware and software.
 
If you really just buy numbers then it's up to you to fork our repo and tweak this overclocking/overvolting stuff in both kernel sources and fex settings. Everything's documented (check loboris github repo) and you're free to do any harm to your device if you want
 
But please don't expect support from us. We're more interested in stability and ease of use than overclocking...

I do not know if i understand this question the right way. After you have connected the DAC there are three soundcards
aplay -l will show us this:
root@orangepipc:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: audiocodec [audiocodec], device 0: SUNXI-CODEC sndcodec-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: snddaudio [snddaudio], device 0: SUNXI-TDM0 snddaudio-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: sndhdmi [sndhdmi], device 0: SUNXI-HDMIAUDIO sndhdmi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 In this case it is possible to access the i2s card with hw:1 or better  hw:snddaudio in your audio applications. (Be aware , that you can see this three cards even when only the Modules are loaded,[pcm0]
daudio_used = 1 is changed in the fex File and there is no Card connected)
 
Regards

I am able to test SPI successfully with 5.04 release.
Device  used : RFID Reader RC522
 
Here is the steps to followed :
 
1. Connection
 
     Mifare_RC522_RFID  OP One
     MOSI ——————————> pin 19
     MISO ——————————-> pin 21
     SCLK ——————————-> pin 23
     SDA ——————————–> pin 24
     RST ———————————> pin 22
     IRQ ———————————-> NONE
 
2. Check device ls /dev/spidev0.0 ( Armbian 5.04 gives it out of the box)
 
3) Install python dev
     apt-get install python-dev
 
4) Install orangepi_PC_gpio_pyH3 Library
      git clone https://github.com/duxingkei33/orangepi_PC_gpio_pyH3.git
      cd orangepi_PC_gpio_pyH3
      python setup.py install
 
5) Install SPI-Py Library
    git clone https://github.com/lthiery/SPI-Py.git
    cd SPI-Py
     python setup.py install
 
6) Install MFRC522-python
     git clone https://github.com/rasplay/MFRC522-python.git
 
7)To read id data:
    cd MFRC522-python
    edit  MFRC522.py and comment out line 108.109.110  and 356( as shown below)
          # GPIO.setmode(GPIO.BOARD)
          #GPIO.setup(22, GPIO.OUT)
          #GPIO.output(self.NRSTPD, 1)
    
           #GPIO.output(self.NRSTPD, 1)
 
        python read.py
 
root@orangepione:~/MFRC522-python# python read.py
Card read UID: 193,11,21,149,74
 

http://pastebin.com/hb4dUSMf- orange pi 2/ mini 2 both get same only model name change.

Boot is very long 2min of black screen then is starting after ln to orangepi2 script

tkaiser has built a new Kernel with i2s Modules. With this Kernel and some cheap DAC  e.g. (http://www.ebay.de/itm/Audiophonics-I2S-DAC-ES9023-Sabre-to-Analog-24bit-192KHZ-fur-Raspberry-PI-/291573327639?hash=item43e31fe717:g:TTwAAOSw~OdVZXtm)  it is possible to get good quality sound  out of the Orange Pis. After installing the Kernel
Two Things have to be changed in the fex File:
 
Change Directory to boot:
cd /boot Turn the script.bin to a fex-File and open it in an Editor
sudo bin2fex script.bin script.fex sudo nano script.fex Now change the following Entries:
[twi1] twi_used = 1 to
[twi1] twi_used = 0 and
[pcm0] daudio_used = 0 to
[pcm0] daudio_used = 1 Save your changes and do :
sudo fex2bin script.fex script.bin After a reboot your done.
 
 
I do not know for what the Section [twi1] is good for, i hope nothing serious..
This connections have to be made:
 
5V > Pin 2
Gnd > Pin6
BCK > Pin 27
LRCK > Pin 28
Data > Pin37
 
(according to the Picture "giachi" has posted on the diyaudio Forum http://www.diyaudio.com/forums/pc-based/285427-i2s-connection-orange-dac.html#post4587580
see below)
 
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

On the back side of OPiOne PCB you can find also TVOut signal and MUTE which is used to disable audio amplifier but of course OPiOne has no such on board and even OPiPC had this unit removed.

orangepi@orangepipc:~$ zgrep CONFIG_FW_LOADER_USER_HELPER /proc/config.gz # CONFIG_FW_LOADER_USER_HELPER is not set CONFIG_FW_LOADER=yCONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_FW_LOADER_USER_HELPER is not set