rpi/domo
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Bump buildroot to version 2017-02

Browse Source 
TG-3 #closed
This commit is contained in:
jbnadal
2017-03-28 18:29:16 +02:00
parent 93b7fd91d2
commit 42c92a6bcb
3010 changed files with 41289 additions and 46428 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
bsp/buildroot/docs/manual/adding-packages-asciidoc.txt
View File

@@ -19,9 +19,9 @@ Although Buildroot only contains one document written in AsciiDoc, there
is, as for packages, an infrastructure for rendering documents using the
AsciiDoc syntax.
Also as for packages, the AsciiDoc infrastructure is available from
xref:outside-br-custom[BR2_EXTERNAL]. This allows documentation for a
BR2_EXTERNAL tree to match the Buildroot documentation, as it will be
Also as for packages, the AsciiDoc infrastructure is available from a
xref:outside-br-custom[br2-external tree]. This allows documentation for
a br2-external tree to match the Buildroot documentation, as it will be
rendered to the same formats and use the same layout and theme.
==== +asciidoc-document+ tutorial
@@ -63,6 +63,11 @@ information is (assuming the document name is +foo+) :
to one or more directories containing so-called resources (like CSS or
images). By default, empty.
* +FOO_DEPENDENCIES+, optional, the list of packages (most probably,
host-packages) that must be built before building this document.
If a hook of your document needs to access the _Kconfig_ structure,
you may add +prepare-kconfig+ to the list of dependencies.
There are also additional hooks (see xref:hooks[] for general information
on hooks), that a document may set to define extra actions to be done at
various steps:

5
bsp/buildroot/docs/manual/adding-packages-directory.txt
View File

@@ -7,7 +7,7 @@ First of all, create a directory under the +package+ directory for
your software, for example +libfoo+.
Some packages have been grouped by topic in a sub-directory:
+x11r7+, +efl+ and +matchbox+. If your package fits in
+x11r7+, +qt5+ and +gstreamer+. If your package fits in
one of these categories, then create your package directory in these.
New subdirectories are discouraged, however.
@@ -384,9 +384,6 @@ openGL libraries.
See xref:virtual-package-tutorial[] for more on the virtual packages.
See xref:virtual-package-list[] for the symbols to depend on if your package
depends on a feature provided by a virtual package.
=== The +.mk+ file
[[adding-packages-mk]]

22
bsp/buildroot/docs/manual/adding-packages-generic.txt
View File

@@ -250,6 +250,13 @@ information is (assuming the package name is +libfoo+) :
+LIBFOO_SITE=/opt/software/libfoo.tar.gz+ +
+LIBFOO_SITE=$(TOPDIR)/../src/libfoo+
* +LIBFOO_DL_OPTS+ is a space-separated list of additional options to
pass to the downloader. Useful for retrieving documents with
server-side checking for user logins and passwords, or to use a proxy.
All download methods valid for +LIBFOO_SITE_METHOD+ are supported;
valid options depend on the download method (consult the man page
for the respective download utilities).
* +LIBFOO_EXTRA_DOWNLOADS+ is a space-separated list of additional
files that Buildroot should download. If an entry contains +://+
then Buildroot will assume it is a complete URL and will download
@@ -310,11 +317,12 @@ information is (assuming the package name is +libfoo+) :
the package source code. Buildroot copies the contents of the
source directory into the package's build directory.
* +LIBFOO_GIT_SUBMODULES+, when +LIBFOO_SITE_METHOD=git+, will create
an archive with the git submodules in the repository.
Note that we try not to use such git submodules when they contain
bundled libraries, in which case we prefer to use those libraries
from their own package.
* +LIBFOO_GIT_SUBMODULES+ can be set to +YES+ to create an archive
with the git submodules in the repository. This is only available
for packages downloaded with git (i.e. when
+LIBFOO_SITE_METHOD=git+). Note that we try not to use such git
submodules when they contain bundled libraries, in which case we
prefer to use those libraries from their own package.
* +LIBFOO_STRIP_COMPONENTS+ is the number of leading components
(directories) that tar must strip from file names on extraction.
@@ -521,8 +529,8 @@ endef
In the action definitions, you can use the following variables:
* +$(FOO_PKGDIR)+ contains the path to the directory containing the
+foo.mk+ and +Config.in+ files. This variable is useful when it is
* +$(LIBFOO_PKGDIR)+ contains the path to the directory containing the
+libfoo.mk+ and +Config.in+ files. This variable is useful when it is
necessary to install a file bundled in Buildroot, like a runtime
configuration file, a splashscreen image...

6
bsp/buildroot/docs/manual/adding-packages-kconfig.txt
View File

@@ -75,3 +75,9 @@ be set to suit the needs of the package under consideration:
configuration file after copying it or running a kconfig editor. Such
commands may be needed to ensure a configuration consistent with other
configuration of Buildroot, for example. By default, empty.
* +FOO_KCONFIG_DOTCONFIG+: path (with filename) of the +.config+ file,
relative to the package source tree. The default, +.config+, should
be well suited for all packages that use the standard kconfig
infrastructure as inherited from the Linux kernel; some packages use
a derivative of kconfig that use a different location.

49
bsp/buildroot/docs/manual/adding-packages-linux-kernel-spec-infra.txt
View File

