Sascha Hauer, kernel developer at Pengutronix, gives an update about the status of Barebox bootloader at the Embedded Linux Conference 2012 in Barcelona, Spain.
Booting Linux is still a hot topic on embedded systems. It has been 3 years since the last presentation about Barebox at ELC-E, and the barebox community has grown and developed many new and unique features during that time. The talk gives an update on the status of barebox, including MMU support, compressed images, menu system, automouter, tftp, nfs filesystem, USB updating techniques and other goodies.
The presentation is for kernel porters who need a robust, flexible,extensible and well structured tool to bring up Linux on embedded hardware. It is equally suitable for new and experienced barebox users.
Agenda of the talk:
Tour through Barebox – Basic hardware initialization (SDRAM, clocks), Startup, User Interface, Start operating system, Update and Initial hardware bring-up.
Arnout Vandecappelle, senior embedded software architect at Essensium/Mind, talks about ways to greatly decrease the risk of bricking your board/device during upgrade thanks to gubies scripts and tools at the Embedded Linux Conference in Barcelona, Spain, on November 6, 2012.
Embedded systems are often modified remotely, e.g. to upgrade the firmware or change the configuration. This may however break the system and render it inaccessible, which is a major problem if the device is hard to reach physically. Unfortunately, no catch-all failsafe solution exists to make sure that the device stays accessible remotely even if a modification goes wrong. Instead, the possible failures have to be anticipated and covered. This talk discusses some of the frequently occurring failures, how they can be detected and handled. These include power failure, kernel crashes, network failure and data corruption. We include examples of concrete use cases. Finally, there is room for discussion about possible alternative or more generic solutions than the ones proposed.
This talk is geared towards system architects and developers who want to improve the quality of their product.
Power failure during firmware update. Solutions:
Add fail-safe firmware
Detect failed power
Atomic update of firmware images
Use journalling filesystem for writable data
Bad firmware. Solutions:
Fall back on previous (known good) firmware
Fail-safe firmware that can do upgrades
Upgrade script included in upgrade image
Watchdog reboot + boot fail-safe after bad boot
Communication errors. Solution: verify data before writing (e.g. GnuGP). If memory is lacking to store the full firmware before upgrade, split in chunks for streaming upgrade
Boot loader upgrade
if boot loader is broken, no recovery is possible => avoid bugs and features in the bootloader.
Upgrade of boot loader with (bootable) backup media
Advantage – results in smaller upgrade files
Drawbacks – Difficult to predict what is installed exactly, more places where something can go wrong, and no package manager is truly atomic (but nixos package manager comes close).
You can download the slides for this presentation, as well as checkout gupies (Generic UPgrade Infrastructure for Embedded Systems), a set of set of scripts and source code that can be used for upgrading the firmware of embedded systems maintained by Arnout.
Chris Simmonds, freelance consultant and trainer (2net ltd), discusses the future of embedded Linux now that storage and processing power are no longer an major issue, and try to find the best Linux platform for embedded systems at ELCE 2012.
Embedded Linux is at a cross roads where the combination of Moore’s law making devices more powerful and the mass production of consumer devices, especially mobile, making them cheaper means that the old ways no longer work. Only a few years ago we though in mega: MHz, MBytes, MBits/s. Now we have to think in giga. The days of the single core CPU are almost over, as are the days of the QVGA display.
All this means that there is a need to re-think how embedded devices are programmed. Two obvious roads lie ahead: Android and Ubuntu (or other desktop operating system of your choice). This talk considers the possibilities and challenges in following either route, and considers how embedded engineers can make the best choices for future projects.
Where is Embedded Linux Headed? Mainstream distro, embedded Linux distro, or Android?
Chris talk is structured as follows:
Evolution of embedded hardware
10 years ago: 80 MHz MCU, 16 MB RAM, 8 MB NOR flash. Price: $500
Cost of hardware – The Beagleboard started the low-cost board revolution
Embedded Linux past
Low RAM, clock speed, and amount of storage. Headless, or simple user interface from keypad or touch screen.
Lots of specific tools – Cross toolchain, uClibc, busbox, read-only file systems, lots of custom BSP…
Embedded Linux now and the future
Clock speed, RAM and storage no longer an issue (less need for busybox, uClibc and small rootfs)
Storage move from flash to eMMC and SD card (reduced need for jffs2)
New problems: Complexity, user interface, maintainability and skill level.
My ideal embedded Linux OS – Multi-platform fully open source OS with good board support, minimal rootfs availability, reduce writes to storage, proper logging, remote upgrade, good debugging tools and long term support.
Options – Choice between Mainstream Distro (e.g. Ubuntu, Debian, Fedora), Embedded Linux (e.g. Open Embedded, Yocto) and Android. He compares those 3 choices according to the criteria mentioned above.
Android is the winner? – Android barely won the contest, but it is monolithic, inflexible, not a community project, and only good for devices that look like smartphones and tablets.
Conclusion – Future devices will take more from mainstream distros, but there’s more work to do, and there is always Android for some kind of devices
Keshava Munegowda and Sourav Poddar, software engineers at Texas Instruments, give a presentation about 2 relatively new file system benchmarks: The Flexible Filesystem Benchmark (FFSB ) and IOzone at the Embedded Linux Conference Europe 2012.
The IOzone is widely used File System Bench-marking tool in both linux and windows systems. The Flexible Filesystem Benchmark (FFSB) is a new cross-platform file-system performance measurement tool. It uses custom profiles as input to measure multiple file systems read/write performances. This paper identifies and compares these file system benchmarking tools in terms of the optimal usage techniques such as buffer size, number of threads, number of write blocks etc. Internals and features of these tools , and the necessary steps involved in the porting of benchmarking tools to different platforms are also discussed. The depicted file system benchmarking performance numbers, in this paper, are measured in both x86 PCs and ARM based SOC platforms.The audience for this presentation are the System Architects and Software Developers working on file systems,storage device drivers and Bench-marking tools.
IOzone and FFSB Benchnmark Results on Intel Core i7 PC running Linux 3.2
Agenda of the talk:
FFSB profile files
Porting of FFSB to ARM based platforms
Porting of IOzone to ARM based platforms
FFSB v/s Iozone Summary
You can download the slides for this presentation, and download IOZone and/or FFSB to give it a try.
Steven Rostedt, working at Red Hat, talks about Real-Time Linux at the Embedded Linux Conference Europe, in Spain on November 6, 2012.
The real-time patch (which provides CONFIG_PREEMPT_RT), has been around since 2005. Started by Ingo Molnar and maintained by Thomas Gleixner and several others, it has grown from a hobby RTOS into a very serious contender. Several distributions (Red Hat, SuSE, Debian, Ubuntu) supply a kernel version that includes this patch. The embedded world has started adding the -rt patch to their own devices that they ship. But do the embedded developers understand what the -rt patch supplies? Programming for real time, and especially when writing kernel code requires special knowledge to avoid real time traps. This talk will explain what the real time patch provides and special programming tips that will ensure embedded developers will get the best from their devices.
Real-Time Linux Option in Make menuconfig: “Fully Preemptible Kernel (RT)”
He goes through the following key points during the presentation:
Real-time OS definition – Deterministic, does not mean fast (but still nice), meet deadlines.
Goal of PREEMP_RT – 100% Preemptible kernel and quick reaction
Different levels of preemption in Linux:
No preemption – Do as most possible with as little scheduling overhead. Use for server in Linux 2.4
Voluntary preemption – Schedule only at “preemption points”
Preemptible Kernel – CONFIG_PREEMPT. Preempt anywhere except within spin_locks
Preemptible Kernel (Basic RT) – For debugging, it will most probably go away…
Fully Preemptible Kernel – PREEMPT_RT_FULL. Preempts everywhere except from preempt_disable and interrupts disabled.
Details of PREEMPT_RT in the Linux kernel – priorities, spin_locks, interrupts, threaded interrupts, etc…
David Anders, embedded systems developer at Texas Instruments, explains how to work with I2C in Linux based embedded systems at ELCE 2012.
Board bring up is one of the most under documented aspects of embedded development. I2C is such a powerful, low-cost, and ubiquitous method of communication, that a basic understanding of it’s usage is essential to the embedded linux developer to quickly bring up and debug embedded designs. This presentation will look at the various software and hardware aspects of working with I2C using simple case studies highlighting the implementation of an EEPROM and a GPIO Expander. Most embedded Linux developers at some point in their career will be handed a piece of hardware that is untested. This presentation intends to provide some information about core tools and methods for bring up of I2C interfaces and assorted I2C based peripheral devices. David Anders has previously presented at Embedded Linux Conference 2012 with “Board Bringup: LCD and Display Interfaces“.
The talk is divided into 3 main parts:
Communication Principles – Asynchronous (e.g. RS232) and Synchronous (e.g. I2C) communication
Drivers and Software Tools – Bootloaders & Linux kernel GPIO bit-bang & I2C chardev, and I2C tools (i2cdetect, i2cdump,. i2cget, i2cset)
Board Bringup Use Cases:
I2C GPIO expanders
You can also download the slides for this presentation.
Koen Kooi, software engineering manager at Circuitco Electronics and lead developer of the Angstrom distribution, explains that device tree does help with the ARM Linux kernel, but brings all the complexity to the bootloader(s), taking the variety of Beaglebone capes as example, at the Embedded Linux Conference in Barcelona, Spain, on November 6, 2012.
Devicetree is marketed as the one ring to rule them all when it comes to non-discoverable hardware for Linux on ARM. The problem with devicetree is that the complexity gets removed from the kernel and put into the bootloader.
Koen first gives an overview of device tree, and provides an example (am33xx.dtsi) to show device tree data structure. Then time for some Beaglebone and capes promotion overview, before moving to the core of the problem:
Thomas Petazzoni, embedded Linux engineer and trainer at Free Electrons, describes the steps he followed to add a new Marvell SoC to the mainline kernel at ELCE 2012.
Since Linus Torvalds raised warnings about the state of the ARM architecture support in the Linux kernel, a huge amount of effort and reorganization has happened in the way Linux supports ARM SoCs. From the addition of the device tree to the pinctrl subsystem, from the new clock framework to the new rules in code organization and design, the changes have been significant over the last one and half year in the Arm Linux kernel world.
Based on the speaker’s experience on getting the support for the new Marvell Armada 370 and Armada XP SoC support in the mainline Linux kernel, we will give an overview of those changes and summarize the new rules for ARM Linux support. We aim at helping developers willing to add support for new ARM SoCs in the Linux kernel by providing a check-list of things to do.
6 Steps to follow to get a minimal Linux image boot on a new ARM SoC
Here’s a summary of the main steps to go through to port a new SoC to ARM Linux:
Minimal image – Write your device tree (arch/arm/boot/dts), implement basic initialization C and header files (arch/arm/mach-foo), the timer driver (drivers/clocksource), the IRQ controller driver (drivers/irqchip), earlyprintk support (arch/am/include/debug), and the serial port driver (drivers/tty/serial)
More core infrastructure – Add pin muxing control (drivers/pinctrl), clocks (drivers/clk), and GPIO (drivers/gpio)
More drivers, advanced features – Add the network driver (drivers/net), SPI controller driver (drivers/spi), SMP support, SATA controller driver (drivers/ata), Power management, and other drivers.
In all the steps above, each driver must have its own device tree binding. and they cannot include <mach/something.h> anymore as they must be supported by different platforms without having to rebuild them. Device tree is now compulsory for all new SoC, and it you have old code for an existing SoC, it’s very likely you’ll have to start from scratch due to device tree and the many changes that occurred in the kernel in the last two years.
Many ARM SoCs still do not comply with the current best practices, and Thomas recommends to have a look at the following implementations to get started:
arch/arm/mach-bcm2835 (So having a Raspberry Pi might be a good idea to learn and experiment about device tree)
You can also download the slides for this presentation.