doc: Formating clean up

docs/build_system.rst

@@ -57,6 +57,7 @@ Example Project
 ---------------
 
 An example project directory tree might look like this::
+
     - myProject/
                  - Makefile
                  - sdkconfig
@@ -66,11 +67,11 @@ An example project directory tree might look like this::
                                - component2/ - component.mk
                                              - Kconfig
                                              - src1.c
-                                             - include/
-                                                    - component2.h
+                                             - include/ - component2.h
                  - main/       - src1.c
                                - src2.c
                                - component.mk
+
                  - build/
 
 This example "myProject" contains the following elements:
@@ -101,6 +102,7 @@ Minimal Example Makefile
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 ::
+
    PROJECT_NAME := myProject
    
    include $(IDF_PATH)/make/project.mk
@@ -135,7 +137,8 @@ Minimal Component Makefile
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The minimal ``component.mk`` file is an empty file(!). If the file is empty, the default component behaviour is set:
-- All source files in the same directory as the makefile (*.c, *.cpp, *.S) will be compiled into the component library
+
+- All source files in the same directory as the makefile (``*.c``, ``*.cpp``, ``*.S``) will be compiled into the component library
 - A sub-directory "include" will be added to the global include search path for all other components.
 - The component library will be linked into the project app.
 
@@ -209,8 +212,8 @@ The following variables can be set inside ``component.mk`` to control the build
   ``COMPONENT_PRIV_INCLUDEDIRS`` variable, except these paths are not
   expanded relative to the component directory.
 - ``COMPONENT_SRCDIRS``: Directory paths, must be relative to the
-  component directory, which will be searched for source files (*.cpp,
-  *.c, *.S). Defaults to '.', ie the component directory
+  component directory, which will be searched for source files (``*.cpp``,
+  ``*.c``, ``*.S``). Defaults to '.', ie the component directory
   itself. Override this to specify a different list of directories
   which contain source files.
 - ``COMPONENT_OBJS``: Object files to compile. Default value is a .o
@@ -366,12 +369,14 @@ The configuration system can be used to conditionally compile some files
 depending on the options selected in ``make menuconfig``:
 
 ``Kconfig``::
+
     config FOO_ENABLE_BAR
         bool "Enable the BAR feature."
         help
             This enables the BAR feature of the FOO component.
 
 ``component.mk``::
+
     COMPONENT_OBJS := foo_a.o foo_b.o
 
     ifdef CONFIG_FOO_BAR

docs/security/secure-boot.rst

@@ -27,18 +27,18 @@ This is a high level overview of the secure boot process. Step by step instructi
 
 2. Secure Boot Configuration includes "Secure boot signing key", which is a file path. This file is a ECDSA public/private key pair in a PEM format file.
 
-2. The software bootloader image is built by esp-idf with secure boot support enabled and the public key (signature verification) portion of the secure boot signing key compiled in. This software bootloader image is flashed at offset 0x1000.
+3. The software bootloader image is built by esp-idf with secure boot support enabled and the public key (signature verification) portion of the secure boot signing key compiled in. This software bootloader image is flashed at offset 0x1000.
 
-3. On first boot, the software bootloader follows the following process to enable secure boot:
+4. On first boot, the software bootloader follows the following process to enable secure boot:
 
    - Hardware secure boot support generates a device secure bootloader key (generated via hardware RNG, then stored read/write protected in efuse), and a secure digest. The digest is derived from the key, an IV, and the bootloader image contents.
    - The secure digest is flashed at offset 0x0 in the flash.
    - Depending on Secure Boot Configuration, efuses are burned to disable JTAG and the ROM BASIC interpreter (it is strongly recommended these options are turned on.)
    - Bootloader permanently enables secure boot by burning the ABS_DONE_0 efuse. The software bootloader then becomes protected (the chip will only boot a bootloader image if the digest matches.)
 
-4. On subsequent boots the ROM bootloader sees that the secure boot efuse is burned, reads the saved digest at 0x0 and uses hardware secure boot support to compare it with a newly calculated digest. If the digest does not match then booting will not continue. The digest and comparison are performed entirely by hardware, and the calculated digest is not readable by software. For technical details see `Hardware Secure Boot Support`.
+5. On subsequent boots the ROM bootloader sees that the secure boot efuse is burned, reads the saved digest at 0x0 and uses hardware secure boot support to compare it with a newly calculated digest. If the digest does not match then booting will not continue. The digest and comparison are performed entirely by hardware, and the calculated digest is not readable by software. For technical details see `Hardware Secure Boot Support`.
 
-5. When running in secure boot mode, the software bootloader uses the secure boot signing key (the public key of which is embedded in the bootloader itself, and therefore validated as part of the bootloader) to verify the signature appended to all subsequent partition tables and app images before they are booted.
+6. When running in secure boot mode, the software bootloader uses the secure boot signing key (the public key of which is embedded in the bootloader itself, and therefore validated as part of the bootloader) to verify the signature appended to all subsequent partition tables and app images before they are booted.
 
 Keys
 ----