Posts Tagged ‘rootfs’

Embedded Linux Conference & IoT Summit Europe 2016 Schedule

August 2nd, 2016 4 comments

Embedded Linux Conference & IoT summit 2016 first took place in the US in April, but the events are now also scheduled in Europe on October 11 – 13 in Berlin, Germany, and the schedule has now been published. Even if you are no going to attend, it’s always interesting to find out more about the topic covered in that type of events, so I had a look, and created my own virtual schedule with some of the sessions.

Embedded_Linux_Conference_Europe_2016Tuesday, October 11

  • 10:40 – 11:30 – JerryScript: An Ultra-lightweight JavaScript Engine for the Internet of Things – Tilmann Scheller, Samsung Electronics

JerryScript is a lightweight JavaScript engine designed to bring the success of JavaScript to small IoT devices like lamps, thermometers, switches and sensors. This class of devices tends to use resource-constrained microcontrollers which are too small to fit a large JavaScript engine like V8 or JavaScriptCore.

JerryScript is heavily optimized for low memory consumption and runs on platforms with less than 64KB of RAM and less than 200KB of flash memory. Despite the low footprint, JerryScript is a full-featured JavaScript engine implementing the entire ECMAScript 5.1 standard. It is actively used in production and runs already on hundreds of thousands of smartwatches!

JerryScript is an open source project and has been released under the Apache License 2.0. The talk will include a demo showing JavaScript code executing on top of JerryScript on a resource-constrained microcontroller.

  • 11:40 – 12:30 – Read-only rootfs: Theory and Practice – Chris Simmonds, 2net

Configuring the rootfs to be read-only makes embedded systems more robust and reduces the wear on flash storage. In addition, by removing all state from the rootfs it becomes easier to implement system image updates and factory reset.

In this presentation, Chris shows how to identify components that need to store some state, and to split it into volatile state that is needed only until the device shuts down and non-volatile state that is required permanently. He gives examples and shows various techniques of mapping writes onto volatile or non-volatile storage. To show how this works in practice, he uses a standard Yocto Project build and shows what changes you have to make to achieve a real-world embedded system with read-only rootfs. In the last section, Chris considers the implications for software image update. Expect a live demonstration.

  • 14:00 – 14:50 – Comparison of Linux Software Update Technologies – Matt Porter, Konsulko

The update of software in an embedded Linux system has always been an important part of any product. In the past, however, planning and design for software update was often an afterthought in system design. Further, software update mechanisms for embedded Linux products were typically implemented as ad hoc one-off projects within each product company. As the requirements for products have matured to include security updates at a frequent intervals, software update strategy has become a focal point of product development. This session will explore a number of different Linux software update technologies that are FOSS projects, comparing each for their strengths and weaknesses. In order to better understand the applicability of these technologies, we will also deep dive into both common and uncommon use cases that drive requirements for these software update mechanisms.

  • 15:00 – 15:50 – Building a Micro HTTP Server for Embedded System – Jian-Hong Pan

Apache HTTP Server, NGINX .. are famous web servers in the world. More and more web server frameworks come and follow up, like Node.js, Bottle of Python .., etc. All of them make us have the abilities to get or connect to the resources behind the web server. However, considering the limitations and portability, they may not be ported directly to the embedded system which has restricted resources. Therefore, we need to re-implement an HTTP server to fulfill that requirement.

Jian-Hong will introduce how he used the convenience of Python to implement a Micro HTTP Server prototype according to RFC 2616/HTTP 1.1. Then, re-write the codes in C to build the Micro HTTP Server and do the automated testing with Python Unit Testing Framework. Finally, he’ll explain how he combined the Micro HTTP Server with an RTOS, and lit the LEDs on an STM32F4-Discovery board.

  • 16:10 – 17:00 – Stuck in 2009 – How I Survived – Will Sheppard, Embedded Bits Limited

When developing Linux based products it’s desirable to use the latest version of the Linux kernel – however this is not always possible. In this presentation Will Sheppard will enlighten you with his experiences in developing a product based on a 2.6.28 kernel. Throughout the presentation he will share with you the reasons why you can be stuck with an old kernel, the issues this causes and the surprising and unexpected benefits that also arise. The presentation will also give you an indication as to how far the kernel has developed since 2009 and perhaps some hope if you too are also stuck working in the past.

  • 17:10 – 18:00 – Power Management Challenges in IoT and How Zephyr RTOS Meets Them – Ramesh Thomas, Intel

An OS that runs on tiny IoT devices is already meeting several challenges. These challenges are due to the limited resources in these devices and the diverse nature of the applications and the ecosystem. These same reasons make adding an effective power management infrastructure extremely complex. These devices that run on tiny batteries for extensive periods, mostly unattended, have a very critical need to conserve power.

