adding-board-support.txt 2.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748
  1. // -*- mode:doc; -*-
  2. // vim: set syntax=asciidoc:
  3. [[adding-board-support]]
  4. == Adding support for a particular board
  5. Buildroot contains basic configurations for several publicly available
  6. hardware boards, so that users of such a board can easily build a system
  7. that is known to work. You are welcome to add support for other boards
  8. to Buildroot too.
  9. To do so, you need to create a normal Buildroot configuration that
  10. builds a basic system for the hardware: (internal) toolchain, kernel,
  11. bootloader, filesystem and a simple BusyBox-only userspace. No specific
  12. package should be selected: the configuration should be as minimal as
  13. possible, and should only build a working basic BusyBox system for the
  14. target platform. You can of course use more complicated configurations
  15. for your internal projects, but the Buildroot project will only
  16. integrate basic board configurations. This is because package
  17. selections are highly application-specific.
  18. Once you have a known working configuration, run +make
  19. savedefconfig+. This will generate a minimal +defconfig+ file at the
  20. root of the Buildroot source tree. Move this file into the +configs/+
  21. directory, and rename it +<boardname>_defconfig+. If the configuration
  22. is a bit more complicated, it is nice to manually reformat it and
  23. separate it into sections, with a comment before each section. Typical
  24. sections are _Architecture_, _Toolchain options_ (typically just linux
  25. headers version), _Firmware_, _Bootloader_, _Kernel_, and _Filesystem_.
  26. Always use fixed versions or commit hashes for the different
  27. components, not the "latest" version. For example, set
  28. +BR2_LINUX_KERNEL_CUSTOM_VERSION=y+ and
  29. +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE+ to the kernel version you tested
  30. with.
  31. It is recommended to use as much as possible upstream versions of the
  32. Linux kernel and bootloaders, and to use as much as possible default
  33. kernel and bootloader configurations. If they are incorrect for your
  34. board, or no default exists, we encourage you to send fixes to the
  35. corresponding upstream projects.
  36. However, in the mean time, you may want to store kernel or bootloader
  37. configuration or patches specific to your target platform. To do so,
  38. create a directory +board/<manufacturer>+ and a subdirectory
  39. +board/<manufacturer>/<boardname>+. You can then store your patches
  40. and configurations in these directories, and reference them from the main
  41. Buildroot configuration. Refer to xref:customize[] for more details.