Olimex A20-OLinuXino-Lime2

From linux-sunxi.org
Jump to: navigation, 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

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 the sun7i-a20-olinuxino-lime2.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 RGMII timing, i.e. if total delay a.k.a. skew applied in MAC and/or PCB and/or PHY is outside the range of 1.5-2 ns, in either or both of transmitting (TX) or receiving (RX) directions.
(TODO: Figure out if forcing only half duplex modes can help identify or rule out this cause)

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

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. building u-boot with option CONFIG_PHY_MICREL_KSZ9031=y and 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).

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 in v2016.05 - v2017.03 (then accidentally disabled) and enabled again since v2020.04; it is not enabled for defconfig A20-OLinuXino-Lime2-eMMC (available since v2017.09).

A workaround (or proper fix?) for rev. F and newer (and maybe rev. A-E as well?) is to build with trace length compensation.
Mainline u-boot supports this workaround 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.
Beware: A bugfix optimal for one board revision may adversely affect other board revisions!
Beware: Mainline u-boot does not enable Micrel PHY by default so you need to build u-boot with option CONFIG_PHY_MICREL_KSZ9031=y in addition to option CONFIG_GMAC_TX_DELAY for rev. H-L boards.

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.

Further testing

Most Olimex OLinuXino boards including Lime2 are equipped with i2c eeprom containing board information and revision information, therefore it should be possible to implement automated quirk management.


  • 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)

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.

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.

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

Personal tools