Scribd
Upload
37 views6 pages

Buildroot: Compiling Root Filesystem Only

Uploaded by

dungnt02121211
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as ODT, PDF, TXT or read online on Scribd
37 views6 pages

Buildroot: Compiling Root Filesystem Only

Uploaded by

dungnt02121211
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as ODT, PDF, TXT or read online on Scribd

Build root - make root FS only

Build root can help us to generate only a root file system:


We can use it to split our entire builds into separate builds in case we will need to make clean one of
them.
Sometimes we must do make clean because we added a package and we still got an error.
For example.
We add PNG support for QT5 after we already built the image.
We added libmount and blueZ after we have the image ready.
Those operation and many others in buildroot will require to to clean and make which will takes
time.
For example. We can seperate the kernel build and root file system into two separate directories and
each one will create the files we need.

When we build , for example raspberry pi 3 full image , we get:


two partitions , boot( as FAT16) and ext2,3 or 4 as we select

Suppose we want only to compile the root file system. The rootfs.ext4 and only that one to copy to
the image.

The steps can be as follow:


1. Do create a full image, compile your kernel , file system.
2. Copy that folder into a new folder , and remove everything related to kernel.
3. flash the rootfs.ext2 or 4 into the sd card only using dd command

This task of using rootfs buildroot only require a lot of attension because there are option that affect
the kernel , for example , when adding firmware options like bluetooth and wifii , it add drivers to
the kernel build, there for a kernel should be build again.

When building rootfs only really require that only rootfs related packages will be selected.
Before we start:
We want to use xconfig , for that we need to install QT 4

We need QT4 dev tools:


[Link]
04

sudo apt-get update


sudo apt-get install libqt4-dev pkg-config

or full:
sudo apt-get install -y build-essential kernel-package libncurses5-dev bzip2 bin86 qt4-
dev-tools wget libncurses5 git-core nautilus-open-terminal

I will start with the raspberry pi 3 defconfig , for the 32 bit arm
make raspberrypi3_defconfig
#
# configuration written to /home/first/buildroot/buildroot-2017.05/.config
#
it will copy the config to the current directory as .config
and this is the file make xconfig or make menuconfig will work on.

Run
make xconfig
and in kernel , uncheck the linux kernel-package

Two changes to build options:

for savedef config and a common place for the downloads.

We learned already how to build a compiler using crosstool-ng and


how to tell buildroot to use this compiler as external pre built compiler:
When I built the cross tool ng for arm hf compiler it was for 32 bit compiler.
It must match the settings of the buildroot
Some notes:

prefix is the name of the compiler without the -gcc or -g++, just the name
the path is without the bin directory

in hardware and handling

We should remove the rpi-firmware or any other firmware.


Why? As mentioned , the firmware are also drivers modules that are located in the linux kernel,
which we are not compiling now.
we are ready to start the build:

type
make

using external pre-build cross compile will save us about an hour in the build.

We can see how much time it takes:

[Link] the build duration (from buildroot manual)


make graph-build

see prerequisites in 8.9


[Link]

install python:
[Link]

install matplotlib
[Link]
The root fs file is about 63 mega:
rw-r--r-- 1 first first 62914560 Jun 2 01:17 output/images/rootfs.ext2

Using gparted ( sudo apt-get install gparted)


we can see the partitions on the sd card

At the end , we will have a rootfs.ext4 in output/images.


Buildroot will try to run the script that produce the entire image , but it will failed to find all the
files
We can ignore those error, what we need is only the the rootfs.ext4

ln -sf rootfs.ext2 /home/first/buildroot/blrpi3_32_extcompiler/buildroot-2017.05/output/images/


rootfs.ext4
>>> Executing post-image script board/raspberrypi3/[Link]
grep: /home/first/buildroot/blrpi3_32_extcompiler/buildroot-2017.05/output/images/rpi-firmware/
[Link]: No such file or directory
Adding 'dtoverlay=pi3-miniuart-bt' to [Link] (fixes ttyAMA0 serial console).
board/raspberrypi3/[Link]: 12: board/raspberrypi3/[Link]: cannot create
/home/first/buildroot/blrpi3_32_extcompiler/buildroot-2017.05/output/images/rpi-firmware/
[Link]: Directory nonexistent
file([Link]): stat(/home/first/buildroot/blrpi3_32_extcompiler/buildroot-2017.05/
output/images/[Link]) failed: No such file or directory
vfat([Link]): could not setup [Link]
make[1]: *** [target-post-image] Error 1
make: *** [_all] Error 2
first@eliaradfirst:~/buildroot/blrpi3_32_extcompiler/buildroot-2017.05$ ls
output/images/[Link]

