Difference between revisions of "External Toolchains"

Revision as of 11:14, 14 August 2011

You will need to use a recent Armadeus release (with Buildroot > 2011.05) to use the following instructions.

Building common toolchains with Buildroot

• create directory where toolchain will be put:

$ sudo mkdir -p /usr/local/armadeus
$ sudo chown $USER:$USER /usr/local/armadeus

$ make menuconfig

Build options ---->
    () Host dir

Using already built Toolchains

Toolchain ---->
    Toolchain type (External toolchain)  --->
    Toolchain (Custom toolchain)  --->
    (/path/to/staging/usr/) Toolchain path

Then, set the properties of the toolchain accordingly.

Using a recent Buildroot to build rootfs for an Armadeus board

This may be useful if you need some packages that have been integrated in Buildroot after the release used in the latest release (or git head) of the Armadeus SDK.

It allows to build new rootfs or images for the APF boards, keeping support for the specific hardware.

The method uses:

• an Armadeus SDK providing the cross-toolchain and Armadeus specific hardware support;
• a recent Buildroot (from a tarball or a clone of the repository).

There are several ways of getting things done, but at the end, the main difference will be the location of the full target directory; you can choose to install everything:

1. either in the Armadeus target directory;
2. or in the Buildroot one;
3. ...

Setting up the environment

The 1st way is based on the make O=/PATH_TO_ARMADEUS/buildroot/output/target usage in the buildroot tree (for more information, refer to the out-of-tree build section of the Buildroot documentation).

The following explains the 2nd way (the way I use ;-)).

Note: In the following, from step 2, you should run both the Armadeus SDK menuconfig and the Buildroot one at the same time. Despite the some differences, that makes the configuration of Buildroot easier and quicker!

1. Build a minimal target for your board using the Armadeus SDK; what make apfXXX_defconfig sets is sufficient.

Linux kernel and programs provided by the recent Buildroot are not mandatory.

2. Get a recent Buildroot (tarball or head of Buildroot repository) and set the Armadeus cross-toolchain as its external toolchain (cf. Using already built Toolchains).

3. Set the System configuration (of the recent Buildroot) pointing to the Armadeus target directory.

This way ensures that things only provided by the Armadeus SDK will be copied in the target:

System configuration ---->
    Root FS skeleton (custom target skeleton)  --->
    (/PATH_TO_ARMADEUS/buildroot/output/target) custom target skeleton path

4. Set the Filesystem images according to your wish (certainly similar to the Armadeus one).

5. Disable any bootloader.

The current u-boot version used in the Armadeus SDK (u-boot 1.3.4) is no longer available in recent Buildroot. However, some people are working on porting u-boot 2010-03, and maybe barebox too.

6. The kernel configuration depends on which, from the Armadeus SDK or Buildroot, will provide (build and install) the kernel image and its modules:

1. If you have enabled the kernel in the Armadeus SDK, then your should probably not enable it in Buildroot. Misconfigurations may result in unconsistencies between the kernel image and its modules installed in the rootfs.

2. If you have disabled the kernel in the Armadeus SDK, you should build it in Buildroot, but use patch set provided by the Armadeus SDK to keep specific hardware support.

Kernel ---->
    [*] Linux Kernel
          Kernel version (Custom version)  --->
    (2.6.38.1) Kernel version
    (/PATH_TO_ARMADEUS/target/device/armadeus//linux/kernel-patches/$(BR2_LINUX26_VERSION)) Custom kernel patch
          Kernel configuration (Using a custom config file)  --->
    (/PATH_TO_ARMADEUS/target/device/armadeus/BOARD_NAME/BOARD_NAME-linux-$(BR2_LINUX_KERNEL_VERSION).config) Configuration file path
          Kernel binary format (uImage)  --->

From here, you can select any packages you want in Buildroot.

Warning: Take care when enabling/disabling packages from one or the other side. Overriding some packages (ie. enabling a package in both the Armadeus SDK and Buildroot), may result in an unconsistent/unstable system. This mainly targets the busybox and its potential broken symlinks. Some hardware may not work properly without Armadeus patch sets. Some packages have been patched in the Armadeus SDK, that Buildroot's ones does not patch (yet).

Lastly, build and try the freshly built image (shall I recommend usage of nfs-root for that kind of experiments ...).

Links

• Buildroot's documentation about External Toolchains