Zephyr is a RTOS from Intel, designed for IoT and wearable devices. It is open source and supports x86, ARM and ARC SoC platforms. It has a small footprint and can run with very less memory. Power management is built in the core of its scheduling and idling design. It exports infrastructure for PM services to implement custom power policies.

This presentation will give an insight into the Zephyr power management design and the philosophies behind it.

  • 18:10 – 19:00 – BoF: Linux Device Performance Framework – Michael Turquette, BayLibre

Complex system-on-chip processors provide performance levels for their devices and peripherals. The same chips also provide interconnects with performance knobs connecting these devices. For years, Linux has not provided a way to express the relationship between a device and its performance states, nor a uniform method for drivers to change these states. There are many solutions to this in downstream vendor trees. Let’s fix that.

The purpose of this BoF is to start a discussion around the topic with a wide audience, solicit feedback on the currently proposed approach and move forward with consensus. This BoF will discuss the types of performance states that need to be modeled, existing Linux driver frameworks that can be re-used, new code that needs to be written and how Device Tree plays a role. Will we write a new DVFS or Interconnect Framework? Attend and find out!

Wednesday, October 12

  • 09:00 – 09:50 – Supporting the Camera Interface on the C.H.I.P – Maxime Ripard, Free Electrons

Every modern multimedia-oriented ARM SoC usually has some kind of camera interface to be able to capture a video (or photo) stream from an external camera. The framework of choice to support these controllers in Linux is the Video4Linux subsystem, also called v4l2.

This talk will walk through the v4l2 stack, the architecture of a v4l2 driver and the interaction between the SoC driver and its camera’s. The presentation is based on the work Free Electrons has done to develop such a driver for the Allwinner SoCs, as part of enabling the C.H.I.P platform with the upstream Linux kernel.

  • 10:00 – 10:50 – How to Develop the ARM 64bit Board, Samsung TM2 with Exynos5433 – Chanwoo Choi, Samsung Electronics

In the last period of twenty years ARM has been undisputed leader for processor’s architecture in the embedded and mobile industry. With its 64 bit platform, ARM widens up its field of applicability. The ARMv8 introduces a new register set, it is compatible with its 32 bit predecessor ARMv7 and suits best those system that try to be amongst the high end performance devices. Tizen OS is an open multi profile platform that can run on TV, mobile, cars and wearables. Samsung TM2 board based on Exynos5433, which patches has been recently posted to mainline, is an ARM 64-bit board supported by Tizen 64-bit. However, during the bring-up, the kernel developers have faced many challenges that will be presented in this session. The presentation will go through a number of issues and the way they have been solved in order to make Tizen run on a 64 bit platform.

  • 10:45 – 11:35 – Devicetree Hardware Autoconfiguration – Hans de Goede, Red Hat

One can buy 7″ android tablets for around $35 now, assuming one gets the standard Q8 Allwinner based model, these are actually supported by the mainline linux kernel now. These tablets use a standard case + SoC + display, which get paired with a different touchscreen-controller, accelerometer and wifi chip for every other batch.

This talk will outline my experience in making a single devicetree file covering all variants using an in kernel hardware auto-detection module which creates and applies devicetree changesets depending on the detected hardware. This talk will give the audience an idea what is and is not possible wrt dynamic devicetree usage as well as give does and don’ts for people who want to use dynamic devicetree themselves.

  • 11:45 – 12:35 – Wyliodrin STUDIO: An Open Source Tool for IoT Development – Alexandru Radovici, Wyliodrin

Have you been using your development board (like the Raspberry pi for example) as a glorified computer? Are you tired of needing to hookup your boards to a display and keyboard any time you want to program them?

Wyliodrin STUDIO is a software development tool especially created for the design of IoT projects. It comes as an open source Chrome extension so that programmers can use it independently of their specific OS platform and with little setup overhead.

Wyliodrin STUDIO abstract away many of the issues regarding setting up your development boards and allows programmers to directly focus on their projects. It offers a friendly programming environment with many of the features of advanced IDEs, like Eclipse. For beginners, Wyliodrin STUDIO offers a large range of tutorials to help people take their first steps in IoT development. MagPi gave Wylidorin STUDIO a 5/5 rating.

  • 14:00 – 14:50 – ASoC: Supporting Audio on an Embedded Board – Alexandre Belloni, Free Electrons

ASoC, which stands for ALSA System on Chip, is a Linux kernel subsystem created to provide better ALSA support for system-on-chip and portable audio codecs. It allows to reuse codec drivers across multiple architectures and provides an API to integrate them with the SoC audio interface.

This talk will present the typical hardware architecture of audio devices on embedded platforms, present the ASoC API and how to use it for machine drivers, which are used to glue audio codecs with the processor audio interface. Examples, common issues and debugging tips will also be discussed.

  • 15:00 – 15:50 – Cameras in Embedded Systems: Device Tree and ACPI View – Sakari Ailus, Intel

