Alexandre Belloni – Page 2

Atmel SAMA5D4 support in the mainline Linux kernel

Atmel announced its new ARM Cortex-A5-based SoC on October 1, the SAMA5D4. Compared to the previous Cortex-A5 SoC from Atmel, the SAMA5D3, this new version brings a L2 cache, NEON, a slightly different clock tree, a hardware video decoder, and Trustzone support.

Bootlin engineers have worked since several months with Atmel engineers to prepare and submit the support for this new SoC to the mainline Linux kernel. We have actually submitted the patches on September, 11th, almost a month before the official release of the new chip! This means that most of the support for this new SoC will already be part of the upcoming 3.18 kernel release. Meanwhile, it is already possible to test it out by using the linux-next repository.

There are however a few pieces missing pieces to support all aspects of the chip:

A few patches are needed to get proper NAND flash controller support.
The DMA controller is brand new in this SAMA5D4 SoC, and the DMA controller driver has not yet been merged, even though the patches have been posted a long time ago, and are currently in their sixth iteration.
Display support, through a DRM/KMS driver, is also being reviewed. The driver, written by Bootlin engineer Boris Brezillon, was initially designed for the sam9x5 and sam5d3, but will be compatible with sama5d4 as well. The patch series is currently in its seventh iteration.

The last big missing part is support for non-secure mode: for the moment, the system always runs in secure mode. Running the kernel in non-secure mode will require some more work but an initial version will probably be pushed during the next development cycle.

Besides this work on SAMA5D4 support ahead of its public release, Bootlin is also doing a lot of maintenance work on all the Atmel ARM platforms in the Linux kernel: migration to the Device Tree, to the clock framework, to several other new subsystems, etc. See the summary of our kernel contributions to 3.16, 3.15 and 3.14.

Through this work, the Bootlin engineering team has a very deep knowledge of the Linux support for Atmel ARM processors. Do not hesitate to contact us if you need help to bring up the bootloader or kernel on your custom Atmel ARM platform! It is also worth mentioning that Free-Electrons is part of the Atmel partner ecosystem.

Embedded Linux Development with Yocto Project

We were kindly provided a copy of Embedded Linux Development with Yocto Project, written by Otavio Salvador and Daiane Angolini. It is available at Packt Publishing, either in an electronic format (DRM free) or printed.

This book will help you start with your embedded system development and integration using the Yocto Project or OpenEmbedded.

The first chapter sheds some light on the meaning of commonly misused names: Yocto Project, Poky, OpenEmbedded, BitBake. Then, it doesn’t waste time and explains how to install and use Poky to build and then run an image. The entire book is full of examples that can easily be tested, providing useful hands-on experience, using Yocto Project 1.6 (Poky 11).

The following chapters cover:

Hob: a user friendly interface, however, it will soon be deprecated and replaced by Toaster.
BitBake and Metadata: how to use BitBake, how to write recipes for packages or images, how to extend existing recipes, how to write new classes, how to create a layer, where to find existing layers and use them.
The build directory layout: what the generated files are, and what their use is.
Packaging: how to generate different package formats, how to handle a package feed and the package versions.
The various SDKs that can be generated and their integration in Eclipse.
Debugging the metadata: what the common issues are, how to find what is going wrong, and solving these issues.
Debugging the applications on the target: how to generate an image with debugging tools installed.
Available tools to help achieve copyleft compliance: in particular, how to cope with the GPL requirements.

Finally, there is a chapter dedicated to explaining how to generate and run an image on the Wandboard, an i.MX6 based community board.

The book is easy to read, with plenty of examples and useful tips. It requires some knowledge about generic embedded Linux system development (see our training) as only the Yocto Project specifics are covered. I would recommend it both for beginners wanting to learn about the Yocto Project and for developers wanting to improve their current knowledge and their recipes and also understand the BitBake internals.

Speaking of the Yocto Project, it is worth noting that Bootlin is now offering a Yocto Project and OpenEmbedded training course (detailed agenda). If you’re interested, join one of the upcoming public training sessions, or order a session at your location!

Crystalfontz boards support in Yocto

The Yocto 1.5 release is approaching and the Freescale layer trees are now frozen.
Bootlin added support for the various Crystalfontz boards to that release as you can check on the OpenEmbedded metadata index.

First some preparative work has been done in the meta-fsl-arm layer in order to add the required features to generate an image able to boot on the Crystalfontz boards:

Support for a newer version of the Barebox mainline, 2013.08.0. As the previously supported version of Barebox was too old, it didn’t include support for the Crystalfontz boards. Also, some work has been done to make the recipe itself more generic so that custom layers can reuse it more easily.
Inclusion of the patches allowing the imx-bootlets to boot Barebox. The imx-bootlets were only able to boot U-Boot or the Linux kernel until now.
Creation of a new image type, using the imx-bootlets, then Barebox to boot the Linux kernel. All the boards based on a Freescale mxs SoC (i.mx23 and i.mx28) will benefit of this new image type. This is actually the difficult part where you lay out the compiled binaries (bootloaders, kernel and root filesystem) in the final file that is an SD card image ready to be flashed.

Then, the recipes for the Crystalfontz boards have been added to the meta-fsl-arm-extra layer:

First the bootloaders, imx-bootlets and Barebox, including the specific patches and configurations for the Crystalfontz boards.
Then the kernel. The linux-cfa recipe uses the 3.10 based kernel available on github.
The machine configurations themselves, selecting Barebox as the bootloader and the correct kernel recipe. Also, these are choosing to install the kernel in the root filesystem instead of in its own partition.
Touchscreen calibration for the cfa-10057 and the cfa-10058 boards. This is required to get xinput-calibrator working properly as it can’t calibrate without starting values.

In a nut shell, you can now use the following commands to get a working image for your particular Crystalfontz board:

For your convenience, Freescale is providing a repo manifest to retrieve all the necessary git repositories. So first download and install repo:
mkdir ~/bin curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo chmod a+x ~/bin/repo PATH=${PATH}:~/bin
We will work in a directory named fsl-community-bsp:
mkdir fsl-community-bsp cd fsl-community-bsp
Ask repo to get the master branch, when Yocto 1.5 is released, you could select the new branch. (Edit: starting from September, 28th, you can use the branch named dora)
repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b master
Download the layers:
repo sync
Configure the build for cfa-10036:
MACHINE=cfa10036 source ./setup-environment build
Start the build with:
bitbake core-image-minimal
Grab a cup of coffee!

You’ll end up with an image that you can flash using the following command:
sudo dd if=tmp/deploy/images/cfa10036/core-image-minimal-cfa10036.sdcard of=/dev/mmcblk0

Obviously, you need to replace cfa10036 by the board model you are using in the above commands. While not completely perfect, core-image-sato is also working.

In detail, the contributions from Bootlin are:

In meta-fsl-arm:
- Alexandre Belloni (6):
In meta-fsl-arm-extra:
- Alexandre Belloni (14):
In meta-fsl-base:
- Alexandre Belloni (1):
  - README: add crystalfontz boards

Starting Linux directly from AT91bootstrap3

Here is an update for our previous article on booting linux directly from AT91bootstrap. On newer ATMEL platforms, you will have to use AT91bootstrap 3. It now has a convenient way to be configured to boot directly to Linux.

You can check it out from github:

git clone git://github.com/linux4sam/at91bootstrap.git

That version of AT91bootstrap is using the same configuration mechanism as the Linux kernel. You will find default configurations, named in the form:
<board_name><storage>_<boot_strategy>_defconfig

board_name can be: at91sam9260ek, at91sam9261ek, at91sam9263ek, at91sam9g10ek, at91sam9g20ek, at91sam9m10g45ek, at91sam9n12ek, at91sam9rlek, at91sam9x5ek, at91sam9xeek or at91sama5d3xek
storage can be:
- df for DataFlash
- nf for NAND flash
- sd for SD card
our main interest will be in boot_strategy which can be:
- uboot: start u-boot or any other bootloader
- linux: boot Linux directly, passing a kernel command line
- linux_dt: boot Linux directly, using a Device Tree
- android: boot Linux directly, in an Android configuration

Let’s take for example the latest evaluation boards from ATMEL, the SAMA5D3x-EK. If you are booting from NAND flash:

make at91sama5d3xeknf_linux_dt_defconfig make

You’ll end up with a file named at91sama5d3xek-nandflashboot-linux-dt-3.5.4.bin in the binaries/ folder. This is your first stage bootloader. It has the same storage layout as used in the u-boot strategy so you can flash it and it will work.

As a last note, I’ll had that less is not always faster. On our benchmarks, booting the SAMA5D31-EK using AT91bootstrap, then Barebox was faster than just using AT91bootstrap. The main reason is that barebox is actually enabling the caches ~~and decompresses the kernel~~(see below, the kernel is also enaling the caches before decompressing itself) before booting.