mirror of
https://github.com/smaeul/u-boot.git
synced 2025-10-24 17:48:14 +01:00
fa43709b8d
To help guide developers down the right path, begin a document that lists some best practices to follow when creating a new board port. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
27 lines
993 B
ReStructuredText
27 lines
993 B
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0+:
|
|
|
|
Best Practices for Board Ports
|
|
==============================
|
|
|
|
In addition to the regular best practices such as using :doc:`checkpatch` and
|
|
following the :doc:`docstyle` and the :doc:`codingstyle` there are some things
|
|
which are specific to creating a new board port.
|
|
|
|
* Implement :doc:`bootstd` to ensure that most operating systems will be
|
|
supported by the platform.
|
|
|
|
* The platform defconfig file must be generated via `make savedefconfig`.
|
|
|
|
* The Kconfig and Kbuild infrastructure supports using "fragments" that can be
|
|
used to apply changes on top of a defconfig file. These can be useful for
|
|
many things such as:
|
|
|
|
* Supporting different firmware locations (e.g. eMMC, SD, QSPI).
|
|
|
|
* Multiple board variants when runtime detection is not desired.
|
|
|
|
* Supporting different build types such as production and development.
|
|
|
|
Kconfig fragments should reside in the board directory itself rather than in
|
|
the top-level `configs/` directory.
|