customize-store.txt 7.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157
  1. // -*- mode:doc; -*-
  2. // vim: set syntax=asciidoc:
  3. [[customize-store]]
  4. == Storing the configuration
  5. When you have a buildroot configuration that you are satisfied with and
  6. you want to share it with others, put it under revision control or move
  7. on to a different buildroot project, you need to store the configuration
  8. so it can be rebuilt later. The configuration that needs to be stored
  9. consists of the buildroot configuration, the configuration files for
  10. packages that you use (kernel, busybox, uClibc, ...), and your rootfs
  11. modifications.
  12. [[customize-store-basics]]
  13. === Basics for storing the configuration
  14. [[customize-store-buildroot-config]]
  15. ==== Buildroot configuration
  16. For storing the buildroot configuration itself, buildroot offers the
  17. following command: +make savedefconfig+.
  18. This strips the buildroot configuration down by removing configuration
  19. options that are at their default value. The result is stored in a file
  20. called +defconfig+. If you want to save it in another place, change
  21. the +BR2_DEFCONFIG+ option, or call make with +make savedefconfig
  22. BR2_DEFCONFIG=<path-to-defconfig>+. The usual place is
  23. +configs/<boardname>_defconfig+. The configuration can then be rebuilt by
  24. running +make <boardname>_defconfig+.
  25. Alternatively, you can copy the file to any other place and rebuild with
  26. +make defconfig BR2_DEFCONFIG=<path-to-defconfig-file>+.
  27. [[customize-store-package-config]]
  28. ==== Other package configuration
  29. The configuration files for busybox, the linux kernel, barebox and
  30. uClibc should be stored as well if changed. For each of these, a
  31. buildroot configuration option exists to point to an input
  32. configuration file, e.g. +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE+. To
  33. save their configuration, set those configuration options to a path
  34. outside your output directory,
  35. e.g. +board/<manufacturer>/<boardname>/linux.config+. Then, copy the
  36. configuration files to that path.
  37. Make sure that you create a configuration file 'before' changing
  38. the +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE+ etc. options. Otherwise,
  39. buildroot will try to access this config file, which doesn't exist
  40. yet, and will fail. You can create the configuration file by running
  41. +make linux-menuconfig+ etc.
  42. Buildroot provides a few helper targets to make the saving of
  43. configuration files easier.
  44. * +make linux-update-defconfig+ saves the linux configuration to the
  45. path specified by +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE+. It
  46. simplifies the config file by removing default values. However,
  47. this only works with kernels starting from 2.6.33. For earlier
  48. kernels, use +make linux-update-config+.
  49. * +make busybox-update-config+ saves the busybox configuration to the
  50. path specified by +BR2_PACKAGE_BUSYBOX_CONFIG+.
  51. * +make uclibc-update-config+ saves the uClibc configuration to the
  52. path specified by +BR2_UCLIBC_CONFIG+.
  53. * +make barebox-update-defconfig+ saves the barebox configuration to the
  54. path specified by +BR2_TARGET_BAREBOX_CUSTOM_CONFIG_FILE+.
  55. * For at91bootstrap3, no helper exists so you have to copy the config
  56. file manually to +BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_CONFIG_FILE+.
  57. [[customize-store-board-support]]
  58. === Creating your own board support
  59. Creating your own board support in Buildroot allows users of a
  60. particular hardware platform to easily build a system that is known to
  61. work.
  62. To do so, you need to create a normal Buildroot configuration that
  63. builds a basic system for the hardware: toolchain, kernel, bootloader,
  64. filesystem and a simple BusyBox-only userspace. No specific package
  65. should be selected: the configuration should be as minimal as
  66. possible, and should only build a working basic BusyBox system for the
  67. target platform. You can of course use more complicated configurations
  68. for your internal projects, but the Buildroot project will only
  69. integrate basic board configurations. This is because package
  70. selections are highly application-specific.
  71. Once you have a known working configuration, run +make
  72. savedefconfig+. This will generate a minimal +defconfig+ file at the
  73. root of the Buildroot source tree. Move this file into the +configs/+
  74. directory, and rename it +<boardname>_defconfig+.
  75. It is recommended to use as much as possible upstream versions of the
  76. Linux kernel and bootloaders, and to use as much as possible default
  77. kernel and bootloader configurations. If they are incorrect for your
  78. board, or no default exists, we encourage you to send fixes to the
  79. corresponding upstream projects.
  80. However, in the mean time, you may want to store kernel or bootloader
  81. configuration or patches specific to your target platform. To do so,
  82. create a directory +board/<manufacturer>+ and a subdirectory
  83. +board/<manufacturer>/<boardname>+. You can then store your patches
  84. and configurations in these directories, and reference them from the main
  85. Buildroot configuration.
  86. === Step-by-step instructions for storing configuration
  87. To store the configuration for a specific product, device or
  88. application, it is advisable to use the same conventions as for the
  89. board support: put the buildroot defconfig in the +configs+ directory,
  90. and any other files in a subdirectory of the +boards+ directory. This
  91. section gives step-by-step instructions about how to do that. Of course,
  92. you can skip the steps that are not relevant for your use case.
  93. 1. +make menuconfig+ to configure toolchain, packages and kernel.
  94. 1. +make linux-menuconfig+ to update the kernel config, similar for
  95. other configuration.
  96. 1. +mkdir -p board/<manufacturer>/<boardname>+
  97. 1. Set the following options to +board/<manufacturer>/<boardname>/<package>.config+
  98. (as far as they are relevant):
  99. * +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE+
  100. * +BR2_PACKAGE_BUSYBOX_CONFIG+
  101. * +BR2_UCLIBC_CONFIG+
  102. * +BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_CONFIG_FILE+
  103. * +BR2_TARGET_BAREBOX_CUSTOM_CONFIG_FILE+
  104. 1. Write the configuration files:
  105. * +make linux-update-defconfig+
  106. * +make busybox-update-config+
  107. * +make uclibc-update-config+
  108. * +cp <output>/build/at91bootstrap3-*/.config board/<manufacturer>/<boardname>/at91bootstrap3.config+
  109. * +make barebox-update-defconfig+
  110. 1. Create +board/<manufacturer>/<boardname>/fs-overlay/+ and fill it
  111. with additional files you need on your rootfs, e.g.
  112. +board/<manufacturer>/<boardname>/fs-overlay/etc/inittab+.
  113. Set +BR2_ROOTFS_OVERLAY+
  114. to +board/<manufacturer>/<boardname>/fs-overlay+.
  115. 1. Create a post-build script
  116. +board/<manufacturer>/<boardname>/post-build.sh+. Set
  117. +BR2_ROOTFS_POST_BUILD_SCRIPT+ to
  118. +board/<manufacturer>/<boardname>/post-build.sh+
  119. 1. If additional setuid permissions have to be set or device nodes have
  120. to be created, create +board/<manufacturer>/<boardname>/device_table.txt+
  121. and add that path to +BR2_ROOTFS_DEVICE_TABLE+.
  122. 1. +make savedefconfig+ to save the buildroot configuration.
  123. 1. +cp defconfig configs/<boardname>_defconfig+
  124. 1. To add patches to the linux build, set +BR2_LINUX_KERNEL_PATCH+ to
  125. +board/<manufacturer>/<boardname>/patches/linux/+ and add your
  126. patches in that directory. Each patch should be called
  127. +linux-<num>-<description>.patch+. Similar for U-Boot, barebox,
  128. at91bootstrap and at91bootstrap3.
  129. 1. If you need modifications to other packages, or if you need to add
  130. packages, do that directly in the +packages/+ directory, following the
  131. instructions in xref:adding-packages[].