Home > Allwinner A-Series, Android, Debian, Hardware, Linux > Olimex A20-OLinuXino-LIME2-eMMC Board Replaces NAND by eMMC Flash for Better Performance & Reliability

Olimex A20-OLinuXino-LIME2-eMMC Board Replaces NAND by eMMC Flash for Better Performance & Reliability

A20-OLinuXino-LIME boards are the most popular development board sold by Olimex, likely thanks to reasonable pricing, and Allwinner A20 is one of the rare low cost processor to features an actual SATA interface and Gigabit Ethernet support. The company has now launched a new version A20-OLinuXino-LIME2-eMMC, based on A20-OLinuXino-LIME2-4GB, but replacing the NAND flash by an eMMC flash that should offer both better performance and reliability.

A20-OlinuXino-LINE2-eMMC A20-OLinuXino-LIME2-eMMC specifications:

  • SoC – Allwinner A20 dual-core ARM Cortex-A7 CPU @ 1.0 GHz  with dual-core Mali 400 GPU
  • System Memory – 1GB DDR3
  • Storage – 4GB eMMC flash (Micron), SATA data and power connectors, micro SD slot, 2KB EEPROM for MAC address and custom data
  • Connectivity – Gigabit Ethernet
  • Video Output – HDMI up to 1080p60
  • USB – 2x USB 2.0 host ports with power control and current limiter, 1x micro USB-OTG with power control and current limiter
  • Expansion – 160 GPIOs on four GPIO headers (0.05” pitch), LCD header
  • Debugging – DEBUG-UART connector for console debug
  • Misc – Status, battery charge, and power LEDs; 2x buttons with ANDROID functionality and RESET button
  • Power Supply – 5V DC; LiPo battery connector with battery-charging capabilities
  • Dimensions – 84 × 60 mm
  • Temperature Range – 0 to +70C

The board is not pre-loaded with any operating system, but you can find firmware images and instructions on the Wiki, including Debian 8 (Jessie), Debian 7 (Wheezy), and Android 4.2.2 officially supported, as well as several community supported images (Debian & openSUSE). As with most Olimex products, A20-OLinuXino-LIME2-eMMC is open source hardware with all relevant files available for download.

Olimex_LIME_A20_Gigabit_Ethernet_MicroSDThe announcement also mentions that the 4GB eMMC flash is an industrial grade SLC flash made by Micron that’s specified to work in -40 to +90C temperature range. However, some other components (DDR3 and Ethernet PHY) are only commercial grade components, which limits the board use to 0 to 70C. If you want to use the board is tough environment, the good news is that Olimex is also planning to launch an industrial grade version of the board, but they’ve yet to find an industrial grade Ethernet PHY chip, so suggestions are welcome.

A20-OLinuXino-LIME2-eMMC board is now selling for 55 Euros, the same price as the NAND flash version.

  1. tkaiser
    May 4th, 2016 at 16:05 | #1

    Christo Radev, one of our Armbian users made extensive and very helpful testings and enhancements for this board that might give deep insights into some relationships (detailed consumption and so on — all collected in a nice PDF at the end of the thread): http://forum.armbian.com/index.php/topic/853-armbian-customization/page-4

    And if I’m not completely wrong we also support the eMMC variant E starting with Armbian 5.10 already: http://www.armbian.com/olimex-lime-2/

    According to some talk in linux-sunxi IRC yesterday the eMMC specs might be wrongly communicated. But here I’m not sure at all.

  2. tkaiser
    May 4th, 2016 at 16:15 | #2

    Update: The detailed measurements can be found on page 2 of the aforementioned thread and not at the end. And on my TODO is to incorporate Christo’s many monitoring fixes into a generic approach that can be used on any board we support now (A20 based boards being the best supported since there we get most of the relevant data sources already via sysfs with both legacy and mainline kernel). But this will take some time…

  3. Drone
    May 4th, 2016 at 18:48 | #3

    Why is eMMC considered “more reliable” than NAND? Isn’t eMMC just NAND wrapped in added interface and ECC layers? If so, the ECC in eMMC may or may-not be more reliable than NAND interfaced with a host that drives the interface and adds its own robust ECC layer.

  4. May 4th, 2016 at 20:07 | #4

    @Drone
    Based on Olimex blog post, it looks like NAND relies on the driver for wear and tear management, while for eMMC flash it’s done internally. The number of write cycles will depend on the specific part used though.

  5. benjamin
    May 4th, 2016 at 23:02 | #5

    @Drone

    Exactly this. eMMC is just a NAND die coupled with a NAND flash controller and connects to the rest of the system via MMC interface. So performance and reliability is entirely dependent on the flash controller used.

  6. benjamin
    May 4th, 2016 at 23:04 | #6

    @cnxsoft

    Thats very odd. To my understanding, Allwinner uses a flash controller for ONFi and toggle NAND flash. So it should have its own firmware (just like ssds have) and shouldn’t rely on any system level drivers (because that would be a very bad idea).

  7. cortex-a72
    May 5th, 2016 at 01:17 | #7

    @benjamin
    This is not odd at all, NAND is a bare nand memory array, as DRAM chips are (bare memory arrays), you need to manage them by yourself on the SoC side, through some kind of memory controller. eMMC is a nand memory chip plus an eMMC controller on it. In the case of eMMC, internal controller does wearing out management of the underlying nand. Why do you think the internal controller’s firmware would do wearing out management better than the system level driver? It all depends on the quality of the software in both cases equally. Do you think the controller does the magic? No it doesn’t, it is the same bugs-not-free software. But with the controller, you would not be able fix bugs in it.

  8. Drone
    May 5th, 2016 at 17:02 | #8

    @cortex-a72
    That’s the way I understand it. Some SoC’s have hardware assisted NAND controllers on-die. eMMC wraps the NAND memory in an integrated controller. Secure systems integrators will refuse to allow eMMC or use a SoC’s on-die hardware NAND controller because there is no way to guaranty the security of a controller in third-party silicon. However, if you use a soft-controller, the code can be tested and audited for security.

  9. benjamin
    May 6th, 2016 at 13:30 | #9

    @cortex-a72

    Because system level driver will be all kinds of clusterfuck. You want to change nand on the device ? Well, you need to patch the kernel to update the firmware to support that nand (because each nand usually requires a seperate firmware).

    With separate firmware you can keep the system image the same for all devices on a common chipset and only update the firmware within the SoC (just like with a ssd or flash drive) and leave the system image alone.

    There is a reason why host managed NAND never caught on. It would just be one huge clusterfuck.
    Image getting a noname flash drive, plugging it into your favorite linux box, only realising your kernel is not patched yet for the drive to be used properly.

  10. benjamin
    May 6th, 2016 at 13:36 | #10

    >But with the controller, you would not be able fix bugs in it.

    Of course you can. Just update the firmware, like with every other flash drive out there.

  11. mdel
    May 7th, 2016 at 03:57 | #11

    one very nice (and rare) thing about OLinuXino boards is the lipo battery power rail.
    Of course it doesn’t cost much (any $5 power bank board will do) to get that as an external feature on any arm board but well if you want it embedded it’s there.

    I usually don’t use those boards for battery powered projects but it’s a very nice thing to have a failsafe hardware that will let you shut down you system safely when mains go out.

  1. No trackbacks yet.