tkaiser

The button is configured here and by default it is defined to enter suspend to RAM state. Unfortunately I forgot how to define the action (must have been back in February when we changed that). You could try to test acpid out and report back.

I will try the modified fex on a OPi Lite when I get things wrapped up later today... 

donation made for 50 euros - not much but its what i got.

Thx for the offer. Please compare the value of an hour of development work with hardware costs for those boards and decide then again regarding donations
 
At the moment nothing is known about compatibility between 8189ETV as used before and 8189FTV now so the whole approach to get this stuff up and running might waste a few hours easily...

AFAIK @lex provided a more improved version here (already as patch that should apply flawlessly). Thread/discussion here: http://forum.armbian.com/index.php/topic/996-gc2035-driver-update-320x240640x480-20-fps/

I've neither found this nor fixed the code -- I just sat in a beergarden watching others do the work, wrote a summary later and also informed affected vendors where possible (LinkSprite and CubieTech still ignoring the issue and SinoVoip as usual providing a fix in the most complicated way so 99,9% of their users are still affected by exploits targeting this vulnerability, same applies most probably to 100% of Xunlong/loboris OS image users).
 
So kudos to the people who discovered this and fixed it!
 
We should take this as a reminder why 'legacy' kernels should be avoided where possible. You never know how many of these issues are present there since vendor provided kernels are made without code/peer review by contractors/employees paid by SoC vendors that do not care about security at all. Expect the worst. Always!
 
And that's why the ability to use mainline kernel is that important. And why it's important to use a distro like Armbian that is actively developed. I would suspect that most if not all OS images for Orange Pis that are still available on orangepi.org download section will never be upgraded and that the users there not even know what's going on.

I fought the good fight over the weekend trying to get Armbian builder to build full images while running in a docker container.    I've had some success, and managed to build a armban 5.11 image for my Orange Pi One.. I'm running on it with wifi etc.
 
I'm using a CentOS7 Docker 1.9.1 host and using Ubuntu 14.04 Trusty Docker Container for the Armbian builder container. (I just used the Dockerfile from the armbian git repo)
 
Bottom line loopback management inside containers is a bad time.. especially when losetup implementations vary between host and container.   The partprobe step in the container doesn't seem to trigger appropriate feedback to udev to create partitiion devices on the /dev loop back devices.   I got around it by creating them ahead of time.
 
Here's a few tricks to limp through.  I'll try to add more clarity later.
 
1.  Don't. just go build a ubuntu 14.04 VM or use a turn key one on amazon and get your life back.
 
 
From Docker Host
#you need modules modprobe binfmt_misc modprobe loop #scrub loopbacks for good luck rm -rf /dev/loop[0-9]*     Launch armbian builder container with --privileged=true #sudo docker run --privileged=true --name=armbian -it armbianbuilder #or if you're re-using container #sudo docker start -i armbian From container   #start apt-cacher-ng service apt-cacher-ng start ​ #scrub loopbacks again in container for good luck rm -rf /dev/loop[0-9]* #create all your loop back devices mknod /dev/loop0 b 7 0 mknod /dev/loop0p1 b 259 0 mknod /dev/loop0p2 b 259 1 mknod /dev/loop0p3 b 259 2 mknod /dev/loop0p4 b 259 3 mknod /dev/loop1 b 7 1 mknod /dev/loop1p1 b 259 0 mknod /dev/loop1p2 b 259 1 mknod /dev/loop1p3 b 259 2 mknod /dev/loop1p4 b 259 3 mknod /dev/loop2 b 7 2 mknod /dev/loop2p1 b 259 0 mknod /dev/loop2p2 b 259 1 mknod /dev/loop2p3 b 259 2 mknod /dev/loop2p4 b 259 3 #build your dreams cd ~ ./compile.sh Every time you build an image you should destroy the loopbacks and recreate.  It's your best chances of getting the partitions in the loopback image to behave for mounting.
 
 
     

You should take an hour and read carefully through this article here: http://linux-sunxi.org/Sunxi_devices_as_NAS
 
What differentiates Banana Pro from the original Banana Pi (or M1) is just onboard WiFi, same applies to M1+ that has been designed to be a Banana Pro clone (after the LeMaker and SinoVoip divorce -- of course SinoVoip failed with a few details so OS images for Pro are NOT 100 per cent compatible with M1+). 
 