Cameras in embedded systems are often collections of different components rather than monolithic devices such as USB webcams. They consist of sensors, lenses, LED or xenon flashes and ISPs, each of which are individual devices with their specific drivers.

Once the prevalent solution for supporting hardware variation between different ARM based systems was platform data. Since around 2011 new platform data files have had hard time getting to mainline, the preferred solution being the Device tree. However, Device tree support in the V4L2 framework was not around until over a years after that, additionally help from the V4L2 async framework is also required in order to achieve the same functionality as with platform data.

This talk shows how the frameworks are used in drivers and Device tree source, reviews the status of ACPI and discuss potential future developments.

  • 16:30 – 17:20 – Swapping and Embedded: Compression is the Key – Vitaly Wool

Ever since Linux started running on embedded devices, having a swap for such had been considered a misconfiguration rather than a method for overcoming RAM shortage or performance booster. This attitude started to change with the spread of Android devices which usually don’t have a problem utilizing virtually any amount of memory. An with the introduction of ZRAM the usage of a compressed swap in RAM became more useful and more popular. This talk will give a comprehensive description of ZRAM and its counterpart, zswap, a summary of pros and cons of both. This talk will also cover a brand new z3fold compressed memory allocator which can be used for both zswap and ZRAM, of course presenting measurement results for these, obtained on various devices, ranging from set top boxes to laptops, not to forget Android phones.

Thursday, October 14

  • 09:00 – 09:50 – Time is Ready for the Civil Infrastructure Platform – Yoshitake Kobayashi, Corporate Software Engineering Center & Urs Gleim, Seimens

The Civil Infrastructure Platform (CIP) – launched in April – CIP defined and started to realize a super long-term supported open source “base layer” for industrial grade software. This base layer aims to be used for current and future industrial systems which supports machine-to-machine connectivity for digital future. This kind of systems, being the field for decades, should have long-term support for security and robustness reasons. In this talk, we will show the first steps on CIP development. This includes initial set of components for the base layer and its maintainers. Are you ready? It’s time to start your development with and for the CIP.

  • 10:00 – 10:50 – Introduction to Memory Management in Linux – Alan Ott, Signal 11 Software

All modern non-microcontroller CPUs contain a memory management unit and utilize the concept of virtual memory. This presentation will describe the different types of virtual memory spaces and mappings used in the Linux kernel, the cases in which they are useful, how they are implemented in the kernel, and how they differ from user space memory. Concepts such as the hardware memory-management unit (MMU) and translation lookaside buffer (TLB) will be discussed, as well as software concepts like kernel page tables. User space concepts such as growable stacks, memory paging, memory mapping, page faults, exceptions, and other memory-related conditions will be covered as well.

  • 11:15 – 12:15 – MinnowBoard Delta: Fishing for Easy IoT Hardware – David Anders, Intel

With the introduction of the Zephyr Project, a small scalable real-time operating system for use on resource-constrained systems, the need for an easy to use platforms to enable Internet of Things development has grown. With the idea of enabling both hardware and software developers to quickly prototype and develop proof-of-concept, as well as transitioning directly to product, the MinnowBoard Delta was designed as an open source hardware platform to highlight the Zephyr Project. This presentation will cover design considerations as well as implementation methods for creating open source hardware specifically for open source software.

  • 12:15 – 13:05 – Cloud Platforms for the Internet of Things: How Do They Stack Up? – Koustabh Dolui, Politecnico di Milano

With the advent of the Internet of Things (IoT), there has been a recent surge in the number of cloud platforms offering their services for data collection and processing from IoT devices. These platforms, open-source and closed, are diverse in terms of ease of use, architecture, data storage, privacy, security and communication protocols. However, how these cloud platforms measure up against each other, given the set of tradeoffs that they present, remains quite unexplored in existing literature. In this presentation, Koustabh will present a detailed study on the architecture that these platforms are based on and how the open source platforms compare against closed platforms. Koustabh will compare the platforms based on a real data-set generated from a sensor network deployed at the heritage site of Circo Massimo, Rome, as a part of an ongoing project at Politecnico di Milano, Italy.

  • 14:30 – 15:20 – GPIO for Engineers and Makers – Linus Walleij
We will go over the changes to the GPIO subsystem in the recent years, including GPIO descriptor refactoring, new support for things like open drain, some words on device tree and ACPI hardware descriptions, and we will discuss the new userspace character device ABI for GPIO chips and how use cases such as those presented by the maker community or industrial control clients can benefit from it. We will also talk a bit about the future direction of the subsystem.
  • 15:30 – 16:20 – FDO: Magic ‘Make My Program Faster’ Compilation Option? – Pawel Moll, ARM

