d-two/operating-system
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update buildroot to 2020.02.7 (#923)

Browse Source 
Signed-off-by: Pascal Vizeli <pvizeli@syshack.ch>
This commit is contained in:
Pascal Vizeli
2020-10-22 17:05:36 +02:00
committed by Stefan Agner
parent f9c29ef209
commit e43d4cd632
332 changed files with 10767 additions and 1806 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
buildroot/docs/manual/adding-board-support.txt
View File

@@ -10,9 +10,9 @@ that is known to work. You are welcome to add support for other boards
to Buildroot too.
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
builds a basic system for the hardware: (internal) 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
@@ -22,7 +22,17 @@ selections are highly application-specific.
Once 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 +<boardname>_defconfig+.
directory, and rename it +<boardname>_defconfig+. If the configuration
is a bit more complicated, it is nice to manually reformat it and
separate it into sections, with a comment before each section. Typical
sections are _Architecture_, _Toolchain options_ (typically just linux
headers version), _Firmware_, _Bootloader_, _Kernel_, and _Filesystem_.
Always use fixed versions or commit hashes for the different
components, not the "latest" version. For example, set
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y+ and
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE+ to the kernel version you tested
with.
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

41
buildroot/docs/manual/adding-packages-cargo.txt
View File

@@ -47,32 +47,31 @@ package. Let's start with an example:
13: FOO_DEPENDENCIES = host-cargo
14:
15: FOO_CARGO_ENV = CARGO_HOME=$(HOST_DIR)/share/cargo
16: FOO_CARGO_MODE = $(if $(BR2_ENABLE_DEBUG),debug,release)
17:
18: FOO_BIN_DIR = target/$(RUSTC_TARGET_NAME)/$(FOO_CARGO_MODE)
19:
20: FOO_CARGO_OPTS = \
21: --$(FOO_CARGO_MODE) \
22: --target=$(RUSTC_TARGET_NAME) \
23: --manifest-path=$(@D)/Cargo.toml
24:
25: define FOO_BUILD_CMDS
26: $(TARGET_MAKE_ENV) $(FOO_CARGO_ENV) \
27: cargo build $(FOO_CARGO_OPTS)
28: endef
29:
30: define FOO_INSTALL_TARGET_CMDS
31: $(INSTALL) -D -m 0755 $(@D)/$(FOO_BIN_DIR)/foo \
32: $(TARGET_DIR)/usr/bin/foo
33: endef
34:
35: $(eval $(generic-package))
16:
17: FOO_BIN_DIR = target/$(RUSTC_TARGET_NAME)/$(FOO_CARGO_MODE)
18:
19: FOO_CARGO_OPTS = \
20: $(if $(BR2_ENABLE_DEBUG),,--release) \
21: --target=$(RUSTC_TARGET_NAME) \
22: --manifest-path=$(@D)/Cargo.toml
23:
24: define FOO_BUILD_CMDS
25: $(TARGET_MAKE_ENV) $(FOO_CARGO_ENV) \
26: cargo build $(FOO_CARGO_OPTS)
27: endef
28:
29: define FOO_INSTALL_TARGET_CMDS
30: $(INSTALL) -D -m 0755 $(@D)/$(FOO_BIN_DIR)/foo \
31: $(TARGET_DIR)/usr/bin/foo
32: endef
33:
34: $(eval $(generic-package))
--------------------------------
The Makefile starts with the definition of the standard variables for package
declaration (lines 7 to 11).
As seen in line 35, it is based on the
As seen in line 34, it is based on the
xref:generic-package-tutorial[+generic-package+ infrastructure]. So, it defines
the variables required by this particular infrastructure, where Cargo is
invoked:

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

@@ -34,7 +34,7 @@ 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.
On line 11, we tell Buildroot the dependencies of libfoo.
Finally, on line line 13, we invoke the +waf-package+
macro that generates all the Makefile rules that actually allows the

31
buildroot/docs/manual/contribute.txt
View File

@@ -371,6 +371,37 @@ in the following cases:
* whenever you feel it will help presenting your work, your choices,
the review process, etc.
==== Patches for maintenance branches
When fixing bugs on a maintenance branch, bugs should be fixed on the
master branch first. The commit log for such a patch may then contain a
post-commit note specifying what branches are affected:
----
package/foo: fix stuff
Signed-off-by: Your Real Name <your@email.address>
---
Backport to: 2020.02.x, 2020.05.x
(2020.08.x not affected as the version was bumped)
----
Those changes will then be backported by a maintainer to the affected
branches.
However, some bugs may apply only to a specific release, for example
because it is using an older version of a package. In that case, patches
should be based off the maintenance branch, and the patch subject prefix
must include the maintenance branch name (for example "[PATCH 2020.02.x]").
This can be done with the +git format-patch+ flag +--subject-prefix+:
---------------------
$ git format-patch --subject-prefix "PATCH 2020.02.x" \
-M -s -o outgoing origin/2020.02.x
---------------------
Then send the patches with +git send-email+, as described above.
==== Patch revision changelog
When improvements are requested, the new revision of each commit

86
buildroot/docs/manual/manual.html
View File

File diff suppressed because one or more lines are too long

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

Binary file not shown.

93
buildroot/docs/manual/manual.text
View File

@@ -167,13 +167,13 @@ List of Examples
---------------------------------------------------------------------
Buildroot 2020.02.4 manual generated on 2020-07-26 08:11:34 UTC from
git revision dee53013da
Buildroot 2020.02.7 manual generated on 2020-10-12 21:37:33 UTC from
git revision d8082db677
The Buildroot manual is written by the Buildroot developers. It is
licensed under the GNU General Public License, version 2. Refer to
the COPYING [http://git.buildroot.org/buildroot/tree/COPYING?id=
dee53013da87dfa4bcb3433bdef79ec43b5a5c24] file in the Buildroot
d8082db677046e004a6537828b3e4f4b9a818a4f] file in the Buildroot
sources for the full text of this license.
Copyright © 2004-2020 The Buildroot developers
@@ -3670,7 +3670,7 @@ build a system that is known to work. You are welcome to add support
for other boards to Buildroot too.
To do so, you need to create a normal Buildroot configuration that
builds a basic system for the hardware: toolchain, kernel,
builds a basic system for the hardware: (internal) 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
@@ -3682,7 +3682,17 @@ This is because package selections are highly application-specific.
Once 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 <boardname>_defconfig.
and rename it <boardname>_defconfig. If the configuration is a bit
more complicated, it is nice to manually reformat it and separate it
into sections, with a comment before each section. Typical sections
are Architecture, Toolchain options (typically just linux headers
version), Firmware, Bootloader, Kernel, and Filesystem.
Always use fixed versions or commit hashes for the different
components, not the "latest" version. For example, set
BR2_LINUX_KERNEL_CUSTOM_VERSION=y and
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE to the kernel version you
tested with.
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
@@ -5877,7 +5887,7 @@ 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.
On line 11, we tell Buildroot the dependencies 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
@@ -6080,31 +6090,30 @@ for such a package. Let’s start with an example:
13: FOO_DEPENDENCIES = host-cargo
14:
15: FOO_CARGO_ENV = CARGO_HOME=$(HOST_DIR)/share/cargo
16: FOO_CARGO_MODE = $(if $(BR2_ENABLE_DEBUG),debug,release)
17:
18: FOO_BIN_DIR = target/$(RUSTC_TARGET_NAME)/$(FOO_CARGO_MODE)
19:
20: FOO_CARGO_OPTS = \
21: --$(FOO_CARGO_MODE) \
22: --target=$(RUSTC_TARGET_NAME) \
23: --manifest-path=$(@D)/Cargo.toml
24:
25: define FOO_BUILD_CMDS
26: $(TARGET_MAKE_ENV) $(FOO_CARGO_ENV) \
27: cargo build $(FOO_CARGO_OPTS)
28: endef
29:
30: define FOO_INSTALL_TARGET_CMDS
31: $(INSTALL) -D -m 0755 $(@D)/$(FOO_BIN_DIR)/foo \
32: $(TARGET_DIR)/usr/bin/foo
33: endef
34:
35: $(eval $(generic-package))
16:
17: FOO_BIN_DIR = target/$(RUSTC_TARGET_NAME)/$(FOO_CARGO_MODE)
18:
19: FOO_CARGO_OPTS = \
20: $(if $(BR2_ENABLE_DEBUG),,--release) \
21: --target=$(RUSTC_TARGET_NAME) \
22: --manifest-path=$(@D)/Cargo.toml
23:
24: define FOO_BUILD_CMDS
25: $(TARGET_MAKE_ENV) $(FOO_CARGO_ENV) \
26: cargo build $(FOO_CARGO_OPTS)
27: endef
28:
29: define FOO_INSTALL_TARGET_CMDS
30: $(INSTALL) -D -m 0755 $(@D)/$(FOO_BIN_DIR)/foo \
31: $(TARGET_DIR)/usr/bin/foo
32: endef
33:
34: $(eval $(generic-package))
The Makefile starts with the definition of the standard variables for
package declaration (lines 7 to 11).
As seen in line 35, it is based on the generic-package infrastructure
As seen in line 34, it is based on the generic-package infrastructure
. So, it defines the variables required by this particular
infrastructure, where Cargo is invoked:
@@ -7499,7 +7508,35 @@ the following cases:
* whenever you feel it will help presenting your work, your
choices, the review process, etc.
21.5.4. Patch revision changelog
21.5.4. Patches for maintenance branches
When fixing bugs on a maintenance branch, bugs should be fixed on the
master branch first. The commit log for such a patch may then contain
a post-commit note specifying what branches are affected:
package/foo: fix stuff
Signed-off-by: Your Real Name <your@email.address>
---
Backport to: 2020.02.x, 2020.05.x
(2020.08.x not affected as the version was bumped)
Those changes will then be backported by a maintainer to the affected
branches.
However, some bugs may apply only to a specific release, for example
because it is using an older version of a package. In that case,
patches should be based off the maintenance branch, and the patch
subject prefix must include the maintenance branch name (for example
"[PATCH 2020.02.x]"). This can be done with the git format-patch flag
--subject-prefix:
$ git format-patch --subject-prefix "PATCH 2020.02.x" \
-M -s -o outgoing origin/2020.02.x
Then send the patches with git send-email, as described above.
21.5.5. Patch revision changelog
When improvements are requested, the new revision of each commit
should include a changelog of the modifications between each