Workshop on the Altera SoC FPGA platform

On June 25, 2013, Altera and some partner companies where organizing a workshop in Toulouse (where some of the Bootlin offices are located) about the Altera SoC FPGA platform. For $99, I participated to this full-day workshop, with a small training of the hardware and software tools available for this platform, and went away with a the development kit that was used for the practical labs, the Arrow SoCKit evaluation board.

sockit-1

The Altera SoC FPGA platform is a single chip that combines a dual Cortex-A9 processor and a Cyclone V FPGA (other variants are available, such as single core ARM, or bigger FPGAs). Since both are integrated on the same chip, it removes the need for a complex bus between the application processor and a separate FPGA, and it provides a very high bandwidth between the processor and the FPGA to exchange data. As can be seen on the following diagram, the Arrow SocKit evaluation board has a good number of peripherals, some of them connected to the HPS side of the processor (HPS stands for Hard Processor System, which is dual Cortex-A9 and all the hard peripherals), and some others connected to the FPGA side of the processor. Specifically, the workshop was centered around playing with the LEDs and the buttons connected to the FPGA side.

Block diagram of the SoCKit evaluation board
Block diagram of the SoCKit evaluation board

The morning of the workshop was dedicated to the hardware part, using two tools: Qsys (Altera’s System Integration Tool) and Quartus II (FPGA design). The Qsys tool allows to graphically build the hardware architecture of the SoC FPGA: you can bring the Hard Processor System, and then some additional FPGA IPs and connect them together. In the examples, two PIO IPs were added to the FPGA side, one to control LEDs and the other to control buttons. All the pin muxing and the DRAM configuration also takes place in Qsys, which in the end will automatically generate numerous elements:

  • FPGA code to be used by Quartus (for the FPGA side)
  • pre-loader source code (actually modifications to U-Boot to take into account the pin muxing and the DRAM configuration)
  • a Device Tree for the Linux kernel (that takes into account all the peripherals enabled in the system configuration)
  • etc.
Qsys allows to design the overall architecture of the SoC FPGA components, including all the FPGA IPs. On this picture, we see the two PIO IPs used to control LEDs and buttons.
Qsys also to design the overall architecture of the SoC FPGA components, including all the FPGA IPs. On this picture, we see the two PIO IPs used to control LEDs and buttons.

Once this system-level configuration is done with Qsys, Quartus is used to synthesize the FPGA side. Finally, the FPGA bitstream can be loaded into the FPGA, and using a JTAG connection and a System Console tool, one can directly read/write the registers of the FPGA IPs that have been integrated, and easily test them without having any software running. With the SOCKit evaluation board, the JTAG connection takes place through a USB to micro-USB cable, so no special hardware is needed.

The afternoon of the workshop was dedicated to the software part, obviously mostly centered on U-Boot and Linux. The pre-loader source code (actually the U-Boot SPL) is generated by the Qsys tool to take into account all the details of the system configuration, so after doing a build of U-Boot, the labs explained how to push the U-Boot binary to the board using the JTAG connection, under the DS-5 development environment (which is the development environment provided by ARM, based on Eclipse, with a special integration of Altera tools). The lab showed that you can set breakpoints, and do step by step execution of U-Boot, as one would expect. One nice thing is that the “Peripheral Registers” view in DS-5 is automatically updated according to the hardware components in the system: all the registers of the FPGA IPs we had integrated were immediately visible, and one was able to play with the LEDs and buttons directly from DS-5 through the JTAG connection. The remainder of the labs were dedicated to booting a pre-built Linux kernel, using a Device Tree generated by Qsys previously and loaded by U-Boot. Once Linux was booted, the labs were demonstrating how to play with the LEDs using /sys/class/leds/.

Registers of FPGA IPs are automatically visible in DS5
Registers of FPGA IPs are automatically visible in DS5

All in all, it was a great workshop, giving a good overview of the tools they offer and the capabilities of such platforms, I definitely recommend others to look for the other dates of this workshop and attend, it was well worth the price (dates in US, dates in Europe). I also appreciated that the amount of marketing/commercial was really reduced to the minimum. After the lunch break, there was an additional presentation by a person from Linear Technology about the power supply architecture of two boards based on this SoC FPGA processor, and it was very technical and highly informative.

As an embedded Linux developer, I’ve however found the tools to be too much based on graphical interfaces, with millions of windows and buttons to fill in, and a sensation of not really controlling which tool was doing what exactly. For example, it is a bit unclear at first which files are really your “source” files and which other files are generated. Having graphical interfaces also makes me wonder how all the build steps can be automated. It seems like version control and automated builds are not necessarily taken into account when designing those tools, but more investigation is certainly needed to get a good understanding of what those tools are doing.

On the Linux kernel side, it is worth noting that Altera has engaged into an upstreaming process for this architecture, and one can find some mainline support for this platform in arch/arm/mach-socfpga in the kernel tree. It is worth mentioning that Xilinx also has a similar architecture combining a dual Cortex-A9 and FPGA, called Zynq, which has mainline kernel support in arch/arm/mach-zynq.