using gpared we can see our previous disk image


the partition was created before when I did a full image build with buildroot.

Now lets copy using dd command , the file system that we built into the second partition and
replace the existing one:
If it is the first time, just create the two partitions using gparted.

let's move to output/images

sudo dd if=rootfs.ext4 of=/dev/sdb2

if = is the source
of = the destination

122880+0 records in
122880+0 records out
62914560 bytes (63 MB) copied, 52.5073 s, 1.2 MB/s

Suggestion to work flow:


* Create your entire image , with rootfs , kernel and boot files.
* Test it on your raspberry pi 3.
* now copy the buildroot directory into two directories.
1. Kernel
[Link]
In the kernel , just leave a kernel options checked.
In the root fs just leave rootfs options checked.

Common questions

Powered by AI

One strategy to minimize build times in Buildroot when cross-compiling is to use an external pre-built cross compiler. This can significantly reduce the build duration, saving about an hour . Additionally, managing build components separately, such as splitting the kernel and root file system into different directories, helps focus changes only on the necessary components and avoids unnecessary recompilation of the entire system . Utilizing tools like 'make graph-build' for tracking the build duration can provide insights for further optimization .

Specific errors during post-image script execution in Buildroot can include missing directories or files such as 'config.txt' or 'bcm2710-rpi-3-b.dtb', resulting in the script's failure to complete. These issues typically arise when the script attempts to access components that are not included in the current build configuration. Addressing these errors involves ensuring that all necessary components are specified in the build or adjusting the script to skip over or handle these missing parts without causing the build to fail .

The 'dd' command is essential in Buildroot projects for writing the generated root file system onto the Raspberry Pi's SD card. It performs a low-level copy of the file system (e.g., rootfs.ext4) from the Buildroot output images to the SD card's partition, effectively preparing the Raspberry Pi to boot from the newly built system. This step is crucial to test the newly compiled root file system in a real Raspberry Pi environment .

Challenges when using scripts in Buildroot include missing files and directories, leading to script executions failing, such as attempting to access non-existent firmware directories or config files. To mitigate these issues, ensure all necessary directories and files are in place before running the scripts, or modify the scripts to handle missing components gracefully. Ignoring non-critical errors involving files that are not required for the current build target can also prevent unnecessary build process interruptions .

Separating build directories for the kernel and the root file system allows for more efficient management of the build process in a Buildroot project. It enables focused changes on specific components without the need to rebuild the entire image when changes are made. For instance, if only the root file system needs updates, the kernel remains untouched, saving time and resources by avoiding redundant recompilations .

'Make xconfig' is a graphical configuration tool that facilitates customizing Buildroot build configurations. It provides an intuitive interface for selecting or deselecting packages, kernel options, and other settings. To use 'make xconfig', the QT4 development tools must be installed, which include libraries and tools necessary for its GUI. Correct setup of these prerequisites ensures 'make xconfig' functions optimally, enhancing ease in configuration management .

Installing Python and Matplotlib is necessary in the context of Buildroot for generating graphical representations of build durations using 'make graph-build'. These tools enable visualization of the time spent on different build components, helping identify bottlenecks and optimize the build process. Python provides the scripting environment, while Matplotlib offers the plotting capabilities essential for rendering these graphs .

To enable Bluetooth support in a Buildroot project for Raspberry Pi, one must add the Bluetooth firmware and related packages to the build configuration. This involves selecting the appropriate options related to Bluetooth in the Buildroot menu configuration (xconfig or menuconfig), ensuring that any kernel drivers required for Bluetooth are included. Modifications may require rebuilding the kernel to incorporate new drivers, emphasizing the need to segregate kernel and root FS builds to avoid unnecessary rebuilds .

Modifying firmware options can significantly impact the build process of a root file system in Buildroot as it adds drivers to the kernel build. As a result, any changes in firmware options require a recompilation of the kernel, even when the primary target is the root file system. Therefore, when building the root file system separately, it's crucial to ensure only rootfs related packages are selected to avoid unnecessary kernel recompilations .

Not matching the cross-compiler settings with Buildroot's configuration can lead to build failures and non-functional binaries. Buildroot relies on precise compiler configurations, such as architecture and other compiler-specific options, to ensure compatibility. Discrepancies may cause incompatibility issues, resulting in runtime errors or failing to produce the desired output. Therefore, it is crucial to align the cross-compiler settings with Buildroot's specifications to ensure successful builds .

You might also like