Olimex A20-OLinuXino-Lime2

From linux-sunxi.org
Jump to navigation Jump to search
Olimex A20-OLinuXino-Lime2
Lime2 top.jpg
Manufacturer Olimex
Dimensions 84mm x 60mm x 20mm
Release Date September 2014
Website Device Product Page
SoC A20 @ 1Ghz
DRAM 1GiB DDR3 @ 480MHz
eMMC 4GB (optional)
NAND 4GB (optional)
Power DC 5V (5.5/2.1 jack), 3.7V LiPo (JST PHR-2 header)
Video HDMI (Type A, full)
Network 10/100/1000Mbps Ethernet (Realtek RTL8211CL PHY in rev. A-E, Realtek RTL8211E PHY in rev. F-G2, Micrel KSZ9031 PHY in rev. H-L)
Storage µSD, SATA
USB 2x USB2.0 Host, 1x mini USB2.0 OTG
Headers UART, 5x GPIO headers

The A20 Olinuxino LIME2 is an OSHW board produced by Olimex.

The A20-OLinuXino-LIME2 is an upgrade of the Olimex A20-OLinuXino-Lime, but it comes with 1GiB RAM and gigabit ethernet. There are also two extra variants with onboard storage: A20-OLinuXIno-LIME2-4GB with 4GB NAND and A20-OLinuXino-LIME2-eMMC with 4GB eMMC.


The board is marked as A20-OLinuXino-Lime on both the top and bottom of the PCB.

Note that it is not marked as Lime2. The Lime2 variant can be distinguished by the presence of two dram chips on the top of the board between the SoC and the USB connectors, also the ethernet phy is on the bottom of the board instead of the top.

Sunxi support

Current status


  • Mainline kernel patches posted to linux-arm-kernel mailing list 2014-09-28
  • Mainline u-boot patches posted to u-boot mailing list 2014-09-28

Manual build

You can build things for yourself by following our Manual build howto and by choosing from the configurations available below.


Sunxi/Legacy U-Boot

Use the A20-OLinuXino_Lime2 build target. _FEL version is also available for USB booting.

Mainline U-Boot

Use the A20-OLinuXino-Lime2_defconfig build target or A20-OLinuXino-Lime2-eMMC_defconfig if you have the eMMC version.

Linux Kernel

Sunxi/Legacy Kernel

Use the a20-olinuxino_lime2.fex file. (Please note that this fex file adopted DRAM clock setting from the Lime2's predecessor - only dram_tpr4 differs for unknown reasons. Using this fex file the DRAM is clocked with just 384 MHz, which costs some few percent performance depending on the application used.)

Mainline kernel

Use either sun7i-a20-olinuxino-lime2.dtb or sun7i-a20-olinuxino-lime2-emmc.dtb device-tree binary.

Recovery button

Tips, Tricks, Caveats

FEL mode

The Recovery button (under sata connector, nearest hdmi connector) triggers FEL mode.

Lime2 UEXT connector

GMAC quirks

Different ethernet PHY is used depending on board revision Each of those designs have quirks at gigabit speeds, with slightly different symptoms:

Possible causes

A possible cause for packet loss only at gigabit speed is wrongly calibrated trace length compensation a.k.a. RGMII timing a.k.a. TX/RX skew: the sum of a) physical wiring length between MAC and PHY, b) compensations in MAC, and c) compensations in PHY, must result in a 1.5-2 ns delay from TX source clock in MAC and RX source clock in PHY.

A possible cause for packet loss only in master or slave mode is failure to seed or align with RGMII source-synchronous clock (this is newest suspected cause for rev. A-E boards but an older guess of the cause being clock calibration seems not ruled out).

A possible cause for packet loss only for Micrel PHY is a bug fixed since mainline linux v5.1 and unfixed in mainline u-boot (as of v2020.07).

Workarounds or fixes

calibrate at PHY

Proper fix for rev. F and newer is to apply trace length compensation at the PHY.

This is done by default (also for rev. H and newer despite commit message mentioning only realtek not Micrel) since mainline linux v5.15 and since mainline u-boot v2022.04;
before that it is supported by custom-compiling a device-tree binary with above change applied since mainline linux v5.9 (and backported to v5.8.15) and since mainline u-boot v2022.04.

