A20-OLinuXino-LIME2 new HW Rev. E

[chradev]

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
Chris

[jon]

Hello,

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.

Jon.

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

[chradev]

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:
https://drive.google.com/file/d/0B7hed-DxVjhoYmhNMDhNbkZYVUE

Best regards
Chris

[jon]

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.

[jon]

Hi to all,

It looks like the gmac patch is not working.

https://github.com/igorpecovnik/lib/blob/master/patch/u-boot/u-boot-next/sunxi-gmac-fix.patch.disabled

"
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
#endif

+#ifdef CONFIG_MACPWR
+   gpio_request(CONFIG_MACPWR, "macpwr");
+   gpio_direction_output(CONFIG_MACPWR, 1);
+#endif
   return 0;
}

@@ -152,6 +156,7 @@ void s_init(void)
   timer_init();
   gpio_init();
   i2c_init_board();
+   eth_init_board();
}

#ifdef CONFIG_SPL_BUILD
@@ -259,30 +264,3 @@ void enable_caches(void)
   dcache_enable();
}
#endif
-
-#ifdef CONFIG_CMD_NET
-/*
- * Initializes on-chip ethernet controllers.
- * to override, implement board_eth_init()
- */
-int cpu_eth_init(bd_t *bis)
-{
-   __maybe_unused int rc;
-
-#ifdef CONFIG_MACPWR
-   gpio_request(CONFIG_MACPWR, "macpwr");
-   gpio_direction_output(CONFIG_MACPWR, 1);
-   mdelay(200);
-#endif
-
-#ifdef CONFIG_SUNXI_GMAC
-   rc = sunxi_gmac_initialize(bis);
-   if (rc < 0) {
-      printf("sunxi: failed to initialize gmac\n");
-      return rc;
-   }
-#endif
-
-   return 0;
-}
-#endif
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);
+#else
+static inline void eth_init_board(void) {}
+#endif

#endif
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);
#endif
-
-#ifdef CONFIG_DM_ETH
-   return 0;
-#else
-# ifdef CONFIG_RGMII
-   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
-#endif
}
--
2.7.3
"

Kind regards,

Jon

[chradev]

Hi Jon,

To solve a slow GBit Ethernet I use U-Boot patch proposed by Olimex:
http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7491

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:
http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7762
http://forum.armbian.com/index.php/topic/853-armbian-customization/page-4#entry8074
where I have measured 980Mbps GBit LAN peak throughput.

Best regards
Chris

[jon]

Hello,

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 192.168.0.23 port 5001 connected with 192.168.0.24 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?

Thanks,

Jon

[soenke]

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.

[Albern]

Hi

Can you describe your testing setup?

[jon]

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.

[jon]

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