A20-OLinuXino-LIME2 new HW Rev. E

Started by chradev, April 02, 2016, 11:29:56 pm

Previous topic - Next topic


Hi to All,

These days I get HDMI LCD monitor and after connecting it to Lime2 board find following:

  • If the monitor is connected but not powered on total and measured by PMU consumption increases with 30mA@5V or approximately 150mW

  • The temperature increases in such a case are 2.1°C for CPU and 1.8°C for PMU

  • If the monitor is powered on consumption is not influenced but CPU temperatures increases with 5.7°C which is probably related to GPU activities

Temperatures are measured with CPU aluminum heat sink and the board in open air.

Best regards



I have a rev. E lime2-emmc and suffer from the problems you mention.
I am new to the sbc scene. I have update/upgrade my installation using:
- Armbian_5.10_Lime2_Debian_jessie_4.5.2.raw
- a20-lime2_mainline_uboot_GMAC_master_sunxi_kernel_3.4.103_jessie_emmc_rel_5.img

I installed the "dev" packages from http://www.armbian.com/kernel.
I copy files to /dev/null just in case my sd card is too slow.
Nothing works. 13MB/sec is the max i can transfer on gbe. Other machines on the network can do at least 60MB/sec.
I don't understand how I can absorb the changes that were made as it is stated they have been applied (somewhere).
Do I have to patch everything myself? I would have thought an update/upgrade would have pulled the changes in for me.
Can someone point out what i am misunderstanding?

Thanks in advance.


P.s. Great community you have here. Hoping to be able to contribute some code...


Hi Jon,

You probably talk about GBit Ethernet problem.

The patch sunxi-gmac-fix.patch is added to Armbian repository (for next branch only) but is disabled.

If you want to fix GBit Ethernet problem in Lime2-eMMC board you have to build at least U-Boot yourself.
I do not test dev branch but as it uses the same U-Boot revision it has to be patched as well.

The same is for eMMC support (add-emmc-lime2.patch) it is added to to both next and dev branches but disabled.

Of course, the get eMMC support mainline kernel has to be patched as well (add-emmc-lime2.patch).
It is added to Armbian repository (for next branch only) but disabled.

Unfortunately, Armbian do not support out of the box Lime2 rev. E boards (incl. eMMC variant).
That is way you have to build at least the U-Boot and Kernel or better whole Armbian image.

You can read my post http://forum.armbian.com/index.php/topic/853-armbian-customization/.
There I have described all my way to get stable and fully functional Lime2-eMMC system based on Armbian next.

In case of interest I can publish all my customization staff but its usage needs of relevant experience.

As a beginning you can try U-boot and Kernel from my custom build:

Best regards


Thanks for the help Chris I will give it a try.
Yes mainly gbit but also emmc.
I just ordered an SSD so I can play with that as well.


June 02, 2016, 12:21:45 am #19 Last Edit: June 02, 2016, 12:46:35 am by jon
Hi to all,

It looks like the gmac patch is not working.


cpu_eth_init is no longer called for dm enabled eth drivers, this
was causing the sunxi gmac eth controller to no longer work in u-boot.

This commit fixes this by moving the gpio setup to gpio_init() and by
calling the clock, reset and pinmux setup function from s_init().

Note that the mdelay is dropped as the phy gets enabled much earlier
now, so it is no longer needed.

Signed-off-by: Hans de Goede <hdegoede at redhat.com>
arch/arm/cpu/armv7/sunxi/board.c            | 32 +++++------------------------
arch/arm/include/asm/arch-sunxi/sys_proto.h |  6 +++++-
board/sunxi/gmac.c                          | 14 +------------
3 files changed, 11 insertions(+), 41 deletions(-)

diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index e80785b..9a97049 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -100,6 +100,10 @@ static int gpio_init(void)
#error Unsupported console port number. Please fix pin mux settings in board.c

+   gpio_request(CONFIG_MACPWR, "macpwr");
+   gpio_direction_output(CONFIG_MACPWR, 1);
   return 0;

@@ -152,6 +156,7 @@ void s_init(void)
+   eth_init_board();