And below, the front and bottom of the SoC Kit evaluation board:

SoC Kit evaluation board back side

SoC Kit evaluation board front side

GSoC: Buildroot gaining improved ARM multimedia support

Google Summer of Code 2013 logo

The Buildroot project is participating for the first time to the famous Google Summer of Code. This program, operated by Google, allows open-source projects to have students working on specific tasks for the summer, and the students get paid for their work, get mentored by open-source developers, learn about software development, open-source communities and more.

For its first participation to the GSoC, the Buildroot community has chosen one project: improving support for multimedia features of popular ARM SoCs. This consists in packaging in Buildroot all the necessary libraries and software components to support OpenGL, OpenVG, EGL, OpenMAX and similar technologies for the major ARM processors. The selected student for this project is Spenser Gilliland and Bootlin engineer Thomas Petazzoni is mentoring Spenser for this project.

The focus of the project is to add support for the multimedia features of the OMAP3, OMAP4 and AM33xx processors from Texas Instruments, the Broadcom processor found on the RasberryPi, the i.MX6 processor from Freescale, the Exynos 4 from Samsung and the Allwinner A1x processors. Throughout the next three months, support for the multimedia capabilities of those processors in Buildroot should become easier to use.

Spenser has already contributed support for GStreamer 1.x in Buildroot (which required upgrading the entire GLib/Gtk/Webkit stack) and OpenMAX support for the RasberryPi, and he is currently working on OpenGL support for the OMAP3/OMAP4/AM33xx platforms. The initial part of Spenser’s work will be in the next 2013.08 Buildroot release, while the remainder will have to wait the 2013.11 release.

For more details about the project, see its description on the eLinux.org wiki, and you can also keep track of Spenser’s progress.

Buildroot 2013.05 released, Bootlin contributions inside!

Buildroot logoAs planned by the release schedule, the Buildroot 2013.05 version landed at the end of May. Peter Korsgaard, the project’s maintainer, highlighted the most important additions in his release email. With more than 900 commits, it has been the busiest ever development cycle, showing that the Buildroot project is more and more active.

With 175 commits in this release, Bootlin has again participated significantly to the development of Buildroot:

   217  Gustavo Zacarias
   167  Thomas Petazzoni (Bootlin)
   109  Will Wagner
    86  Peter Korsgaard
    44  Simon Dawson
    27  Yann E. MORIN
    25  gilles.talis@gmail.com
[...]
     6  Maxime Ripard (Bootlin)
[...]
     1  Alexandre Belloni (Bootlin)
     1  Ezequiel Garcia (Bootlin)
[...]

Amongst the features and improvements contributed by Bootlin:

  • Support for the next generation Wayland display server has been added. For now, only Wayland over the framebuffer is supported, but additional improvements are expected to come in the future.
  • Integration of packages to build all the Qt5 components: qt5base, qt5declarative, qt5graphicaleffects, qt5imageformats, qt5jsbackends, qt5multimedia, qt5quick1, qt5script, qt5svg, qt5webkit and qt5xmlpatterns.
  • A mechanism of virtual packages to expose the OpenGL, OpenVG and EGL implementations has been put in place, with for now the RasberryPi providing such implementations. Those virtual packages are for example used in the Qt5 packages mentionned above, for those that require OpenGL.
  • A cleanup of Buildroot core dependencies: flex and bison are no longer mandatory to use Buildroot, they are automatically built when needed. This apparently simple move required a number of fixes and updated to a significant number of packages.
  • Many external toolchains were updated, especially the Linaro toolchains.
  • The build process of gdb was converted to the package infrastructure, instead of being a hand-written Makefile. This is part of an effort to progressively convert the toolchain building process to the package infrastructure.
  • A default configuration was added for the Atmel AT91SAM9G45M10-EK evaluation board, which allows Buildroot users to easily build a minimal working system for this platform.
  • A number of build issues were fixed by Maxime Ripard, thanks to the daily automated builds done by the Bootlin Jenkins system that Maxime has set up.
  • A huge number of build issues trigerred by the autobuilders have also been fixed thanks to Bootlin engineers contributions.

In addition to this, Thomas Petazzoni has done some major improvements to the automated build system that the Buildroot project uses, which he detailed in an e-mail sent to the project mailing list. These improvements make the autobuilder infrastructure more scalable, and allows to provide statistics, and a much better daily report sent to the project’s mailing list.

In detail, the contributions of Bootlin were:

Bootlin contributions to the 3.9 kernel

A few months ago, we published a blog post showing our contributions to the 3.8 Linux kernel. With 128 commits merged in 3.8, Bootlin was ranked as the 17th company in terms of kernel contributions.

The 3.9 kernel has been released a few weeks ago, with again a significant number of contributions from Bootlin. According to these statistics, Bootlin contributed 92 patches during the 3.9 cycle, making the company the 26th most important contributor to the Linux kernel for this release, and this time, five engineers from Bootlin contributed patches.

