Google_study: Fix Markdown lint warnings

- MD004 Unordered list style
- MD005 Inconsistent indentation for list items at the same level
- MD013 Line length
- MD025 Multiple top level headers in the same document
- MD030 Spaces after list markers

Signed-off-by: Philip Molloy <[email protected]>

src/case_studies/Google_study.md

@@ -14,13 +14,13 @@ from obscure, complex firmware to simpler, open source firmware.
 There have been a number of contributors to the Google LinuxBoot project
 including:
 
--  Ron Minnich (technical lead)
--  Gan-shun Lim
--  Ryan O'Leary
--  Prachi Laud
--  Chris Koch
--  Xuan Chen
--  Andrew Sun
+- Ron Minnich (technical lead)
+- Gan-shun Lim
+- Ryan O'Leary
+- Prachi Laud
+- Chris Koch
+- Xuan Chen
+- Andrew Sun
 
 Ryan O'Leary is one of the Open Compute Platform Foundation
 [Open System Firmware project](https://www.opencompute.org/projects/open-system-firmware)
@@ -64,7 +64,7 @@ of the UEFI, but takes over after that point, replacing the
 UEFI drivers. It therefore completely replaces a large portion
 of the boot process.
 
-# Phases of the project
+## Phases of the project
 
 Google's LinuxBoot project is focused on moving UEFI boot functionality
 into the kernel and userspace. That is, converting UEFI firmware
@@ -83,7 +83,7 @@ Step 1. Reduce or replace UEFI components
    The following diagram shows the phases of the UEFI boot process.
    The items in <span style="color:red">red</span> are components
    that are either reduced or eliminated with LinuxBoot.
-   The dark <span style="color:blue">blue</span> items on the left
+   The <span style="color:blue">dark blue</span> items on the left
    cannot be changed.
 
 <img src="../images/Case-study-step1.svg" width=600px>
@@ -112,34 +112,34 @@ LinuxBoot provides a file system based on u-root standard
 utilities written in Go.
 
 Step 4. Through trial and error, continue to remove DXEs until you
-   can't remove anymore.
-
-   The DXEs are delivered as binary blobs. There are three ways
-    to handle them:
-
-   1. The most desirable is to remove them and let Linux drivers take
-      over what they did. This works well for USB, network, disk,
-      and other drivers, as well as network protocols and file
-      systems. In fact we have resolved many system reliability
-      and performance issues just by removing DXEs!
-
-   1. The second way is to replace the DXE with an open source driver.
-      This is less desirable, as the DXE environment is not as
-      hardened as the Linux kernel environment.
-   1. The final, least desired option, is to continue to use the DXE.
-      This is required if the DXE contains proprietary code that
-      "tweaks" chipset settings, for example, memory timing or
-      other controls, and there is no chance of ever bringing
-      them to open source.
+can't remove anymore.
+
+The DXEs are delivered as binary blobs. There are three ways
+ to handle them:
+
+1. The most desirable is to remove them and let Linux drivers take
+   over what they did. This works well for USB, network, disk,
+   and other drivers, as well as network protocols and file
+   systems. In fact we have resolved many system reliability
+   and performance issues just by removing DXEs!
+
+1. The second way is to replace the DXE with an open source driver.
+   This is less desirable, as the DXE environment is not as
+   hardened as the Linux kernel environment.
+1. The final, least desired option, is to continue to use the DXE.
+   This is required if the DXE contains proprietary code that
+   "tweaks" chipset settings, for example, memory timing or
+   other controls, and there is no chance of ever bringing
+   them to open source.
 
 <img src="../images/Case-study-step4.svg" width=600px>
 
 Step 5. Replace closed source DXEs with open source
 
 If we can build a DXE from source, we can use `utk` to:
 
-*  Remove the proprietary one
-*  Replace it with one built from source
+- Remove the proprietary one
+- Replace it with one built from source
 
 <img src="../images/Case-study-step5.svg" width=600px>
 
@@ -150,8 +150,11 @@ development continues to provide an open-source solution that
 does the following:
 
 1. Brings up the Linux kernel as a DXE in flash ROM instead of the UEFI shell.
-1. Provides a Go based userland that can then bring up the kernel that you want to run on the machine.
-1. Enables writing traditional firmware applications such as bootloader, debugging, diagnosis, and error detection applications as cross-architecture and cross-platform portable Linux applications.
+1. Provides a Go based userland that can then bring up the kernel that you want
+   to run on the machine.
+1. Enables writing traditional firmware applications such as bootloader,
+   debugging, diagnosis, and error detection applications as cross-architecture
+   and cross-platform portable Linux applications.
 
 The complete LinuxBoot solution is shown in the following diagram.