In my personal opinion all these cheap onboard WiFi solutions aren't worth a look so I would neither choose Pro nor M1+ but the original Banana Pi instead (also cheaper). In case you want to use WiFi do some research before regarding your specific use case. And please remember that M1+ is made by a company 'famous' for not being able to provide correct hardware descriptions (be it .fex files or .dts files -- they still simply don't give a sh*t about correct information -- until this is resolved I would not buy anything from them).
 
Regarding M1+ (and WiFi) also worth a read:
http://forum.armbian.com/index.php/topic/340-banana-pi-pro-m1plus-no-wifi-armbian-45/ http://forum.armbian.com/index.php/topic/1149-patches-for-m1-dts-file-for-wifi/ http://forum.armbian.com/index.php/topic/1079-the-armbian-status-for-banana-pi-m1-plus/ BTW: We can expect an A20 successor called A20E rather soon (internally called sun8iw11p1, still dual core, still SATA capable but clocked somewhat higher). But since this chip seems to be based on different IP blocks compared to 4 years old A20 while it might be 100% pin compatible to A20 we currently know nothing what to expect regarding drivers and general compatibility).

I have 2 Opi Ones if additional testing is needed. one with heatsink one without. i have a 2e coming also
 
Sent from my SM-G920V using Tapatalk

You might be talking about /etc/update-motd.d/40-updates? Please keep in mind that the information there might be outdated by 2 days since the count of available updates will be somehow cached since it migth delay any login attempt otherwise.
 
https://github.com/igorpecovnik/lib/blob/master/scripts/update-motd.d/40-updates#L139
 
So in case you really believe this is valuable 'information' then think about adjusting the script so that it updates /var/cache/apt/archives/updates.number anyway and call it from cron hourly or in case you love ultra slow logins modify the twodays_ago formula to your needs.

Wow! Guess who made the original picture: http://linux-sunxi.org/File:Orange_Pi_One_Top.jpg#filehistory
 