Among the contributions that we made:

  • Added a basic infrastructure for irqchip drivers in the drivers/irqchip directory. This directory is now used to store the drivers for the IRQ controllers of various processors.
  • Made a number of improvements to the Marvell SDIO driver, including the addition of a Device Tree binding for it, and enabled its usage on Marvell Armada 370 and Armada XP platforms, as well as converting the Marvell Kirkwood platforms to use Device Tree probing instead of legacy probing for their SDIO interface.
  • Contributed a number of improvements to support Crystalfontz i.MX28 based modules, including the Device Tree for the CFA10037 expansion board, various improvements for the CFA10049 expansion boards, and a driver for the Himax HX8357B LCD controller.
  • A large number of improvements to the support of the Allwinner ARM SoCs, most notably a pinctrl driver for those SoCs, which allows to configure the muxing of I/O pins, and a gpio driver, to use the pins as general-purpose I/Os. We also contributed the support for the Miniand Hackberry platform, based on an Allwinner SoC. This work is all done by our engineer Maxime Ripard, who is the maintainer of the Allwinner SoC support in the Linux kernel.
  • Improvements to the PCA953x driver (for I2C GPIO expanders) in order to support the PCA9505 chip, that has 40 GPIOs. This required quite some work, as the PCA953x was originally limited to chips having at most 32 GPIOs. This improvement was done in order to support the GPIO expander box provided by Globalscale for the Armada 370-based Mirabox platform.
  • We added support for the Real Time Clock on Armada 370 and Armada XP based platforms, added support for local timers on Armada XP, added support for the new Armada XP GP evaluation board.
  • We enabled support for the SPI controllers and the USB controllers on Armada 370 and Armada XP based platforms.

Our high rate of contributions is going to continue, as we already have 95 patches merged for the upcoming 3.10 kernel and have already submitted a number of patches for the 3.11 kernel.

Here are details about our contributions to the 3.9 kernel:

FIQ Handlers in the ARM Linux Kernel

Part of the work on the CFA-10036 and its breakout boards was to write a driver that was using the FIQ mechanism provided by the ARM architecture to bitbang GPIOs on the first GPIO bank of the iMX28 port controller.

Abstract

FIQ stands for Fast Interrupt reQuest, and it is basically a higher priority interrupt. This means that it will always have precedence over regular interrupts, but also that regular interrupts won’t mask or interrupt an FIQ, while an FIQ will mask or interrupt any IRQ.

FIQs are usually not used by the Linux Kernel, yet some infrastructure is available to do everything you need to be able to use the FIQs in a driver. And since Linux only cares about the IRQs, it will never mess with the FIQs, allowing to achieve some hard real time constraints, without having to bother about the masked interrupts.

There are two more things to know about the FIQs. First, FIQs are executed in a dedicated execution mode, and this FIQ mode has 7 dedicated registers, from r8 to r14. This allows to have persistent values between each FIQ handler code, and avoids the overhead of pushing and popping in the handler. The second thing to know is that, unlike the regular IRQ handlers, the FIQ handler has to be written using ARM assembly, mostly because the C compiler won’t produce any code that can use only these r8 to r14 registers.

Practical case

In the CFA-10036 case, we wanted to bitbang a set of GPIOs at a programmable interval with a microsecond accuracy, and from a userspace application. The setup we chose was to make a large memory buffer of instructions available to userspace through mmap, and use a simple consumer/producer setup. An instruction was basically the interval to the next handler firing, which GPIOs values to clear, and which ones to set.

Step 1: Setup a timer

One thing to keep in mind is that basically, we will do many things behind the kernel’s back. So you won’t be able to use the standard kernel framework APIs from the FIQ handler. That means that we won’t be able to use the gpiolib, the regular timer API, etc. So you have to make sure to use either something that is not used at all by the kernel or something the kernel can deal with. The first thing to do then is to register a timer so that we can generate our FIQ on a regular basis. Here, we chose the third iMX28 timer, that is the first timer not used by the kernel. Of course, since it is device dependent and not using the kernel’s API, we had to do the timer initialization by hand in our driver.

We obviously made it generate an interrupt when it expires, and then had to poke into the iMX28 interrupt controller to generate a FIQ from this interrupt. How to achieve this is once again dependent on the hardware, and some architectures provide functions to do so (s3c24xx_set_fiq for Samsung’s Exynos, mxc_set_irq_fiq for Freescale’s IMX, etc.) while some others don’t, like it was the case for iMX28 (which is part of the MXS architecture), so we had to do it by hand once again in our driver.

Once this is done, we now have a timer that generates an FIQ on a regular basis. The second step will obviously be to register our handler for this FIQ.

Step 2: Register our handler

Registering an FIQ handler is actually quite simple. The first thing to do is actually to call the claim_fiq function, that mostly makes sure no other FIQ handler has already been registered.

The next step is to register your FIQ handler. This is done with the set_fiq_handler function. This  function takes a pointer to the handler and the size of the handler code as argument, to basically memcpy your handler directly into the interrupt vector.

Most of the time, we would have something like below in our assembly code, and compute the handler size by the difference between the two labels.

my_handler:
handler code
my_handler_end:

