xref: /OK3568_Linux_fs/buildroot/docs/manual/adding-board-support.txt (revision 4882a59341e53eb6f0b4789bf948001014eff981)
1*4882a593Smuzhiyun// -*- mode:doc; -*-
2*4882a593Smuzhiyun// vim: set syntax=asciidoc:
3*4882a593Smuzhiyun
4*4882a593Smuzhiyun[[adding-board-support]]
5*4882a593Smuzhiyun== Adding support for a particular board
6*4882a593Smuzhiyun
7*4882a593SmuzhiyunBuildroot contains basic configurations for several publicly available
8*4882a593Smuzhiyunhardware boards, so that users of such a board can easily build a system
9*4882a593Smuzhiyunthat is known to work. You are welcome to add support for other boards
10*4882a593Smuzhiyunto Buildroot too.
11*4882a593Smuzhiyun
12*4882a593SmuzhiyunTo do so, you need to create a normal Buildroot configuration that
13*4882a593Smuzhiyunbuilds a basic system for the hardware: (internal) toolchain, kernel,
14*4882a593Smuzhiyunbootloader, filesystem and a simple BusyBox-only userspace. No specific
15*4882a593Smuzhiyunpackage should be selected: the configuration should be as minimal as
16*4882a593Smuzhiyunpossible, and should only build a working basic BusyBox system for the
17*4882a593Smuzhiyuntarget platform. You can of course use more complicated configurations
18*4882a593Smuzhiyunfor your internal projects, but the Buildroot project will only
19*4882a593Smuzhiyunintegrate basic board configurations. This is because package
20*4882a593Smuzhiyunselections are highly application-specific.
21*4882a593Smuzhiyun
22*4882a593SmuzhiyunOnce you have a known working configuration, run +make
23*4882a593Smuzhiyunsavedefconfig+. This will generate a minimal +defconfig+ file at the
24*4882a593Smuzhiyunroot of the Buildroot source tree. Move this file into the +configs/+
25*4882a593Smuzhiyundirectory, and rename it +<boardname>_defconfig+. If the configuration
26*4882a593Smuzhiyunis a bit more complicated, it is nice to manually reformat it and
27*4882a593Smuzhiyunseparate it into sections, with a comment before each section. Typical
28*4882a593Smuzhiyunsections are _Architecture_, _Toolchain options_ (typically just linux
29*4882a593Smuzhiyunheaders version), _Firmware_, _Bootloader_, _Kernel_, and _Filesystem_.
30*4882a593Smuzhiyun
31*4882a593SmuzhiyunAlways use fixed versions or commit hashes for the different
32*4882a593Smuzhiyuncomponents, not the "latest" version. For example, set
33*4882a593Smuzhiyun+BR2_LINUX_KERNEL_CUSTOM_VERSION=y+ and
34*4882a593Smuzhiyun+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE+ to the kernel version you tested
35*4882a593Smuzhiyunwith.
36*4882a593Smuzhiyun
37*4882a593SmuzhiyunIt is recommended to use as much as possible upstream versions of the
38*4882a593SmuzhiyunLinux kernel and bootloaders, and to use as much as possible default
39*4882a593Smuzhiyunkernel and bootloader configurations. If they are incorrect for your
40*4882a593Smuzhiyunboard, or no default exists, we encourage you to send fixes to the
41*4882a593Smuzhiyuncorresponding upstream projects.
42*4882a593Smuzhiyun
43*4882a593SmuzhiyunHowever, in the mean time, you may want to store kernel or bootloader
44*4882a593Smuzhiyunconfiguration or patches specific to your target platform. To do so,
45*4882a593Smuzhiyuncreate a directory +board/<manufacturer>+ and a subdirectory
46*4882a593Smuzhiyun+board/<manufacturer>/<boardname>+. You can then store your patches
47*4882a593Smuzhiyunand configurations in these directories, and reference them from the main
48*4882a593SmuzhiyunBuildroot configuration. Refer to xref:customize[] for more details.
49