A20-OLinuXino-LIME2 new HW Rev. E

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

Previous topic - Next topic

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

#19
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

#20
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