Beware that it can get nasty, especially when you use a numeric constant that will get stored in a literal pool (for example when storing large variables into a register using LDR), if you  don’t pay attention, the literal pool will be stored outside of the bounds you asked to copy, resulting in the value you use in the actual FIQ handler being garbage. We can also pre-set some register values that you will find in FIQ mode, typically to pass arguments to your handler, using the set_fiq_regs function.

The last step is obviously to enable the FIQ, using the enable_fiq function.

Once this is done, we have the basic infrastructure to process the data that will come from the shared buffer.

Step 3: Allocate the instruction buffer and share it

We needed a pretty large instruction buffer to share with userspace. We wanted to store about 1 million instructions in the buffer, each instruction taking 12 bytes (3 unsigned long integers), which makes around 12 MiB.

The usual allocation mechanism couldn’t be used, because __get_free_pages can only allocate up to 512 pages. Each page on ARM being of 4 KiB, this function is thus limited to 2 MiB.

So we chose to use CMA (Contiguous Memory Allocator) that was introduced in the 3.4 kernel, and is used precisely to allocate large chunk of contiguous memory. It achieves this by allocating a given size of movable pages at boot time, that will be used by the kernel as long as no one needs them, and will be reclaimed when a driver needs them. CMA is also used directly through the regular DMA API, so we’re in known territory.

The first thing to do to use CMA is to declare the memory region we want to reserve for our device in the device tree (we have been using the “Device tree support for CMA” patchset).

As you may know, the device tree is for hardware description and the CMA shouldn’t be in it at all, since it doesn’t describe the hardware in itself, but how we need to allocate the memory for a given piece of hardware. The chosen node is here exactly for that, since it will hold all the things the system needs, but doesn’t describe hardware. A similar case is the kernel command line. In our case, we add a subnode to chosen, with which amount of memory we should pre-allocate (0xc00000, which is 12 MiB, in our case), at which kernel address (0 in our case, since we basically don’t care about the base address of the buffer, we just want it to be there), and which device should use it.

Then, in our driver, we only need to call dma_alloc_coherent from our driver, and that’s it.

Now, we need to share this memory through mmap. This wouldn’t be a big deal, except for the caches. Indeed, the ARMv5 caches are virtually tagged, resulting in cache coherency problem when using two different virtual addresses pointing to the same physical address, which is exactly the situation we will be in.

We thus need to disable the cache on this particular mapping. This is done through a flag set with the pgprot_noncached function, that sets the page protection flags before calling the remap_pfn_range function in the mmap driver hook.

This should be ok by now, and you should be able to use the data inside the buffer from both sides now.

Step 4: Actual Results

We here tried to generate a 50kHz square waveform by bitbanging the GPIOs both using a FIQ and using a regular IRQs, and here is the result (to emulate some load on the system, a dd if=/dev/zero of=/file was run when the captures were taken).

interrupt

This is using regular IRQs. We can notice several thing wrong about this. The first one is pretty obvious, since we have a lot of jitter. The next one is that even though we requested a interval between each timer firing of 10microseconds, we here see that we are more around 16us, with quite a lot of latency.

Now, here is what we get with an FIQ:

fiq

We can see that there’s no longer any jitter, the 50kHz square waveform we requested is almost perfectly output by our FIQ handler. We can notice however that there is still a constant ~1us latency, presumably because we had to reprogram the timer from our handler.

Final Words

Working on this FIQ thing has been really great, mostly because it involved several things I wasn’t used to, like CMA, or to make sure the kernel could deal with something changing behind its back. For example, we had to change slightly the imx28 gpio driver, because it was keeping an internal cache of the GPIO values it previously set, resulting in a pretty nasty behaviour when changing a GPIO value from the FIQ, and then controlling another one through the regular GPIO interface.

The application for this was to generate waveforms sent to stepper drivers, to control a 3D printer from the CFA-10036. You can watch the end result of all this work on Crystalfontz‘ Youtube channel, and especially on this video:

Finally, we can conclude that the FIQ can be an effective way to achieve near-real-time latencies, on a vanilla kernel without any RT patches.

Of course, you can find the whole code on Crystalfontz Github, most notably the driver, the handler and a small application demo for it.

Sysadmin notes: post-only mailing lists with GNU Mailman

Need for notification mailing lists

I found several people looking for a way to implement post-only mailing lists with GNU Mailman. However, I couldn’t find solutions that are described in sufficient detail.

In particular, this type of list is useful for notification mailing lists. In Bootlin’scase, whenever someone pushes commits to our public git trees, a notification e-mail is sent. Sometimes, internal discussions can follow, but we do not wish to make them public. This is why we do not want the list e-mail address to be shown in the messages that are sent. If the list address doesn’t appear in the To, CC or in Reply-To headers, members who are authorized to post messages without moderation won’t post replies to the list by mistake by using the “Reply to all” functionality of their e-mail client.

The problem is that the current version of GNU Mailman doesn’t support this type of list yet, at least with the parameters in the list administration interface. You can turn on the “Full personalization” option, which will send messages to each member individually, so that the list address doesn’t appear in the To header. You can also customize the Reply-To header, to an address that is different from the list address. However, the CC header will still hard-code the list address.