Feedback Driven Optimisation (FDO), also known as Profile Guided Optimisation (PGO) is a well known code optimisation technique, employed by compilers since mid XX century, yet not widely used in the wild these days. It relies on providing runtime-captured information about code execution (eg. “branch taken or not?”) during next code compilation, improving quality of decisions made by compiler heuristics.

To be fair, there were good reasons for its demise which I hope to discuss, mainly time and complexity overhead and deployment difficulties, but there is some hope on the horizon, coming with new approach, called AutoFDO and originating at Google, based on statistical profiling (namely Linux perf + extra tools) and source code level attribution. I’ll discuss existing support for it available in mainline GCC and LLVM and give examples of real-life, successful deployments.

If you’d like to attend the event, you can do so by registering online, and paying the entry fee:

  • Early Registration Fee: US$550 (through August 1, 2016)
  • Standard Registration Fee: US$650 (August 2, 2016 – September 3, 2016)
  • Late Registration Fee: US$850 (September 4, 2016 – Event)
  • Student Registration Fee: US$175 (valid student ID required)
  • Hobbyist Registration Fee: US$175

How to Boot a Headless Linux Image on Amlogic S802 TV Boxes (Tronsmart Vega S89 Elite)

May 15th, 2014 34 comments

As some of you already know, I’ve been playing around with Tronsmart Vega S89 Elite, an Android TV Box powered by Amlogic S802 quad core ARM Cortex A9r4 processor at 2 GHz. Today, I’ll show how to boot a headless Linux image on any Amlogic based S802 TV Box from the network. The instructions can mainly be used as a starting point for developers, as it requires access to a serial terminal via  UART, but if you’ve never done it before, the instructions should be easy enough to follow. Everything is loaded from the network, the kernel (via boot.img) is loaded via TFTP, and the rootfs (Linaro ALIP image) is mounted via NFS, so it’s nearly impossible to brick your device using the method provided. Linaro ALIP rootfs comes with LXDE, but at this stage the desktop environment is not showing, even through my HDMI TV is properly detected by the drivers. However, Ethernet, USB mass storage, and the micro SD seem to be working just fine.


If you want to skip the kernel compilation part, ramdisk modification, and just boot your Vega S89 Elite from network you can download vegas89eboot.img (compressed with bzip2), and skip steps 4 to 9 included. Please don’t just flash this image or use it without reading the post, as even if it should not brick your device, Android won’t boot at all if you don’t follow the right instructions.

Let’s get started

  1. Make sure you’ve connected a USB to serial board to your S802 based device.
  2. If not done already, you’ll need to install TFTP and NFS servers, and the get basic development tools in a Linux computer. All instructions here have been performed in a PC running Ubuntu 14.04 64-bit.
    • For the TFTP server, I installed and ran aftfpd as follows:
    • Instructions to install an NFS server on Ubuntu/Debian.
    • You’ll need to install the build-essentials and other tools to successfully build Linux, something like:
  3. Download a rootfs, and extract it to your NFS directory. For example:
  4. Get the device tree file (DTD) for your device from its firmware image or, if not available, directly from the NAND flash.
  5. Follow the instructions to get S802 kernel source and setup the source tree until after the step where you do
  6. Run “make ARCH=arm menuconfig” to enable NFS client support as shown below.
    Linux_3.10_NFSThen exit and save
  7. You’ll need to edit script for your device using the correct DTD file, which you need to copy to ./arch/arm/boot/dts/amlogic/ directory.  I’ve renamed the script to, and edited it as follows:
  8. We also need to create and init to switch the root to NFS. Normally, we should be able to do  in the bootloader with “bootargs” but this did not work for me, probably because I missed some steps.
    1. Extract the ramdisk provided with the source code
    2. Delete sbin/init symlink to busybox, and create a new init file. Be very careful at this stage as if you inadvertently add a leading slash, you’ll mess up with your PC system.
    3. Here’s the content of sbin/init. Replace by the IP address of your PC / NFS server, and /srv/nfs/alip by the path where you extracted your rootfs in the NFS directory.
    4. Recreate the ramdisk
  9. Now we can finally build the kernel, and boot.img:
  10. It should take between a minute to a few minutes depending on your machine, and if everything works as planned you could get your boot.img, in my case vegas89eboot.img. Copy it to your tftp server directory
  11. Now start minicom connected to ttyUSB0 (115200 8N1), and power the TV box. Press the space bar, or any other key, during boot up to access U-boot command line. Let’s define IP addresses for the board, the TFTP server, and gateway (router), and save these to the U-boot environment:
  12. Setup the boot arguments for NFS. I know I should really have used fixed IP instead of dhcp, for consistency, and to shave off two or three seconds to boot time, but…

    You could also use saveenv to save these, but then Android won’t boot anymore next time your start the board. Alternatively, you could create a bootargs2 and copy this to bootargs before running Linux.
  13. Load boot.img from the TFTP server
  14. Start the system

    Once you make sure boot.img loads properly from TFTP server, you could also combine both commands with “bootp; bootm
  15. You should now have access to the command line as root, no password required. An sshd daemon is already running so you can access it via ssh if you want. The board temperature will be outputted every second or so. There must be a way to disable that in the code, but in the meantime you can do:

