jeans/motioneyeos
jeans/motioneyeos
1
0
Fork 0
mirror of https://github.com/motioneye-project/motioneyeos.git synced 2025-07-30 06:36:34 +00:00
Code Issues Packages Projects Releases Wiki Activity

documentation: Update to explain how board support works

Browse Source 
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This commit is contained in:
Thomas Petazzoni 2010-12-05 21:52:45 +01:00 committed by Peter Korsgaard
parent beb43c7d26
commit 9460079914
1 changed files with 32 additions and 77 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

109
docs/buildroot.html
View File

@ -578,87 +578,42 @@ $(ZLIB_DIR)/libz.a: $(ZLIB_DIR)/.configured
<h2 id="board_support"> Creating your own board support</h2> <h2 id="board_support"> Creating your own board support</h2>
<p>Creating your own board support in Buildroot allows you to have <p>Creating your own board support in Buildroot allows users of a
a convenient place to store your project's target filesystem skeleton particular hardware platform to easily build a system that is
and configuration files for Buildroot, Busybox, uClibc, and the kernel. 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> <p>Once you have a known working configuration, run <code>make
<li>Create a new directory in <code>target/device/</code> named savedefconfig</code>. This will generate a
after your company or organization</li> 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 <p>It is recommended to use as much as possible upstream versions
"target/device/yourcompany/Config.in"</code> in of the Linux kernel and bootloaders, and to use as much as
<code>target/device/Config.in</code> so that your board appears possible default kernel and bootloader configurations. If they are
in the configuration system</li> 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 <p>However, in the mean time, you may want to store kernel or
directory for your project. This way, you'll be able to store bootloader configuration or patches specific to your target
several of your company's projects inside Buildroot.</li> platform. To do so, create a
directory <code>board/MANUFACTURER</code> and a
<li>Create a <code>target/device/yourcompany/Config.in</code> subdirectory <code>board/MANUFACTURER/BOARDNAME</code> (after
file that looks like the following: replacing, of course, MANUFACTURER and BOARDNAME with the
appropriate values, in lower case letters). You can then store
<pre> your patches and configurations in these directories, and
menuconfig BR2_TARGET_COMPANY reference them from the main Buildroot configuration.</p>
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>
<h2 id="using_toolchain">Using the generated toolchain outside Buildroot</h2> <h2 id="using_toolchain">Using the generated toolchain outside Buildroot</h2>