A possibility is to hack the /usr/lib/mailman/Mailman/Handlers/CookHeaders.py file, but this solution would apply to all the lists at once, and the changes you could make may interfere with Mailman updates. A much nice solution is to extend Mailman, to modify its behavior for specific mailing lists.

A working solution

This solution is based on explanations given on the Mailman wiki, and was implemented on Ubuntu 12.04.

First, create a list-test mailing list. Some of the commands below will assume that you named your new list this way. Now, go to its administration interface and enable “Full Personalization” in “Non-digest” options. In “General options”, in the “Reply-To: header munging” section, specify a reply-to address.

If you send a test message to your new list, you will see that the list address is still in the CC header of the message that you receive.

Now, create a RemoveCC.py file in the Handlers directory (/usr/lib/mailman/Mailman/Handlers/RemoveCC.py on Ubuntu 12.04):

# Your comments here

"""Remove CC header in post-only mailing lists

This is to avoid unmoderated members to reply to messages,
making their replies public. Replies should instead go to a private list.
"""

def process(mlist, msg, msgdata):
    del msg['Cc']

This will be yet another filter the list messages will go through. Now compile this file in the directory where you put it:

pycompile RemoveCC.py

The next thing to do is to modify the default filter pipeline for your new list. You can do it by creating a /var/lib/mailman/lists/list-test/extend.py file with the below contents:

import copy
from Mailman import mm_cfg
def extend(mlist):
    mlist.pipeline = copy.copy(mm_cfg.GLOBAL_PIPELINE)
    # The next line inserts MyHandler after CookHeaders.
    mlist.pipeline.insert(mlist.pipeline.index('CookHeaders') + 1, 'RemoveCC')

This will add your new filter right after the CookHeaders one. To enable this, you have to run:

/usr/sbin/config_list -i /var/lib/mailman/lists/list-test/extend.py list-test

You can now send a new test message, and you will see that the CC header is now gone.

Notes

  • Of course, you can reuse the same extend.py file for multiple mailing lists. However, the solution doesn’t work if you don’t put the file inside /var/lib/mailman/lists/list-name (distributions other than Ubuntu 12.04 may have different paths).
  • I didn’t manage to undo this change. The Mailman wiki gives a solution based on creating a file containing del mlist.pipeline and running /usr/sbin/config_list -i this-file list-name, but it didn’t work for me. Please post a comment below if you find a way to implement this, and return to “factory” settings.
  • Don’t hesitate to share other ways of implementing this kind of functionality!

Linux kernel 3.8 released, Bootlin top #17 contributor

Thomas Petazzoni and Grégory Clement, Bootlin kernel engineers
Thomas Petazzoni (front) and Grégory Clement (back) at the Embedded Linux Conference 2013 in San Francisco, discussing ARM Linux kernel issues.
Early last week, version 3.8 of the Linux kernel has been released by Linus Torvalds. The KernelNewbies web site, has, as usual, a great summary of what’s new in this release, together with lots of links to the relevant LWN articles. With 12394 commits, 3.8 has been the busiest ever kernel release cycle, the previous record being held by 2.6.25 with 12243 commits.

Despite this huge activity, Bootlin has been the 17th most active employer during the 3.8 cycle, with 128 commits merged into the mainline Linux kernel, representing a bit more than 1% of the total number of commits. See the statistics by employer at http://www.remword.com/kps_result/3.8_whole.html and in the traditional LWN article. This puts Bootlin before Nvidia, Qualcomm, ARM or Oracle in number of commits, and just a few commits behind Freescale. See the Git repository for the list of our contributions.

In detail, Bootlin contributions for 3.8 have been:

  • A large number of contributions related to the support of the Marvell Armada 370 and Armada XP SoCs, done by Grégory Clement and Thomas Petazzoni. Contributions included: a new network driver for the Armada 370 and Armada XP, support for the Armada XP-based OpenBlocks AX3 platform, support for the Armada 370-based Globalscale Mirabox platform, a big number of improvements and Device Tree support for the Marvell XOR engine driver, beginning of Device Tree support for the older Marvell Orion5x SoC family, support for the L2 cache found in Armada 370/XP, clock drivers for Armada 370/XP, SMP support for Armada XP, enabling of SATA on Armada 370/XP platforms.
  • The contribution of the initial support for a new SoC family in the mainline Linux kernel: the Allwinner A10 and Allwinner A13 ARM SoCs. This support has been contributed by Maxime Ripard, who has become the maintainer for this new ARM sub-architecture.
  • A driver for the I2C-based SSD1304 OLED display, a nice 128×32 pixels monochrome OLED display, contributed by Maxime Ripard.
  • A number of improvements in the support for the Crystalfontz i.MX28-based platforms, the CFA10036 and its expansion board the CFA10049. These contributions have also been made by Maxime Ripard.

