Mirrors/u-boot
1
0
Fork 0
mirror of https://source.denx.de/u-boot/u-boot.git synced 2026-06-13 15:03:58 +03:00
Code Issues Packages Projects Releases Wiki Activity

Merge tag 'doc-2026-04-rc2' of https://source.denx.de/u-boot/custodians/u-boot-efi

Browse Source 
Pull request doc-2026-04-rc2

Documentation:

* describe QEMU VGA emulation
* development process
  - Move the existing block about patch application
  - Rework the custodian feedback section
  - Explain when/how Custodians may edit patches
  - Move Custodians section
  - Make "Work flow of a Custodian" a subsection
  - Document using b4 and patchwork for custodians
* develop: codingstyle: Update b4 external link
* develop: sending_patches: Update link to patchwork
This commit is contained in:
Tom Rini
2026-01-28 17:04:34 -06:00
parent fcd28a598d 302c054d64
commit 6a1bdb7e95
5 changed files with 143 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
doc/board/emulation/index.rst
View File

@@ -9,6 +9,7 @@ Emulation
acpi
blkdev
network
video
qemu-arm
qemu-mips
qemu-ppce500

63
doc/board/emulation/video.rst Normal file
View File

@@ -0,0 +1,63 @@
.. SPDX-License-Identifier: GPL-2.0-or-later
Emulation of a graphics adapter
===============================
Currently QEMU's ``bochs-display`` is the only emulated GPU that U-Boot's
generic QEMU defconfigs support. It emulates a PCIe-connected graphics card
with VESA 2.0 VBE extensions.
The following parameters can be specified:
edid
controls whether EDID information is available. Allowable values are
``off`` and ``on``. The default is ``on``.
vgamem
specifies the display memory size. The default value is 16 MiB.
For UHD resolution 32 MiB is required.
The following configuration parameters are relevant:
CONFIG_VIDEO_BOCHS
enable support for the Bochs GPU.
CONFIG_VIDEO_BOCHS_SIZE_X
defines the display width.
CONFIG_VIDEO_BOCHS_SIZE_Y
defines the display height.
CONFIG_VIDEO_PCI_DEFAULT_FB_SIZE
sets the framebuffer size that QEMU can use for a device driver that is
enabled after relocation. This should be chosen as
.. code-block::
CONFIG_VIDEO_PCI_DEFAULT_FB_SIZE >=
4 * CONFIG_VIDEO_BOCHS_SIZE_X * CONFIG_VIDEO_BOCHS_SIZE_Y
Here is an example QEMU invocation for qemu-riscv64_smode_defconfig:
.. code-block:: bash
qemu-system-riscv64 \
-M virt \
-device bochs-display,vgamem=33554432 \
-serial mon:stdio \
-device qemu-xhci \
-device usb-kbd \
-kernel u-boot
``mon:stdio`` provides a serial console, ``qemu-xhci`` a USB root hub,
``usb-kbd`` a USB keyboard.
To start QEMU without GPU emulation, use parameter ``-nographic``, as shown in
the following example:
.. code-block:: bash
qemu-system-riscv64 \
-M virt \
-nographic \
-kernel u-boot

4
doc/develop/codingstyle.rst
View File

@@ -24,7 +24,9 @@ The following rules apply:
<https://peps.python.org/pep-0008/>`_. Use `pylint
<https://github.com/pylint-dev/pylint>`_ for checking the code.
* Use the `b4 <https://git.kernel.org/pub/scm/utils/b4/b4.git/>`_ tool to prepare and
.. _b4_contrib:
* Use the `b4 <https://b4.docs.kernel.org/en/latest/>`__ tool to prepare and
send your patches. b4 has become the preferred tool to sending patches for many
Linux kernel contributors, and U-Boot ships with a ready-to-use ``.b4-config`` that
targets ``u-boot@lists.denx.de`` and integrates with ``scripts/get_maintainer.pl`` for

106
doc/develop/process.rst
View File