Let’s have a look at free memory, storage devices and more.

There’s about 1.5GB ram free, I’ve got a lot of storage in the root as it is the 1TB hardware in my PC, and my 4GB USB flash drive was almost mounted automatically.

I’ll also through the CPU information for reference:

You should easily be able to adapt these instructions to boot from flash, by inserting boot.img into one of the available firmware update packages, and switching root to a USB flash or hard drive with the rootfs. I’m not sure how to access the flash partitions right now, as only the bootloader shows up in the MTD partition, but it;s the same thing in Android.

I’m not sure I’ll go much further myself, but hopefully some people will pick up on this, and we’ll get a fully working easily installable Linux server and desktop images for Amlogic S802 based platforms.

Booting Linux in Less Than 1 Second in AllWinner A10 Devices? Yes! You Can!

April 22nd, 2013 6 comments

threewater, a Chinese developer, has just posted a very interesting demo on linux-sunxi mailing list showing a device based on AllWinner A10 boot linux within 0.85s, and if you add a Qt app, the total time is just about 1.2s.

This appears to be a custom hardware (EM6000), but we do know it’s based on AllWinner A10, comes with 512 MB RAM, and 4GB NAND Flash. On the software side, the device runs kernel 3.4 from linux-sunxi, with a customized version of uboot, a squashfs rootfs, and a Qt 4.7.4 app showing a gauge. Both the rootfs (7MB) and the kernel (2MB) have been compressed with LZO. All that boots from NAND flash for optimal speed.

The 1.2 second time includes kernel + rootfs + app time, and the total time is a bit longer, but this is still impressive. Here’s the boot log:

If you just boot to the command line, it’s even faster:

This is not the first time, people have implemented ultra fast boot on ARM hardware, an example is a ~400ms boot on the Beagleboard, but it’s still nice to see what can be achieved thanks to developers’ communities such as linux-sunxi.

The complete details and/or binary files are not available at this time, but if you are interested in Linux fast boot, you may considering checking Adeneo Embedded presentation at ELCE 2012 who did something very similar on Freescale i.MX51 & i.MX 6Q hardware.

Embedded Linux Boot Time Optimizations – ELCE 2012

January 15th, 2013 No comments

Alexandre Belloni, embedded Linux engineer and trainer at Adeneo Embedded, gives a presentation about different techniques to optimize boot time for Embedded Linux at ELCE 2012. He also explains how they’ve measured the boot time.


A common problem faced when embedding Linux is the long boot time before the system is functional. There are many ways to improve boot up time. For a particular project, we had to answer a CAN message from Linux userspace in less than 420 ms from going out of CPU reset. We will describe our methodology and the techniques we finally chose to implement in that particular use case. We will also detail how we measured the boot time efficiently. A live demo will show the results of our work.

More specifically, Alexandre discusses two projects at Adeneo where boot time was critical:

  • An automotive platform based on Freescale i.mx53 needs to reply to a CAN message in less than 500ms
  • An OpenGL application must boot as fast as possible on a platform powered by Freescale i.mx6 Quad. After optimization, the app starts within 590ms from reset, 720ms from power on, instead of the 15 to 53!? seconds in the initial rootfs. See video demo.

He describes the different techniques tried to optimize the bootloader, kernel and rootfs, and provides the techniques they finally used in the final solutions.

You can also download the slides for this presentation. Adeneo released the bootloader source code (they completely got rid of U-boot), and you can find most of the techniques used on the Boot Time page from

Getting Ubuntu armel/armhf Rootfs in Ubuntu 12.04

May 18th, 2012 No comments

I’ve recently upgraded to Ubuntu 12.04 and this is a great operating system. However, if you do some arm development and expect to be able to install cross libraries (armel/armhf) or easily generate an arm rootfs using the tools you’ve been used to, you’ll be disappointed.

In Ubuntu 11.10 (Oneiric), I used xapt and dpkg-cross to retrieve armel libraries, but it’s broken for Ubuntu 12.04, at least on my system. I’ve been told to switch to multiarch because this will be how it’s done from now on. But I soon discovered this is work in progress as quite a few packages are not multiarched yet including python.

Ubuntu developers also decided to remove rootstock (which makes sense since xapt/dpkg-cross will be deprecated), so if you want to generate a rootfs the “gool ol'” way (which won’t be supported much longer), you’d have to install an Oneric chroot to run rootstock, or copy the rootstock script in Pangolin.