Through these contributions, Bootlin have gained a good expertise in support for ARM SoCs and boards inside the Linux kernel. If you are interested in having us help you bring the support of your ARM board or ARM SoC into the mainline Linux kernel, do not hesitate to contact us, you will be directly answered by our engineers doing Linux kernel development!

Android seminar slides

Android robotWe have delivered two seminars about Android during the last quarter of 2012. The seminars were held in Belfort and Grenoble, France, and were organized by Captronic, a French public program to support innovation in electronic systems.

This one day seminar targets people who wish to understand the constraints and implications of using Android in embedded products, and know the steps to follow. The seminar is led by Maxime Ripard, Bootlin’sAndroid expert. Maxime is also the creator of Bootlin’sAndroid system development course.

Agenda

Morning

  • General introduction to Android
  • Opportunities to use Android in embedded systems which are neither phones nor tablets
  • Details on Android’s architecture and how to customize it:
    • Source code and compiling
    • Android changes to the Linux kernel
    • Bootloaders for Android
    • Supporting new hardware
    • Android filesystem layout
    • Android native layers and calling a C program to access specific hardware
    • Introduction to application development
    • Customizing the system
    • Using adb (Android Debug Bridge) for debugging and device remote access
    • Advice and resources

Afternoon

  • Completing the morning presentations (if necessary)
  • Demonstrating multiple aspects of system development with Android:
    • Getting sources and compiling
    • Android emulator demonstration
    • Starting Android on an electronic board with an ARM OMAP3530 processor, using a serial console.
    • Adding support for specific buttons. “Back” button example.
    • Using adb: installing, accessing system logs, accessing a command line interface on the device, exchanging files with the PC.
    • Customizing the system: change the product name, the default wallpaper, add new properties.
    • To access specific hardware (such as a USB device), development of a native library and accessing this functionality from the Android framework through a specific class and JNI library.
    • Describing an application that allows to control a USB device.
    • Questions and answers

Presentation slides

Note: see updates to these materials.

Creative commonsPresentation slides are available in PDF and LaTeX source formats. As usual, they are released under the terms of the Creative Commons Attribution – ShareAlike 3.0 license. This means that you can reuse and modify them according to your own needs.

If you are interested in having one of us run such a seminar on your own part of the world, giving the audience the opportunity to ask all the questions they can have on the use of Android in embedded systems, don’t hesitate to contact us.

Videos of the Embedded Linux Conference Europe 2012

With the approaching Embedded Linux Conference, to be held February 20-22 in San Francisco, we felt that it was time to finally fight with ffmpeg/libav and get the videos we had taken from the last Embedded Linux Conference Europe talks, encode them and publish them online. So here they are, as what we could consider a late Christmas gift.

There are so many talks that it might be hard to watch everything. So I’d like to share with you my preferred talks from this last ELCE (of course, I haven’t been able to see all talks, but only a third of them, so the following selection is only taken from the talks I have seen) :

  • For sure, the talk I have preferred is the Understanding PREEMPT_RT (The Real-Time Patch) talk from Steven Rostedt (Redhat). In an hour, Steven explained some very interesting internals of PREEMPT_RT, in a very clear way. Definitely a must see, in my opinion.
  • I also enjoyed the ARC Linux: From a Tumbling Toddler to a Graduating Teen talk from Vineet Gupta (Synopsys). While talking about a specific new CPU architecture that probably most of us have never used, Vineet is able to tell a very nice story by bringing you through various issues they had while porting Linux on this new CPU architecture, giving interesting and funny technical details in the process.
  • The talk about Regmap: The Power of Subsystems and Abstractions from Mark Brown (Wolfson Microelectronics) was also very good, in that it clearly explained the need for this new kernel subsystem, how the API works, etc. Definitely the kind of talk I’d like to see about more kernel subsystems: in an hour, you learn the philosophy of the subsystem, why it’s there, how it has been designed to solve the original problems, and the basics of its APIs. It’s often what’s missing from an API documentation: the philosophy behind it. Hour long talks that are capable of conveying this philosophy are therefore highly useful.
  • As usual, David Anders talk, this time about Board bringup: you, me and I2C has been very nice as well. It is a good introduction about electronics related to I2C, it doesn’t go very far for anyone having an existing experience of I2C, but is indeed a very good introduction for those who don’t. I really enjoyed the good explanation about pull-up resistors.
  • Finally, another talk that was great is Samuel Ortiz (Intel) talk about Near Field Communication with Linux. A bit like the Regmap talk, the great benefit of Samuel talk is that in an hour, he went through the different hardware available for NFC in Linux, the architecture of the software stack, the different software components that exist, their strenghts and weaknesses and so on. So without any prior knowledge about NFC, you get at the end of the talk a very good coverage of how this technology is supported by Linux today.

Well, enough with my suggestions, here is the complete list of videos:

Matt RanostayVideo capture
Beaglebone: The Perfect Telemetry Platform?
Slides
Video (24 minutes):
full HD (153M), 800×450 (74M)

Jim HuangVideo capture
0xlab
Implement Checkpointing for Android
Slides
Video (43 minutes):
full HD (291M), 800×450 (168M)

