Overview

DevelBoard is a Linux-based device, running version 3.18 of the Linux kernel at the time of writing this guide. As such, it runs on an open-source core that can be easily modified and extended to add any required functionality.

The process of modifying and building the DevelBoard BSP is based on buildroot, an easy-to-use Linux-based tool designed to configure and generate embedded Linux systems, including a root filesystem, bootloaders and a cross-compilation toolchain.

Getting the DevelBoard BSP

The latest source for the DevelBoard BSP is available on GitHub at the following link.

The kernel directory will have the following layout:

    .
    ├── buildroot
    │   ├── arch
    │   ├── board
    │   ├── boot
    │   ├── configs
    │   ├── ...
    │   └── Makefile
    ├── tools
    └── Makefile

    7 directories, 2 files

This is the typical layout of a buildroot-based project.

Each subfolder under ./buildroot is responsible for the configuration of a specific aspect of the build process.

Building the BSP

Once it has been downloaded, it is ready to be built using the default configuration:

$ git clone https://github.com/DevelBoard/kernel
$ cd kernel
$ make

The build process takes place in the ./buildroot/output folder. This folder will contain several subdirectories after building the source. In particular, the output/images directory will contain the final products of the build, which by default include bootloaders, device tree, root filesystem and finally the kernel image.

Modifying the BSP

The default BSP configuration produces a fully-functional BSP suitable for DevelBoard and EVA01, based on the linux4sam kernel. However, it may be necessary for the user to modify the default configuration of the Linux kernel in order to enable support for additional peripherals, additional modules and so on.

IMPORTANT: for the rest of the guide, it is assumed that the kernel version used by the BSP is 3.18, corresponding to the tag linux4sam_4.7. This may not necessarily be the case, so change names and version numbers to match the current ones, where needed.

Traditionally, Linux development has followed a patch-based approach, in which the user who wants to submit a modification to the kernel must submit a patch relative to the tag that is being modified. buildroot, and by extension the DevelBoard BSP, continues to follow the same approach. In particular, all the files related to the DevelBoard configuration are located in ./buildroot/board/develer/develboard/.

In particular, two files are of particular interest to the user in this folder:

  • the file linux-linux4sam_4.7.config is the configuration file for the Linux kernel image.
  • the folder linux-linux4sam_4.7-patches/ contains all the patches related to the tag linux4sam_4.7 of the linux4sam kernel, in the format linux-XXX-NNNN-yyy.patch, where:
    • XXX is the tag version, same as the folder name (e.g. linux4sam_4.7)
    • NNNN is the sequence number of the patch (patch order IS important)
    • yyy is the user-defined name of the patch (e.g. add-print-support)

So, modifying the kernel is a matter of:

  1. finding out which kernel version the current DevelBoard BSP is based on
  2. retrieving the kernel
  3. setting up the cross-compilation toolchain
  4. aligning the kernel with the DevelBoard BSP
  5. modifying it according to the user's needs
  6. moving the changes back to the BSP
  7. (re)building the BSP

Each of these steps will be illustrated below.

Getting the kernel version

It is possible to retrieve the kernel version used by the BSP by running the following commands:

# From the Develboard/kernel repository root
$ make configure-buildroot
$ cd buildroot
$ make menuconfig

The last command will open a ncurses-based configuration interface, populated with the appropriate values for DevelBoard.

Navigate inside Kernel, and take note of the URL of the custom repository (e.g. https://github.com/linux4sam/linux-at91) and the repository version (e.g. linux4sam_4.7).

Retrieving the kernel

Clone the repository found in the previous point and switch to the required tag:

# In another directory
$ git clone https://github.com/linux4sam/linux-at91.git
$ cd linux-at91
$ git checkout linux4sam_4.7

Note that permanently retaining any commits done to this local repository requires creating a new local branch (e.g. linux4sam_4.7_develboard_patches):

$ git checkout -b linux4sam_4.7_develboard_patches

Setting up the toolchain

Before proceeding, it is necessary to extract and configure the cross-compilation toolchain, in order to build for ARM targets on non-ARM platforms (i.e. the host PC). This toolchain is automatically downloaded the first time the DevelBoard kernel is built using buildroot. Otherwise, it can be downloaded here.

You can extract the toolchain to a temporary location for convenience, additional export its bin folder to PATH:

$ mkdir /opt/toolchain
$ cd /opt/toolchain
# From the DevelBoard BSP repository (or any directory where the toolchain is located)
$ tar zxf buildroot/dl/arm-buildroot-linux-gnueabihf.tar.gz -C /opt/toolchain
$ export PATH=/opt/toolchain/bin/:$PATH

Aligning to the BSP

The Linux kernel requires a device-dependent configuration step. For this reason, it is also necessary, at this point, to import the kernel configuration for DevelBoard, as a base to perform any modifications.

The defconfig file can be named in any way, we will use develer_defconfig:

# From the DevelBoard BSP repository
$ cd buildroot/board/develer/develboard
$ cp linux-linux4sam_4.7.config <linux4sam_dir>/arch/arm/configs/develer_defconfig

To generate the configuration files:

# From the linux-at91 repository
$ make ARCH=arm CROSS_COMPILE=arm-linux- develer_defconfig

Now would be a good time to commit the changes:

$ git add arch/arm/configs/develer_defconfig
$ git commit -m"Added Develer config"

As said before, there is a folder in the BSP source code containing all the patches made to the mainstream kernel tag (linux4sam_4.7 in the example) in order to make it compatible with DevelBoard. These patches must be applied to the kernel to be modified, in order to be aligned with the BSP release.

To do this, run the following commands:

# From the linux-at91 repository
$ git am <develboard_bsp_dir>/buildroot/board/develer/develboard/linux-linux4sam_4.7-patches/*

This will commit to the local repository all the patches found in the specified directory.

You are now ready to modify the kernel.

Modifying the kernel configuration

At this point, the user can modify the kernel configuration according to their own needs.

As an example, we will add core debug messages for the I²C peripheral. Enter the configuration menu interface:

$ make ARCH=arm CROSS_COMPILE=arm-linux- menuconfig

Navigate to Device Drivers --> I2C support and enable I2C Core debugging messages. Save by navigating to Save at the bottom, and give it a filename (the default .config is fine). Finally Exit until back to the terminal.

Finally, we need to generate the kernel configuration file by issuing:

$ make ARCH=arm CROSS_COMPILE=arm-linux- savedefconfig

This command will generate the defconfig file for the kernel, which will replace the .config file in the DevelBoard BSP.

$ cp defconfig <develboard_bsp_dir>/buildroot/board/develer/develboard/linux-linux4sam_4.7.config

You can issue a git diff in the BSP repository to verify that the new .config file adds I²C debug

--- a/buildroot/board/develer/develboard/linux-linux4sam_4.7.config
+++ b/buildroot/board/develer/develboard/linux-linux4sam_4.7.config
@@ -110,6 +110,7 @@ CONFIG_SERIAL_ATMEL_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 CONFIG_I2C_CHARDEV=y
 CONFIG_I2C_AT91=y
+CONFIG_I2C_DEBUG_CORE=y
 CONFIG_SPI=y
 CONFIG_SPI_ATMEL=y
 CONFIG_GPIO_SYSFS=y

To recompile with the new changes, refer to the device tree section.

Creating a patch for the BSP

As said before, the Linux kernel development is a patch-based development.

If the modifications done to the kernel go beyond a simple configuration change (for example, changing the device tree), the user needs to create a patch that will be later applied during the BSP build process.

For information on how to create a patch, refer to the device tree example, which shows a more complex scenario.