1c24d83cc8
With recent asiidoc versions (at least 10.2.0 is known to report that),
rendering the manual yields a few warnings related to ordered lists:
asciidoc: WARNING: customize-quick-guide.adoc: line 13: list item index: expected 2 got 1
asciidoc: WARNING: customize-quick-guide.adoc: line 15: list item index: expected 3 got 1
[...]
asciidoc: WARNING: customize-quick-guide.adoc: line 65: list item index: expected 13 got 1
asciidoc: WARNING: customize-quick-guide.adoc: line 66: list item index: expected 14 got 1
asciidoc: WARNING: adding-packages-gettext.adoc: line 30: list item index: expected 2 got 1
asciidoc: WARNING: adding-packages-gettext.adoc: line 41: list item index: expected 3 got 1
The reason is that we use the same index to tell asciidoc to
automatically number items.
However, the official way to provide an automatic index is to write no
index:
https://docs.asciidoctor.org/asciidoc/latest/lists/ordered/
[...] since the numbering is obvious, the AsciiDoc processor will
insert the numbers for you if you omit them:
[...]
If you number the ordered list explicitly, you have to manually keep
the list numerals sequential. Otherwise, you will get a warning.
So, abide by the documentation, and drop the repeating indices to
ordered lists where we want automatic numbering.
Note that there is another ordered list, in adding-packages-directory.adoc,
but it does use explicit, sequential numbering. For consistency within
the whole document, we also convert it.
To avoid extra useless churn, the indentation of the items is not
changed to match the elided indices.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
67 lines
3.3 KiB
Plaintext
67 lines
3.3 KiB
Plaintext
// -*- mode:doc; -*-
|
|
// vim: set syntax=asciidoc:
|
|
|
|
=== Quick guide to storing your project-specific customizations
|
|
|
|
Earlier in this chapter, the different methods for making
|
|
project-specific customizations have been described. This section will
|
|
now summarize all this by providing step-by-step instructions to storing your
|
|
project-specific customizations. Clearly, the steps that are not relevant to
|
|
your project can be skipped.
|
|
|
|
. +make menuconfig+ to configure toolchain, packages and kernel.
|
|
. +make linux-menuconfig+ to update the kernel config, similar for
|
|
other configuration like busybox, uclibc, ...
|
|
. +mkdir -p board/<manufacturer>/<boardname>+
|
|
. Set the following options to +board/<manufacturer>/<boardname>/<package>.config+
|
|
(as far as they are relevant):
|
|
* +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE+
|
|
* +BR2_PACKAGE_BUSYBOX_CONFIG+
|
|
* +BR2_UCLIBC_CONFIG+
|
|
* +BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_CONFIG_FILE+
|
|
* +BR2_TARGET_BAREBOX_CUSTOM_CONFIG_FILE+
|
|
* +BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE+
|
|
. Write the configuration files:
|
|
* +make linux-update-defconfig+
|
|
* +make busybox-update-config+
|
|
* +make uclibc-update-config+
|
|
* +cp <output>/build/at91bootstrap3-*/.config
|
|
board/<manufacturer>/<boardname>/at91bootstrap3.config+
|
|
* +make barebox-update-defconfig+
|
|
* +make uboot-update-defconfig+
|
|
. Create +board/<manufacturer>/<boardname>/rootfs-overlay/+ and fill it
|
|
with additional files you need on your rootfs, e.g.
|
|
+board/<manufacturer>/<boardname>/rootfs-overlay/etc/inittab+.
|
|
Set +BR2_ROOTFS_OVERLAY+
|
|
to +board/<manufacturer>/<boardname>/rootfs-overlay+.
|
|
. Create a post-build script
|
|
+board/<manufacturer>/<boardname>/post_build.sh+. Set
|
|
+BR2_ROOTFS_POST_BUILD_SCRIPT+ to
|
|
+board/<manufacturer>/<boardname>/post_build.sh+
|
|
. If additional setuid permissions have to be set or device nodes have
|
|
to be created, create +board/<manufacturer>/<boardname>/device_table.txt+
|
|
and add that path to +BR2_ROOTFS_DEVICE_TABLE+.
|
|
. If additional user accounts have to be created, create
|
|
+board/<manufacturer>/<boardname>/users_table.txt+ and add that path
|
|
to +BR2_ROOTFS_USERS_TABLES+.
|
|
. To add custom patches to certain packages, set +BR2_GLOBAL_PATCH_DIR+
|
|
to +board/<manufacturer>/<boardname>/patches/+ and add your patches
|
|
for each package in a subdirectory named after the package. Each
|
|
patch should be called +<packagename>-<num>-<description>.patch+.
|
|
. Specifically for the Linux kernel, there also exists the option
|
|
+BR2_LINUX_KERNEL_PATCH+ with as main advantage that it can also
|
|
download patches from a URL. If you do not need this,
|
|
+BR2_GLOBAL_PATCH_DIR+ is preferred. U-Boot, Barebox, at91bootstrap
|
|
and at91bootstrap3 also have separate options, but these do not
|
|
provide any advantage over +BR2_GLOBAL_PATCH_DIR+ and will likely be
|
|
removed in the future.
|
|
. If you need to add project-specific packages, create
|
|
+package/<manufacturer>/+ and place your packages in that
|
|
directory. Create an overall +<manufacturer>.mk+ file that
|
|
includes the +.mk+ files of all your packages. Create an overall
|
|
+Config.in+ file that sources the +Config.in+ files of all your
|
|
packages. Include this +Config.in+ file from Buildroot's
|
|
+package/Config.in+ file.
|
|
. +make savedefconfig+ to save the buildroot configuration.
|
|
. +cp defconfig configs/<boardname>_defconfig+
|