Wolfram SangVideo capture
Pengutronix e.K.
Maintainer’s Diary: Devicetree and Its Stumbling Blocks
Slides
Video (49 minutes):
full HD (329M), 800×450 (160M)

Matthias BruggerVideo capture
ISEE 2007 S.L.
A War Story: Porting Android 4.0 to a Custom Board
Slides
Video (34 minutes):
full HD (230M), 800×450 (106M)

Kishon Vijay AbrahamVideo capture
Texas Instruments
USB Debugging and Profiling Techniques
Slides
Video (40 minutes):
full HD (245M), 800×450 (109M)

Alan OttVideo capture
Signal 11 Software
Wireless Networking with IEEE 802.15.4 and 6LoWPAN
Slides
Video (52 minutes):
full HD (339M), 800×450 (156M)

João Paulo Rechi VitaVideo capture
INdT
Bluetooth Smart devices and Low Energy support on Linux
Slides
Video (36 minutes):
full HD (250M), 800×450 (116M)

Peter StugeVideo capture
OpenOCD: Hardware Debugging and More
Video (47 minutes):
full HD (316M), 800×450 (155M)

Alessandro RubiniVideo capture
PF_ZIO: Using Network Frames to Convey I/O Data and Meta-Data
Slides
Video (48 minutes):
full HD (317M), 800×450 (141M)

Joo-Young HwangVideo capture
Samsung
A New File System Designed for Flash Storage in Mobile
Slides
Video (54 minutes):
full HD (369M), 800×450 (152M)

Alexandre BelloniVideo capture
Adeneo Embedded
Boot Time Optimizations
Slides
Video (39 minutes):
full HD (261M), 800×450 (129M)

Philipp ZabelVideo capture
Pengutronix e.K.
Modular Graphics on Embedded ARM
Slides
Video (32 minutes):
full HD (217M), 800×450 (100M)

Karim YaghmourVideo capture
Opersys
Inside Android’s User Interface
Slides
Video (42 minutes):
full HD (284M), 800×450 (117M)

Samuel OrtizVideo capture
Intel
Near Field Communication with Linux
Slides
Video (35 minutes):
full HD (232M), 800×450 (92M)

Arnout VandecappelleVideo capture
Essensium/Mind
Upgrading Without Bricking
Slides
Video (56 minutes):
full HD (373M), 800×450 (172M)

Tim BirdVideo capture
Sony Network Entertainment
BoFs: Developer Tools and Methods: Tips & Tricks
Slides
Video (62 minutes):
full HD (395M), 800×450 (160M)

Matt LockeVideo capture
Texas Instruments
Are We Headed for a Complexity Apocalypse in Embedded SoCs?
Video (27 minutes):
full HD (167M), 800×450 (76M)

Sascha HauerVideo capture
Pengutronix e.K.
Barebox Bootloader
Slides
Video (47 minutes):
full HD (313M), 800×450 (134M)

Benjamin ZoresVideo capture
Alcatel-Lucent
Dive Into Android Networking: Adding Ethernet Connectivity
Slides
Video (46 minutes):
full HD (270M), 800×450 (118M)

Jiyoun ParkVideo capture
Samsung
Experiences as an OEM with Development of UI Frameworks
Video (42 minutes):
full HD (282M), 800×450 (158M)

Keshava MunegowdaVideo capture
Texas Instruments
FFSB and IOzone: File system Benchmarking Tools, Features and Internals
Slides
Video (56 minutes):
full HD (367M), 800×450 (171M)

Chris SimmondsVideo capture
2net Limited
The End of Embedded Linux (As We Know It)
Slides
Video (47 minutes):
full HD (324M), 800×450 (150M)

Steven RostedtVideo capture
Red Hat
Understanding PREEMPT_RT (The Real-Time Patch)
Slides
Video (61 minutes):
full HD (412M), 800×450 (186M)

Klaas van GendVideo capture
Vector Fabrics
Application Parallelization for Multi-Core Android Devices
Slides
Video (44 minutes):
full HD (293M), 800×450 (124M)

David AndersVideo capture
Texas Instruments
Board Bringup: You, Me, and I2C
Slides
Video (38 minutes):
full HD (217M), 800×450 (97M)

Rama PallalaVideo capture
Intel
Linux Power Supply Charging Subsystem
Video (35 minutes):
full HD (213M), 800×450 (83M)

Agusti FontquerniVideo capture
ISEE 2007 S.L.
Embedded Linux RADAR Device
Slides
Video (50 minutes):
full HD (331M), 800×450 (140M)

Matt PorterVideo capture
Texas Instruments
What’s Old Is New: A 6502-based Remote Processor
Slides
Video (58 minutes):
full HD (389M), 800×450 (181M)

Thomas PetazzoniVideo capture
Bootlin
Your New ARM SoC Linux Support Check-List
Slides
Video (56 minutes):
full HD (362M), 800×450 (150M)

Tracey M. Erway and Nithya A. RuffVideo capture
Intel and Synopsys
Can You Market an Open Source Project?
Slides
Video (43 minutes):
full HD (272M), 800×450 (103M)