There are 2 ways to get an Ubuntu rootfs now:

  1. Download the official Ubuntu-Core 12.04  armel or armhf image (a minimal image without X). This is the recommend method, especially if stability is the most important for you, or if you need armel.
  2. Download one of the monthly Linaro armhf releases. That’s the image you’ll want if you need the latest developments. This version should work just fine, but is not as thoroughly tested as the official Ubuntu release.

If you select method 1, you’ll then need to install the needed packages with apt-get. In case your target board only support Wi-Fi (i.e. no Ethernet), you may have to download the required packages (e.g. wireless-tools, wpa-supplicant…) and install them manually (TBC).

To get the armel rootfs:


and the armhf roofs:


Several Ubuntu rootfs are available with the monthly Linaro releases:

  • Ubuntu Desktop (Official Linaro Release) –  e.g. April 2012 Release (492 MB)
  • ARM Linux Internet Platform (ALIP), a lightweight distribution for internet browsing and emails.  April 2012 Release (248 MB)
  • Nano – A minimal image with terminal access only. April 2012 Release (36 MB)
  • Developer – Same as nano but with development tools, e.g. gcc, gdb, libtool, automake… (aka build essentials). April 2012 Release (146 MB)
  • Server (which was not available last month)

You can get the latest images monthly from usually released around the 25th.

How to Create Your Own Debian / Ubuntu Image for Mele A1000 (AllWinner A10 Based STB)

April 28th, 2012 36 comments

Developers working on AllWinner A10 have released an Ubuntu 10.04 LTS SD card image (4GB) for the Mele A1000.

I’ll show how you can create your own Debian or Ubuntu image based on this image for any size of SD Card using Debian 6.0 (Squeeze) and the recent Ubuntu 12.04 (Precise Pangolin) as example. The current image is not perfect, for example Ethernet doesn’t work (but you can still get network connectivity with WiFi), the NAND flash can not be accessed, the system does not appear to be very stable when running X and a few more issues. But this will be fixed by the developer community over time.

Mele A1000 Debian Serial Port Output

Mele A1000 Debian 6.0.4 Terminal

First download the SD card image


Install 7z (if you don’t have it yet) and decompress the file:

sudo apt-get install p7zip-full
7z x mele-ubuntu-lucid.img.lzma

The decompressed size is 4008706048, which might be larger than your 4GB SD Card (as it was my case). If you card is larger, you can simply dd the image to it:

dd if=mele-ubuntu-lucid.img of=/dev/sdX

where X is the letter corresponding to your SD Card device.

Let’s now have a look at the partitions in this image:

file mele-ubuntu-lucid.img
mele-ubuntu-lucid.img: x86 boot sector; partition 1: ID=0x83, starthead 33, startsector 2048, 32768 sectors; partition 2: ID=0x83, starthead 65, startsector 34816, 7794688 sectors, code offset 0x0

There are 2 partitions, let try to mount in 2 directories using the startsector value:

mkdir mnt
mkdir mnt2
sudo mount -o loop,offset=$((512*2048)) mele-ubuntu-lucid.img mnt
sudo mount -o loop,offset=$((512*34816)) mele-ubuntu-lucid.img mnt2

mount | grep loop
/dev/loop0 on /home/jaufranc/edev/mele_A1000/mnt type vfat (rw,offset=1048576)
/dev/loop1 on /home/jaufranc/edev/mele_A1000/mnt2 type ext4 (rw,offset=17825792)

So we can now see the content of the 2 partitions:

  • Partition 1 (FAT 32) – Linux 3.0.8 Kernel (uImage) + some binaries files (evb.bin, mele.bin and sys_config1.mele_mod.bin).
  • Partition 2 (EXT-4) – Ubuntu 10.04 rootfs

There are some files specific to A10 in the rootfs, namely the kernel modules and OpenGL ES files, so we need to extract them in order to copy in the our new rootfs lateron.

cd mnt2
tar cjvf ../a10_modules_3.0.8.tar.bz2 lib/modules/3.0.8+/
tar cjvf ../a10_opengles.tar.bz2 lib/ lib/ lib/ lib/ lib/
cd ..
sudo umount mnt
sudo umount mnt2

We haven’t found the bootloader yet, but you may noticed there is a 1MB offset (512*2048) for the first partition, that because the partition table and the bootloader are located in the first 1MB of the SD Card as explained in A10 MMC Page. There are two part for U-boot: U-boot and  the X-loader up-streaming(SPL), but they are both located in the first 1MB of the SD Card.

Now let’s make a copy of u-boot (and u-boot SPL) and the FAT 32 partition:

dd if=mele-ubuntu-lucid.img of=mele_u-boot.bin bs=1024 skip=8 count=1008
dd if=mele-ubuntu-lucid.img of=mele_kernel_3.0.8_vfat.bin skip=2048 count=32768

Now that we have all what’s needed from the SD card image, let’s create the root file system.

Here are the instructions to get a minimal Debian 6.0 (Squeeze) rootfs:

