diff --git a/docs/buildroot.html b/docs/buildroot.html index 8293c8fec3..9d6e835f67 100644 --- a/docs/buildroot.html +++ b/docs/buildroot.html @@ -578,87 +578,42 @@ $(ZLIB_DIR)/libz.a: $(ZLIB_DIR)/.configured
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. +
Creating your own board support in Buildroot allows users of a + particular hardware platform to easily build a system that is + known to work.
-Follow these steps to integrate your board in Buildroot:
+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.
-target/device/
named
- after your company or organizationOnce you have a known working configuration, run make
+ savedefconfig
. This will generate a
+ minimal defconfig
file at the root of the Buildroot
+ source tree. Move this file into the configs/
+ directory, and rename it MYBOARD_defconfig
.
source
- "target/device/yourcompany/Config.in"
in
- target/device/Config.in
so that your board appears
- in the configuration systemIt 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.
-target/device/yourcompany/
, create a
- directory for your project. This way, you'll be able to store
- several of your company's projects inside Buildroot.target/device/yourcompany/Config.in
- file that looks like the following:
-
--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 -- - 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.
target/device/yourcompany/Makefile.in
- file that looks like the following:
-
--ifeq ($(BR2_TARGET_COMPANY_PROJECT_FOOBAR),y) -include target/device/yourcompany/project-foobar/Makefile.in -endif -- -
target/device/yourcompany/project-foobar/Makefile.in
- file. It is recommended that you define a
- BOARD_PATH
variable set to
- target/device/yourcompany/project-foobar
as it
- will simplify further definitions. Then, the file might define
- one or more of the following variables:
- TARGET_SKELETON
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
- $(BOARD_PATH)/target_skeleton
so that the target
- skeleton is stored in the board specific directory.target/device/yourcompany/project-foobar/
- 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
- something_defconfig
and are stored in the toplevel
- configs/
directory. Your users will then be able
- to run make something_defconfig
and get the right
- configuration for your projectHowever, 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 board/MANUFACTURER
and a
+ subdirectory board/MANUFACTURER/BOARDNAME
(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.