fix Markdown issues

- reduce headline levels
- `markdownlint-cli2 --fix 'src/**/*.md' !src/SUMMARY.md`

Signed-off-by: Daniel Maslowski <[email protected]>

Author: orangecms

src/SUMMARY.md

@@ -1,6 +1,6 @@
 - [PSI Spec Introduction](intro.md)
-    * [Application Processors](application-processors.md)
-    * [Peripherals](peripherals.md)
+  - [Application Processors](application-processors.md)
+  - [Peripherals](peripherals.md)
 - [Mask ROMs and Loaders](mask-roms-loaders.md)
 - [Platform Initialization](platform-initialization.md)
 - [Boot Environments](boot-environments.md)

src/application-processors.md

@@ -1,4 +1,4 @@
-## Application Processors
+# Application Processors
 
 An _Application Processor_ (AP) is the main processing unit of a system,
 commonly designed as a _System on Chip_ (SoC). APs are sometimes also considered
@@ -8,7 +8,7 @@ over the years, psi-spec is concerned with the kind of processors that feature a
 _Memory Management Unit_ (MMU) and DRAM, allowing for many concurrent tasks and
 processing large amounts of data.
 
-### System on Chip
+## System on Chip
 
 An SoC integrates processing units with IO [peripherals](peripherals.md) via
 internal system buses and networks, all packaged into one chip.

src/boot-environments.md

@@ -1,4 +1,4 @@
-## Boot Environments
+# Boot Environments
 
 A _boot environment_ is the hosting system of a _boot loader_.
 

src/intro.md

@@ -1,10 +1,10 @@
-## Introduction
+# Introduction
 
 ![PSI logo](images/logo.svg)
 
 The Platform System Interface Specification, or _psi-spec_, is
 a collection of documents for [hardware and software co-design](
-#) from a general perspective.
+# ) from a general perspective.
 It describes how [microprocessors](./application-processors) provide an
 [environment for booting](boot-environments.md) operating systems or otherwise
 bare-metal applications, typically starting from intermediate, rewritable code

src/mask-roms-loaders.md

@@ -1,4 +1,4 @@
-## Mask ROMs and Loaders
+# Mask ROMs and Loaders
 
 Many SoCs have initial pieces of code baked into them to bootstrap the system.
 Some may call them boot ROMs, otherwise known as mask ROMs or Zero Stage Boot
@@ -16,7 +16,7 @@ of such a mechanism, they also have their own software utilities that understand
 the respective protocol. With that software, one may read out chip information,
 perform MMIO access, transfer data into memory and execute it, set fuses, etc.
 
-### Generic protocols, variants and tools
+## Generic protocols, variants and tools
 
 - [USB Device Firmware Upgrade (DFU)](https://www.usb.org/document-library/device-firmware-upgrade-11-new-version-31-aug-2004)
   - [STM32](https://www.st.com/resource/en/application_note/an3156-usb-dfu-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf)
@@ -26,7 +26,7 @@ perform MMIO access, transfer data into memory and execute it, set fuses, etc.
   - [U-Boot documentation on fastboot](https://docs.u-boot.org/en/latest/android/fastboot-protocol.html)
   - [fastboot host-side implementation in Rust](https://github.com/platform-system-interface/fastboot)
 
-### Vendor specific protocols and tools
+## Vendor specific protocols and tools
 
 - Allwinner: FEL mode, usable with
   - [`sunxi-fel`](https://github.com/linux-sunxi/sunxi-tools)

src/peripherals.md

@@ -1,4 +1,4 @@
-## Peripherals
+# Peripherals
 
 Systems connect with external hardware components, also known as _peripherals_,
 using buses and controllers. A controller is a unit driving a bus, such as the

src/platform-initialization.md

@@ -1,4 +1,4 @@
-## Platform Initialization
+# Platform Initialization
 
 Booting a rich, virtual memory operating system poses challenges. While modern
 machines may offer gigabytes or even terabytes of _dynamic random access memory_
@@ -12,7 +12,7 @@ controllers as needed to load and boot an operating system. Due to the high
 diversity of hardware, every SoC, SoM and mainboard comes with specific
 necessities.
 
-### Boot Flows
+## Boot Flows
 
 Since memory and storage parts can be complex, additional firmware and loaders
 are implemented in software. They would initialize the platform step by step,
@@ -29,8 +29,8 @@ phase by phase, or stage by stage; projects differ in naming.
 | oreboot           | mask ROM |    boot block    |  bt0  |        main        |      LinuxBoot      |     OS     |
 
 **Note**:
-[oreboot
-](https://github.com/oreboot/oreboot/tree/main/Documentation/boot-flow.md) and
+[oreboot](https://github.com/oreboot/oreboot/tree/main/Documentation/boot-flow.md)
+and
 [coreboot](https://doc.coreboot.org/getting_started/architecture.html) do not
 implement boot loaders to access external storage themselves. Instead, they
 provide options for payloads that could load a final OS or stand for themselves;
@@ -56,16 +56,16 @@ unless ways to circumvent the verification are found. This is also true for many
 OEM products in general, where custom firmware is not part of the product
 design. I.e., it is [protected against modification](platform-security.md).
 
-### References
+## References
 
-#### Arm platforms
+### Arm platforms
 
 - [How Arm systems are booted](https://youtu.be/GXFw8SV-51g)
 - [U-Boot / Amlogic](https://youtu.be/u0-swEMDFp0)
 - Arm secure boot chain on Ampere Altra
-  * [Armed to boot talk](https://youtu.be/i2IG6Au34xM)
-  * [Armed to boot blog post](https://blog.cloudflare.com/armed-to-boot/)
+  - [Armed to boot talk](https://youtu.be/i2IG6Au34xM)
+  - [Armed to boot blog post](https://blog.cloudflare.com/armed-to-boot/)
 
-#### RISC-V platforms
+### RISC-V platforms
 
-**TODO**
+TODO

src/platform-security.md

@@ -1,4 +1,4 @@
-## Platform Security
+# Platform Security
 
 In order to design a secure platform, each and every component in the boot
 process must be _measured_ and/or _verified_. In addition, the platform in its