mkdir debian_armel_squeeze
sudo apt-get install debootstrap
sudo debootstrap --foreign --arch armel squeeze debian_armel_squeeze

Here are the instructions to get a Ubuntu 12.04 (Precise Pangolin) desktop: (JLA check command in Ubuntu virtual box)

sudo apt-get install rootstock
sudo rootstock --fqdn ubuntu --login ubuntu --password ubuntu --imagesize 3G --seed ubuntu-desktop,openssh-server --serial ttyS0 --dist precise

Which ever command you choose it will take while, so in the meantime, let’s prepare the SD Card. I’ll only provide a summary here, for line by line details refer to the instructions provided in the Format section of A10 MMC page. I’ll use /dev/sdb as the drive letter, it may be different on your computer.

  1. Wipe out the SD card partition table:
  2. Create 2 partitions with fdisk:

    The first partition must start at sector 2048 and its size must be 16MB.
    The second partition must start at sector 34816 (I think this may slightly vary depending on your SD card) and fill the rest of the SD card.
  3. Format partition 2:
  4. Copy the u-boot and kernel binaries to your SD card

Once the rootfs of your choice has been generated, first mount the ext4 partition:

Then copy the rootfs to the SD card together with the kernel modules and OpenGL ES files. We are using Ubuntu 12.04 armel here, but if you want to use Ubuntu 12.04 armhf (hard-float) the OpenGL ES file might not work on this system, and AllWinner would have to release hard-float binaries.

For Debian:

For Ubuntu:

At this point the Ubuntu image is basically done and you should be able to see the desktop and login, as long as the Mele A1000 is connected to an HDMI display.

For Debian, you’ll need to complete the second stage of deboostrap and add the apt-get source list using the Mele A1000 serial console, basically following the instructions given in the section “Generating ARMEL Debian Squeeze Rootfs” of that post. Since Ethernet does not work and WiFi is then required for internet connectivity, you also need to go to, download the Debian Squeeze armel packages for libdbus-1-3, libiw30, libnl1, libpcsclite1, multiarch-support, wireless-tools_30 and wpasupplicant_0.6 and copy them to the ext4 partition or a USB thumbdrive to install it at a later stage. You can install the package with dpkg in the Mele A1000:

If you’d like to use the network in your device (including apt-get), you’ll need to setup Wi-Fi. With Ubuntu, you can simply do so in the graphical interface like you would do in PC or use the following instructions for Debian. With Debian, create /etc/network/interfaces file as follows (assuming you are using WPA/WPA2):

Make sure the Wi-Fi module (8192cu) is loaded with lsmod. If not, run depmod -a and possibly restart your device.

Wi-Fi should start automatically, if not run “ifup wlan0”.

By default (due to a setting in the Android kernel provide), a normal user will not be able to access the network, to change that (for user ubuntu):

A final tip. In case you prefer to use VGA instead of HDMI, you can use this code:

The value in this code are based on drv_display_sun4i.h in the kernel code.
Build it and run it:

In case somebody tries those instructions and find some issues or have ideas for improvements, please let me know in the comments section as I may have missed some steps.

Raspberry Pi Releases Arch Linux SD Card Image

March 5th, 2012 6 comments
English: Logo of Arch Linux Nederlands: Het lo...

The Raspberry Pi Foundation has just announced the release of Arch Linux for the Raspberry Pi. This image is based on a minimal image of Arch Linux and does not come with a graphical interface. This distribution may not be suitable for beginners and you may be better off using the Debian SD Card image or even the upcoming Fedora 14 Raspberry Pi Remix image.

You can always install extra packages with Pacman,  the Arch Linux package manager.

To update the package list:

To Install LXDE Graphical Interface:

To run LXDE:

You can download it using BitTorrent: (preferred method) or via one of the HTTP mirrors: (This link will redirect your download to the closest available HTTP server).

The default login credentials are: root/root

I haven’t tried it, but you should be able to use this release in qemu, by following instructions similar to the one I gave to run Raspberry Pi Debian release in QEMU.

Raspberry Pi Releases 1st SD Card Image (Debian) – How-to use it in QEMU

February 18th, 2012 55 comments

The Raspberry Pi Foundation has just released the first SD Card Image that you will be able to use with your Raspberry Pi board. This image is based on Debian Squeeze (6.0) and comes with  LXDE user interface and Midori browser, development tools, and sample code for accessing the multimedia functionality on the device.

You can download it using BitTorrent: (preferred method) or via one of the many http mirrors available on RPi Community page.

This image contains all necessary files including the binary blob and closed source libraries, the kernel and the root file systems.

If you want to to prepare an SD Card with this image simply use dd in Linux:

sudo dd if=debian6-17-02-2012/debian6-17-02-2012.img of={sd_card_path}

