documentation: Update to explain how board support works
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This commit is contained in:
parent
beb43c7d26
commit
9460079914
|
@ -578,87 +578,42 @@ $(ZLIB_DIR)/libz.a: $(ZLIB_DIR)/.configured
|
|||
|
||||
<h2 id="board_support"> Creating your own board support</h2>
|
||||
|
||||
<p>Creating your own board support in Buildroot allows you to have
|
||||
a convenient place to store your project's target filesystem skeleton
|
||||
and configuration files for Buildroot, Busybox, uClibc, and the kernel.
|
||||
<p>Creating your own board support in Buildroot allows users of a
|
||||
particular hardware platform to easily build a system that is
|
||||
known to work.</p>
|
||||
|
||||
<p>Follow these steps to integrate your board in Buildroot:</p>
|
||||
<p>To do so, you need to create a normal Buildroot configuration
|
||||
that builds a basic system for the hardware: toolchain, kernel,
|
||||
bootloader, filesystem and a simple Busybox-only userspace. No
|
||||
specific package should be selected: the configuration should be
|
||||
as minimal as possible, and should only build a working basic
|
||||
Busybox system for the target platform. You can of course use more
|
||||
complicated configurations for your internal projects, but the
|
||||
Buildroot project will only integrate basic board
|
||||
configurations. This is because package selections are highly
|
||||
application-specific.</p>
|
||||
|
||||
<ol>
|
||||
<li>Create a new directory in <code>target/device/</code> named
|
||||
after your company or organization</li>
|
||||
<p>Once you have a known working configuration, run <code>make
|
||||
savedefconfig</code>. This will generate a
|
||||
minimal <code>defconfig</code> file at the root of the Buildroot
|
||||
source tree. Move this file into the <code>configs/</code>
|
||||
directory, and rename it <code>MYBOARD_defconfig</code>.</p>
|
||||
|
||||
<li>Add a line <code>source
|
||||
"target/device/yourcompany/Config.in"</code> in
|
||||
<code>target/device/Config.in</code> so that your board appears
|
||||
in the configuration system</li>
|
||||
<p>It is recommended to use as much as possible upstream versions
|
||||
of the Linux kernel and bootloaders, and to use as much as
|
||||
possible default kernel and bootloader configurations. If they are
|
||||
incorrect for your platform, we encourage you to send fixes to the
|
||||
corresponding upstream projects.</p>
|
||||
|
||||
<li>In <code>target/device/yourcompany/</code>, create a
|
||||
directory for your project. This way, you'll be able to store
|
||||
several of your company's projects inside Buildroot.</li>
|
||||
|
||||
<li>Create a <code>target/device/yourcompany/Config.in</code>
|
||||
file that looks like the following:
|
||||
|
||||
<pre>
|
||||
menuconfig BR2_TARGET_COMPANY
|
||||
bool "Company projects"
|
||||
|
||||
if BR2_TARGET_COMPANY
|
||||
|
||||
config BR2_TARGET_COMPANY_PROJECT_FOOBAR
|
||||
bool "Support for Company project Foobar"
|
||||
help
|
||||
This option enables support for Company project Foobar
|
||||
|
||||
endif
|
||||
</pre>
|
||||
|
||||
Of course, you should customize the different values to match your
|
||||
company/organization and your project. This file will create a
|
||||
menu entry that contains the different projects of your
|
||||
company/organization.</li>
|
||||
|
||||
<li>Create a <code>target/device/yourcompany/Makefile.in</code>
|
||||
file that looks like the following:
|
||||
|
||||
<pre>
|
||||
ifeq ($(BR2_TARGET_COMPANY_PROJECT_FOOBAR),y)
|
||||
include target/device/yourcompany/project-foobar/Makefile.in
|
||||
endif
|
||||
</pre>
|
||||
|
||||
</li>
|
||||
|
||||
<li>Create the
|
||||
<code>target/device/yourcompany/project-foobar/Makefile.in</code>
|
||||
file. It is recommended that you define a
|
||||
<code>BOARD_PATH</code> variable set to
|
||||
<code>target/device/yourcompany/project-foobar</code> as it
|
||||
will simplify further definitions. Then, the file might define
|
||||
one or more of the following variables:
|
||||
<ul>
|
||||
<li><code>TARGET_SKELETON</code> to a directory that contains
|
||||
the target skeleton for your project. If this variable is
|
||||
defined, this target skeleton will be used instead of the
|
||||
default one. If defined, the convention is to define it to
|
||||
<code>$(BOARD_PATH)/target_skeleton</code> so that the target
|
||||
skeleton is stored in the board specific directory.</li>
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
<li>In the
|
||||
<code>target/device/yourcompany/project-foobar/</code>
|
||||
directory you can store configuration files for the kernel,
|
||||
Busybox or uClibc.
|
||||
|
||||
You can furthermore create one or more preconfigured configuration
|
||||
files, referencing those files. These config files are named
|
||||
<code>something_defconfig</code> and are stored in the toplevel
|
||||
<code>configs/</code> directory. Your users will then be able
|
||||
to run <code>make something_defconfig</code> and get the right
|
||||
configuration for your project</li>
|
||||
</ol>
|
||||
<p>However, in the mean time, you may want to store kernel or
|
||||
bootloader configuration or patches specific to your target
|
||||
platform. To do so, create a
|
||||
directory <code>board/MANUFACTURER</code> and a
|
||||
subdirectory <code>board/MANUFACTURER/BOARDNAME</code> (after
|
||||
replacing, of course, MANUFACTURER and BOARDNAME with the
|
||||
appropriate values, in lower case letters). You can then store
|
||||
your patches and configurations in these directories, and
|
||||
reference them from the main Buildroot configuration.</p>
|
||||
|
||||
<h2 id="using_toolchain">Using the generated toolchain outside Buildroot</h2>
|
||||
|
||||
|
|
Loading…
Reference in a new issue