Someone sent me two pictures from Orange Pi forums (which I've not visited since 5 months), I combined those two images in Photoshop so that the image alone should be significant enough to get the idea and forgot to mention "@GUTEK@ the greatest artist on planet" since I didn't even know that the great @GUTEK@ was responsible for creating this masterpiece of art (combining a screenshot from schematic with someone else's photo). I truly apologyze for my mistake. Will correct that immediately!
 
OMFG! It was such a mistake starting to support Orange Pi H3 boards.

I put the board into a plastic enclosure and jammed a cotton ball above the processor. cpuburn-a7 has been running for over an hour and the temperature won't go above 97°C. CPU frequency toggles between 480 and 648 Mhz.
 

You find most if not all used methodologies/tools listed here: http://de.slideshare.net/brendangregg/broken-linux-performance-tools-2016
 
On a SBC I would always take care to use a minimalistic monitoring approach since when the monitoring task starts to influence the behaviour of the system (always running at highest clockspeeds for example when interactive performance governor is used) then this is simply 'Monitoring gone wrong'.
 
Another huge difference when we're talking about more recent SBCs is the thermal/throttling and dvfs/cpufreq behaviour. Not taking that into account and looking at something more or less useless like 'load average' is just fooling yourself (without taking notice). So if you've fun watching at meaningless graphs this might be great. Otherwise better stay away from it unless it serves ok for specific use cases you're an expert in (networking stuff for example)
 
Please just think a few seconds about a monitoring approach that does not monitor CPU clockspeeds and throttling strategies either. Is having an average CPU utilisation of 50% 'bad'? When the system is downclocking to 240 MHz at the same time to save energy and lower temperatures? Is it better when the system only shows 10% CPU utilisation since cpufreq settings let it run at 1200 MHz instead (and the SBC consumes twice as much energy due to dvfs settings)?

Relax - Wireless is solved for OPI ONE
 
There seems to be a lot of confusion and missing information on how to access the dirt cheap OPI ONE wirelessly and the steps necessary to successfully use cheap Realtek USB dongles ( 8188cus, 8188eu ) with Armbian_5.10.
 
This is a short summary of the needed materials and steps to turn your OPI ONE into a wireless client or wireless AP. There are NO custom kernels, custom modules or anything else needed, we are using stock Armbian_5.10 with stock kernel, stock modules and stock software to configure wireless access for select tested and working Realtek wifi dongles.
 
Follow the steps without variation. Once you get wifi working you may adapt setup/configuration to your specific needs
 
Prerequisites
 
- OPI ONE with quality power supply 5V/2A
- MicroSD ( 4G or higher ) with stock Armbian_5.10 installed per official instructions
- Supported wifi USB dongle
- LAN connection to host computer ( preferrably notebook running Linux ) for needed setup/configuration 
- WLAN-router accessible from host computer to test wireless connections.
 
General procedure to set up wireless on OPI ONE
 
- Set up your OPI ONE with basic Armbian_5.10 and configure a static IP LAN-address
- Access OPI ONE via ssh from your host computer
- Plug in wireless dongle and load correct driver module
- check capabilities of wifi dongle (iw list)
- configure wpa_supplicant for client mode
- configure hostapd for AP mode
 
>>> all configurations will be minimal without added automagic complexities ( bridges, DHCP etc...)
 
OPI ONE wireless client
 
Module 8192cu works with Realtek 8188CUS dongles and provides a wireless interface wlan0 ready to be configured in managed mode with wpa_supplicant.
 
 
nano /etc/modules-load.d/modules.conf
=====================================

#8189es
8192cu
 
 
 
nano /etc/network/interfaces (adapt to your network setup)
==========================================================

auto lo
        iface lo inet loopback

#----- lan interface ( standard maintenance connection via ssh ) 
        
allow-hotplug eth0
   iface eth0 inet static
        address 192.168.3.164           
        netmask 255.255.255.0
        network 192.168.3.0
 
#----- Realtek 8192cu wlan interface client ( access defined in /etc/wpa_supplicant/wpa_supplicant.conf )
            
allow-hotplug wlan0
   iface wlan0 inet static
        address 192.168.2.164
        netmask 255.255.255.0
        network 192.168.2.0
        broadcast 192.168.2.255
        gateway 192.168.2.77
    dns-nameservers 192.168.1.1
    dns-nameservers 8.8.8.8

        wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
 
 
nano /etc/wpa_supplicant/wpa_supplicant.conf
============================================

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
        ssid="<your_ssid>"
        psk="<your_password>"
        key_mgmt=WPA-PSK
        priority=99
}
 
 
After restarting OPI ONE it should be connected to your configured wireless router and accessible under the static IP.
Wireless connection is working now and the rest is up to your hopefully wild imagination and creativity.
 
Tested working dongles
 
RTL8188CUS cheap no-name dongle from Aliexpress ( < $2 )
 
Bus 002 Device 003: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter

RTL8188CUS Edimax EW-7811Un high quality dongle ( $10 )
 
Bus 001 Device 008: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]

Wifi performance is not stellar, but definitely adequate. Under ideal conditions ( same room as router, little interference ) speeds of 80mbps ( measured with iperf ) can be expected. Crossing two walls at 20m distance from router the signal was still usable yielding 20mbps.
 
 
OPI ONE access point + wireless client
 
Surprise : You were asking for AP mode and  now you are getting AP deluxe with an extra client interface for free.
 
Module 8188eu works with Realtek 8188EU dongle and provides TWO wireless interfaces : wlan0 is ready to be configured in AP mode with hostapd and wlan1 in managed mode with wpa_supplicant.
 
When the dongle is plugged in and the driver correctly loaded, iw list will enumerate the drivers parameters for the two new interfaces. iwconfig will show wlan0 and wlan1.
 
 
 
nano /etc/modules-load.d/modules.conf
=====================================

#8189es
8188eu

nano /etc/default/hostapd
=========================

DAEMON_CONF="/etc/hostapd.conf"


nano /etc/network/interfaces
============================

auto lo
        iface lo inet loopback

#----- lan interface ( standard maintenance connection via ssh )
        
allow-hotplug eth0
   iface eth0 inet static
        address 192.168.3.164
        netmask 255.255.255.0
        network 192.168.3.0

#----- Realtek 8188eu wlan interface AP ( access defined in /etc/hostapd.conf )
              
allow-hotplug wlan0
   iface wlan0 inet static
        address 192.168.4.164
        netmask 255.255.255.0
        network 192.168.4.0

#----- Realtek 8188eu wlan interface client ( access defined in /etc/wpa_supplicant/wpa_supplicant.conf )
            