Related documentation about Micrel KSZ9031 PHY compensations where updated since v5.12.


A simple general workaround is to avoid speeds showing package loss, either by advertising only lower speeds, or by turning off auto-negotiation and setting one specific lower speed, or doing similar advertising/fixation at the peer host.
Mainline u-boot supports environment variable disable_giga for Micrel 9031 PHY since v2017.09; i.e. setting disable_giga in u-boot environment should work for rev. H-L boards.
Linux supports changing speed and auto-negotiation with ethtool or systemd (see option advertise in either man ethtool or man systemd.link).
Beware: You may need additional changes with older linux or u-boot.

master mode

A workaround for rev. A-E boards is to force the device into master mode, either by fixating device to only offer master mode or by fixating peer device to only offer slave mode.
Beware: This workaround has the adverse effect of complete network failure at any speed with a peer device in master mode!
Mainline linux supports forcing master or slave mode since v5.7 which should be possible to control from ethtool v5.8 or newer.
Mainline u-boot supports option RTL8211X_PHY_FORCE_MASTER=y for any Realtek RTL8211x PHY since v2016.05, and limited to Realtek RTL8211B/C PHYs since v2017.01 (i.e. it is ignored on newer revisions of LIME2); it is enabled by default for defconfig A20-OLinuXino-Lime2 (since v2016.05 intermittently and) since v2020.04; it is not enabled for defconfig A20-OLinuXino-Lime2-eMMC (available since v2017.09).
Beware: You may need additional changes with older linux or u-boot.

calibrate at MAC

A workaround for rev. F and newer (and maybe rev. A-E as well?) is to apply trace length compensation at the MAC.
Mainline u-boot supports compensating at MAC since v2015.04 using option CONFIG_GMAC_TX_DELAY.
Olimex fork of u-boot hardcodes the equivalent of CONFIG_GMAC_TX_DELAY=2 for rev. F-G2 boards, and the equivalent of CONFIG_GMAC_TX_DELAY=4 for rev. H-L boards.
Some have alternative had success with rev. G2 and u-boot option CONFIG_GMAC_TX_DELAY=4.
Some have alternatively had success with rev. K and u-boot option CONFIG_GMAC_TX_DELAY=3, also noting that the Micrel PHY gets significantly hotter than the older Realtek RTL8211CL/RTL8211E PHYs.
Beware: A bugfix optimal for one board revision may adversely affect other board revisions!
Beware: You may need additional changes with older linux or u-boot.

Further testing

Current approach in mainline u-boot of unconditionally compensating at MAC require different values for rev. F-G2 as for rev. H-K.

Port Olimex board-detection to mainline u-boot

Olimex fork of u-boot probes and apply compensations conditional to i2c eeprom information about board revision. Maybe that can be ported to mainline u-boot.

Change device-tree to use PHY-mode RGMII-ID

Changing device-tree to use PHY-mode RGMII-ID (not RGMII), and rely on driver-specific default compensations, has been succesfully tested to work with rev. H-L board.

Tests require recompiling u-boot to not apply other ethernet quirks, and then use a device-tree binary patched like this:

dtc sun7i-a20-olinuxino-lime2.dtb | sed 's/"rgmii"/"rgmii-id"/' | dtc -o test - && mv --force test sun7i-a20-olinuxino-lime2.dtb

(beware that above code is sloppy and may wreak havoc on other revisions of the device tree files than the current one)

If this works reliably for all three board revisions, solution is probably to first get a patch like this (applied for another board since v5.13) accepted in mainline linux, and then have mainline u-boot drop current quirks.

Misc. ideas

  • test rev. A-E board with u-boot option CONFIG_GMAC_TX_DELAY=N at various values and without RTL8211X_PHY_FORCE_MASTER=y
  • test rev. F-G2 board with u-boot option CONFIG_RTL8211E_PINE64_GIGABIT_FIX=y
  • test rev. F-G2 board with u-boot option CONFIG_GMAC_TX_DELAY=N at various values (including 2 or 3 which some find optimal)
  • test rev. H-L board with u-boot option CONFIG_PHY_MICREL_KSZ9031=y and u-boot command setenv disable_giga
  • test rev. H-L board with u-boot options CONFIG_PHY_MICREL_KSZ9031=y and CONFIG_GMAC_TX_DELAY=N with the latter at various values (including 3 or 4 which some find optimal)
  • test with u-boot and Linux device-tree option phy-mode = "rgmii-id"
  • inspect with ethtool 5.8 or newer if ethernet is in master or slave mode when conducting other tests, and try force the opposite mode to check if a calibration setup behaves same in both modes.

