7 files changed, 89 insertions, 7 deletions
diff --git a/doc/develop/bootstd.rst b/doc/develop/bootstd.rst
index b8773f8339d..f7fc7257076 100644
--- a/doc/develop/bootstd.rst
+++ b/doc/develop/bootstd.rst
@@ -21,7 +21,7 @@ feature is typically called `distro boot` (see :doc:`distro`) because it is
 a way for distributions to boot on any hardware.
 
 Traditionally U-Boot has relied on scripts to implement this feature. See
-disto_boodcmd_ for details. This is done because U-Boot has no native support
+distro_bootcmd_ for details. This is done because U-Boot has no native support
 for scanning devices. While the scripts work remarkably well, they can be hard
 to understand and extend, and the feature does not include tests. They are also
 making it difficult to move away from ad-hoc CONFIGs, since they are implemented
@@ -52,7 +52,7 @@ BootLoaderSpec_ format. which looks something like this::
        initrd /initramfs-5.3.7-301.fc31.armv7hl.img
 
 As you can see it specifies a kernel, a ramdisk (initrd) and a directory from
-which to load devicetree files. The details are described in disto_boodcmd_.
+which to load devicetree files. The details are described in distro_bootcmd_.
 
 The bootflow is provided by the distro. It is not part of U-Boot. U-Boot's job
 is simply to interpret the file and carry out the instructions. This allows
@@ -669,7 +669,7 @@ Other ideas:
   not need to specify things like `pxefile_addr_r`
 
 
-.. _disto_boodcmd: https://github.com/u-boot/u-boot/blob/master/include/config_distro_bootcmd.h
+.. _distro_bootcmd: https://github.com/u-boot/u-boot/blob/master/include/config_distro_bootcmd.h
 .. _BootLoaderSpec: http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
 .. _distro_boot: https://github.com/u-boot/u-boot/blob/master/boot/distro.c
 .. _bootflow_h: https://github.com/u-boot/u-boot/blob/master/include/bootflow.h
diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst
index a6bc37bbb44..1d5d0192b3e 100644
--- a/doc/develop/codingstyle.rst
+++ b/doc/develop/codingstyle.rst
@@ -248,5 +248,5 @@ will be much faster (10-100x or more) if they can directly call run_command()
 and ut_check_console_line() instead of using Python to send commands over a
 pipe to U-Boot.
 
-Tests run all supported CI systems (gitlab, travis, azure) using scripts in the
-root of the U-Boot tree.
+Tests run all supported CI systems (GitLab, Azure) using scripts in the root of
+the U-Boot tree.
diff --git a/doc/develop/crash_dumps.rst b/doc/develop/crash_dumps.rst
index 85030b4e360..4237b073bc9 100644
--- a/doc/develop/crash_dumps.rst
+++ b/doc/develop/crash_dumps.rst
@@ -12,8 +12,8 @@ Creating a crash dump voluntarily
 ---------------------------------
 
 For describing the analysis of a crash dump we need an example. U-Boot comes
-with a command 'exception' that comes in handy here. The command is enabled
-by::
+with a command :doc:`exception <../usage/cmd/exception>` that comes in handy
+here. The command is enabled by::
 
     CONFIG_CMD_EXCEPTION=y
 
@@ -122,3 +122,63 @@ If we want to dive deeper, we can disassemble the U-Boot binary::
 
 This example is based on the ARMv8 architecture but the same procedures can be
 used on other architectures as well.
+
+Crashs in UEFI binaries
+-----------------------
+
+If UEFI images are loaded when a crash occurs, their load addresses are
+displayed. If the process counter points to an address in a loaded UEFI
+binary, the relative process counter position is indicated. Here is an
+example executed on the U-Boot sandbox::
+
+    => load host 0:1 $kernel_addr_r buggy.efi
+    5632 bytes read in 0 ms
+    => bootefi $kernel_addr_r
+    Booting /buggy.efi
+    Buggy world!
+
+    Segmentation violation
+    pc = 0x19fc264c, pc_reloc = 0xffffaa4688b1664c
+
+    UEFI image [0x0000000019fc0000:0x0000000019fc6137] pc=0x264c '/buggy.efi'
+
+The crash occured in UEFI binary buggy.efi at relative position 0x264c.
+Disassembly may be used to find the actual source code location::
+
+    $ x86_64-linux-gnu-objdump -S -D buggy_efi.so
+
+    0000000000002640 <memset>:
+        2640:       f3 0f 1e fa             endbr64
+        2644:       48 89 f8                mov    %rdi,%rax
+        2647:       48 89 f9                mov    %rdi,%rcx
+        264a:       eb 0b                   jmp    2657 <memset+0x17>
+        264c:       40 88 31                mov    %sil,(%rcx)
+
+Architecture specific details
+-----------------------------
+
+ARMv8
+~~~~~
+
+On the ARM 64-bit architecture CONFIG_ARMV8_SPL_EXCEPTION_VECTORS controls
+if the exception vector tables are set up in the Secondary Program Loader (SPL).
+Without initialization of the tables crash dumps cannot be shown. The feature is
+disabled by default on most boards to reduce the size of the SPL.
+
+RISC-V
+~~~~~~
+
+On the RISC-V architecture CONFIG_SHOW_REGS=y has to be specified to show
+all registers in crash dumps.
+
+Sandbox
+~~~~~~~
+
+The sandbox U-Boot binary must be invoked with parameter *-S* to display crash
+dumps:
+
+.. code-block:: bash
+
+    ./u-boot -S -T
+
+Only with CONFIG_SANDBOX_CRASH_RESET=y the sandbox reboots after a crash.
diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index c94c7fe0efa..f7ee09db246 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -14,6 +14,7 @@ General
    process
    release_cycle
    system_configuration
+   sending_patches
 
 Implementation
 --------------
diff --git a/doc/develop/patman.rst b/doc/develop/patman.rst
new file mode 120000
index 00000000000..0fcb7d61d40
--- /dev/null
+++ b/doc/develop/patman.rst
@@ -0,0 +1 @@
+../../tools/patman/patman.rst
+\ No newline at end of file
diff --git a/doc/develop/process.rst b/doc/develop/process.rst
index 0ef24e81998..388945cf9bb 100644
--- a/doc/develop/process.rst
+++ b/doc/develop/process.rst
@@ -139,6 +139,10 @@ like this:
    as the Linux kernel.  Following this and adding a ``Signed-off-by:`` line
    that contains the developer's name and email address is required.
 
+   * Please note that when importing code from other projects you must say
+     where it comes from, and what revision you are importing. You must not
+     however copy ``Signed-off-by`` or other tags.
+
 #. Everybody who can is invited to review and test the changes.  Typically, we
    follow the same guidelines as the Linux kernel for `Acked-by
    <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by>`_
diff --git a/doc/develop/sending_patches.rst b/doc/develop/sending_patches.rst
new file mode 100644
index 00000000000..0542adeaed9
--- /dev/null
+++ b/doc/develop/sending_patches.rst
@@ -0,0 +1,16 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Sending patches
+===============
+
+.. toctree::
+   :maxdepth: 2
+
+   patman
+
+
+You can use a tool called patman to prepare, check and sent patches. It creates
+change logs, cover letters and patch notes. It also simplified the process of
+sending multiple versions of a series.
+
+See more details at :doc:`patman`.