@@ -120,29 +120,6 @@ these can be "cherry-picked" and are subject to the normal merge rules. For
example, a bug fix can come in later in the window but a full re-sync only
happens within the merge window itself.
.. _custodians:
Custodians
----------
The Custodians take responsibility for some area of the U-Boot code. The
in-tree ``MAINTAINERS`` files list who is responsible for which areas.
It is their responsibility to pick up patches from the mailing list
that fall into their responsibility, and to process these.
A very important responsibility of each custodian is to provide
feedback to the submitter of a patch about what is going on: if the
patch was accepted, or if it was rejected (which exact list of
reasons), if it needs to be reworked (with respective review
comments). Even a "I have no time now, will look into it later"
message is better than nothing. Also, if there are remarks to a
patch, these should leave no doubt if they were just comments and the
patch will be accepted anyway, or if the patch should be
reworked/resubmitted, or if it was rejected. However, if a submitter
feels it has been too long since posting their patch and not received
any feedback, it is OK to follow-up and ask.
Review Process, Git Tags
------------------------
@@ -214,8 +191,78 @@ document.
For example, when your change affects a specific board or driver, then makes
a lot of sense to put the respective maintainer of this code on Cc:
.. _custodians:
Custodians
----------
The Custodians take responsibility for some area of the U-Boot code. The
in-tree ``MAINTAINERS`` files list who is responsible for which areas.
It is their responsibility to pick up patches from the mailing list
that fall into their responsibility, and to process these.
A very important responsibility of each custodian is to provide
feedback to the submitter of a patch about what is going on:
* If the patch was accepted, or if it was rejected (with exact list
of reasons), if it needs to be reworked (with respective review
comments). Even a "I have no time now, will look into it later"
message is better than nothing. Also, if there are remarks to a
patch, these should leave no doubt if they were just comments and
the patch will be accepted anyway, or if the patch should be
reworked/resubmitted, or if it was rejected. However, if a submitter
feels it has been too long since posting their patch and not
received any feedback, it is OK to follow-up and ask.
* A custodian may make changes suggested by :doc:`checkpatch.pl
<checkpatch>`. They must also in turn amend the commit message noting
their change, for example ``[trini: Fix typos]``, and add their own
:ref:`Signed-off-by <dco>` tag. All other changes must be handled by
another iteration of the patch, or follow-up patch.
* If the patch itself can still be applied to the tree. The custodian
is expected to put in a "best effort" if a patch does not apply
cleanly, but can be made to apply still. It is up to the custodian
to decide how recent of a commit the patch must be against. It is
acceptable to request patches against the last officially released
version of U-Boot or newer. Of course a custodian can also accept
patches against older code. It can be difficult to find the correct
balance between putting too much work on the custodian or too much
work on an individual submitting a patch when something does not
apply cleanly.
Tooling
^^^^^^^
There are a number of tools available to help custodians and
contributors alike with their contributions. As a project we make use of
the Patchwork project hosted at `OzLabs <http://patchwork.ozlabs.org/>`__
and more discussion on how it is used from both a contributor as well as
custodian point of view can be found :ref:`here <patchwork>`.
Another useful tool is `b4 <https://b4.docs.kernel.org/en/latest/>`__
and is documented from a contributor point of view :ref:`here
<b4_contrib>`. It also has a number of useful features from a custodian
point of view:
* `Integration with patchwork
<https://b4.docs.kernel.org/en/latest/config.html#patchwork-integration-settings>`__
which allows for automatic state tracking.
* `"am" and "shazam"
<https://b4.docs.kernel.org/en/latest/maintainer/am-shazam.html>`__
for applying a patch or series of patches. Of note is that with
``shazam`` review tags can be applied automatically and cover letters
can be integrated as part of merging a series.
* `"ty" <https://b4.docs.kernel.org/en/latest/maintainer/ty.html>`__ for
automatically sending emails once patches have been applied. It is
strongly encouraged to keep the default ``${summary}`` in the template
as that shows what the git commit hash is for a particular patch.
Work flow of a Custodian
------------------------
^^^^^^^^^^^^^^^^^^^^^^^^
The normal flow of work in the U-Boot development process will look
like this:
@@ -236,15 +283,8 @@ like this:
#. U-Boot Philosophy, as documented in :doc:`designprinciples`.
#. Applies cleanly to the source tree. The custodian is expected to put in
a "best effort" if a patch does not apply cleanly, but can be made to apply
still. It is up to the custodian to decide how recent of a commit the
patch must be against. It is acceptable to request patches against the
last officially released version of U-Boot or newer. Of course a
custodian can also accept patches against older code. It can be
difficult to find the correct balance between putting too much work on
the custodian or too much work on an individual submitting a patch when
something does not apply cleanly.
#. Can be applied easily to the source tree, as documented in the
:ref:`custodians` section.
#. Passes :doc:`ci_testing` as this checks for new warnings and other issues.

4
doc/develop/sending_patches.rst
View File

@@ -322,10 +322,12 @@ Notes
the memory footprint of the code. Remember: Small is beautiful! When adding
new features follow the guidelines laid out in :doc:`system_configuration`.
.. _patchwork:
Patch Tracking
--------------
Like some other projects, U-Boot uses `Patchwork <http://patchwork.ozlabs.org/>`_
Like some other projects, U-Boot uses `Patchwork <http://patchwork.ozlabs.org/>`__
to track the state of patches. This is one of the reasons why it is mandatory
to submit all patches to the U-Boot mailing list - only then they will be
picked up by patchwork.