@@ -259,30 +264,3 @@ void enable_caches(void)
- * Initializes on-chip ethernet controllers.
- * to override, implement board_eth_init()
- */
-int cpu_eth_init(bd_t *bis)
-   __maybe_unused int rc;
-   gpio_request(CONFIG_MACPWR, "macpwr");
-   gpio_direction_output(CONFIG_MACPWR, 1);
-   mdelay(200);
-   rc = sunxi_gmac_initialize(bis);
-   if (rc < 0) {
-      printf("sunxi: failed to initialize gmac\n");
-      return rc;
-   }
-   return 0;
diff --git a/arch/arm/include/asm/arch-sunxi/sys_proto.h b/arch/arm/include/asm/arch-sunxi/sys_proto.h
index 9df3744..a373319 100644
--- a/arch/arm/include/asm/arch-sunxi/sys_proto.h
+++ b/arch/arm/include/asm/arch-sunxi/sys_proto.h
@@ -24,6 +24,10 @@ void sdelay(unsigned long);
void return_to_fel(uint32_t lr, uint32_t sp);

/* Board / SoC level designware gmac init */
-int sunxi_gmac_initialize(bd_t *bis);
+#if !defined CONFIG_SPL_BUILD && defined CONFIG_SUNXI_GMAC
+void eth_init_board(void);
+static inline void eth_init_board(void) {}

diff --git a/board/sunxi/gmac.c b/board/sunxi/gmac.c
index 4e222d8..69eb8ff 100644
--- a/board/sunxi/gmac.c
+++ b/board/sunxi/gmac.c
@@ -6,7 +6,7 @@
#include <asm/arch/clock.h>
#include <asm/arch/gpio.h>

-int sunxi_gmac_initialize(bd_t *bis)
+void eth_init_board(void)
   int pin;
   struct sunxi_ccm_reg *const ccm =
@@ -79,16 +79,4 @@ int sunxi_gmac_initialize(bd_t *bis)
   for (pin = SUNXI_GPA(26); pin <= SUNXI_GPA(27); pin++)
      sunxi_gpio_set_cfgpin(pin, SUN6I_GPA_GMAC);
-   return 0;
-   return designware_initialize(SUNXI_GMAC_BASE, PHY_INTERFACE_MODE_RGMII);
-# elif defined CONFIG_GMII
-   return designware_initialize(SUNXI_GMAC_BASE, PHY_INTERFACE_MODE_GMII);
-# else
-   return designware_initialize(SUNXI_GMAC_BASE, PHY_INTERFACE_MODE_MII);
-# endif

Kind regards,



June 02, 2016, 01:05:28 am #20 Last Edit: June 02, 2016, 01:08:39 am by chradev
Hi Jon,

To solve a slow GBit Ethernet I use U-Boot patch proposed by Olimex:

It works fine for me for U-Boot up to ver. 2016.05.
Tested on Armbian with both legacy and mainline kernels.

You can see some test results:
where I have measured 980Mbps GBit LAN peak throughput.

Best regards



Can anyone actually confirm that they have seen representative gigabit speed on lime2 hv rev e?
I am running:
root@lime2:~# cat /proc/version
Linux version 4.6.1-sunxi (root@ubuntu) (gcc version 4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1) ) #1 SMP Sun Jun 5 13:34:47 CEST 2016

So no patches are enabled (by me), but iperf gives 895Mb/sec
root@lime2:~# iperf -s
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
[  4] local port 5001 connected with port 43669
[ ID] Interval       Transfer     Bandwidthrdware
[  4]  0.0-10.0 sec  1.05 GBytes   895 Mbits/sec

When I apply the patches, iperf gives roughly the same figures.

In both cases, the actual transfer rates seen (yes, using scp which seems to be more 'read world') are 12MB/sec.
On my network I get at least 50MB/sec data rates.
Is there a hardware limitation restricting the data rates or am I misunderstanding/missing something?




scp and other high level protocols might be slower because the CPU wont be able to encrypt that much data at 100MB/s.
Try uncompressed netcat, that might work.



Can you describe your testing setup?


Hello, I am running armbian next jessie image, built by me.
This has been tested with patches for emmc and gigabit and without.
Connected directly to d-link unmanaged gigabit router.
Copy between corei3 laptop running centos 7 and the lime2-emmc.
Tried to copy to (cheap probably fake) sd card, emmc and ssd. Also /dev/null. Very little change in throughput so I guess the limit is not storage related.

root@lime2:/proc# cat version
Linux version 4.6.1-sunxi (root@ubuntu) (gcc version 4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1) ) #1 SMP Sun Jun 5 23:31:55 CEST 2016

I will have a go at using nc.


Using nc I get about 36 MB/s
Using nc with a gigabit usb 3.0 dingle I get 15 MB/s
Scp limit is about 12 MB/s using built in or use ethernet