documentation: Update to explain how board support works

    <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>Follow these steps to integrate your board in Buildroot:</p>

    <ol>

      <li>Create a new directory in <code>target/device/</code> named

      after your company or organization</li>

      <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>

      <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>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>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>

    <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>

    <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>

    <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>