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.
Matt Ranostay, technical staff at Ranostay Industries, gives a presentation about a telemetry system based on Beaglebone at the Embedded Linux Conference Europe on November 5, 2012.
The author will discuss his ongoing and other team members efforts to develop hardware and software that reports sensor data to the community. This talk will be split into several parts a) types of useful sensors b) hardware design of Beaglebone capes c) and telemetry reports to Pachube/Cosm. Demonstrating that in the new world of cheap prototyping boards with I2C, GPIO, and SPI that anyone can setup a decent monitoring system for home security, automation, and weather reporting. There will be a live demo of prototype geiger counter + weather station.
The audience targeted is the professional hobbyist who likes to hack on microcontrollers in their spare time. It will take little to medium knowledge of electrical engineering to follow this talk.
Telemetry System (Weather Station + Geiger Counter) Block Diagram
You can download the slides for this presentation, and demo source (Python) is available on Github. There are also many other references at the end of the presentation slides.
Matthias Brugger, embedded engineer at ISEE, describes the steps the company had to follow (referred to as a “war story”) to port Android 4.0 to a custom industrial board at ELCE 2012, Barcelona, on November 5, 2012.
This talk will explain the lessons learned by giving a step-by-step introduction of porting Android to a custom board which was designed for an industrial environment. This includes an introduction to the Android build environment, first board bring-up and peripheral integration. The talk will cover bootloader integration, power management. It will focus on the peculiarities configuring Ethernet and Wi-Fi in Android. Also button and display integration, as well as integration of third-party accelerator support will be explained.
Android devices are getting popular not only in the mobile market but although in the industrial environment. Porting Android to a custom board can be challenging, especially as little information about Android internals are available. The talk is addressed to embedded developer and CTOs who regard the introduction of Android in the industrial field.
ISEE Ported Android 4.0 to this Custom Industrial Device
His talk features the key points below:
Android beyond smartphones? – Good for HMI centred embedded systems
Why a war story – Little documentation, small community, vendor specific communities, developing process of Android, and a huge jungle of programming languages. Although Android is based on Linux, Android is not Linux, and there are many differences.
Our custom board – Industrial board based on TI OMAP3 without battery monitor, nor phone function, but with buttons, Ethernet…
Android building system
Add device – Devices are found under device/<manufactor>/<board> folder with 4 files: <device_name>.mk, device.mk, BoardConfig.mk and vendorsetup.sh.
Bootloader/Kernel integration – Specific toolchain needed, and extra boot parameters required (androidboot.console=ttyO2, init=/init).
Power supply – The system hangs at boot time because there’s no battery monitor => Add a “test power driver” to shows battery 50% charged.
Button – Code in frameworks/base/services/input. Key Layout File (/system/usr/keylayout) maps raw input key to internal Android key representation, and Key Char Map File (/system/usr/keychars) describes action for internal Android key
Wi-Fi – 5 different folders with userspace code… Legacy implementation reads wpa supplicant config file (/data/misc/wifi/wpa_supplicant.conf). A template is available in /system/etc/wifi/wpa_supplicant.conf. Drivers and firmware path defined in BoardConfig.mk.
Sound – Audio player is stagefright, AudioFlinger interfaces hardware abstraction.
HW acceleration – Add own multimedia framework and implement wrapper for audio (AudioTrack) and video (Surface).
You can also download the slides for this presentation.
Andre Guedes and João Paulo Rechi Vita, software engineers at Instituto Nokia de Tecnologia (INdT), give a presentation about Bluetooth Low Energy support on Linux (BlueZ stack) at the Embedded Linux Conference Europe in Barcelona on November 5, 2012.
Bluetooth Low Energy Architecture
This presentation will cover a brief introduction on how the Bluetooth Low Energy technology works. Then it will present the current status of its support on Linux, presenting the available APIs and how to interact with Bluetooth Smart devices. Then we’ll present the profiles we’re currently working on and what support can be expected to be found on Linux and BlueZ this year. There will be also a few demos of Bluetooth Smart devices working on Linux. The audience of this talk is application or framework developers that want to add support for Bluetooth Smart devices to their software, hardware vendors,and technology curious. Basic Bluetooth understanding is recommended but not required.
The agenda of the talk is as follows:
Intro to BLE technology – Specified in Bluetooth 4.0 for low power consumption (Coin-cell battery devices), fast connection establishment and short range. BLE is to be used in PCs, wellness and medical devices, mobile phones, as well as sensors and automation.
LE profiles supported by BlueZ
Generic Attribute Profile
Proximity Profile – When reporter distances from monitor an alert is emitted
Find Me Profile – Emit an alert on the remote device upon a command
Time Profile – Synchronizes the current local time
Health Thermometer Profile – Temperature measurements at periodic intervals
HID over GATT Profile – LE Human Interface Devices
Broadcaster & Observer – Undirected connectionless data transfer used for sensors and info advertisement.
Current support status
Work in progress – GATT API improvements, Broadcaster and Observer APIs and Profiles (Alert Notification, Phone alert status)
Demos – Proximity, Time and HID over GATT
You can also download the slides for this presentation.
Alan Ott, founder of Signal 11 Software, gives a presentation dealing with wireless networking for the internet of things in Linux, especially with 802.15.4 and 6LoWPAN standards at the Embedded Linux Conference in Barcelona, Spain on November 5, 2012.
With the rise of the internet of things, low-power wireless devices will become increasingly prevalent. IEEE 802.15.4 is a wireless networking protocol designed for low-power and low-data-rate devices, such as those used in wireless sensor networks. While some higher layer protocols based on 802.15.4 are proprietary, an open standard called 6LoWPAN enables IPv6 traffic over 802.15.4. This presentation will give overviews of 802.15.4, its status in the Linux kernel, hardware support, comparison with other wireless protocols, and a demonstration of a simple 802.15.4/6loWPAN network.
This presentation is targeted toward developers who wish to create low-power, low-data-rate wireless networks for sensors or other applications. Attendees can expect to gain a basic understanding of 802.15.4 and 6loWPAN and also gain some ideas for use in their own systems. Technical expertise required is low.
Beaglebone based Alarm System with Adafruit Proto Cape, Microchip MRF24J40MA (802.15.4 radio transceiver module), Maxbotix HRLV-EZ0 ( ultrasonic rangefinder), LM7805 (5V regulator) and Battery. PS: I almost forget the Altoids can and the piece of cork…
Alan talk covers the following main items:
IEEE 802.15.4 Introduction:
Standard for low-power, low data rate wireless communication between small devices.
It’s not Zigbee which sits on top of 802.15.4 (OSI Level 3 vs OSI Levels 1 & 2). Zigbee license conflicts with the GPL and can’t be implemented in the Linux kernel.
802.15.4 can operate on 2.4 GHz, 915 MHz and 865 MHz bands depending on local regulations.
6LoWPAN Overview – IPv6 over IEEE 802.15.4 can provide an IP address to all small devices.
Linux Support for IEEE 802.15.4 and 6LoWPAN with 2 kernel trees and independent projects:
Linux-Zigbee project – 802.15.4 and partial 6LoWPAN implementation. No updates of the kernel for 6 months. The project includes user space tools (iz, izcoordinator, and izchat) and support for multiple drivers for chips from Atmel, TI, Analog Devices and Redwire.
Linux-wsn project – Project up-to-date in mainline kernel with support for raw 802.15.4 sockets and 6LoWPAN. It uses the same user space tools as Linux-Zigbee, and provides drivers for Atmel AT86RF230, Microchip MRF24J40 and Redwire Econotag. Many things currently work, but there’s still more things to do for both 802.15.4 and 6LoWPAN implementations.
Other Support for IEEE 802.15.4 and 6LoWPAN – Contiki OS and TinyOS,
The presentation also includes a security system demo (Alarm) with 2 nodes: A Beaglebone + Microchip MRF24J40MA + Maxbotix Ultrasonic Range Finder (HRLV-EZ0) and a laptop + Redwire Econotag.
Peter Stuge, self-employed hardware, software and security consultant, talks about OpenOCD open source tool for JTAG debugging at ELCE 2012 in Barcelona.
The presentation walks through how to use the OpenOCD open source software to debug embedded systems on the hardware level via JTAG interface, allowing single stepping, setting breakpoints, inspecting register and memory contents and more, starting before the CPU even executes the first instruction. After an introduction to JTAG debugging we look at how to use OpenOCD both standalone for firmware flashing as well as together with the GDB GNU Debugger for convenient debugging of bootloaders or the Linux kernel. These tasks will be demonstrated, and the respective OpenOCD configuration details will be explained.The presentation targets intermediate-level developers who work on bootloaders, BSPs and kernel drivers, deeply embedded systems, and test and production engineers with an interest in using OpenOCD, which can allow unified tooling across all of development, testing and production.