Roll Your Own Embedded Linux System with Buildroot
When you gain enough experience with Buildroot and decide you are brave enough to modify some of the uClibc, BusyBox and/or kernel parameters, the way to do it is to compile Buildroot with default settings for all three, and after that, run the following commands to modify the parameters and eventually recompile everything:
make uclibc-menuconfig make busybox-menuconfig make linux26-menuconfig
Note that the last one will work only after you enable the Linux kernel option in the main Buildroot configuration menu. Chances are that you already know how to configure the kernel, and uClibc configuration rarely requires tweaking, unless you want to compile out some functionality in order to save memory, so I'm going to look at BusyBox configuration only.
The BusyBox menu can be divided into settings and applets. I concentrate on the latter, as that's probably what you would want to modify first. Applets are applications in BusyBox parlance, with one small difference. In order to save space, BusyBox usually is installed as a single binary that includes all the utilities you decided to compile: shell, ping, gzip and so on. You can launch an individual applet either by giving its name as an argument to BusyBox—busybox ping, for instance—or you can create a symbolic link, ln -s /bin/ping /bin/busybox, and BusyBox will choose the correct applet automatically, depending on the link from which it was executed. BusyBox installation automatically creates links for all the compiled applets. If you are curious, you can run it without any parameters to see what applets were compiled in. You should have no difficulty in choosing the right set of applets for your project. The only thing worth mentioning is the shell. BusyBox does not support standard shells such as bash or tcsh; instead, you get to choose between ash, hush and msh with ash being the closest to bash and the one I always work with. Note that even though standard bash is not part of BusyBox, it is supported by Buildroot if you need it.
When you are finished configuring your embedded system, run make to compile everything. Now you are ready to program your newly compiled kernel and filesystem images to your board and boot. Actual Flash programming depends on your system, bootloader, type of Flash and so on, and it is beyond the scope of this article.
If you want to compile your own applications, you can (and should) use the toolchain created by Buildroot. You can get (or build) a different toolchain, but if it is not based on uClibc or if it was compiled with different kernel headers, it may not work. All you have to do in order to use the Buildroot toolchain is add the output/staging/usr/bin/ directory to your path and then simply run arm-linux-uclibcgnueabi-gcc.
The important point to remember is that Buildroot is not fool-proof in the sense that it is relatively easy to create a configuration that won't work or even compile. You should not expect every parameter combination to work, and always keep your last working configuration file. The upside is that there is a large and active community behind this project, which will be happy to help.
BSP stands for Board Support Package. The term is somehow associated with RTOSes, such as VxWorks. Therefore, some people prefer the more “politically correct” LSP (Linux Support Package). Anyhow, the BSP is a set of usually small kernel and bootloader modifications specific to your hardware. Intel x86 developers take for granted that all x86 systems have the same basic hardware and peripheral interface, which is not the case on embedded systems. BSP development usually includes fixing memory mappings, configuring interrupt controllers and development of at least the following basic drivers: serial (for console), network and Flash.
An Application Binary Interface (ABI) describes the low-level interface between an application and an operating system and hardware. ARM Linux supports Old ABI (OABI) and Embedded ABI (EABI). OABI is deprecated, and it is recommended that you use EABI. As this parameter affects the kernel, the compiler and the standard libraries, it is important to use the same ABI everywhere, even though mixing ABIs may be supported. Compared to OABI, EABI defines a more-efficient system call convention, improves floating-point performance, changes structure packing, removes the minimal four-byte size limitation and some other minor improvements.