markdownlint-cli2 --fix src/**/*.md

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

Author: orangecms

src/case_studies/TiogaPass.md

@@ -14,15 +14,15 @@ Corporation](http://www.wiwynn.com/english).
 
 It contains following sections:
 
-* [Quick Start](#Quick-Start)
-* [Details](#Details)
-  * [How to build](#How-to-build)
-  * [How to operate](#How-to-operate)
-  * [Platform info](#Platform-info)
-* [Support](#Support)
-  * [Hardware support](#Hardware-support)
-  * [Community support](#Community-support)
-  * [Professional support](#Professional-support)
+* [Quick Start](#quick-start)
+* [Details](#details)
+  * [How to build](#how-to-build)
+  * [How to operate](#how-to-operate)
+  * [Platform info](#platform-info)
+* [Support](#support)
+  * [Hardware support](#hardware-support)
+  * [Community support](#community-support)
+  * [Professional support](#professional-support)
 
 ## Quick Start
 
@@ -33,11 +33,14 @@ It contains following sections:
 * Flash the firmware.
   * Copy the downloaded firmware to OpenBMC.
   * From OpenBMC
+
     ```
       fw-util mb --update bios --force ./<firmware image name>
     ```
+
 * Boot and enjoy.
   * From OpenBMC
+
     ```
       power-util mb reset
       sol-util mb
@@ -47,7 +50,7 @@ It contains following sections:
 
 ### How to build
 
-Follow [Build Details](#Build-Details) for details on how to get the source
+Follow [Build Details](#build-details) for details on how to get the source
 code, and how to build.
 
 Boot flow of the current firmware solution is: Power on → minimized UEFI →
@@ -59,15 +62,19 @@ target OS.
 #### Build Details
 
 * Download the code from [linuxboot github](https://github.com/linuxboot/linuxboot)
+
   ```
     git clone https://github.com/linuxboot/linuxboot.git
   ```
+
 * You need to apply Wiwiynn's linuxboot patch for now
+
   ```
   cd linuxboot
   wget -O TiogaPass.patch https://github.com/johnnylinwiwynn/linuxboot/commit/28ae8450b3b05c6e6b8c74e29d0974ccf711d5e6.patch
   git am TiogaPass.patch
   ```
+
 * Build the kernel bzImage (has embedded initramfs) for linuxboot, please
   reference [Building u-root](https://github.com/linuxboot/book/tree/master/coreboot.u-root.systemboot#building-u-root)
   and [Building a suitable Linux kernel](https://github.com/linuxboot/book/tree/master/coreboot.u-root.systemboot#building-a-suitable-linux-kernel)
@@ -77,12 +84,14 @@ target OS.
 * Place the tioga.rom into linuxboot/boards/tioga which is provided from Wiwynn
   after ordering, and also put your bzImage to the root folder of linuxboot,
   and then make
+
   ```
     cp path/to/tioga.rom linuxboot/boards/tioga
     cp path/to/bzImage linuxboot
     cd linuxboot
     BOARD=tioga make
   ```
+
 * You should see the built image at build/tioga/linuxboot.rom.
 
 ### How to operate
@@ -122,4 +131,4 @@ IRC channel, a mailing list and regular meetings.
 
 Following companies provides professional support services:
 
-** TBD **
+**TBD**

src/coreboot.u-root.systemboot/index.md

@@ -78,7 +78,7 @@ path with `-o`. Run `u-root -h` for additional command line parameters.
 Note: the above command will include only pure-Go commands from `u-root`. If
 you need to include other files or non-Go binaries, use the `-file` option in
 `u-root`.  For example, you may want to include static builds of `kexec` or
-`flashrom`, that we build on https://github.com/systemboot/binaries .
+`flashrom`, that we build on <https://github.com/systemboot/binaries> .
 
 Then, the initramfs has to be compressed. This step is necessary to embed the
 initramfs in the kernel as explained below, in order to maintain the image size
@@ -143,7 +143,7 @@ make tinyconfig
 ```
 
 Some more information about tiny configs can be found at
-https://tiny.wiki.kernel.org (last checked 2018-12-01).
+<https://tiny.wiki.kernel.org> (last checked 2018-12-01).
 
 ### A few fundamental features
 
@@ -184,7 +184,7 @@ In menuconfig:
   &rarr; `Enable eventpoll support`
 
 Additional information about Go's minimum requirements can be found at
-https://github.com/golang/go/wiki/MinimumRequirements (last checked
+<https://github.com/golang/go/wiki/MinimumRequirements> (last checked
 2018-12-01).
 
 ### Enable devtmpfs
@@ -302,7 +302,7 @@ The image will be located under `arch/${ARCH}/boot/bzImage` if your
 architecture supports bzImage (e.g. x86).
 
 For more details on how to build a kernel, see
-https://kernelnewbies.org/KernelBuild (last checked 2018-12-01).
+<https://kernelnewbies.org/KernelBuild> (last checked 2018-12-01).
 
 ## Building coreboot
 

src/intro.md

@@ -29,19 +29,19 @@ be used as a recovery environment.
 
 Many other implementations exist independently of the project:
 
-- [petitboot](https://github.com/open-power/petitboot) under the OpenPOWER
+* [petitboot](https://github.com/open-power/petitboot) under the OpenPOWER
   project originally targeting the PS3
-- [k-boot](https://github.com/BayLibre/k-boot) developed by BayLibre in 2023
+* [k-boot](https://github.com/BayLibre/k-boot) developed by BayLibre in 2023
   using BusyBox
-- [nmbl](https://github.com/rhboot/nmbl-poc) developed by RedHat in 2024
-- [ZFSBootMenu](https://docs.zfsbootmenu.org/en/latest)
+* [nmbl](https://github.com/rhboot/nmbl-poc) developed by RedHat in 2024
+* [ZFSBootMenu](https://docs.zfsbootmenu.org/en/latest)
 
 And there is a long history of similar implementations including projects that
 are no longer maintained:
 
-- MILO on Alpha started before 2000 (see [What is
+* MILO on Alpha started before 2000 (see [What is
   MILO?](https://tldp.org/HOWTO/MILO-HOWTO/what-section.html))
-- kboot developed by Werner Almesberger in 2005
+* kboot developed by Werner Almesberger in 2005
 
 These projects all attempt to reduce the role of firmware to a small,
 fixed-function core whose only purpose is to get a flash-based Linux kernel
@@ -91,7 +91,7 @@ Reliability
   hardened Linux drivers
 * Proven approach for almost 20 years in military, consumer electronics, and
   supercomputers – wherever reliability and performance are paramount
-* Fault Tolerance - Linux isolates processes** **(for example, when `pxeboot`
+* Fault Tolerance - Linux isolates processes****(for example, when `pxeboot`
   fails catastrophically, `diskboot` still works afterwards)
 
 Security

src/utilities/UEFI_Tool_Kit.md

@@ -422,8 +422,8 @@ Visitor pattern means decoupling the structure from the operations.
 
 Good resources:
 
-1. https://sourcemaking.com/design_patterns/visitor
-2. https://en.wikipedia.org/wiki/Visitor_pattern
+1. <https://sourcemaking.com/design_patterns/visitor>
+2. <https://en.wikipedia.org/wiki/Visitor_pattern>
 
 A good visitor still works when new Firmware are introduced. A good Firmware
 still works when a new visitor is introduced.

src/utilities/cpu.md

@@ -574,7 +574,7 @@ Even though the binaries themselves are running on the remote ARM system.
 
 #### cpu and virtiofs
 
-While 9p is very general, because it is *transport-independent*, there are
+While 9p is very general, because it is _transport-independent_, there are
 cases where we can get much better performance by using a less general file
 system. One such case is with virtofs.
 
@@ -633,7 +633,7 @@ There are thus several choices for setting up the mounts
 
 * 9p support by the cpu client
 * 9p supported by the cpu client, with additional mounts via -fstab or -namespace
-* 9p *without* any bind mounts, i.e. -9p=false -namespace "", in which case, on
+* 9p _without_ any bind mounts, i.e. -9p=false -namespace "", in which case, on
   the remote machine, files from the client are visible in /tmp/cpu, but no
   bind mounts are done; with additional mounts provided by fstab
   mounts are provided

src/utilities/dut.md

@@ -1,4 +1,4 @@
-# DUT, a simple Device Under Test utility.
+# DUT, a simple Device Under Test utility
 
 Points of contact: [Ron Minnich](https://github.com/rminnich)
 
@@ -19,6 +19,7 @@ This chapter describes how we build and use DUT.
 ## Components
 
 DUT is intended to be built into a u-root image. First one must fetch it:
+
 ```
 go get github.com/linuxboot/dut
 # ignore the warning message.
@@ -27,31 +28,37 @@ go get github.com/linuxboot/dut
 DUT source tree is structured such that a program called uinit is produced. This is convenient for u-root usage.
 
 Building it into a u-root image is easy:
+
 ```
 go run $(GOPATH)/src/github.com/u-root/u-root -build=bb minimal github.com/linuxboot/dut/uinit
 ```
 
 I almost always add an sshd to u-root; it's just too handy. U-root sshd does not support
 passwords, so you have to supply the public key:
+
 ```
 go run $(GOPATH)/src/github.com/u-root/u-root -build=bb -files key.pub minimal  github.com/linuxboot/dut/uinit   github.com/u-root/u-root/xcmds/sshd
 ```
 
 ### DUT on the device
+
 On boot, the standard init program will find dut, and run it. The standard mode on a device
 is device mode, and dut will bring up the ethernet, currently
 using 192.168.0.2, and assuming the tester is 192.168.0.1 (this should be fixed ...).
 It will then attempt to connect to a uinit running in 'tester' mode on 192.168.0.1. Once connected, it functions
 as a server and waits for requests.
 
 ### DUT on the controller
+
 Running on the controller is easy:
+
 ```
 uinit -m tester
 ```
 
 On the controller, the program waits for a connection and then starts issuing commands to the device.
 The controller has the option of calling the following RPC functions:
+
 ```
 RPCWelcome - return a welcome message
 RPCExit - exit the testing mode
@@ -61,6 +68,7 @@ RPCSsh - start the sshd
 ```
 
 Each of these RPCs takes arguments and returns a result, with Welcome being the most fun:
+
 ```
 ______________
 < welcome to DUT >