allow-hotplug wlan1
   iface wlan1 inet static
        address 192.168.2.164
        netmask 255.255.255.0
        network 192.168.2.0
        broadcast 192.168.2.255
        gateway 192.168.2.77
    dns-nameservers 192.168.1.1
    dns-nameservers 8.8.8.8

        wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf


nano /etc/hostapd.conf
======================

ssid=<your-OPI-ONE-ssid>            
interface=wlan0
hw_mode=g
channel=5
driver=nl80211
logger_syslog=0
logger_syslog_level=0
wmm_enabled=1
ieee80211n=1
wpa=3
preamble=1
#wpa_psk=66eb31d2b48d19ba216f2e50c6831ee11be98e2fa3a8075e30b866f4a5ccda27
wpa_passphrase='12345678'
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
auth_algs=1
macaddr_acl=0
noscan=1
#ht_capab=[HT40-][sHORT-GI-40][sHORT-GI-40][DSSS_CCK-40]
country_code=<your country code>
#ieee80211d=1


nano /etc/wpa_supplicant/wpa_supplicant.conf
============================================

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
        ssid="<your-router-ssid>"
        psk="<your-router-password>"
        key_mgmt=WPA-PSK
        priority=99
}
 
 
After restarting OPI ONE it should be connected to your configured wireless router and accessible under the static IP. On your notebook the newly created OPI ONE access point should be visible when scanning. Specify a static IP for the link and connect using the chosen password ( e.g. '12345678' ) . Feel like a hero, empty a sixpack and order more pizza....
Wireless connection is working now and the rest is up to your hopefully wild imagination and creativity.
 
 
Tested working dongle for AP mode :
 
RTL8188EU cheap no-name dongle from Aliexpress (  $2.20  )
Bus 001 Device 009: ID 0bda:0179 Realtek Semiconductor Corp. ( noname identified as 8188EU )

Wifi performance with both interfaces active is surprisingly good. Under ideal conditions ( same room as router, little interference ) speeds of 60 (client) / 30 (AP) mbps can be expected. Crossing two walls at 20m distance from router signals were still usable yielding 20 (client) / 5 (AP) mbps.
 
 
Troubleshooting
Most of the problems encountered while setting up WIFI are caused by inadequate or overly complicated testing setups, procedures and rampant wild guesses. Keep it simple and solve one problem at a time. As a stable datum you should realize that the procedures outlined above DO WORK and have been adequately TESTED and RETESTED..
 
Solution No. 1 :  Follow the steps outlined
Solution No. 2 :  Find out where you did not follow the steps outlined
Solution No. 3 :  Find out what you added to the steps outlined
Solution No. 4 :  Reiterate
 
 
Good luck with your wireless OPI ONE, enjoy and flood the forum with working solutions.

I just updated the fswebcam code on github so you are able to set Exposure, Vflip and Hflip contols using command line if you don't want to mess with kernel side.
  Grab the code:  git clone https://github.com/avafinger/fswebcam cd fswebcam ./configure --prefix=/usr --disable-v4l1 --enable-32bit-buffer make sudo make install   Some command line samples: fswebcam --Vflip 1 -r 1600x1200 -p YUV420P - > cam1600x1200_2.jpg fswebcam --Hflip 1 -r 800x600 -p YUV420P - > cam800x600_1.jpg fswebcam --exposure 4 -r 640x480 -p YUV420P - > cam640x480_1.jpg   Exposure = [-4 to 4] Vflip = [0,1] - Flip image Vertically  Hflip = [0,1] - Filp image Horizontally    Enjoy
 
 

We should add in big letters to download info that disconnecting peripherals (especially WiFi dongles and USB hubs) on first boot helps resolving most of the auto detection problems until this is resolved.

I'm running an Orange Pi One -- no heat sink, open sitting on my desk.    I built latest legacy armbian kernel via armbian build process.  Folllowed instructions for fex settings, etc.
 
I've been running cpuburn for over an hour, and here's the bottom of my log.. I'll run overnight and post on a gist or something
 