Lars KnollVideo capture
Qt Project
Qt on Embedded Systems
Video (50 minutes):
full HD (337M), 800×450 (175M)

Koen KooiVideo capture
Circuitco
Supporting 200 Different Expansionboards: The Broken Promise of Devicetree
Slides
Video (37 minutes):
full HD (232M), 800×450 (102M)

Anna DushistovaVideo capture
Eclipse and Embedded Linux Developers: What it Can and Cannot Do For You
Slides
Video (58 minutes):
full HD (378M), 800×450 (167M)

Dave StewartVideo capture
Intel
Yocto Project Overview and Update
Video (52 minutes):
full HD (338M), 800×450 (139M)

Vineet GuptaVideo capture
Synopsys
ARC Linux: From a Tumbling Toddler to a Graduating Teen
Slides
Video (44 minutes):
full HD (269M), 800×450 (113M)

Laurent PinchartVideo capture
Ideas on Board
DRM/KMS, FB and V4L2: How to Select a Graphics and Video API
Slides
Video (48 minutes):
full HD (328M), 800×450 (145M)

Frank RowandVideo capture
Sony Network Entertainment
Practical Data Visualization
Slides
Video (46 minutes):
full HD (308M), 800×450 (141M)

Marcin JuszkiewiczVideo capture
Linaro
ARM 64-Bit Bootstrapping with OpenEmbedded
Slides
Video (32 minutes):
full HD (208M), 800×450 (88M)

Wim DecroixVideo capture
TPVision
Practical Experiences With Software Crash Analysis in TV
Slides
Video (35 minutes):
full HD (224M), 800×450 (87M)

Mark BrownVideo capture
Wolfson Microelectronics
Regmap: The Power of Subsystems and Abstractions
Video (44 minutes):
full HD (282M), 800×450 (124M)

Hans VerkuilVideo capture
Cisco Systems
Video4Linux: Current Status and Future Work
Slides
Video (33 minutes):
full HD (217M), 800×450 (100M)

Holger BehrensVideo capture
Wind River
Yocto Layer for In-Vehicle Infotainment
Slides
Video (43 minutes):
full HD (284M), 800×450 (123M)

Tero KristoVideo capture
Texas Instruments
Debugging Embedded Linux (Kernel) Power Management
Slides
Video (36 minutes):
full HD (241M), 800×450 (108M)

Martin BisVideo capture
BIS
Real-Time Linux in Industrial Appliances
Slides
Video (48 minutes):
full HD (323M), 800×450 (145M)

Jens GeorgVideo capture
Openismus GmbH
Rygel: Open Source DLNA, ready for Customer Products?
Slides
Video (33 minutes):
full HD (215M), 800×450 (88M)

Yoshitake KobayashiVideo capture
Toshiba
Improvement of Scheduling Granularity for Deadline Scheduler
Slides
Video (31 minutes):
full HD (195M), 800×450 (82M)

Tsugikazu ShibataVideo capture
NEC
LTSI (Long-Term Stable Initiative) Status Update
Slides
Video (44 minutes):
full HD (278M), 800×450 (111M)

Thomas GleixnerVideo capture
Linutronix
UBI Fastmap
Slides
Video (45 minutes):
full HD (299M), 800×450 (121M)

Videos of the Embedded track at FOSDEM 2012

Better late than never: we finally found the time to update our video encoding scripts, and therefore encode and upload the videos we had taken of the embedded track at FOSDEM 2012. Amongst many other interesting talks, you’ll notice two talks given by Bootlin engineers: one by Maxime Ripard on the IIO subsystem, a kernel subsystem for Industrial I/O devices, and another by Thomas Petazzoni about the usage of the Qt framework for non-graphical applications in embedded Linux systems.

Cédric BailVideo capture
EFL the upcoming embedded UI toolkit
Slides
Video (51 minutes):
full HD (337M), 800×450 (138M)

Julius Baxter, Olof KindgrenVideo capture
OpenCores.org
The OpenRisc Project
Slides
Video (28 minutes):
full HD (184M), 800×450 (74M)

Jeremy BennettVideo capture
Embecosm
Open Source Software Meets Open Source Hardware, OpenCores and the OpenRisc 1000
Video (28 minutes):
full HD (165M), 800×450 (71M)

Vasilis GeorgitzikisVideo capture
PMH: Home Automation made right
Slides
Video (27 minutes):
full HD (187M), 800×450 (81M)

Thomas PetazzoniVideo capture
Bootlin
Using Qt for non-graphical applications
Slides
Video (47 minutes):
full HD (307M), 800×450 (129M)

Jean PihetVideo capture
Texas Instruments
Linux (SoC) power management
Slides
Video (39 minutes):
full HD (268M), 800×450 (117M)

Maxime RipardVideo capture
Bootlin
IIO, a new subsystem for I/O devices
Slides
Video (35 minutes):
full HD (211M), 800×450 (97M)

Arnoult VandecappelleVideo capture
Mind
Safe upgrade of embedded systems
Slides
Video (47 minutes):
full HD (320M), 800×450 (138M)