GMAC-related software bugs

Rev. A-E would fail to work in master mode, because workaround for a GMAC quirk was accidentally disabled since v2017.03).
Fixed since mainline u-boot v2020.04.

Rev. H-L would fail to work or lose packets at 100 megabit or gigabit speeds, because Micrel PHY driver was not loaded by default.
Fixed since mainline linux v5.5 and mainline u-boot v2021.01.

Expansion ports

The internal GPIO headers appear to be mirrored compared to the original Lime boards [1]. Due to this there are specific A20-OLinuXino-Lime2-UEXT adapters, however as of 2014-09-28 these do not appear to be available directly from the Olimex shop.

Booting from SPI Flash

See the main Bootable_SPI_flash article for generic guides on how to boot from SPI flash. With SPI flash it is possible to use SATA or network boot without any need to use an SD card for storing the U-Boot bootloader.

Since rev. K all Lime2 boards are equipped with SPI NOR flash.

In case you have older revision, it is possible to add it yourself, as this requires soldering wires to 3 pads on the empty NAND socket in order to get access to the PC0,PC1,PC2 pins.

Using LiPo battery

Warning! Battery connector, JST, is exactly the same as SATA power connector!

PMIC AXP209 can charge LiPo battery and it has DC-DC bust-up converter to power the board from battery.

LED "CHGLED" (near battery connector): yellow — battery is charging.

If you connect the battery when the board is powered off, it will not power on automatically.

SATA power connector

Unlike other sunxi boards the Olimex boards don't use the JST XH 0.1"/2.5mm header for SATA power but the smaller JST PHR-2 header normally used for connecting LiPo batteries.

Hardware reliability

There are known cases where Lime2 boards are failing in the wild. The main suspects are DRAM clock speed and CPU core voltage. For more information see [Hardware Reliability Tests].

DRAM clock speed limit

DRAM is clocked at 480 MHz by the hardware vendor (in fact even 532Mhz is mentioned in the blog). The board uses somewhat non-standard resistors for ZQ calibration (ZQ = 330 Ohm, SZQ = 330 Ohm), but at least they seem to be the same in Lime2 revisions from Rev.B to Rev.E according to the board schematics. Still it's best to always mention the board revision in the results table in order to avoid any surprises.

DRAM test results

Having done runs on a larger set of boards, initial test results looked appalling. Machines that where known to have caused trouble in the past, failed within the hour. Others kept going for a few hours actually. We did notice temperature variation influences. On a Monday, the heating in the building was broken and the ambient temperature was only 20 degrees Celsius and 3 boards ran overnight without a problem. On Wednesday the heating was fixed and the ambient temperature rose to 23 degrees Celsius and all three boards had crashed. All of the initial 6 test subjects crashed and failed at their stock 480 DRAM frequency setting!

Expanding this test to influence ambient temperature, even more interesting results where found. For example, 456 Mhz seemed stable at 22 degrees Celsius, but with an ambient temperature of 50 degrees Celsius a few boards still crashed. Lowering the frequency even more, to 432 MHz stabilized that and thus the ambient temperature was increased to 70 degrees Celsius. Here the sunxi_tp_temp, which is very unreliable, reported core temperatures of about 77 degrees Celsius. The board however remained running stable at least one hour.

Lima-memtester was used for testing. The full tests results can be seen in this sheet, and can eventually be modified into table below.

Hardware Diagnostic software lima-memtester passes lima-memtester fails Notes
User:JohnDoe's A20-OLinuXino-Lime2 Rev.? fel-boot-lima-memtester-on-a20-lime2-v1.tar.gz ? MHz ? MHz ? MHz fails after running for ? minutes

Adding a serial port

UART connector

There is a clearly marked UART0 connector on the edge of the board beside the ethernet connector. All you have to do is attach some leads according to our UART howto.


See also

Manufacturer images

Olimex images for Lime2