It's been holding steady with these numbers for at least 30 minutes
23:43:33:  912MHz  4.01 100%   0%  99%   0%   0%   0%   78°C 23:43:38:  912MHz  4.01 100%   0%  99%   0%   0%   0%   78°C 23:43:43:  912MHz  4.01 100%   0%  99%   0%   0%   0%   78°C 23:43:48:  912MHz  4.01 100%   0%  99%   0%   0%   0%   77°C 23:43:53:  912MHz  4.01 100%   0%  99%   0%   0%   0%   77°C 23:43:59:  912MHz  4.01  99%   1%  98%   0%   0%   0%   78°C 23:44:04:  912MHz  4.01  99%   0%  99%   0%   0%   0%   78°C 23:44:09:  912MHz  4.01  99%   0%  99%   0%   0%   0%   77°C 23:44:14:  912MHz  4.01  99%   0%  99%   0%   0%   0%   77°C 23:44:19:  912MHz  4.00  99%   0%  99%   0%   0%   0%   78°C 23:44:24:  912MHz  4.00 100%   0%  99%   0%   0%   0%   78°C 23:44:29:  912MHz  4.00 100%   0%  99%   0%   0%   0%   78°C 23:44:34:  912MHz  4.00  99%   0%  99%   0%   0%   0%   78°C 23:44:40:  912MHz  4.00  99%   0%  99%   0%   0%   0%   78°C 23:44:45:  912MHz  4.00  99%   0%  99%   0%   0%   0%   78°C 23:44:50:  912MHz  4.08  99%   0%  99%   0%   0%   0%   78°C 23:44:55:  912MHz  4.07 100%   0%  99%   0%   0%   0%   78°C 23:45:00:  912MHz  4.06 100%   0%  99%   0%   0%   0%   77°C 23:45:05:  912MHz  4.06  99%   0%  98%   0%   0%   0%   78°C 23:45:10:  912MHz  4.05  99%   0%  98%   0%   0%   0%   78°C 23:45:15:  912MHz  4.05  99%   0%  98%   0%   0%   0%   78°C 23:45:21:  912MHz  4.05 100%   0%  99%   0%   0%   0%   78°C
 
 
And Since I had already let it run overnight.. here's a graph of it holding steady just because
 

I have an Orange Pi One. I have an acrylic case, but the board is just laying on a table open to ambient air (25.9C). How long should I run cpuburn-a7? The board seems to be staying at 80C, and switching between mostly 912Mhz and sometimes 768Mhz.

Prebuilt kernel: https://www.dropbox.com/sh/d55gb7gfjpaika3/AAB9LjYI4RqrPBGR0uEXWuWta?dl=0
 
For testing it's recommended to disable userspace corekeeper by editing /etc/rc.local
 
Please also post dmesg log here in spoiler and code blocks or on pastebin or similar service.

It's a bug I introduced in early April -- will be fixed with soon to be released Armbian 5.11: http://forum.armbian.com/index.php/topic/1223-prepare-v511-bugfix-update/?view=getlastpost

This patch modifies the sunxi-dev/bananapi-r1-switch-driver.patch to work with
the changed phy/mdio interface in 4.5.
It was also necessary to revert commit
88f8b1bb41c6208f81b6a480244533ded7b59493 "stmmac: Fix 'eth0: No PHY found' regression"
because it breaks networking on all my sun7i-a20 boards (bananapi, cubietruck, and bananapi-r1)
 
From ce978c1235f68cf7bfeb81693d047afcee6df038 Mon Sep 17 00:00:00 2001
From: Werner Boellmann <WeeB@sample.net>
Date: Mon, 15 Feb 2016 12:22:08 +0100
Subject: [PATCH] bananapi-r1 switch driver: Modifications for Kernel v4.5

---
 drivers/net/phy/b53/b53_mdio.c      | 63 ++++++++++---------------------------
 drivers/net/phy/b53/b53_phy_fixup.c |  4 +--
 2 files changed, 19 insertions(+), 48 deletions(-)

diff --git a/drivers/net/phy/b53/b53_mdio.c b/drivers/net/phy/b53/b53_mdio.c
index 3c25f0e..fcf3a23 100644
--- a/drivers/net/phy/b53/b53_mdio.c
+++ b/drivers/net/phy/b53/b53_mdio.c
@@ -257,11 +257,11 @@ static int b53_phy_probe(struct phy_device *phydev)
     int ret;
 
     /* allow the generic phy driver to take over */
-    if (phydev->addr != B53_PSEUDO_PHY && phydev->addr != 0)
+    if (phydev->mdio.addr != B53_PSEUDO_PHY && phydev->mdio.addr != 0)
         return -ENODEV;
 
     dev.current_page = 0xff;
-    dev.priv = phydev->bus;
+    dev.priv = phydev->mdio.bus;
     dev.ops = &b53_mdio_ops;
     dev.pdata = NULL;
     mutex_init(&dev.reg_mutex);
