pierre ficheux ([email protected]) cto open wide...

1Buildroot hardware support

Adding hardware support to Buildroot

Pierre Ficheux ([email protected])

CTO Open Wide / OS4I

08/07/2010

mailto:[email protected]


Several ways to get a distribution

● Using commercial product (Wind River, MV, …) => €€€ / $$$

● Adapting standard GNU/Linux distribution :(– Hardware support limitation

– Large footprint

● Creating « from scratch » – Good knowledge necessary

– Not industrial: dependencies, updates, etc.

● Using a generation tool :-) – Buildroot, OpenEmbedded, LTIB, ...


Generation tool principle

● An software “engine” generates distribution from adapted sources by applying patches

● Sources are not provides: only patches + root-fs skeleton

● Handle dependencies :)● Can produce the « GNU Toolchain » (gcc, ...)● Can produce distribution, several images :

– Bootloader image (u-boot.bin)

– Linux kernel (zImage, uImage)

– Root-fs image: EXT2, JFFS2, CRAMFS, TAR, CPIO, ...


Some famous tools

● OpenEmbedded– Engine written in Python (BitBake)

– Very powerful but complicated

– Based on configuration files (no GUI)

● LTIB– Used by Freescale

– Looks like Buildroot but old fashioned

● Buildroot– First a demonstrator for uClibc

– Since 2009, a powerful, well maintained tool !


About Buildroot

● Linked with uClibc (micro-C-libc) : lightweight Libc (about 5 times smaller / Glibc)

● Initial goal: producing test images for uClibc● Engine based on Makefile(s) and shell-scripts :-)● Based on Busybox● Use Kconfig language (just like kernel

configurator) in Config.in files for GUI● Can produce toolchain (uClibc based) or use

external toolchain● No official release before 2009 :(


Buildroot today

● Since 2009, managed by Peter Korsgaard and Thomas Petazzoni

● Official realease every 3 months: 2009.02, ..., 2009.11, 2010.02, 2010.05

● Switched to Git :)● More documentation● More “packages”, with extended .mk since 2010● Supports x86, ARM, PowerPC, SH4, …● Direct supports for some boards: Atmel, ...● It’s “simple” to add board support, if you are

fluent in Makefile and Kconfig !


Using Buildroot “in a nutshell”

● Get it from http://buildroot.uclibc.org● Extract archive● Configure with make menuconfig● Compile with make● Results is in output/images

– Bootloader image

– Linux kernel

– Root-filesystem image(s)

● Needs a fast connection for downloading sources (or use make sources first then work off-line)

http://buildroot.uclibc.org/


Configuring Buildroot

● Target Architecture + Variant : arm then arm920t

● Target options: trivial if in Preset Devices● Toolchain: internal (uClibc) or external (Glibc,

Eglibc, …) => could be tricky● Packages => what to add to root-filesystem, at

least Busybox● Target filesystems: JFFS2, CRAMFS, SQUASHFS

(flash), TAR (NFS Root) ● Kernel and Bootloaders (disabled by default)● Configuration saved in .config file


Advanced configuration, stage 1

● In case of supported board, just type make myboard_config

● Once .config is done, just copy it to configs/myboard_config, but...

● Some configuration are not accessible by GUI– Cool, it’s fine not to give access to everything

to GUI lovers

● It’s nice to have board definition in Preset Devices

– Fine to be able to tune the configuration (in case of similar boards from same maker)

– Smart for marketing guys :)


What can you do with Advanced configuration, stage 2?

● Quite everything !– Target specific skeleton for rootfs =>

TARGET_SKELETON

– Target specific /dev content => TARGET_DEVICE_TABLE

– Customized kernel patches + configuration

– Customized U-Boot sources + configuration

– Handle a set a boards with common configuration + one by one tuning (i.e. : adding /dev/foo to board A and /dev/bar to board B)


What do you need to know?

● Read http://buildroot.uclibc.org/buildroot.html first !

● Makefile– Good knowledge

● Config.in => Kconfig language– Good knowledge

● Shell script– Basic knowledge

● grep -R “BR2_” *– Very good knowledge :)

● Cut/paste !– Very good knowledge ;-)

http://buildroot.uclibc.org/buildroot.html


Example, example !!

● Want to add boards “model A” and “model B” from “Board Maker Inc.” company (BMI)

– “Board Maker Inc.” provides only support for a specific “old” version of kernel, assuming 2.6.28.7

– Model A and Model B use same kernel patch BUT different kernel configuration

– Model A and Model B use same U-Boot version BUT different patches

– Each board has specific entries in /dev (defined by device_table.txt)

– Each board has specific Busybox configuration (why not?)


Step 1, adding board(s) directory

● Several ways to do the job, here is one !● First create a target/devices/BMI directory with

ModelA and ModelB and kernel-patches-2.6.28.7 subdirs

● Copy Board Maker specific patch file to kernel-patches-2.6.28.7 with .patch extension