where sd_card_path is the device pointing to you SD Card (e.g. /dev/sdc). Make sure you use the correct device (e.g. with fdisk -l) or you may wipeout your hard drive with this command.

Since most of us (including myself), don’t have a Raspberry Pi board just yet, we can still run the rootfs of this image in qemu.

First we need to extract the root file system from the SD card image.  We can analyse the SD Card image with the file utility to find the rootfs partition.

#file debian6-17-02-2012/debian6-17-02-2012.img

debian6-17-02-2012/debian6-17-02-2012.img: x86 boot sector; partition 1: ID=0xc, starthead 0, startsector 2048, 153600 sectors; partition 2: ID=0x83, starthead 3, startsector 157696, 3256320 sectors; partition 3: ID=0x82, starthead 3, startsector 3416064, 391168 sectors, code offset 0xb8

This tool shows the SD image image contains three partitions:

  • FAT 32 Partition – with the GPU binary blob and relevant libraries, the kernel image and some configuration files
  • EXT-4 Partition – with the Debian rootfs (that’s what we want)
  • Swap Partition – ~200 MB swap partition (Virtual memory)

We can now extract the Debian rootfs using dd and the offset (startsector) and size returned the the file utility.

dd if=debian6-17-02-2012/debian6-17-02-2012.img of=rootfs_debian6_rpi.ext4 skip=157696 count=3256320

Good! We’ve got our rootfs. It contains some modules compiled against linux kernel 3.1.9, so we need to compile an ARM11 kernel 3.1.9 for qemu by following the instructions given at, replacing kernel 3.0.4 by 3.1.9 AND enabling ext-4 with make menuconfig.

Once the build is complete copy linux-3.1.9/arch/arm/boot/zImage to zImage_3.1.9.

If you don’t want to experience the joy of building the kernel yourself, you can download the binary:

We can now start the virtual machine with R-Pi Debian rootfs and our updated kernel:

qemu-system-arm -M versatilepb -cpu arm1176 -m 256 -hda rootfs_debian6_rpi.ext4 -kernel zImage_3.1.9 -append "root=/dev/sda" -serial stdio -redir tcp:2222::22

During the system boot, there will be lots of error (like the GPU driver can’t find the GPU…) but you can still reach the login screen. The username/password: pi/suse.

[Update: An error (assertion in arp_table.c) with qemu occurs with many people. You may need to add “-net none” to make it work.  The problem seems somewhat random, some people also had success after downgrading or upgrading qemu).]

You’ll then have access to the command line. LXDE does not start automatically, you need to run:


and after a short while you should see LXDE desktop

QEMU Runs Debian Squeeze LXDE Image

Raspberry Pi Debian LXDE in QEMU

Update: Since some of you have problems, here’s the detail of my setup: Debian Squeeze 6.0.4, Qemu 1.0 running in a Virtual Machine in Virtual Box 4.1.6

You may also wonder what’s inside the FAT partition. Let’s extract it, mount it and list the files:

dd if=./mnt2/debian6-17-02-2012.img of=rpi.fat skip=2048 count=153600
sudo mount -o loop rpi.fat mnt
$ ls -l mnt
total 28072
-rwxr-xr-x 1 root root  2001244 Feb 17 19:02 arm128_start.elf
-rwxr-xr-x 1 root root  2001244 Feb 17 19:02 arm192_start.elf
-rwxr-xr-x 1 root root  2001244 Feb 17 19:02 arm224_start.elf
-rwxr-xr-x 1 root root    16528 Feb 14 01:53 bootcode.bin
-rwxr-xr-x 1 root root      141 Feb 15 01:38 cmdline_testmode.txt
-rwxr-xr-x 1 root root      127 Feb 15 01:52 cmdline.txt
-rwxr-xr-x 1 root root 16412020 Feb 15 01:47 kernel_emergency.img
-rwxr-xr-x 1 root root  3990020 Feb 14 01:53 kernel.img
-rwxr-xr-x 1 root root   314691 Feb 14 01:53 loader.bin
-rwxr-xr-x 1 root root  2001244 Feb 17 19:02 start.elf
sudo umount mnt

start.elf is the GPU binary blob, bootcode.bin / loader.bin are the first files the GPU looks for when booting (I assume), kernel.img is the kernel image and cmdline.txt the configuration file.

There are 3 other binary blob files that can be used to replace start.elf:

  • arm128_start.elf – 128 MB for Linux and the rest (128 MB) for the GPU. To be used for application where the GPU requires a lot of memory (e.g. XBMC)
  • arm192_start.elf – 192 MB for Linux and the rest (64 MB) for the GPU. To be used for application where the GPU requires a moderate amount of memory.
  • arm224_start.elf – 224 MB for Linux and the rest (32 MB) for the GPU. To be used for application where the GPU is not used (for graphics tasks) such as a headless server. The GPU still needs some memory has it performs some other tasks internally.