@@ -285,7 +285,7 @@ static int b53_phy_config_init(struct phy_device *phydev)
     struct b53_device *dev;
     int ret;
 
-    dev = b53_switch_alloc(&phydev->dev, &b53_mdio_ops, phydev->bus);
+    dev = b53_switch_alloc(&phydev->mdio.dev, &b53_mdio_ops, phydev->mdio.bus);
     if (!dev)
         return -ENOMEM;
 
@@ -341,10 +341,10 @@ static int b53_phy_read_status(struct phy_device *phydev)
     return 0;
 }
 
-/* BCM5325, BCM539x */
-static struct phy_driver b53_phy_driver_id1 = {
-    .phy_id        = 0x0143bc00,
+static struct phy_driver b53_phy_drivers[] = {
+ { /* BCM5325, BCM539x */
     .name        = "Broadcom B53 (1)",
+    .phy_id        = 0x0143bc00,
     .phy_id_mask    = 0x1ffffc00,
     .features    = 0,
     .probe        = b53_phy_probe,
@@ -352,15 +352,10 @@ static struct phy_driver b53_phy_driver_id1 = {
     .config_aneg    = b53_phy_config_aneg,
     .config_init    = b53_phy_config_init,
     .read_status    = b53_phy_read_status,
-    .driver = {
-        .owner = THIS_MODULE,
-    },
-};
-
-/* BCM53125, BCM53128 */
-static struct phy_driver b53_phy_driver_id2 = {
-    .phy_id        = 0x03625c00,
+ },
+ { /* BCM53125, BCM53128 */
     .name        = "Broadcom B53 (2)",
+    .phy_id        = 0x03625c00,
     .phy_id_mask    = 0x1ffffc00,
     .features    = 0,
     .probe        = b53_phy_probe,
@@ -368,15 +363,10 @@ static struct phy_driver b53_phy_driver_id2 = {
     .config_aneg    = b53_phy_config_aneg,
     .config_init    = b53_phy_config_init,
     .read_status    = b53_phy_read_status,
-    .driver = {
-        .owner = THIS_MODULE,
-    },
-};
-
-/* BCM5365 */
-static struct phy_driver b53_phy_driver_id3 = {
-    .phy_id        = 0x00406000,
+ },
+ { /* BCM5365 */
     .name        = "Broadcom B53 (3)",
+    .phy_id        = 0x00406000,
     .phy_id_mask    = 0x1ffffc00,
     .features    = 0,
     .probe        = b53_phy_probe,
@@ -384,38 +374,19 @@ static struct phy_driver b53_phy_driver_id3 = {
     .config_aneg    = b53_phy_config_aneg,
     .config_init    = b53_phy_config_init,
     .read_status    = b53_phy_read_status,
-    .driver = {
-        .owner = THIS_MODULE,
-    },
+ }
 };
 
 int __init b53_phy_driver_register(void)
 {
-    int ret;
-
-    ret = phy_driver_register(&b53_phy_driver_id1);
-    if (ret)
-        return ret;
-
-    ret = phy_driver_register(&b53_phy_driver_id2);
-    if (ret)
-        goto err1;
-
-    ret = phy_driver_register(&b53_phy_driver_id3);
-    if (!ret)
-        return 0;
-
-    phy_driver_unregister(&b53_phy_driver_id2);
-err1:
-    phy_driver_unregister(&b53_phy_driver_id1);
-    return ret;
+    return phy_drivers_register(b53_phy_drivers,
+            ARRAY_SIZE(b53_phy_drivers), THIS_MODULE);
 }
 
 void __exit b53_phy_driver_unregister(void)
 {
-    phy_driver_unregister(&b53_phy_driver_id3);
-    phy_driver_unregister(&b53_phy_driver_id2);
-    phy_driver_unregister(&b53_phy_driver_id1);
+    phy_drivers_unregister(b53_phy_drivers,
+            ARRAY_SIZE(b53_phy_drivers));
 }
 
 module_init(b53_phy_driver_register);
diff --git a/drivers/net/phy/b53/b53_phy_fixup.c b/drivers/net/phy/b53/b53_phy_fixup.c
index 72d1373..ac3779e 100644
--- a/drivers/net/phy/b53/b53_phy_fixup.c
+++ b/drivers/net/phy/b53/b53_phy_fixup.c
@@ -29,9 +29,9 @@
 static int b53_phy_fixup(struct phy_device *dev)
 {
     u32 phy_id;
-    struct mii_bus *bus = dev->bus;
+    struct mii_bus *bus = dev->mdio.bus;
 
-    if (dev->addr != B53_PSEUDO_PHY)
+    if (dev->mdio.addr != B53_PSEUDO_PHY)
         return 0;
 
     /* read the first port's id */
--
2.7.0
 

Hi to All,
 
Some results from the performance tests of eMMC on A20-Olinuxinot-Lime2-eMMC can be found on the following  posts:
http://forum.armbian.com/index.php/topic/853-armbian-customization/page-4#entry8846 - in graphics form
http://forum.armbian.com/index.php/topic/853-armbian-customization/page-4#entry8847 - data in raw format
 
Best regards
Chris

Corporation mission, vision & marketing chit chat is pure bullshit, spam, if this is more understandable. Nothing to take seriously into account.

Ah, forgot that before: Regarding software support everything's already in position (since I would suspect Steven/Xunlong is as smart as in the past and uses exactly the same pins for the same stuff). All we'll have to do get hardware working correctly (applies both to legacy and vanilla kernel) is to use fex/dts from Orange Pi PC and exchange network with the GbE network stuff from Orange Pi Plus.
 
Differences:
DRAM: Xunlong uses the same type of Samsung DRAM on all 512MB/1GB variants and SK Hynix modules on Plus 2/2E. Since we didn't get reports about non-working OPi Plus 2 so far I would suspect DRAM initialization within u-boot for this different DRAM type works. WiFi: Xunlong said they replace 8189ETV used on the older OPi with 8189FTV on OPi Lite, PC Plus and Plus 2E. At least I have no idea whether both chips work with the same driver so unless someone holds a Lite or Plus 2E in his hands (and Igor managed to compile the new driver and include it into Armbian) we simply don't know what to expect Both users of Orange Pi Plus 2 and Plus 2E are encouraged to start DRAM reliability testing using fel-boot-lima-memtester-on-orange-pi-pc-v3 as outlined here: http://linux-sunxi.org/Orange_Pi_PC#DRAM_clock_speed_limit (ssvb's package for OPi PC can be used since the only difference between Plus 2E and PC is a different Ethernet PHY used and this should not make a difference)

Just FYI: Orange Pi Plus 2E is now available for $35 and shipping costs remain the same (pretty low compared to some competitors): 
 
http://aliexpress.com/store/product/Orange-Pi-Plus-2-E-H3-Quad-Core-1-6GHZ-2GB-RAM-4K-Open-source-development/1553371_32665196281.html
 
Please remember that this board was designed based on community requests (dropping the slow GL830 USB-to-SATA bridge and the internal USB hub and exposing all 4 USB ports physically to the outside) and should make up for a really nice server with 2 GB DRAM, Gbit Ethernet and 4 USB ports (3 real hosts ports and one Micro OTG).
 
So now we have the following H3 boards with Gigabit Ethernet:
 
Banana Pi M2+ for $33 (1 GB RAM, 8 GB eMMC, no USB hub / no shared bandwidth, only 2 USB host ports useable) OPi Plus 2E for $35 (2 GB RAM, 16 GB eMMC, no USB hub / no shared bandwidth, 3 USB host ports useable) OPi Plus for $39 (1 GB RAM, 8 GB eMMC, GL830 slow USB-to-SATA, internal USB hub / shared bandwidth) OPi Plus 2 for $49 (2 GB RAM, 16 GB eMMC, GL830 slow USB-to-SATA, internal USB hub / shared bandwidth)   SinoVoip said to release also a cost down version of M2+ without eMMC and WiFi that might be then the cheapest GbE equipped board. But since there you only get 1 GB DRAM (which might be totally ok for most use cases -- please compare with http://www.linuxatemyram.com if in doubt) and they don't use a programmable voltage regulator and always feed the SoC with 1.3V VDD_CPUX core voltage IMO spending a few bucks more to get OPi Plus 2E with twice the RAM/eMMC size, 1 more USB port, more performance and also lesser temperature/consumption is the better idea.   BTW: WiFi capabilities not mentioned intentionally since in my opinion those cheap SDIO 2.4 GHz implementations are all not worth a look (or time/efforts to get the crappy drivers running)