– As boards use same kernel patch, you should put it at BMI level (save space)

● Add the following to target/device/Config.in– source "target/device/BMI/Config.in"


Step 2: creating Config.in for BMI

● Create target/device/BMI/Config.in● Define a new variable BR2_TARGET_BMI● BMI => ARM + ARM920 + OABI

menuconfig BR2_TARGET_BMI

depends on (BR2_arm && BR2_arm920t && BR2_ARM_OABI)

bool "Support for Board Maker Inc. boards"

help

Support for Board Maker Inc. boards


Step 3: adding definition for boards

if BR2_TARGET_BMI

config BR2_TARGET_BMI_MODEL_A

bool "Support for BMI Model A"

help

Support for BMI Model A

config BR2_TARGET_BMI_MODEL_B

bool "Support for BMI Model B"

help

Support for BMI Model A


Step 4: Adding boards names

if BR2_TARGET_BMI_MODEL_A

config BR2_BOARD_NAME

string

default "ModelA" <--- force value

endif

if BR2_TARGET_BMI_MODEL_B

config BR2_BOARD_NAME

string

default "ModelB"

endif


Step 5: Generic parameters 1/2

● Depend on board names

config BR2_BOARD_PATH

string

default "target/device/BMI/$(BR2_BOARD_NAME)"

# BMI uses specific kernel version

config BR2_KERNEL_ARCH_PATCH_VERSION

string

depends on BR2_KERNEL_ARCH_PATCH_ENABLED

default "2.6.28.7"


Step 6: Generic parameters 2/2

● Kernel patch path, same U-Boot version● End of Config.in :)

config BR2_KERNEL_ARCH_PATCH_DIR

string

default "target/device/BMI/kernel-patches-$(BR2_KERNEL_ARCH_PATCH_VERSION)"

config BR2_UBOOT_VERSION

string

default "1.1.6"

endif


Step 7: Makefile.in

● Simpler: defines specific variables at compilation time

● Use qstrip macro to get “basename”

BOARD_NAME:=$(call qstrip,$(BR2_BOARD_NAME))

BOARD_PATH:=$(call qstrip,$(BR2_BOARD_PATH))

TARGET_DEVICE_TABLE=$(BOARD_PATH)/device_table.txt

BR2_PACKAGE_BUSYBOX_CONFIG=$(BOARD_PATH)/busybox.config


Step 8: ModelA/ModelB content

● ModelA– busybox.config

– ModelA-linux-2.6.28.7.config

– device_table.txt

– u-boot-1.1.6.patch

● ModelB– busybox.config

– ModelB-linux-2.6.28.7.config

– device_table.txt

– u-boot-1.1.6.patch


Step 9: Test new GUI● New Board Maker Inc. entries should appear in

Target options / Preset Devices menu if you set correct dependencies

● We could carry on with configuration files but a bit complicated => let GUI help us for each board :

– Kernel

– U-Boot

– System banner

– System name

– Console device (UART)

– Toolchain

– ...


Step 10: U-Boot

● In Bootloaders menu● Das U-Boot Boot Monitor

– Set board name to U-Boot board name (not BR board name !) => bmi_A, bmi_B

– BR will do make myboard_config to build U-boot

– Set custom patch to $(BR2_BOARD_PATH)/u-boot-1.1.6.patch

– U-Boot Version is useless as BR2_UBOOT_VERSION was set in Config.in


Step 10 screen


Step 11: Kernel● For Kernel type, select linux (Advanced configuration)

● In Linux Kernel Version select Linux <custom> version

● Enter 2.6.28.7 to Linux Tarball Version AND Linux Version

● In Patches menu, set Add ARCH specific patch

● In Linux Kernel configuration menu, select .config file option which should depend on BR2_BOARD_PATH and BR2_BOARD_NAME

● Set kernel binary format to uImage as we use U-Boot


Step 11, screen 1


Step 11, screen 2


Step 11, screen 3


Step 12: finish configuration

● Set any other parameter, just like the first test: packages, toolchain, rootfs images in Target filesystems options menu, …

● Save your configuration for each board !● Copy each .config to configs/bmi_modelX_defconfig file (X= A then B)

● That’s it !


Providing BR support for BMI boards

● As a board maker you just have to :– Tell to customer to get standard BR => you

don’t maintain a specific tool + BR is famous now

– Simply provide a patch to BR in order to add your products to Preset Devices list

– Patch will include everything added to standard BR

● As a customer you just have to :– Get standard BR + apply board maker patch

– Type make bmi_modelA_defconfig (or B) then type make

– Flash output/images/* files to the board :)


Why using Buildroot

● Stable, maintained by embedded Linux experts● For customers and board makers: ONE Interface

for ALL boards● Graphical GUI with make xconfig● Light and fast: get everything including toolchain

in 20/25 mn with standard Core 2 Duo PC, several hours for OE

● Should become (if not already) a standard in embedded Linux world


Questions?

pierre ficheux ([email protected]) cto open wide...

Documents