path: root/Documentation
diff options
authorSascha Hauer <>2019-09-12 07:53:05 +0200
committerSascha Hauer <>2019-09-12 07:53:05 +0200
commit9b1102c02bfd39352e0d2995c733edb7be3b0601 (patch)
tree3f089c640bab75c020b69f5dcf44d744a0a7f2e4 /Documentation
parentf48a1596f4e911d4516b986e4778f18321b39b48 (diff)
parenta10dbfc4175867c0d15f02b7f244837c5d41478e (diff)
Merge branch 'for-next/misc'
Diffstat (limited to 'Documentation')
3 files changed, 11 insertions, 5 deletions
diff --git a/Documentation/boards/efi.rst b/Documentation/boards/efi.rst
index 3da2daa..2178c9a 100644
--- a/Documentation/boards/efi.rst
+++ b/Documentation/boards/efi.rst
@@ -43,7 +43,7 @@ name it ``BOOTx64.EFI`` on 64bit architectures and ``BOOTIA32.EFI`` on 32bit
architectures. Switching to USB boot in the BIOS should then be enough to
start barebox via USB. Some BIOSes allow to specify a path to a binary to
be executed, others have a "start UEFI shell" entry which executes
-EFI/Shellx64.efi on the :term:`ESP`. This can be a barebox binary aswell.
+EFI/Shellx64.efi on the :term:`ESP`. This can be a barebox binary as well.
To use the :ref:`state_framework`, the describing devicetree file ``state.dtb``
has to be put into the ``EFI/barebox/`` directory.
Supported backends for EFI are raw partitions that can be discovered via a
@@ -200,7 +200,7 @@ EFI device paths
In EFI each device can be pointed to using a device path. Device paths have multiple
components. The toplevel component on X86 systems will be the PCI root complex, on
-other systems this can be the physical memory space. Each component will now descrive
+other systems this can be the physical memory space. Each component will now describe
how to find the child component on the parent bus. Additional device path nodes can
describe network addresses or filenames on partitions. Device paths have a binary
representation and a clearly defined string representation. These characteristics make
@@ -274,7 +274,7 @@ Network Protocol GUID:
EFI_GUID( 0xA19832B9, 0xAC25, 0x11D3, 0x9A, 0x2D, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D )
Matching between EFI devices and drivers is done based on the Protocol GUIDs, so
-whenever a driver GUID matches one of the GUIDs a device imeplements the drivers
+whenever a driver GUID matches one of the GUIDs a device implements the drivers
probe function is called.
.. _efi_building_edk2:
diff --git a/Documentation/boards/imx/zii-imx7d-dev/openocd.cfg b/Documentation/boards/imx/zii-imx7d-dev/openocd.cfg
index f971c3f..6056b89 100644
--- a/Documentation/boards/imx/zii-imx7d-dev/openocd.cfg
+++ b/Documentation/boards/imx/zii-imx7d-dev/openocd.cfg
@@ -138,6 +138,12 @@ proc start_barebox { } {
+# disable internal reset-assert handling to
+# allow reset-init to work
+$_TARGETNAME.0 configure -event reset-assert ""
+$_TARGETNAME.1 configure -event reset-assert ""
+$_TARGETNAME_2 configure -event reset-assert ""
# hook the init function into the reset-init event
${_TARGETNAME}.0 configure -event reset-init { board_init }
diff --git a/Documentation/ b/Documentation/
index ec6ec04..bcd8633 100644
--- a/Documentation/
+++ b/Documentation/
@@ -53,9 +53,9 @@ copyright = u'2014, The barebox project'
# The short X.Y version.
import os
-version = os.environ["KERNELVERSION"]
+version = os.environ.get("KERNELVERSION", 'unknown version')
# The full version, including alpha/beta/rc tags.
-release = os.environ["KERNELRELEASE"]
+release = os.environ.get("KERNELRELEASE", 'unknown release')
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.