@@ -12,33 +12,36 @@ hooks for building Linux kernel tools or/and building Linux kernel extensions.
Buildroot offers a helper infrastructure to build some userspace tools
for the target available within the Linux kernel sources. Since their
source code is part of the kernel source code, it is not very
practical to use separate packages for them as they often need to be
built with the same kernel version as the kernel being used on the
target. The small Linux kernel tools infrastructure is a simplified
packaging mechanism based on the generic package infrastructure to
help building those tools.
source code is part of the kernel source code, a special package,
+linux-tools+, exists and re-uses the sources of the Linux kernel that
runs on the target.
Let's look at an example of a Linux tool. For a new Linux tool named
+foo+, create a new menu entry in the existing
+linux/Config.tools.in+. This file will contain the option
+package/linux-tools/Config.in+. This file will contain the option
descriptions related to each kernel tool that will be used and
displayed in the configuration tool. It would basically look like:
------------------------------
01: config BR2_LINUX_KERNEL_TOOL_FOO
01: config BR2_PACKAGE_LINUX_TOOLS_FOO
02: bool "foo"
03: help
04: This is a comment that explains what foo kernel tool is.
05:
06: http://foosoftware.org/foo/
03: select BR2_PACKAGE_LINUX_TOOLS
04: help
05: This is a comment that explains what foo kernel tool is.
06:
07: http://foosoftware.org/foo/
------------------------------
The name of the option starts with the prefix +BR2_LINUX_KERNEL_TOOL_+,
The name of the option starts with the prefix +BR2_PACKAGE_LINUX_TOOLS_+,
followed by the uppercase name of the tool (like is done for packages).
Then for each linux tool, add a new +.mk+ file named +linux/linux-tool-foo.mk+.
It would basically look like:
.Note
Unlike other packages, the +linux-tools+ package options appear in the
+linux+ kernel menu, under the `Linux Kernel Tools` sub-menu, not under
the `Target packages` main menu.
Then for each linux tool, add a new +.mk+ file named
+package/linux-tools/linux-tool-foo.mk+. It would basically look like:
------------------------------
01: ################################################################################
@@ -52,19 +55,19 @@ It would basically look like:
09: FOO_DEPENDENCIES = libbbb
10:
11: define FOO_BUILD_CMDS
12: $(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/tools foo
12: $(TARGET_MAKE_ENV) $(MAKE) -C $(LINUX_DIR)/tools foo
13: endef
14:
15: define FOO_INSTALL_STAGING_CMDS
16: $(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/tools \
17: DESTDIR=$(STAGING_DIR) \
18: foo_install
16: $(TARGET_MAKE_ENV) $(MAKE) -C $(LINUX_DIR)/tools \
17: DESTDIR=$(STAGING_DIR) \
18: foo_install
19: endef
20:
21: define FOO_INSTALL_TARGET_CMDS
22: $(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/tools \
23: DESTDIR=$(@D) \
24: foo_install
22: $(TARGET_MAKE_ENV) $(MAKE) -C $(LINUX_DIR)/tools \
23: DESTDIR=$(TARGET_DIR) \
24: foo_install
25: endef
--------------------------------
@@ -84,7 +87,7 @@ used only when the +foo+ tool is selected. The only supported commands are
.Note
One *must not* call +$(eval $(generic-package))+ or any other
package infrastructure! Linux tools are not packages by themselves,
they are part of the +linux+ package.
they are part of the +linux-tools+ package.
[[linux-kernel-ext]]
==== linux-kernel-extensions

13
bsp/buildroot/docs/manual/adding-packages-perl.txt
View File

@@ -47,7 +47,7 @@ built.
Most of these data can be retrieved from https://metacpan.org/.
So, this file and the Config.in can be generated by running
the script +supports/scripts/scancpan Foo-Bar+ in the Buildroot directory
(or in the +BR2_EXTERNAL+ directory).
(or in a br2-external tree).
This script creates a Config.in file and foo-bar.mk file for the
requested package, and also recursively for all dependencies specified by
CPAN. You should still manually edit the result. In particular, the
@@ -68,8 +68,8 @@ As a policy, packages that provide Perl/CPAN modules should all be
named +perl-<something>+ in Buildroot.
This infrastructure handles various Perl build systems :
+ExtUtils-MakeMaker+, +Module-Build+ and +Module-Build-Tiny+.
+Build.PL+ is always preferred when a package provides a +Makefile.PL+
+ExtUtils-MakeMaker+ (EUMM), +Module-Build+ (MB) and +Module-Build-Tiny+.
+Build.PL+ is preferred by default when a package provides a +Makefile.PL+
and a +Build.PL+.
The main macro of the Perl/CPAN package infrastructure is
@@ -97,6 +97,13 @@ A few additional variables, specific to the Perl/CPAN infrastructure,
can also be defined. Many of them are only useful in very specific
cases, typical packages will therefore only use a few of them.
* +PERL_FOO_PREFER_INSTALLER+/+HOST_PERL_FOO_PREFER_INSTALLER+,
specifies the preferred installation method. Possible values are
+EUMM+ (for +Makefile.PL+ based installation using
+ExtUtils-MakeMaker+) and +MB+ (for +Build.PL+ based installation
using +Module-Build+). This variable is only used when the package
provides both installation methods.
* +PERL_FOO_CONF_ENV+/+HOST_PERL_FOO_CONF_ENV+, to specify additional
environment variables to pass to the +perl Makefile.PL+ or +perl Build.PL+.
By default, empty.

8
bsp/buildroot/docs/manual/adding-packages-python.txt
View File

@@ -178,7 +178,7 @@ your host.
When at the root of your buildroot directory just do :
-----------------------
./support/script/scanpypi foo bar -o package
./support/scripts/scanpypi foo bar -o package
-----------------------
This will generate packages +python-foo+ and +python-bar+ in the package
@@ -195,10 +195,10 @@ license and license files are guessed and must be checked. You also
need to manually add the package to the +package/Config.in+ file.
If your Buildroot package is not in the official Buildroot tree but in
a +BR2_EXTERNAL+ tree, use the -o flag as follows:
a br2-external tree, use the -o flag as follows:
-----------------------
./support/script/scanpypi foo bar -o other_package_dir
./support/scripts/scanpypi foo bar -o other_package_dir
-----------------------
This will generate packages +python-foo+ and +python-bar+ in the
@@ -207,7 +207,7 @@ This will generate packages +python-foo+ and +python-bar+ in the
Option +-h+ will list the available options:
-----------------------
./support/script/scanpypi -h
./support/scripts/scanpypi -h
-----------------------
[[python-package-cffi-backend]]

6
bsp/buildroot/docs/manual/adding-packages-virtual.txt
View File

@@ -83,9 +83,6 @@ On line 3, we select +BR2_PACKAGE_HAS_SOMETHING_VIRTUAL+, and on line 11, we
set the value of +BR2_PACKAGE_PROVIDES_SOMETHING_VIRTUAL+ to the name of the
provider, but only if it is selected.
See xref:virtual-package-list[] for the symbols to select if you implement
a new provider for an existing virtual package.
==== Provider's +.mk+ file
The +.mk+ file should also declare an additional variable
@@ -99,9 +96,6 @@ packages it is an implementation of:
Of course, do not forget to add the proper build and runtime dependencies for
this package!
See xref:virtual-package-list[] for the names of virtual packages to provide
if you implement a new provider for an existing virtual package.
==== Notes on depending on a virtual package
When adding a package that requires a certain +FEATURE+ provided by a virtual

85
bsp/buildroot/docs/manual/adding-packages-waf.txt Normal file
View File

@@ -0,0 +1,85 @@
// -*- mode:doc; -*-
// vim: set syntax=asciidoc:
=== Infrastructure for Waf-based packages
[[waf-package-tutorial]]
==== +waf-package+ tutorial
First, let's see how to write a +.mk+ file for a Waf-based package, with
an example :
------------------------
01: ################################################################################
02: #
03: # libfoo
04: #
05: ################################################################################
06:
07: LIBFOO_VERSION = 1.0
08: LIBFOO_SOURCE = libfoo-$(LIBFOO_VERSION).tar.gz
09: LIBFOO_SITE = http://www.foosoftware.org/download
10: LIBFOO_CONF_OPTS = --enable-bar --disable-baz
11: LIBFOO_DEPENDENCIES = bar
12:
13: $(eval $(waf-package))
------------------------
On line 7, we declare the version of the package.
On line 8 and 9, we declare the name of the tarball (xz-ed tarball
recommended) and the location of the tarball on the Web. Buildroot
will automatically download the tarball from this location.
On line 10, we tell Buildroot what options to enable for libfoo.
On line 11, we tell Buildroot the depednencies of libfoo.
Finally, on line line 13, we invoke the +waf-package+
macro that generates all the Makefile rules that actually allows the
package to be built.
[[waf-package-reference]]
==== +waf-package+ reference
The main macro of the Waf package infrastructure is +waf-package+.
It is similar to the +generic-package+ macro.
Just like the generic infrastructure, the Waf infrastructure works
by defining a number of variables before calling the +waf-package+
macro.
First, all the package metadata information variables that exist in
the generic infrastructure also exist in the Waf infrastructure:
+LIBFOO_VERSION+, +LIBFOO_SOURCE+, +LIBFOO_PATCH+, +LIBFOO_SITE+,
+LIBFOO_SUBDIR+, +LIBFOO_DEPENDENCIES+, +LIBFOO_INSTALL_STAGING+,
+LIBFOO_INSTALL_TARGET+.
An additional variable, specific to the Waf infrastructure, can
also be defined.
* +LIBFOO_NEEDS_EXTERNAL_WAF+ can be set to +YES+ or +NO+ to tell
Buildroot to use the bundled +waf+ executable. If set to +NO+, the
default, then Buildroot will use the waf executable provided in the
package source tree; if set to +YES+, then Buidlroot will download,
install waf as a host tool and use it to build the package.
* +LIBFOO_WAF_OPTS+, to specify additional options to pass to the
+waf+ script at every step of the package build process: configure,
build and installation. By default, empty.
* +LIBFOO_CONF_OPTS+, to specify additional options to pass to the
+waf+ script for the configuration step. By default, empty.
* +LIBFOO_BUILD_OPTS+, to specify additional options to pass to the
+waf+ script during the build step. By default, empty.
* +LIBFOO_INSTALL_STAGING_OPTS+, to specify additional options to pass
to the +waf+ script during the staging installation step. By default,
empty.
* +LIBFOO_INSTALL_TARGET_OPTS+, to specify additional options to pass
to the +waf+ script during the target installation step. By default,
empty.

2
bsp/buildroot/docs/manual/adding-packages.txt
View File

@@ -29,6 +29,8 @@ include::adding-packages-kconfig.txt[]
include::adding-packages-rebar.txt[]
include::adding-packages-waf.txt[]
include::adding-packages-kernel-module.txt[]
include::adding-packages-asciidoc.txt[]

38
bsp/buildroot/docs/manual/appendix.txt
View File

@@ -3,40 +3,4 @@
include::makedev-syntax.txt[]
include::makeusers-syntax.txt[]
// Automatically generated lists:
[[package-list]]
== List of target packages available in Buildroot
include::package-list.txt[]
[[virtual-package-list]]
== List of virtual packages
These are the virtual packages known to +Buildroot+, with the
corresponding symbols and providers.
include::virtual-package-list.txt[]
[[host-package-list]]
== List of host utilities available in Buildroot
The following packages are all available in the menu +Host utilities+.
include::host-package-list.txt[]
[[deprecated-list]]
== Deprecated features
The following features are marked as _deprecated_ in Buildroot due to
them being either too old or unmaintained. They will be removed at
some point, so stop using them.
Each deprecated symbol in kconfig depends on a symbol
+BR2_DEPRECATED_SINCE_xxxx_xx+, which provides an indication of when
the feature can be removed: features will not be removed within the
year following deprecation. For example, a symbol depending on
+BR2_DEPRECATED_SINCE_2013_05+ can be removed from 2014.05 onwards.
include::deprecated-list.txt[]
include::br2-external-converting.txt[]

39
bsp/buildroot/docs/manual/br2-external-converting.txt Normal file
View File

@@ -0,0 +1,39 @@
// -*- mode:doc; -*-
// vim: set syntax=asciidoc:
[[br2-external-converting]]
== Converting old br2-external trees
Before Buildroot 2016.11, it was possible to use only one br2-external
tree at once. With Buildroot 2016.11 came the possibility to use more
than one simultaneously (for details, see xref:outside-br-custom[]).
This however means that older br2-external trees are not usable as-is.
A minor change has to be made: adding a name to your br2-external tree.
This can be done very easily in just a few steps:
* First, create a new file named +external.desc+, at the root of your
br2-external tree, with a single line defining the name of your
br2-external tree:
+
----
$ echo 'name: NAME_OF_YOUR_TREE' >external.desc
----
+
.Note
Be careful when choosing a name: It has to be unique and be made
with only ASCII characters from the set +[A-Za-z0-9_]+.
* Then, change every occurence of +BR2_EXTERNAL+ in your br2-external
tree with the new variable:
+
----
$ find . -type f | xargs sed -i 's/BR2_EXTERNAL/BR2_EXTERNAL_NAME_OF_YOUR_TREE_PATH/g'
----
Now, your br2-external tree can be used with Buildroot 2016.11 onward.
.Note:
This change makes your br2-external tree incompatible with Buildroot
before 2016.11.

5
bsp/buildroot/docs/manual/common-usage.txt
View File

@@ -91,8 +91,9 @@ to +make+ or set in the environment:
Buildroot stores/retrieves downloaded files
+
Note that the Buildroot download directory can also be set from the
configuration interface, so through the Buildroot +.config+ file; this
is the recommended way of setting it.
configuration interface, so through the Buildroot +.config+ file. See
xref:download-location[] for more details on how you can set the download
directory.
* +BR2_GRAPH_ALT+, if set and non-empty, to use an alternate color-scheme in
build-time graphs
* +BR2_GRAPH_OUT+ to set the filetype of generated graphs, either +pdf+ (the

4
bsp/buildroot/docs/manual/configure.txt
View File

@@ -31,7 +31,7 @@ code for your system. It consists of a compiler (in our case, +gcc+),
binary utils like assembler and linker (in our case, +binutils+) and a
C standard library (for example
http://www.gnu.org/software/libc/libc.html[GNU Libc],
http://www.uclibc.org/[uClibc]).
http://www.uclibc-ng.org/[uClibc-ng]).
The system installed on your development station certainly already has
a compilation toolchain that you can use to compile an application
@@ -81,7 +81,7 @@ by itself a cross-compilation toolchain, before building the userspace
applications and libraries for your target embedded system.
This backend supports several C libraries:
http://www.uclibc.org[uClibc],
http://www.uclibc-ng.org[uClibc-ng],
http://www.gnu.org/software/libc/libc.html[glibc] and
http://www.musl-libc.org[musl].

19
bsp/buildroot/docs/manual/contribute.txt
View File

@@ -258,6 +258,12 @@ removed, preferably with the upstream commit ID. Also any other
required changes should be explained explicitly, like configure
options that no longer exist or are no longer needed.
If you are interested in getting notified of build failures and of
further changes in the packages you added or modified, please add
yourself to the DEVELOPERS file. This should be done in a separate
patch of the series. See xref:DEVELOPERS[the DEVELOPERS file] for more
information.
==== Preparing a patch series
Starting from the changes committed in your local git view, _rebase_
@@ -283,10 +289,19 @@ automatically adding the +Signed-off-by+ line.
Once patch files are generated, you can review/edit the commit message
before submitting them, using your favorite text editor.
Lastly, send/submit your patch set to the Buildroot mailing list:
Buildroot provides a handy tool to know to whom your patches should be
sent, called +get-developers+ (see xref:DEVELOPERS[] for more
information). This tool reads your patches and outputs the appropriate
+git send-email+ command to use:
---------------------
$ git send-email --to buildroot@buildroot.org outgoing/*
$ ./support/scripts/get-developers outgoing/*
---------------------
Use the output of +get-developers+ to send your patches:
---------------------
$ git send-email --to buildroot@buildroot.org --cc bob --cc alice outgoing/*
---------------------
Note that +git+ should be configured to use your mail account.

13
bsp/buildroot/docs/manual/customize-directory-structure.txt
View File

@@ -13,7 +13,8 @@ section.
Orthogonal to this directory structure, you can choose _where_ you place
this structure itself: either inside the Buildroot tree, or outside of
it using +BR2_EXTERNAL+. Both options are valid, the choice is up to you.
it using a br2-external tree. Both options are valid, the choice is up
to you.
-----
+-- board/
@@ -38,8 +39,8 @@ it using +BR2_EXTERNAL+. Both options are valid, the choice is up to you.
|
+-- package/
| +-- <company>/
| +-- Config.in (if not using BR2_EXTERNAL)
| +-- <company>.mk (if not using BR2_EXTERNAL)
| +-- Config.in (if not using a br2-external tree)
| +-- <company>.mk (if not using a br2-external tree)
| +-- package1/
| | +-- Config.in
| | +-- package1.mk
@@ -47,14 +48,14 @@ it using +BR2_EXTERNAL+. Both options are valid, the choice is up to you.
| +-- Config.in
| +-- package2.mk
|
+-- Config.in (if using BR2_EXTERNAL)
+-- external.mk (if using BR2_EXTERNAL)
+-- Config.in (if using a br2-external tree)
+-- external.mk (if using a br2-external tree)
------
Details on the files shown above are given further in this chapter.
Note: if you choose to place this structure outside of the Buildroot
tree using +BR2_EXTERNAL+, the <company> and possibly <boardname>
tree but in a br2-external tree, the <company> and possibly <boardname>
components may be superfluous and can be left out.
==== Implementing layered customizations

338
bsp/buildroot/docs/manual/customize-outside-br.txt
View File

@@ -11,99 +11,303 @@ place project-specific customizations in two locations:
branches in a version control system so that upgrading to a newer
Buildroot release is easy.
* outside of the Buildroot tree, using the +BR2_EXTERNAL+ mechanism.
* outside of the Buildroot tree, using the _br2-external_ mechanism.
This mechanism allows to keep package recipes, board support and
configuration files outside of the Buildroot tree, while still
having them nicely integrated in the build logic. This section
explains how to use +BR2_EXTERNAL+.
having them nicely integrated in the build logic. We call this
location a _br2-external tree_. This section explains how to use
the br2-external mechanism and what to provide in a br2-external
tree.
+BR2_EXTERNAL+ is an environment variable that can be used to point to
a directory that contains Buildroot customizations. It can be passed
to any Buildroot +make+ invocation. It is automatically saved in the
hidden +.br-external+ file in the output directory. Thanks to this,
there is no need to pass +BR2_EXTERNAL+ at every +make+ invocation. It
can however be changed at any time by passing a new value, and can be
removed by passing an empty value.
One can tell Buildroot to use one or more br2-external trees by setting
the +BR2_EXTERNAL+ make variable set to the path(s) of the br2-external
tree(s) to use. It can be passed to any Buildroot +make+ invocation. It
is automatically saved in the hidden +.br-external.mk+ file in the output
directory. Thanks to this, there is no need to pass +BR2_EXTERNAL+ at
every +make+ invocation. It can however be changed at any time by
passing a new value, and can be removed by passing an empty value.
.Note
The +BR2_EXTERNAL+ path can be either an absolute or a relative path,
but if it's passed as a relative path, it is important to note that it
is interpreted relative to the main Buildroot source directory, *not*
to the Buildroot output directory.
The path to a br2-external tree can be either absolute or relative.
If it is passed as a relative path, it is important to note that it is
interpreted relative to the main Buildroot source directory, *not* to
the Buildroot output directory.
.Note:
If using an br2-external tree from before Buildroot 2016.11, you need to
convert it before you can use it with Buildroot 2016.11 onward. See
xref:br2-external-converting[] for help on doing so.
Some examples:
-----
buildroot/ $ make BR2_EXTERNAL=/path/to/foobar menuconfig
buildroot/ $ make BR2_EXTERNAL=/path/to/foo menuconfig
-----
From now on, external definitions from the +/path/to/foobar+
directory will be used:
From now on, definitions from the +/path/to/foo+ br2-external tree
will be used:
-----
buildroot/ $ make
buildroot/ $ make legal-info
-----
We can switch to another external definitions directory at any time:
We can switch to another br2-external tree at any time:
-----
buildroot/ $ make BR2_EXTERNAL=/where/we/have/barfoo xconfig
buildroot/ $ make BR2_EXTERNAL=/where/we/have/bar xconfig
-----
Or disable the usage of external definitions:
We can also use multiple br2-external trees:
----
buildroot/ $ make BR2_EXTERNAL=/path/to/foo:/where/we/have/bar menuconfig
----
Or disable the usage of any br2-external tree:
-----
buildroot/ $ make BR2_EXTERNAL= xconfig
-----
+BR2_EXTERNAL+ allows three different things:
==== Layout of a br2-external tree
* One can store all the board-specific configuration files there,
such as the kernel configuration, the root filesystem overlay, or
any other configuration file for which Buildroot allows to set its
location. The +BR2_EXTERNAL+ value is available within the
Buildroot configuration using +$(BR2_EXTERNAL)+. As an example, one
could set the +BR2_ROOTFS_OVERLAY+ Buildroot option to
+$(BR2_EXTERNAL)/board/<boardname>/overlay/+ (to specify a root
filesystem overlay), or the +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE+
Buildroot option to
+$(BR2_EXTERNAL)/board/<boardname>/kernel.config+ (to specify the
location of the kernel configuration file).
A br2-external tree must contain at least those three files, described
in the following chapters:
* One can store package recipes (i.e. +Config.in+ and
+<packagename>.mk+), or even custom configuration options and make
logic. Buildroot automatically includes +$(BR2_EXTERNAL)/Config.in+ to
make it appear in the top-level configuration menu, and includes
+$(BR2_EXTERNAL)/external.mk+ with the rest of the makefile logic.
+
.Note
Providing +Config.in+ and +external.mk+ is mandatory, but they can be
empty.
+
The main usage of this is to store package recipes. The recommended
way to do this is to write a +$(BR2_EXTERNAL)/Config.in+ file that
looks like:
+
------
source "$BR2_EXTERNAL/package/package1/Config.in"
source "$BR2_EXTERNAL/package/package2/Config.in"
------
+
Then, have a +$(BR2_EXTERNAL)/external.mk+ file that looks like:
+
------
include $(sort $(wildcard $(BR2_EXTERNAL)/package/*/*.mk))
------
+
And then in +$(BR2_EXTERNAL)/package/package1+ and
+$(BR2_EXTERNAL)/package/package2+ create normal Buildroot
package recipes, as explained in xref:adding-packages[].
If you prefer, you can also group the packages in subdirectories
called <boardname> and adapt the above paths accordingly.
* +external.desc+
* +external.mk+
* +Config.in+
* One can store Buildroot defconfigs in the +configs+ subdirectory of
+$(BR2_EXTERNAL)+. Buildroot will automatically show them in the
output of +make list-defconfigs+ and allow them to be loaded with the
normal +make <name>_defconfig+ command. They will be visible under the
+User-provided configs+' label in the 'make list-defconfigs' output.
Apart from those mandatory files, there may be additional and optional
content that may be present in a br2-external tree, like the +configs/+
directory. They are described in the following chapters as well.
A complete example br2-external tree layout is also described later.
===== The +external.desc+ file
That file describes the br2-external tree: the _name_ and _description_
for that br2-external tree.
The format for this file is line based, with each line starting by a
keyword, followed by a colon and one or more spaces, followed by the
value assigned to that keyword. There are two keywords currently
recognised:
* +name+, mandatory, defines the name for that br2-external tree. That
name must only use ASCII characters in the set +[A-Za-z0-9_]+; any
other character is forbidden. Buildroot sets the variable
+BR2_EXTERNAL_$(NAME)_PATH+ to the absolute path of the br2-external
tree, so that you can use it to refer to your br2-external tree. This
variable is available both in Kconfig, so you can use it to source your
Kconfig files (see below) and in the Makefile, so that you can use it
to include other Makefiles (see below) or refer to other files (like
data files) from your br2-external tree.
+
.Note:
Since it is possible to use multiple br2-external trees at once, this
name is used by Buildroot to generate variables for each of those trees.
That name is used to identify your br2-external tree, so try to come up
with a name that really describes your br2-external tree, in order for
it to be relatively unique, so that it does not clash with another name
from another br2-external tree, especially if you are planning on
somehow sharing your br2-external tree with third parties or using
br2-external trees from third parties.
* +desc+, optional, provides a short description for that br2-external
tree. It shall fit on a single line, is mostly free-form (see below),
and is used when displaying information about a br2-external tree (e.g.
above the list of defconfig files, or as the prompt in the menuconfig);
as such, it should relatively brief (40 chars is probably a good upper
limit). The description is available in the +BR2_EXTERNAL_$(NAME)_DESC+
variable.
Examples of names and the corresponding +BR2_EXTERNAL_$(NAME)_PATH+
variables:
* +FOO+ -> +BR2_EXTERNAL_FOO_PATH+
* +BAR_42+ -> +BR2_EXTERNAL_BAR_42_PATH+
In the following examples, it is assumed the name to be set to +BAR_42+.
.Note:
Both +BR2_EXTERNAL_$(NAME)_PATH+ and `BR2_EXTERNAL_$(NAME)_DESC` are
available in the Kconfig files and the Makefiles. They are also
exported in the environment so are available in post-build, post-image
and in-fakeroot scripts.
===== The +Config.in+ and +external.mk+ files
Those files (which may each be empty) can be used to define package
recipes (i.e. +foo/Config.in+ and +foo/foo.mk+ like for packages bundled
in Buildroot itself) or other custom configuration options or make logic.
Buildroot automatically includes the +Config.in+ from each br2-external
tree to make it appear in the top-level configuration menu, and includes
the +external.mk+ from each br2-external tree with the rest of the
makefile logic.
The main usage of this is to store package recipes. The recommended way
to do this is to write a +Config.in+ file that looks like:
------
source "$BR2_EXTERNAL_BAR_42_PATH/package/package1/Config.in"
source "$BR2_EXTERNAL_BAR_42_PATH/package/package2/Config.in"
------
Then, have an +external.mk+ file that looks like:
------
include $(sort $(wildcard $(BR2_EXTERNAL_BAR_42_PATH)/package/*/*.mk))
------
And then in +$(BR2_EXTERNAL_BAR_42_PATH)/package/package1+ and
+$(BR2_EXTERNAL_BAR_42_PATH)/package/package2+ create normal
Buildroot package recipes, as explained in xref:adding-packages[].
If you prefer, you can also group the packages in subdirectories
called <boardname> and adapt the above paths accordingly.
You can also define custom configuration options in +Config.in+ and
custom make logic in +external.mk+.
===== The +configs/+ directory
One can store Buildroot defconfigs in the +configs+ subdirectory of
the br2-external tree. Buildroot will automatically show them in the
output of +make list-defconfigs+ and allow them to be loaded with the
normal +make <name>_defconfig+ command. They will be visible in the
'make list-defconfigs' output, below an +External configs+ label that
contains the name of the br2-external tree they are defined in.
.Note:
If a defconfig file is present in more than one br2-external tree, then
the one from the last br2-external tree is used. It is thus possible
to override a defconfig bundled in Buildroot or another br2-external
tree.
===== Free-form content
One can store all the board-specific configuration files there, such
as the kernel configuration, the root filesystem overlay, or any other
configuration file for which Buildroot allows to set the location (by
using the +BR2_EXTERNAL_$(NAME)_PATH+ variable). For example, you
could set the paths to a global patch directory, to a rootfs overlay
and to the kernel configuration file as follows (e.g. by running
`make menuconfig` and filling in these options):
----
BR2_GLOBAL_PATCH_DIR=$(BR2_EXTERNAL_BAR_42_PATH)/patches/
BR2_ROOTFS_OVERLAY=$(BR2_EXTERNAL_BAR_42_PATH)/board/<boardname>/overlay/
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE=$(BR2_EXTERNAL_BAR_42_FOO)/board/<boardname>/kernel.config
----
===== Example layout
Here is an example layout using all features of br2-external (the sample
content is shown for the file above it, when it is relevant to explain
the br2-external tree; this is all entirely made up just for the sake of
illustration, of course):
----
/path/to/br2-ext-tree/
|- external.desc
| |name: BAR_42
| |desc: Example br2-external tree
| `----
|
|- Config.in
| |source "$BR2_EXTERNAL_BAR_42_PATH/package/pkg-1/Config.in"
| |source "$BR2_EXTERNAL_BAR_42_PATH/package/pkg-2/Config.in"
| |
| |config BAR_42_FLASH_ADDR
| | hex "my-board flash address"
| | default 0x10AD
| `----
|
|- external.mk
| |include $(sort $(wildcard $(BR2_EXTERNAL_BAR_42_PATH)/package/*/*.mk))
| |
| |flash-my-board:
| | $(BR2_EXTERNAL_BAR_42_PATH)/board/my-board/flash-image \
| | --image $(BINARIES_DIR)/image.bin \
| | --address $(BAR_42_FLASH_ADDR)
| `----
|
|- package/pkg-1/Config.in
| |config BR2_PACKAGE_PKG_1
| | bool "pkg-1"
| | help
| | Some help about pkg-1
| `----
|- package/pkg-1/pkg-1.hash
|- package/pkg-1/pkg-1.mk
| |PKG_1_VERSION = 1.2.3
| |PKG_1_SITE = /some/where/to/get/pkg-1
| |PKG_1_LICENSE = blabla
| |
| |define PKG_1_INSTALL_INIT_SYSV
| | $(INSTALL) -D -m 0755 $(PKG_1_PKGDIR)/S99my-daemon \
| | $(TARGET_DIR)/etc/init.d/S99my-daemon
| |endef
| |
| |$(eval $(autotools-package))
| `----
|- package/pkg-1/S99my-daemon
|
|- package/pkg-2/Config.in
|- package/pkg-2/pkg-2.hash
|- package/pkg-2/pkg-2.mk
|
|- configs/my-board_defconfig
| |BR2_GLOBAL_PATCH_DIR="$(BR2_EXTERNAL_BAR_42_PATH)/patches/"
| |BR2_ROOTFS_OVERLAY="$(BR2_EXTERNAL_BAR_42_PATH)/board/my-board/overlay/"
| |BR2_ROOTFS_POST_IMAGE_SCRIPT="$(BR2_EXTERNAL_BAR_42_PATH)/board/my-board/post-image.sh"
| |BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="$(BR2_EXTERNAL_BAR_42_FOO)/board/my-board/kernel.config"
| `----
|
|- patches/linux/0001-some-change.patch
|- patches/linux/0002-some-other-change.patch
|- patches/busybox/0001-fix-something.patch
|
|- board/my-board/kernel.config
|- board/my-board/overlay/var/www/index.html
|- board/my-board/overlay/var/www/my.css
|- board/my-board/flash-image
`- board/my-board/post-image.sh
|#!/bin/sh
|generate-my-binary-image \
| --root ${BINARIES_DIR}/rootfs.tar \
| --kernel ${BINARIES_DIR}/zImage \
| --dtb ${BINARIES_DIR}/my-board.dtb \
| --output ${BINARIES_DIR}/image.bin
`----
----
The br2-external tree will then be visible in the menuconfig (with
the layout expanded):
----
External options --->
*** Example br2-external tree (in /path/to/br2-ext-tree/)
[ ] pkg-1
[ ] pkg-2
(0x10AD) my-board flash address
----
If you are using more than one br2-external tree, it would look like
(with the layout expanded and the second one with name +FOO_27+ but no
+desc:+ field in +external.desc+):
----
External options --->
Example br2-external tree --->
*** Example br2-external tree (in /path/to/br2-ext-tree)
[ ] pkg-1
[ ] pkg-2
(0x10AD) my-board flash address
FOO_27 --->
*** FOO_27 (in /path/to/another-br2-ext)
[ ] foo
[ ] bar
----

25
bsp/buildroot/docs/manual/customize-packages.txt
View File

@@ -14,8 +14,9 @@ packages in a project-specific directory.
As shown in xref:customize-dir-structure[], the recommended location for
project-specific packages is +package/<company>/+. If you are using the
+BR2_EXTERNAL+ feature (see xref:outside-br-custom[]) the recommended
location is +$(BR2_EXTERNAL)/package/+.
br2-external tree feature (see xref:outside-br-custom[]) the recommended
location is to put them in a sub-directory named +package/+ in your
br2-external tree.
However, Buildroot will not be aware of the packages in this location,
unless we perform some additional steps. As explained in
@@ -37,14 +38,6 @@ have only one extra directory level below +package/<company>/+):
include $(sort $(wildcard package/<company>/*/*.mk))
-----
If you are using +BR2_EXTERNAL+, create a file
+$(BR2_EXTERNAL)/external.mk+ with following contents (again assuming only
one extra level):
-----
include $(sort $(wildcard $(BR2_EXTERNAL)/package/*/*.mk))
-----
For the +Config.in+ files, create a file +package/<company>/Config.in+
that includes the +Config.in+ files of all your packages. An exhaustive
list has to be provided since wildcards are not supported in the source command of kconfig.
@@ -59,13 +52,5 @@ Include this new file +package/<company>/Config.in+ from
+package/Config.in+, preferably in a company-specific menu to make
merges with future Buildroot versions easier.
If you are using +BR2_EXTERNAL+, create a file
+$(BR2_EXTERNAL)/Config.in+ with similar contents:
-----
source "$BR2_EXTERNAL/package/package1/Config.in"
source "$BR2_EXTERNAL/package/package2/Config.in"
-----
You do not have to add an include for this +$(BR2_EXTERNAL)/Config.in+
file as it is included automatically.
If using a br2-external tree, refer to xref:outside-br-custom[] for how
to fill in those files.

46
bsp/buildroot/docs/manual/developers.txt Normal file
View File

@@ -0,0 +1,46 @@
// -*- mode:doc; -*-
// vim: set syntax=asciidoc:
[[DEVELOPERS]]
== DEVELOPERS file and get-developers
The main Buildroot directory contains a file named +DEVELOPERS+ that
lists the developers involved with various areas of Buildroot. Thanks
to this file, the +get-developer+ tool allows to:
- Calculate the list of developers to whom patches should be sent, by
parsing the patches and matching the modified files with the
relevant developers. See xref:submitting-patches[] for details.
- Find which developers are taking care of a given architecture or
package, so that they can be notified when a build failure occurs on
this architecture or package. This is done in interaction with
Buildroot's autobuild infrastructure.
We ask developers adding new packages, new boards, or generally new
functionality in Buildroot, to register themselves in the +DEVELOPERS+
file. As an example, we expect a developer contributing a new package
to include in his patch the appropriate modification to the
+DEVELOPERS+ file.
The +DEVELOPERS+ file format is documented in detail inside the file
itself.
The +get-developer+ tool, located in +support/scripts+ allows to use
the +DEVELOPERS+ file for various tasks:
- When passing one or several patches as command line argument,
+get-developer+ will return the appropriate +git send-email+
command.
- When using the +-a <arch>+ command line option, +get-developer+ will
return the list of developers in charge of the given architecture.
- When using the +-p <package>+ command line option, +get-developer+
will return the list of developers in charge of the given package.
- When using the +-c+ command line option, +get-developer+ will look
at all files under version control in the Buildroot repository, and
list the ones that are not handled by any developer. The purpose of
this option is to help completing the +DEVELOPERS+ file.

2
bsp/buildroot/docs/manual/download-location.txt
View File

@@ -1,6 +1,8 @@
// -*- mode:doc; -*-
// vim: set syntax=asciidoc:
[[download-location]]
==== Location of downloaded packages
The various tarballs that are downloaded by Buildroot are all stored

10
bsp/buildroot/docs/manual/legal-notice.txt
View File

@@ -73,6 +73,16 @@ distribution is required).
When you run +make legal-info+, Buildroot produces warnings in the +README+
file to inform you of relevant material that could not be saved.
Finally, keep in mind that the output of +make legal-info+ is based on
declarative statements in each of the packages recipes. The Buildroot
developers try to do their best to keep those declarative statements as
accurate as possible, to the best of their knowledge. However, it is very
well possible that those declarative statements are not all fully accurate
nor exhaustive. You (or your legal department) _have_ to check the output
of +make legal-info+ before using it as your own compliance delivery. See
the _NO WARRANTY_ clauses (clauses 11 and 12) in the +COPYING+ file at the
root of the Buildroot distribution.
[[legal-info-list-licenses]]
=== License abbreviations

600
bsp/buildroot/docs/manual/manual.html
View File

File diff suppressed because one or more lines are too long

21
bsp/buildroot/docs/manual/manual.mk
View File

@@ -7,25 +7,4 @@
MANUAL_SOURCES = $(sort $(wildcard docs/manual/*.txt) $(wildcard docs/images/*))
MANUAL_RESOURCES = $(TOPDIR)/docs/images
# Our manual needs to generate lists
define MANUAL_GEN_LISTS
$(Q)$(call MESSAGE,"Updating the manual lists...")
$(Q)$(COMMON_CONFIG_ENV) \
BR2_DEFCONFIG="" \
TOPDIR=$(TOPDIR) \
O=$(@D) \
python -B $(TOPDIR)/support/scripts/gen-manual-lists.py
endef
MANUAL_POST_RSYNC_HOOKS += MANUAL_GEN_LISTS
# Our list-generating script requires argparse
define MANUAL_CHECK_LISTS_DEPS
$(Q)if ! python -c "import argparse" >/dev/null 2>&1 ; then \
echo "You need python with argparse on your host to generate" \
"the list of packages in the manual"; \
exit 1; \
fi
endef
MANUAL_CHECK_DEPENDENCIES_HOOKS += MANUAL_CHECK_LISTS_DEPS
$(eval $(call asciidoc-document))

BIN
bsp/buildroot/docs/manual/manual.pdf
View File

Binary file not shown.

5825
bsp/buildroot/docs/manual/manual.text
View File

File diff suppressed because it is too large Load Diff

4
bsp/buildroot/docs/manual/manual.txt
View File

@@ -12,7 +12,7 @@ It is licensed under the GNU General Public License, version 2. Refer to the
http://git.buildroot.org/buildroot/tree/COPYING[COPYING] file in the Buildroot
sources for the full text of this license.
Copyright (C) 2004-2014 The Buildroot developers
Copyright (C) 2004-2017 The Buildroot developers
image::logo.png[]
@@ -64,6 +64,8 @@ include::debugging-buildroot.txt[]
include::contribute.txt[]
include::developers.txt[]
= Appendix
include::appendix.txt[]

2
bsp/buildroot/docs/manual/prerequisite.txt
View File

@@ -35,6 +35,8 @@ between distributions).
** +python+ (version 2.6 or any later)
** +unzip+
** +rsync+
** +file+ (must be in +/usr/bin/file+)
** +bc+
* Source fetching tools:
** +wget+

36
bsp/buildroot/docs/website/download.html
View File

@@ -8,71 +8,71 @@
<div class="panel-heading">Download</div>
<div class="panel-body">
<h3 style="text-align: center;">Latest stable release: <b>2016.08</b></h3>
<h3 style="text-align: center;">Latest stable release: <b>2017.02</b></h3>
<div class="row mt centered">
<div class="col-sm-6">
<div class="flip-container center-block" ontouchstart="this.classList.toggle('hover');">
<div class="flipper">
<div class="front">
<a href="/downloads/buildroot-2016.08.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2017.02.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
</div>
<div class="back">
<a href="/downloads/buildroot-2016.08.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2017.02.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
</div>
</div>
</div>
<h3><a href="/downloads/buildroot-2016.08.tar.gz">buildroot-2016.08.tar.gz</a></h3>
<p><a href="/downloads/buildroot-2016.08.tar.gz.sign">PGP signature</a></p>
<h3><a href="/downloads/buildroot-2017.02.tar.gz">buildroot-2017.02.tar.gz</a></h3>
<p><a href="/downloads/buildroot-2017.02.tar.gz.sign">PGP signature</a></p>
</div>
<div class="col-sm-6">
<div class="flip-container center-block" ontouchstart="this.classList.toggle('hover');">
<div class="flipper">
<div class="front">
<a href="/downloads/buildroot-2016.08.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2017.02.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
</div>
<div class="back">
<a href="/downloads/buildroot-2016.08.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2017.02.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
</div>
</div>
</div>
<h3><a href="/downloads/buildroot-2016.08.tar.bz2">buildroot-2016.08.tar.bz2</a></h3>
<p><a href="/downloads/buildroot-2016.08.tar.bz2.sign">PGP signature</a></p>
<h3><a href="/downloads/buildroot-2017.02.tar.bz2">buildroot-2017.02.tar.bz2</a></h3>
<p><a href="/downloads/buildroot-2017.02.tar.bz2.sign">PGP signature</a></p>
</div>
</div>
<!--
<h3 style="text-align: center;">Latest release candidate: <b>2016.08-rc3</b></h3>
<h3 style="text-align: center;">Latest release candidate: <b>2017.02-rc3</b></h3>
<div class="row mt centered">
<div class="col-sm-6">
<div class="flip-container center-block" ontouchstart="this.classList.toggle('hover');">
<div class="flipper">
<div class="front">
<a href="/downloads/buildroot-2016.08-rc3.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2017.02-rc3.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
</div>
<div class="back">
<a href="/downloads/buildroot-2016.08-rc3.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2017.02-rc3.tar.gz"><img src="images/zip.png" width="180" alt=""></a>
</div>
</div>
</div>
<h3><a href="/downloads/buildroot-2016.08-rc3.tar.gz">buildroot-2016.08-rc3.tar.gz</a></h3>
<p><a href="/downloads/buildroot-2016.08-rc3.tar.gz.sign">PGP signature</a></p>
<h3><a href="/downloads/buildroot-2017.02-rc3.tar.gz">buildroot-2017.02-rc3.tar.gz</a></h3>
<p><a href="/downloads/buildroot-2017.02-rc3.tar.gz.sign">PGP signature</a></p>
</div>
<div class="col-sm-6">
<div class="flip-container center-block" ontouchstart="this.classList.toggle('hover');">
<div class="flipper">
<div class="front">
<a href="/downloads/buildroot-2016.08-rc3.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2017.02-rc3.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
</div>
<div class="back">
<a href="/downloads/buildroot-2016.08-rc3.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
<a href="/downloads/buildroot-2017.02-rc3.tar.bz2"><img src="images/package.png" width="180" alt=""></a>
</div>
</div>
</div>
<h3><a href="/downloads/buildroot-2016.08-rc3.tar.bz2">buildroot-2016.08-rc3.tar.bz2</a></h3>
<p><a href="/downloads/buildroot-2016.08-rc3.tar.bz2.sign">PGP signature</a></p>
<h3><a href="/downloads/buildroot-2017.02-rc3.tar.bz2">buildroot-2017.02-rc3.tar.bz2</a></h3>
<p><a href="/downloads/buildroot-2017.02-rc3.tar.bz2.sign">PGP signature</a></p>
</div>
</div>
-->

5
bsp/buildroot/docs/website/footer.html
View File

@@ -1,6 +1,5 @@
<script src="https://code.jquery.com/jquery-1.11.3.min.js"></script>
<script src="https://oss.maxcdn.com/bootstrap/3.3.5/js/bootstrap.min.js"></script>
<script type="text/javascript" src="https://www.google.com/jsapi"></script>
<script src="https://code.jquery.com/jquery-3.1.1.min.js"></script>
<script src="https://oss.maxcdn.com/bootstrap/3.3.7/js/bootstrap.min.js"></script>
<script src="https://cdn.rawgit.com/zenorocha/clipboard.js/master/dist/clipboard.min.js"></script>
<script type="text/javascript" src="js/buildroot.js"></script>
</body>

2
bsp/buildroot/docs/website/header.html
View File

@@ -10,7 +10,7 @@
<title>Buildroot - Making Embedded Linux Easy</title>
<link href="https://oss.maxcdn.com/bootswatch/3.3.5/paper/bootstrap.min.css" rel="stylesheet">
<link href="https://oss.maxcdn.com/bootswatch/3.3.7/paper/bootstrap.min.css" rel="stylesheet">
<link href="css/main.css" rel="stylesheet">
<!--[if lt IE 9]>

BIN
bsp/buildroot/docs/website/images/free-electrons-logo.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 9.7 KiB

After

Width:  |  Height:  |  Size: 9.0 KiB

73
bsp/buildroot/docs/website/js/buildroot.js
View File

@@ -1,15 +1,17 @@
function load_activity(feedurl, divid) {
var feed = new google.feeds.Feed(feedurl);
var yqlURL = "https://query.yahooapis.com/v1/public/yql";
var yqlQS = "?q=select%20entry%20from%20xml%20where%20url%20%3D%20'";
var yqlOPTS = "'%20limit%2010&format=json&callback=";
var container = document.getElementById(divid);
var loaded = 0;
var nb_display = 8;
feed.setNumEntries(30);
feed.load(function(result) {
if (result.error) {
return;
}
for (var i = 0; i < result.feed.entries.length; i++) {
var entry = result.feed.entries[i];
var url = yqlURL + yqlQS + encodeURIComponent(feedurl) + yqlOPTS;
$.getJSON(url, function(data){
var result = data.query.results;
var loaded = 0;
var nb_display = 8;
if (result==null) return;
for (var i = 0; i < result.feed.length; i++) {
var entry = result.feed[i].entry;
if (entry.title.indexOf("git commit") != -1)
continue;
loaded += 1;
@@ -17,12 +19,12 @@ function load_activity(feedurl, divid) {
break;
var div = document.createElement("p");
var link = document.createElement("a");
var d = new Date(entry.publishedDate);
var d = new Date(entry.published);
var data = '[' + d.toLocaleDateString() + '] ' + entry.title
var text = document.createTextNode(data);
link.appendChild(text);
link.title = entry.title;
link.href = entry.link
link.href = entry.link.href;
div.appendChild(link);
container.appendChild(div);
}
@@ -33,11 +35,6 @@ function load_activity(feedurl, divid) {
});
}
function initialize() {
load_activity("http://rss.gmane.org/topics/excerpts/gmane.comp.lib.uclibc.buildroot", "mailing-list-activity");
load_activity("http://git.buildroot.org/buildroot/atom/?h=master", "commit-activity");
}
function google_analytics() {
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-21761074-1']);
@@ -53,34 +50,6 @@ function google_analytics() {
s.parentNode.insertBefore(ga, s);
}
$(function() {
$('a[href*=#]:not([href=#])').click(function() {
if (location.pathname.replace(/^\//,'') == this.pathname.replace(/^\//,'') && location.hostname == this.hostname) {
var target = $(this.hash);
target = target.length ? target : $('[name=' + this.hash.slice(1) +']');
if (target.length) {
$('html,body').animate({
scrollTop: target.offset().top
}, 1000);
return false;
}
}
});
});
google.load("feeds", "1");
google.setOnLoadCallback(initialize);
google_analytics();
jQuery(document).ready(function($) {
var url = window.location.href;
// Get the basename of the URL
url = url.split(/[\\/]/).pop()
$('.nav a[href="/' + url + '"]').parent().addClass('active');
$('#slides').html('<iframe src="https://docs.google.com/gview?url=http://free-electrons.com/doc/training/buildroot/buildroot-slides.pdf&embedded=true" style="position:absolute; width:100%; height:100%; top:0; left:0;" frameborder="0"></iframe>')
});
function showTooltip(elem, msg) {
elem.setAttribute('class', 'btn tooltipped tooltipped-s');
elem.setAttribute('aria-label', msg);
@@ -98,7 +67,7 @@ clipboard.on('success', function(e) {
});
$(function() {
$('a[href*=#]:not([href=#])').click(function() {
$('a[href*=\\#]:not([href=\\#])').click(function() {
if (location.pathname.replace(/^\//,'') == this.pathname.replace(/^\//,'') && location.hostname == this.hostname) {
var target = $(this.hash);
target = target.length ? target : $('[name=' + this.hash.slice(1) +']');
@@ -111,3 +80,15 @@ $(function() {
}
});
});
jQuery(document).ready(function($) {
var url = window.location.href;
// Get the basename of the URL
url = url.split(/[\\/]/).pop()
$('.nav a[href="/' + url + '"]').parent().addClass('active');
load_activity("http://buildroot-busybox.2317881.n4.nabble.com/Buildroot-busybox-ft2.xml", "mailing-list-activity");
load_activity("http://git.buildroot.org/buildroot/atom/?h=master", "commit-activity");
$('#slides').html('<iframe src="https://docs.google.com/gview?url=http://free-electrons.com/doc/training/buildroot/buildroot-slides.pdf&embedded=true" style="position:absolute; width:100%; height:100%; top:0; left:0;" frameborder="0"></iframe>')
});

243
bsp/buildroot/docs/website/news.html
View File

@@ -9,6 +9,242 @@
<h2>News</h2>
<ul class="timeline">
<li>
<div class="timeline-badge"><i class="glyphicon glyphicon-thumbs-up"></i></div>
<div class="timeline-panel">
<div class="timeline-heading">
<h4 class="timeline-title">2017.02 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>28 February 2017</small></p>
</div>
<div class="timeline-body">
<p>The stable 2017.02 release is out - Thanks to everyone
contributing and testing the release candidates. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.02">CHANGES</a>
file for more details
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.02.tar.bz2">2017.02 release</a>.</p>
</div>
</div>
</li>
<li class="timeline-inverted">
<div class="timeline-badge"><i class="glyphicon glyphicon-thumbs-up"></i></div>
<div class="timeline-panel">
<div class="timeline-heading">
<h4 class="timeline-title">2017.02-rc3 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>26 February 2017</small></p>
</div>
<div class="timeline-body">
<p>Release candidate 3 is out with more cleanups and security
/ build fixes. See
the <a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.02-rc3">CHANGES</a>
file for details.</p>
<p>Head to the <a href="/downloads/">downloads page</a> to
pick up
the <a href="/downloads/buildroot-2017.02-rc3.tar.bz2">2017.02-rc3
release candidate</a>, and report any problems found to
the <a href="support.html">mailing list</a>
or <a href="https://bugs.uclibc.org">bug tracker</a>.</p>
</div>
</div>
</li>
<li>
<div class="timeline-badge"><i class="glyphicon glyphicon-thumbs-up"></i></div>
<div class="timeline-panel">
<div class="timeline-heading">
<h4 class="timeline-title">2017.02-rc2 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>20 February 2017</small></p>
</div>
<div class="timeline-body">
<p>We have a new release candidate! Lots of changes all over the tree, see
the <a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.02-rc2">CHANGES</a>
file for details.
</p>
<p>Head to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.02-rc2.tar.bz2">2017.02-rc2
release candidate</a>, and report any problems found to the
<a href="support.html">mailing list</a> or
<a href="https://bugs.buildroot.org">bug tracker</a>.</p>
</div>
</div>
</li>
<li class="timeline-inverted">
<div class="timeline-badge"><i class="glyphicon glyphicon-thumbs-up"></i></div>
<div class="timeline-panel">
<div class="timeline-heading">
<h4 class="timeline-title">2017.02-rc1 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>11 February 2017</small></p>
</div>
<div class="timeline-body">
<p>We have a new release candidate! Lots of changes all over
the tree, see
the <a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2017.02-rc1">CHANGES</a>
file for details, read
the <a href="http://lists.busybox.net/pipermail/buildroot/2017-February/183729.html">announcement</a>.
</p>
<p>Head to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2017.02-rc1.tar.bz2">2017.12-rc1
release candidate</a>, and report any
problems found to the
<a href="support.html">mailing list</a> or
<a href="https://bugs.buildroot.org">bug tracker</a>.</p>
</div>
</div>
</li>
<li>
<div class="timeline-badge"><i class="glyphicon glyphicon-thumbs-up"></i></div>
<div class="timeline-panel">
<div class="timeline-heading">
<h4 class="timeline-title">2016.11.2 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>25 January 2017</small></p>
</div>
<div class="timeline-body">
<p>The 2016.11.2 bugfix release is out, fixing a number of important /
security related issues discovered since the 2016.11.1 release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2016.11.2">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2017-January/182095.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2016.11.2.tar.bz2">2016.11.2 release</a>.</p>
</div>
</div>
</li>
<li class="timeline-inverted">
<div class="timeline-badge"><i class="glyphicon glyphicon-thumbs-up"></i></div>
<div class="timeline-panel">
<div class="timeline-heading">
<h4 class="timeline-title">2016.11.1 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>29 December 2016</small></p>
</div>
<div class="timeline-body">
<p>The 2016.11.1 bugfix release is out, fixing a number of important /
security related issues discovered since the 2016.11 release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2016.11.1">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2016-December/180622.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2016.11.1.tar.bz2">2016.11.1 release</a>.</p>
</div>
</div>
</li>
<li>
<div class="timeline-badge"><i class="glyphicon glyphicon-thumbs-up"></i></div>
<div class="timeline-panel">
<div class="timeline-heading">
<h4 class="timeline-title">2016.11 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>30 November 2016</small></p>
</div>
<div class="timeline-body">
<p>The stable 2016.11 release is out - Thanks to everyone
contributing and testing the release candidates. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2016.11">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2016-November/178514.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2016.11.tar.bz2">2016.11 release</a>.</p>
</div>
</div>
</li>
<li class="timeline-inverted">
<div class="timeline-badge"><i class="glyphicon glyphicon-thumbs-up"></i></div>
<div class="timeline-panel">
<div class="timeline-heading">
<h4 class="timeline-title">2016.11-rc3 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>28 November 2016</small></p>
</div>
<div class="timeline-body">
<p>Release candidate 3 is out with more cleanups and security
/ build fixes. See
the <a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2016.11-rc3">CHANGES</a>
file for details.</p>
<p>Head to the <a href="/downloads/">downloads page</a> to
pick up
the <a href="/downloads/buildroot-2016.11-rc3.tar.bz2">2016.11-rc3
release candidate</a>, and report any problems found to
the <a href="support.html">mailing list</a>
or <a href="https://bugs.uclibc.org">bug tracker</a>.</p>
</div>
</div>
</li>
<li>
<div class="timeline-badge"><i class="glyphicon glyphicon-thumbs-up"></i></div>
<div class="timeline-panel">
<div class="timeline-heading">
<h4 class="timeline-title">2016.11-rc2 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>13 November 2016</small></p>
</div>
<div class="timeline-body">
<p>We have a new release candidate! Lots of
changes all over the tree, see
the <a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2016.11-rc2">CHANGES</a>
file for details.
</p>
<p>Head to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2016.11-rc2.tar.bz2">2016.11-rc2
release candidate</a>, and report any
problems found to the
<a href="support.html">mailing list</a> or
<a href="https://bugs.buildroot.org">bug tracker</a>.</p>
</div>
</div>
</li>
<li class="timeline-inverted">
<div class="timeline-badge"><i class="glyphicon glyphicon-thumbs-up"></i></div>
<div class="timeline-panel">
<div class="timeline-heading">
<h4 class="timeline-title">2016.11-rc1 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>3 November 2016</small></p>
</div>
<div class="timeline-body">
<p>We have a new release candidate! Lots of
changes all over the tree, see
the <a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2016.11-rc1">CHANGES</a>
file for details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2016-November/176453.html">announcement</a>.
</p>
<p>Head to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2016.11-rc1.tar.bz2">2016.11-rc1
release candidate</a>, and report any
problems found to the
<a href="support.html">mailing list</a> or
<a href="https://bugs.buildroot.org">bug tracker</a>.</p>
</div>
</div>
</li>
<li>
<div class="timeline-badge"><i class="glyphicon glyphicon-thumbs-up"></i></div>
<div class="timeline-panel">
<div class="timeline-heading">
<h4 class="timeline-title">2016.08.1 released</h4>
<p><small class="text-muted"><i class="glyphicon glyphicon-time"></i>21 September 2016</small></p>
</div>
<div class="timeline-body">
<p>The 2016.08.1 bugfix release is out. This release fixes a
potential entire root filesystem removal issue with the
external toolchain handling discovered since the 2016.08
release. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2016.08.1">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2016-September/172712.html">announcement</a> and go to the
<a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2016.08.1.tar.bz2">2016.08.1 release</a>.</p>
</div>
</div>
</li>
<li class="timeline-inverted">
<div class="timeline-badge"><i class="glyphicon glyphicon-thumbs-up"></i></div>
<div class="timeline-panel">
@@ -20,7 +256,8 @@
<p>The stable 2016.08 release is out - Thanks to everyone
contributing and testing the release candidates. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2016.08">CHANGES</a>
file for more details
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2016-September/171172.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2016.08.tar.bz2">2016.08 release</a>.</p>
</div>
@@ -108,7 +345,7 @@
contributing and testing the release candidates. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2016.05">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2016-May/162428.html">announcement<a>
<a href="http://lists.busybox.net/pipermail/buildroot/2016-May/162428.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2016.05.tar.bz2">2016.05 release</a>.</p>
</div>
@@ -196,7 +433,7 @@
contributing and testing the release candidates. See the
<a href="http://git.buildroot.net/buildroot/plain/CHANGES?id=2016.02">CHANGES</a>
file for more details, read the
<a href="http://lists.busybox.net/pipermail/buildroot/2016-March/154535.html">announcement<a>
<a href="http://lists.busybox.net/pipermail/buildroot/2016-March/154535.html">announcement</a>
and go to the <a href="/downloads/">downloads page</a> to pick up the
<a href="/downloads/buildroot-2016.02.tar.bz2">2016.02 release</a>.</p>
</div>

75
bsp/buildroot/docs/website/sponsors.html
View File

@@ -9,23 +9,42 @@
<div class="panel-body">
<div class="row">
<div class="col-sm-12">
<div class="panel panel-default">
<div class="panel-body">
<div class="col-sm-4">
<a href="http://ingenierie.openwide.fr">
<img class="img-responsive center-block" src="images/owi-smile-logo.png"/>
<a href="http://www.google.com">
<img class="img-responsive center-block" src="images/google-logo.png"/>
</a>
</div>
<div class="col-sm-8">
<a href="http://ingenierie.openwide.fr">OpenWide/Smile</a> is sponsoring
the Buildroot Summer Camp taking place on July 1-5 2016 in Toulouse, France. OpenWide/Smile is
sponsoring the participation of Romain Naour and paid the food expenses for the meeting participants.
<a href="http://www.google.com">Google</a> is
sponsoring
the <a href="http://elinux.org/Buildroot:DeveloperDaysFOSDEM2017">Buildroot
Developers Meeting at FOSDEM 2017</a> in Brussels, by
providing logistics for the meeting: a free meeting
room and lunch for the participants.
</div>
</div>
</div>
<div class="col-sm-12">
<div class="panel panel-default">
<div class="panel-body">
<div class="col-sm-4">
<a href="http://www.mind.be">
<img class="img-responsive center-block" src="images/mind-logo.png"/>
</a>
</div>
<div class="col-sm-8">
As it did in previous years, <a href="http://www.mind.be">Mind</a>
is sponsoring the Monday night dinner at the <a href="http://elinux.org/Buildroot:DeveloperDaysFOSDEM2017">Buildroot
Developers Meeting at FOSDEM 2017</a> in Brussels.
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
@@ -36,6 +55,23 @@
various companies, that we would like to thank below.</p>
<div class="row">
<div class="col-sm-4">
<div class="panel panel-default panel-sponsor">
<div class="panel-body">
<div class="col-sm-12">
<a href="http://ingenierie.openwide.fr">
<img class="img-responsive center-block" src="images/owi-smile-logo.png"/>
</a>
</div>
<div class="col-sm-12">
<a href="http://ingenierie.openwide.fr">OpenWide/Smile</a> sponsored
the Buildroot Summer Camp that took place on July 1-5 2016 in Toulouse, France. OpenWide/Smile is
sponsoring the participation of Romain Naour and paid the food expenses for the meeting participants.
</div>
</div>
</div>
</div>
<div class="col-sm-4">
<div class="panel panel-default panel-sponsor">
<div class="panel-body">
@@ -46,9 +82,10 @@
</div>
<div class="col-sm-12">
<a href="http://www.mind.be">Mind</a> sponsored the
dinner of the FOSDEM 2014, 2015 and 2016 Developers
Meeting (Brussels), the meeting room and the dinner
for the ELCE 2014 Developers Meeting (Düsseldorf).
dinner of the FOSDEM 2014, 2015, 2016 and 2017
Developers Meeting (Brussels) and ELCE 2016 (Berlin),
the meeting room and the dinner for the ELCE 2014
Developers Meeting (Düsseldorf).
</div>
</div>
</div>
@@ -70,7 +107,9 @@
</div>
</div>
</div>
</div>
<div class="row">
<div class="col-sm-4">
<div class="panel panel-default panel-sponsor">
<div class="panel-body">
@@ -86,9 +125,7 @@
</div>
</div>
</div>
</div>
<div class="row">
<div class="col-sm-4">
<div class="panel panel-default panel-sponsor">
<div class="panel-body">
@@ -120,7 +157,9 @@
</div>
</div>
</div>
</div>
<div class="row">
<div class="col-sm-4">
<div class="panel panel-default panel-sponsor">
<div class="panel-body">
@@ -136,9 +175,7 @@
</div>
</div>
</div>
</div>
<div class="row">
<div class="col-sm-4">
<div class="panel panel-default panel-sponsor">
<div class="panel-body">
@@ -169,7 +206,9 @@
</div>
</div>
</div>
</div>
<div class="row">
<div class="col-sm-4">
<div class="panel panel-default panel-sponsor">
<div class="panel-body">
@@ -178,9 +217,11 @@
<img class="img-responsive center-block" src="images/free-electrons-logo.png"/></a></p>
</div>
<div class="col-sm-12">
<p><a href="http://www.free-electrons.com">Free Electrons</a>
sponsored the lunch for the ELCE 2009 Developer Days in
Grenoble, France.</p>
<p><a href="http://www.free-electrons.com">Free
Electrons</a> sponsored the meeting location for the
ELCE 2016 Developer Days in Berlin, Germany, and the
lunch for the ELCE 2009 Developer Days in Grenoble,
France.</p>
</div>
</div>
</div>

6
bsp/buildroot/docs/website/support.html
View File

@@ -50,9 +50,11 @@
list, since there is a good chance someone else has asked the same question
before.</p>
<form method="get" action="http://search.gmane.org/">
<form method="get" action="http://buildroot-busybox.2317881.n4.nabble.com/template/NamlServlet.jtp">
<input type="text" name="query">
<input type="hidden" name="group" value="gmane.comp.lib.uclibc.buildroot">
<input type="hidden" name="macro" value="search_page">
<input type="hidden" name="node" value="2">
<input type="hidden" name="sort" value="date">
<button type="submit" class="btn btn-default">Submit</button>
</form>
</div>