Browse Source

docs/manual: do not instruct doctoring the saved defconfig

Doctoring a defconfig is tedious, and it is not easy to update a
defconfig, as it requires manual copy-pasting, adding comments and so
on...

Instead, just require defconfigs to be generated with 'savedefconfig'.
Any details can/must be provided in the commit log.

Reported-by: Edgar Bonet <bonet@grenoble.cnrs.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit 17bdd10cb350e9c45926c2a5a05f278d104ee4c9)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Yann E. MORIN 10 tháng trước cách đây
mục cha
commit
87cb2999c3

+ 1 - 5
docs/manual/adding-board-support.adoc

@@ -22,11 +22,7 @@ selections are highly application-specific.
 Once you have a known working configuration, run +make
 Once you have a known working configuration, run +make
 savedefconfig+. This will generate a minimal +defconfig+ file at the
 savedefconfig+. This will generate a minimal +defconfig+ file at the
 root of the Buildroot source tree. Move this file into the +configs/+
 root of the Buildroot source tree. Move this file into the +configs/+
-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_.
+directory, and rename it +<boardname>_defconfig+.
 
 
 Always use fixed versions or commit hashes for the different
 Always use fixed versions or commit hashes for the different
 components, not the "latest" version. For example, set
 components, not the "latest" version. For example, set