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>
Yann E. MORIN 10 months ago
parent
commit
17bdd10cb3
1 changed files with 1 additions and 5 deletions
  1. 1 5
      docs/manual/adding-board-support.adoc

+ 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