diff --git a/cosmetic/gui.md b/cosmetic/gui.md
index 45accad5..6c52e3d2 100644
--- a/cosmetic/gui.md
+++ b/cosmetic/gui.md
@@ -9,13 +9,13 @@ Main thing this guide will go over:
 
 So to get started, we're gonna need 0.5.7 or newer as these builds have the GUI included with the rest of the files. If you're on an older version, I recommend updating: [Updating OpenCore](../universal/update.md)
 
-Once that's done, we'll need a couple things:
+Once that's done, we'll need a couple of things:
 
 * [Binary Resources](https://github.com/acidanthera/OcBinaryData)
 * [OpenCanopy.efi](https://github.com/acidanthera/OpenCorePkg/releases)
   * Note: OpenCanopy.efi must be from the same build as your OpenCore files, as mismatched files can cause boot issues
 
-Once you have both of these, we'll next want to add it to our EFI partition:
+Once you have both of these, we'll next want to add them to our EFI partition:
 
 * Add the [Resources folder](https://github.com/acidanthera/OcBinaryData) to EFI/OC
 * Add OpenCanopy.efi to EFI/OC/Drivers
@@ -25,8 +25,8 @@ Once you have both of these, we'll next want to add it to our EFI partition:
 Now in our config.plist, we have 4 things we need to fix:
 
 * `Misc -> Boot -> PickerMode`: `External`
-* `Misc -> Boot -> PickerAttributes`: `17`
-  * This enables mouse/trackpad support as well as .VolumeIcon.icns reading from the drive, allows for macOS installer icons to appear in the picker
+* `Misc -> Boot -> PickerAttributes`: `17`.
+  * This enables mouse/trackpad support as well as .VolumeIcon.icns reading from the drive, allows for macOS installer icons to appear in the picker.
     * Other settings for PickerAttributes can be found in the [Configuration.pdf](https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/Configuration.pdf)
 * `Misc -> Boot -> PickerVariant`: `Acidanthera\GoldenGate`
   * Applicable variables:
@@ -44,7 +44,7 @@ Once all this is saved, you can reboot and be greeted with a true Mac-like GUI:
 
 ## Setting up Boot-chime with AudioDxe
 
-So to start, we'll need a couple things:
+So to start, we'll need a couple of things:
 
 * Onboard audio output
   * USB DACs will not work
@@ -87,7 +87,7 @@ So to start, we'll need a couple things:
     * ex: `PciRoot(0x0)/Pci(0x1f,0x3)`
 
 * **AudioOut:**
-  * The specific output of your Audio controller, easiest way to find the right one is to go through each one(from 0 to N - 1, where N is the number of outputs listed in your log)
+  * The specific output of your Audio controller, the easiest way to find the right one is to go through each one(from 0 to N - 1, where N is the number of outputs listed in your log)
   * ex: 5 outputs would translate to 0-4 as possible values
     * You can find all the ones for your codec in the OpenCore debug logs:
 
diff --git a/cosmetic/verbose.md b/cosmetic/verbose.md
index 52b21735..fc446c0a 100644
--- a/cosmetic/verbose.md
+++ b/cosmetic/verbose.md
@@ -1,6 +1,6 @@
 # Fixing Resolution and Verbose
 
-Wanting a more clean booting experience with macOS without all that verbose text while booting? Well you need a couple things:
+Wanting a more clean booting experience with macOS without all that verbose text while booting? Well, you need a couple of things:
 
 ## macOS Decluttering
 
diff --git a/gpu-patching/intel-patching/README.md b/gpu-patching/intel-patching/README.md
index 502ee36e..98ef01b1 100644
--- a/gpu-patching/intel-patching/README.md
+++ b/gpu-patching/intel-patching/README.md
@@ -1,6 +1,6 @@
 # Intel iGPU Patching
 
-This guide will be a more in-depth look into patching macOS to support more hardware variations of Intel's iGPUs including proper display out, fixing color tint issues, HiDPI issues and etc. Note this guide is **not** a beginners tutorial, we recommend you follow the recommend iGPU properties listed in the config.plist section of the guide to start off.
+This guide will be a more in-depth look into patching macOS to support more hardware variations of Intel's iGPUs including proper display out, fixing color tint issues, HiDPI issues etc. Note this guide is **not** a beginner's tutorial, we recommend you follow the recommend iGPU properties listed in the config.plist section of the guide to start off.
 
 This guide supports:
 
@@ -89,13 +89,13 @@ From here, lets open up our config.plist and head to DeviceProperties -> Add. No
 
 To determine whether you need a new `device-id` injected, you'll want to compare [WhateverGreen's list of supported IDs](https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md) to what you have.
 
-For this example, lets take a look at the i3-4150 with an HD 4400 iGPU. Using [Intel's ARK page](https://ark.Intel.com/content/www/us/en/ark/products/77486/Intel-core-i3-4150-processor-3m-cache-3-50-ghz.html), we can see the following:
+For this example, let's take a look at the i3-4150 with an HD 4400 iGPU. Using [Intel's ARK page](https://ark.Intel.com/content/www/us/en/ark/products/77486/Intel-core-i3-4150-processor-3m-cache-3-50-ghz.html), we can see the following:
 
 ```
 Device ID = 0x41E
 ```
 
-Now that we have our actual Device ID, lets compare it to [WhateverGreen's list](https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md):
+Now that we have our actual Device ID, let's compare it to [WhateverGreen's list](https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md):
 
 ```
 Native supported DevIDs:
@@ -107,7 +107,7 @@ Native supported DevIDs:
  0x0412
 ```
 
-Unfortunately the ID is not present in macOS, so we'll need to find a similar iGPU to ours and use their Device ID. The HD 4600 found in the [i3-4330](https://ark.Intel.com/content/www/us/en/ark/products/77769/Intel-core-i3-4330-processor-4m-cache-3-50-ghz.html) is a very close match, so we'll use its Device ID:
+Unfortunately, the ID is not present in macOS, so we'll need to find a similar iGPU to ours and use their Device ID. The HD 4600 found in the [i3-4330](https://ark.Intel.com/content/www/us/en/ark/products/77769/Intel-core-i3-4330-processor-4m-cache-3-50-ghz.html) is a very close match, so we'll use its Device ID:
 
 ```
 Device ID = 0x412
diff --git a/gpu-patching/intel-patching/busid.md b/gpu-patching/intel-patching/busid.md
index 273fa902..bdcfdcf5 100644
--- a/gpu-patching/intel-patching/busid.md
+++ b/gpu-patching/intel-patching/busid.md
@@ -72,7 +72,7 @@ Here we have 2 sections:
 
 Mapping videos in macOS is fairly easy, as we can assume that one of our ports is mapped correctly in the framebuffer.
 
-For this example, we'll explain the common [HDMI-hotplug fix for Kaby lake users](https://dortania.github.io/OpenCore-Install-Guide/config-laptop.plist/kaby-lake.html#deviceproperties). To start, lets look at the 0x591B0000 framebuffer:
+For this example, we'll explain the common [HDMI-hotplug fix for Kaby lake users](https://dortania.github.io/OpenCore-Install-Guide/config-laptop.plist/kaby-lake.html#deviceproperties). To start, let's look at the 0x591B0000 framebuffer:
 
 ```
 ID: 591B0000, STOLEN: 38 MB, FBMEM: 21 MB, VRAM: 1536 MB, Flags: 0x0000130B
@@ -109,7 +109,7 @@ So since entry 2 is the second in the list, we'll want to use con1:
 
 * framebuffer-con2-enable
 
-Next lets make the patch, we know that port needs to be patched to 01 and BusID changed to 05:
+Next let's make the patch, we know that port needs to be patched to 01 and BusID changed to 05:
 
 * **0105**0A00 00080000 87010000
 
diff --git a/gpu-patching/intel-patching/connector.md b/gpu-patching/intel-patching/connector.md
index 73bd5775..cbf5944d 100644
--- a/gpu-patching/intel-patching/connector.md
+++ b/gpu-patching/intel-patching/connector.md
@@ -1,8 +1,8 @@
 # Patching Connector Types
 
-* Images and info based off [CorpNewt's Vanilla Guide](https://hackintosh.gitbook.io/-r-hackintosh-vanilla-desktop-guide/config.plist-per-hardware/coffee-lake#pink-purple-tint)
+* Images and info based on [CorpNewt's Vanilla Guide](https://hackintosh.gitbook.io/-r-hackintosh-vanilla-desktop-guide/config.plist-per-hardware/coffee-lake#pink-purple-tint)
 
-This section is mainly relevant for users who either get black screen or incorrect color output on their displays(usually HDMI ports). This is due to Apple forcing display types onto your hardware,. To work around it, we'll patch Apple's connector types to properly respect our hardware.
+This section is mainly relevant for users who either get a black screen or incorrect color output on their displays(usually HDMI ports). This is due to Apple forcing display types onto your hardware,. To work around it, we'll patch Apple's connector types to properly respect our hardware.
 
 For this example, let's take a UHD 630 system with an HDMI display attached. The machine has already been correctly setup however there's a Pink/Purple tint on the HDMI display.
 
diff --git a/gpu-patching/legacy-intel/README.md b/gpu-patching/legacy-intel/README.md
index f7160767..e6ab4510 100644
--- a/gpu-patching/legacy-intel/README.md
+++ b/gpu-patching/legacy-intel/README.md
@@ -13,7 +13,7 @@ Please note this page is more of an info dump, we won't be going to too great of
 
 ## Prerequisites
 
-Unfortunately GMA support is a bit more complicated with PCs, and because of this we need to force a 32-Bit kernelspace as the 64-Bit GMA drivers are known for weird GPU corruption and sleep issues. To do this:
+Unfortunately, GMA support is a bit more complicated with PCs, and because of this we need to force a 32-Bit kernelspace as the 64-Bit GMA drivers are known for weird GPU corruption and sleep issues. To do this:
 
 * Ensure all your kexts are either 32-Bit or FAT
   * Run `lipo -archs` on the kext's binary to verify
diff --git a/gpu-patching/nvidia-patching/README.md b/gpu-patching/nvidia-patching/README.md
index 48c0df9a..bb420253 100644
--- a/gpu-patching/nvidia-patching/README.md
+++ b/gpu-patching/nvidia-patching/README.md
@@ -72,7 +72,7 @@ GeForce GT 220
 
 Amount of VRAM present on your card, in hexadecimal.
 
-For this example, lets convert 1024MB to hexadecimal:
+For this example, let's convert 1024MB to hexadecimal:
 
 ```md
 # Convert 1024MB Megabytes to Bytes
@@ -129,7 +129,7 @@ Now press enter, and return to the main menu. Once there, enter `3` to take you
 
 ![](../../images/gpu-patching/nvidia/nvcap-initial-nvcap.png)
 
-Here you can see the connectors that NVCAP-Calculator was able to find. Each Display may represent multiple DCB Entries, such as DVI (normally represented as two entries) or duplicate DCB entries. The goal here is to assign each display to a head. Each head can only output to one display at a time. For example, if your using 2 DVI ports, each should be on their own head to have proper dual monitor support.
+Here you can see the connectors that NVCAP-Calculator was able to find. Each Display may represent multiple DCB Entries, such as DVI (normally represented as two entries) or duplicate DCB entries. The goal here is to assign each display to a head. Each head can only output to one display at a time. For example, if you're using 2 DVI ports, each should be on their own head to have proper dual monitor support.
 
 Note that some displays may be assigned automatically. An LVDS display will be put on it's own head automatically, and TV displays will be put on the TV head automatically.
 
diff --git a/laptop-specific/battery.md b/laptop-specific/battery.md
index 9f1515e8..df7c719e 100644
--- a/laptop-specific/battery.md
+++ b/laptop-specific/battery.md
@@ -4,7 +4,7 @@ While at the moment battery patching is not something covered in this guide, we'
 
 ## DSDT Patching
 
-While custom DSDT injection should be avoided as to prevent issues with Windows and firmware updates, it can be quite helpful as a starting point since it's a bit easier to grasp and do yourself:
+While custom DSDT injection should be avoided to prevent issues with Windows and firmware updates, it can be quite helpful as a starting point since it's a bit easier to grasp and do yourself:
 
 **[Rehabman's how to patch DSDT for working battery status](https://www.tonymacx86.com/threads/guide-how-to-patch-dsdt-for-working-battery-status.116102/)**
 
diff --git a/misc/msr-lock.md b/misc/msr-lock.md
index 0b3af64a..a274d2fd 100644
--- a/misc/msr-lock.md
+++ b/misc/msr-lock.md
@@ -6,7 +6,7 @@ This guide is only recommended for users who have already installed macOS, for u
 
 ## What is CFG-Lock
 
-CFG-Lock is a setting in your BIOS that allows for a specific register(in this case the MSR 0xE2) to be written to. By default, most motherboards lock this variable with many even hiding the option outright in the GUI. And why we care about it is that macOS actually wants to write to this variable, and not just one part of macOS. Instead both the Kernel(XNU) and AppleIntelPowerManagement want this register.
+CFG-Lock is a setting in your BIOS that allows for a specific register(in this case the MSR 0xE2) to be written to. By default, most motherboards lock this variable with many even hiding the option outright in the GUI. And why we care about it is that macOS actually wants to write to this variable, and not just one part of macOS. Instead, both the Kernel(XNU) and AppleIntelPowerManagement want this register.
 
 So to fix it we have 2 options:
 
@@ -26,7 +26,7 @@ Note: Penyrn based machines actually don't need to worry about unlocking this re
 ## Checking if your firmware supports CFG Lock unlocking
 
 Before proceeding with the rest of this guide, you'll first need to check if your firmware supports CFG Lock unlocking.
-To check it, you can proceed into two ways:
+To check it, you can proceed in two ways:
 
 1. [Use the DEBUG version of OpenCore and check what the log says about CFG Lock](#checking-via-opencore-logs)
 2. [Use a tool called `VerifyMsrE2` which will speed up the whole checking process](#checking-via-verifymsre2)
@@ -67,7 +67,7 @@ For the latter, you don't need to do any CFG-Lock patches and can simply disable
 
 ## Disabling CFG Lock
 
-So you've created the EFI folder but you can't still boot without unlocking before CFG Lock. In order to do this you'll need the following:
+So you've created the EFI folder but you can't still boot without unlocking before CFG Lock. To do this you'll need the following:
 
 Inside your `EFI/OC/Tools` folder and `config.plist`, add the following tool(this can be done with ProperTree's snapshot function(ie. Cmd+R)):
 
diff --git a/misc/rtc.md b/misc/rtc.md
index c759e617..5724571e 100644
--- a/misc/rtc.md
+++ b/misc/rtc.md
@@ -19,9 +19,9 @@ So with OpenCore, we've got a few options to choose:
   * Much easier for the end user to patch
   * Prevents EfiBoot from breaking your system as well
 
-The former is actually already integrated into OpenCore with the `DisableRtcChecksum` quirk, but has the downfall of only blocking regions 0x58-0x59 and only working in the kernel level. Best way to know if this option is best, enable it and try. If this doesn't work, disable as it's an unnecessary patch.
+The former is actually already integrated into OpenCore with the `DisableRtcChecksum` quirk, but has the downfall of only blocking regions 0x58-0x59 and only working in the kernel level. The best way to know if this option is best, enable it and try. If this doesn't work, disable it as it's an unnecessary patch.
 
-With the latter, we're able to block very specific regions of our choice that match our exact model. And we're able to do this both in the kernel level and firmware aiding with hibernation support. This however will requires much more time and [RTCMemoryFixup](https://github.com/acidanthera/RTCMemoryFixup/releases/tag/1.0.6).
+With the latter, we're able to block very specific regions of our choice that match our exact model. And we're able to do this both at the kernel level and firmware aiding with hibernation support. This however will require much more time and [RTCMemoryFixup](https://github.com/acidanthera/RTCMemoryFixup/releases/latest).
 
 ## Finding our bad RTC region
 
@@ -32,7 +32,7 @@ For the rest of this guide, we're going to assume you've tested option 1(`Disabl
 * To omit bad regions, we use the boot-arg `rtcfx_exclude=00-FF`
   * Replace `00-FF` with your bad region (or regions)
   * Reminder that `boot-args` is located under `NVRAM -> Add -> 7C436110-AB2A-4BBB-A880-FE41995C9F82` in your config.plist
-  * This will also require you to have [RTCMemoryFixup](https://github.com/acidanthera/RTCMemoryFixup/releases/tag/1.0.6) in your config.plist and EFI/OC/Kexts folder.
+  * This will also require you to have [RTCMemoryFixup](https://github.com/acidanthera/RTCMemoryFixup/releases/latest) in your config.plist and EFI/OC/Kexts folder.
 * There can be multiple bad regions
 * To find the bad region, we'll want to split out search into chunks
 
@@ -51,7 +51,7 @@ Regarding splitting out chunks, what we'll be doing is omitting chunks of RTC re
   * Note you may also get a bad range of 7F-80, or even bad regions split into multiple sections(ex. 0x00-0x01 **and** 0x80-0x81)
   * You can use `rtcfx_exclude=00-01,7F-80` to resolve this
 
-#### 3. After testing which regions is bad, shrink even more
+#### 3. After testing which regions are bad, shrink even more
 
 * Assuming our bad region was within 0x80-0xFF, you'd next split that into 2:
 * 0x80-0xBF and 0xC0-0xFF
@@ -66,7 +66,7 @@ Regarding splitting out chunks, what we'll be doing is omitting chunks of RTC re
 
 * `(x + y) / 2`
 
-Now lets try to use this with step 1 from earlier:
+Now let's try to use this with step 1 from earlier:
 
 * 0x00-0xFF -> 0-255 -> `(0 + 255) / 2` = 127.5
 
@@ -84,7 +84,7 @@ Once you've found the bad RTC region, you can now finally add it to OpenCore its
 
 For this, open up your config.plist and head to the `NVRAM -> Add` section. Here under the `4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102` GUID, you'll want to add a new entry called `rtc-blacklist`
 
-Next you'll want to add our bad RTC region as an array, so `rtcfx_exclude=85-86` will become `rtc-blacklist | Data | 8586`. This will also work with longer ranges such as 85-89 and such however with `rtc-blacklist` you must include every entry(ie. `<85 86 87 88 89>`). Remember to remove the boot-arg once you're set `rtc-blacklist`
+Next, you'll want to add our bad RTC region as an array, so `rtcfx_exclude=85-86` will become `rtc-blacklist | Data | 8586`. This will also work with longer ranges such as 85-89 and such however with `rtc-blacklist` you must include every entry(ie. `<85 86 87 88 89>`). Remember to remove the boot-arg once you're set `rtc-blacklist`
 
 Next ensure you have `NVRAM -> Delete` also set as NVRAM variables will not be overwritten by OpenCore unless explicitly told so.
 
diff --git a/multiboot/bootcamp.md b/multiboot/bootcamp.md
index cc8063e7..29ba3f9a 100644
--- a/multiboot/bootcamp.md
+++ b/multiboot/bootcamp.md
@@ -1,6 +1,6 @@
 # Installing and using BootCamp utilities
 
-So a neat feature of OpenCore is the ability to avoid the BIOS entirely and use Startup disk solely for multiboot. Problem comes in when we try to boot windows and have no way of setting the boot option back to macOS. That's where the BootCamp utilities come in.
+So a neat feature of OpenCore is the ability to avoid the BIOS entirely and use Startup disk solely for multiboot. The problem comes in when we try to boot windows and have no way of setting the boot option back to macOS. That's where the BootCamp utilities come in.
 
 * Note: This guide will not cover the creation of the Windows installer, only the installation of BootCamp drivers.
   * Example of Windows installer creation: [Build a Bootable Windows ISO](https://www.freecodecamp.org/news/how-make-a-windows-10-usb-using-your-mac-build-a-bootable-iso-from-your-macs-terminal/)
@@ -32,7 +32,7 @@ path/to/Brigadier --model MacPro7,1
 
 ![](../images/bootcamp-md/extension.png)
 
-Next you will find our bootcamp drivers under either:
+Next, you will find our bootcamp drivers under either:
 
 * Windows:
 
@@ -50,11 +50,11 @@ macOS users will next need to expand WindowsSupport.dmg and place it somewhere W
 
 ![](../images/bootcamp-md/done.png)
 
-Next navigate to the `bootcamp-{filename}\BootCamp` folder and run the Setup.exe:
+Next, navigate to the `bootcamp-{filename}\BootCamp` folder and run the Setup.exe:
 
 ![](../images/bootcamp-md/location.png)
 
-Once all is finished, you now have BootCamp switching! There should be a little BootCamp icon in you tray now that you can select which drive to boot to.
+Once all is finished, you now have BootCamp switching! There should be a little BootCamp icon in your tray now that you can select which drive to boot to.
 
 * Note: For those no needing the extra drivers BootCamp provides, you can delete the following:
   * `$WinPEDriver$`: **DO NOT** delete the folder itself, just the drivers inside
diff --git a/multiboot/bootstrap.md b/multiboot/bootstrap.md
index 90a683bf..cb7678de 100644
--- a/multiboot/bootstrap.md
+++ b/multiboot/bootstrap.md
@@ -46,7 +46,7 @@ Because the LauncherOption entry is a protected entry when resetting NVRAM, you'
 * `Misc -> Security -> AllowNvramReset -> True`
 * `Misc -> Boot -> LauncherOption -> Disabled`
 
-Once these are set, you can reboot into the OpenCore picker and select the `Reset NVRAM` entry to clear your NVRAM, which will remove the LauncherOption entry too..
+Once these are set, you can reboot into the OpenCore picker and select the `Reset NVRAM` entry to clear your NVRAM, which will remove the LauncherOption entry too.
 
 ## Updating Bootstrap in 0.6.6
 
diff --git a/universal/audio.md b/universal/audio.md
index 7566a810..f05ca42e 100644
--- a/universal/audio.md
+++ b/universal/audio.md
@@ -19,7 +19,7 @@ So for this example, we'll assume your codec is ALC1220. To verify yours, you ha
 * Run `cat` in terminal on Linux
   * `cat /proc/asound/card0/codec#0 | less`
 
-Now with a codec, we'll want to cross reference it with AppleALC's supported codec list:
+Now with a codec, we'll want to cross-reference it with AppleALC's supported codec list:
 
 * [AppleALC Supported Codecs](https://github.com/acidanthera/AppleALC/wiki/Supported-codecs)
 
diff --git a/universal/drm.md b/universal/drm.md
index 9c74ab70..a941ce45 100644
--- a/universal/drm.md
+++ b/universal/drm.md
@@ -8,7 +8,7 @@ So with DRM, we have a couple things we need to mention:
 * DRM requires a supported dGPU
   * See the [GPU Buyers Guide](https://dortania.github.io/GPU-Buyers-Guide/) for supported cards
 * DRM is broken for iGPU-only systems
-  * This could be fixed with Shiki (now WhateverGreen) til 10.12.2, but broke with 10.12.3
+  * This could be fixed with Shiki (now WhateverGreen) until 10.12.2, but broke with 10.12.3
   * This is due to the issue that our iGPUs don't support Apple's firmware and that our [Management Engine](https://en.wikipedia.org/wiki/Intel_Management_Engine) doesn't have Apple's certificate
 * Working hardware acceleration and decoding
 
@@ -18,7 +18,7 @@ So before we can get started with fixing DRM, we need to make sure your hardware
 
 ![](../images/post-install/drm-md/vda.png)
 
-If you fail at this point, there's a couple things you can check for:
+If you fail at this point, there are a couple things you can check for:
 
 * Make sure your hardware is supported
   * See [GPU Buyers Guide](https://dortania.github.io/GPU-Buyers-Guide/)
diff --git a/universal/iservices.md b/universal/iservices.md
index b3f674ad..6e1bd887 100644
--- a/universal/iservices.md
+++ b/universal/iservices.md
@@ -4,7 +4,7 @@ This page is for those having iMessage and other iServices issues, this is a ver
 
 **Your Apple ID is the single most influential factor in using iServices.**
 
-If you have existing Apple products in your account, such as an iPhone, you should have no issues whatsoever using a generated serial set. However, if you recently created an account, that does not have any existing Apple hardware or App Store purchases, you may be required to call Apple once you have attemped logging in.
+If you have existing Apple products in your account, such as an iPhone, you should have no issues whatsoever using a generated serial set. However, if you recently created an account, that does not have any existing Apple hardware or App Store purchases, you may be required to call Apple once you have attempted logging in.
 
 The following items will be created below and are required to use iServices:
 
@@ -22,7 +22,7 @@ The following items will be created below and are required to use iServices:
 
 Download [GenSMBIOS](https://github.com/corpnewt/GenSMBIOS) and select option 1 to download MacSerial and next option 3 to generate some new serials. What we're looking for is a valid serial that currently has no registered purchase date.
 
-Tip: `iMacPro1,1 10` will print 10 serials, this will save you some time on generating
+Tip: `iMacPro1,1 10` will print 10 serials, this will save you some time in generating
 
 ![](../images/post-install/iservices-md/serial-list.png)
 
@@ -97,7 +97,7 @@ For example:
 
 **ROM:** `0016cb001122`
 
-## Generate an UUID
+## Generate a UUID
 
 Type `uuidgen` in Terminal
 
@@ -155,7 +155,7 @@ This last one is what we're after, as we want something genuine but currently no
 * Board Serial = MLB
 * SmUUID = SystemUUID
 
-**Note**:  "We’re sorry, but this serial number isn’t valid. Please check your information and try again." works for many users as well, do note though if you've had a bad track record with Apple/iServices you many need one that's "Purchase Date not Validated". Otherwise there may be suspicion
+**Note**:  "We’re sorry, but this serial number isn’t valid. Please check your information and try again." works for many users as well, do note though if you've had a bad track record with Apple/iServices you many need one that's "Purchase Date not Validated". Otherwise there may be suspicion.
 
 **Note 2**: Using a "Purchase Date not Validated:" can cause issues down the line if another machine of the same serial ever gets activated, for initial setup it can help alleviate issues with your account but in the long run an invalid serial can be a safer choice.
 
@@ -216,7 +216,7 @@ When adding this to your config, `c0:7e:bf:c3:af:ff` should be converted to `c07
 
 ## Verifying NVRAM
 
-Something that many forget about iServices is that NVRAM is crucial to getting it working correctly, the reason being is that iMessage keys and such are stored in NVRAM. Without NVRAM, iMessage can neither see nor store keys.
+Something that many forget about iServices is that NVRAM is crucial to get it working correctly, the reason being is that iMessage keys and such are stored in NVRAM. Without NVRAM, iMessage can neither see nor store keys.
 
 So we'll need to verify NVRAM works, regardless if "it should work" as some firmwares can be more of a pain than others.
 
@@ -287,5 +287,5 @@ Well mate, you've done it. You blacklisted your AppleID. The fix is simple but n
 ![](../images/post-install/iservices-md/blacklist.png)
 
 * For Apple contacting, there are 2 methods
-  * Apple calls you: [Apple Support](https://getsupport.apple.com/). You must click on Apple ID and then select the iCloud, Facetime & Messages. Now, you should click on Talk to Apple Support Now and type your phone number
+  * Apple calls you: [Apple Support](https://getsupport.apple.com/). You must click on Apple ID and then select  iCloud, Facetime & Messages. Now, you should click on Talk to Apple Support Now and type your phone number
   * You can contact Apple for support and service as well, look for your country in the list and then make a phone call: [Apple Support Phone Numbers](https://support.apple.com/HT201232)
diff --git a/universal/oc2hdd.md b/universal/oc2hdd.md
index 0ff9d17a..baa15de2 100644
--- a/universal/oc2hdd.md
+++ b/universal/oc2hdd.md
@@ -8,18 +8,18 @@ For this example, we'll assume your USB is called `Install macOS Catalina`:
 
 ![](../images/post-install/oc2hdd-md/usb-mount.png)
 
-Once the EFI's mounted, we'll want to grab our EFI folder on there and keep in a safe place. We'll then want to **eject the USB drive's EFI** as having multiple EFI's mounted can confuse macOS sometimes, best practice is to keep only 1 EFI mounted at a time(you can eject just the EFI, the drive itself doesn't need to be removed)
+Once the EFI's mounted, we'll want to grab our EFI folder on there and keep it in a safe place. We'll then want to **eject the USB drive's EFI** as having multiple EFI's mounted can confuse macOS sometimes, best practice is to keep only 1 EFI mounted at a time(you can eject just the EFI, the drive itself doesn't need to be removed)
 
 **Note**: Installers made with gibMacOS's MakeInstall.bat on Windows will default to a Master Boot Record(MBR) partition map, this means there is no dedicated EFI partition instead being the `BOOT` partition that mounts by default in macOS.
 
 ![](../images/post-install/oc2hdd-md/hdd-mount.png)
 
-Now with this done, lets mount our macOS drive. With macOS Catalina, macOS is actually partitioned into 2 volumes: System Partition and User Partition. This means that MountEFI may report multiple drives in it's picker but each partition will still share the same EFI(The UEFI spec only allows for 1 EFI per drive). You can tell if it's the same drive with disk**X**sY (Y is just to say what partition it is)
+Now with this done, let's mount our macOS drive. With macOS Catalina, macOS is actually partitioned into 2 volumes: System Partition and User Partition. This means that MountEFI may report multiple drives in it's picker but each partition will still share the same EFI(The UEFI spec only allows for 1 EFI per drive). You can tell if it's the same drive with disk**X**sY (Y is just to say what partition it is).
 
 ![](../images/post-install/oc2hdd-md/hdd-clean.png)
 
-When you mount your main drive's EFI, you may be greeted with a folder called `APPLE`, this is used for updating the firmware on real Macs but has no effect on our hardware. You can wipe everything on the EFI partition and replace it with the one found on your USB
+When you mount your main drive's EFI, you may be greeted with a folder called `APPLE`, which is used for updating the firmware on real Macs but has no effect on our hardware. You can wipe everything on the EFI partition and replace it with the one found on your USB.
 
 ## Special notes for legacy users
 
-When transferring over your EFI, there are still boot sectors that need to be written to so your non-UEFI BIOS would be able to find it. So don't forget to rerun the [`BootInstall.command`](https://dortania.github.io/OpenCore-Install-Guide/extras/legacy.html) on your macOS drive
+When transferring over your EFI, there are still boot sectors that need to be written to so your non-UEFI BIOS would be able to find it. So don't forget to rerun the [`BootInstall.command`](https://dortania.github.io/OpenCore-Install-Guide/extras/legacy.html) on your macOS drive.
diff --git a/universal/pm.md b/universal/pm.md
index 147095ab..1de13f01 100644
--- a/universal/pm.md
+++ b/universal/pm.md
@@ -17,7 +17,7 @@ XCPM Present           |  Missing XCPM
 :-------------------------:|:-------------------------:
 ![](../images/post-install/pm-md/pm-working.png)  |  ![](../images/post-install/pm-md/pm-not-working.png)
 
-As you can see from the left image, we have the X86PlatformPlugin attached meaning Apple's CPU Power Management Drivers are doing their thing(Note the CPU's name does not matter, CPU names come in many variations such as CP00, CPU0, PR00, etc. What matters is that AppleACPICPU attaches to it). If you get something like to the right image, then there's likely an issue. Make sure to check the following:
+As you can see from the left image, we have the X86PlatformPlugin attached meaning Apple's CPU Power Management Drivers are doing their thing(Note the CPU's name does not matter, CPU names come in many variations such as CP00, CPU0, PR00, etc. What matters is that AppleACPICPU attaches to it). If you get something like the right image, then there's likely an issue. Make sure to check the following:
 
 * SSDT-PLUG.**aml** is both present and enabled in your config.plist and EFI/OC/ACPI
   * If you're missing this, head to [Getting Started With ACPI](https://dortania.github.io/Getting-Started-With-ACPI) on how to make this
@@ -54,7 +54,7 @@ To start, we're gonna need a couple things:
 
 ### LFM: Low Frequency Mode
 
-Now lets run CPUFriendFriend.command:
+Now let's run CPUFriendFriend.command:
 
 ![](../images/post-install/pm-md/lpm.png)
 
diff --git a/universal/security/applesecureboot.md b/universal/security/applesecureboot.md
index 47c1adce..0c19d4ec 100644
--- a/universal/security/applesecureboot.md
+++ b/universal/security/applesecureboot.md
@@ -5,13 +5,13 @@
 
 ## What is Apple Secure Boot
 
-* Information based off of [vit9696's thread](https://applelife.ru/posts/905541), [Apple's T2 docs](https://www.apple.com/euro/macbook-pro-13/docs/a/Apple_T2_Security_Chip_Overview.pdf) and [Osy's Secure Boot page](https://osy.gitbook.io/hac-mini-guide/details/secure-boot)
+* Information based on [vit9696's thread](https://applelife.ru/posts/905541), [Apple's T2 docs](https://www.apple.com/euro/macbook-pro-13/docs/a/Apple_T2_Security_Chip_Overview.pdf) and [Osy's Secure Boot page](https://osy.gitbook.io/hac-mini-guide/details/secure-boot)
 
-To best understand Apple Secure Boot, lets take a look at how the boot process works in Macs vs OpenCore in regards to security:
+To best understand Apple Secure Boot, let's take a look at how the boot process works in Macs vs OpenCore in regards to security:
 
 ![](../../images/post-install/security-md/extension.png)
 
-As we can see, there's several layers of trust incorporated into Apple Secure Boot:
+As we can see, there are several layers of trust incorporated into Apple Secure Boot:
 
 * OpenCore will verify the boot.efi manifest (e.g. boot.efi.j137ap.im4m) to ensure that boot.efi was signed by Apple and can be used by this Secure Boot model.
   * For non-zero ApECID,  OpenCore will additionally verify the ECID value, written in the boot.efi manifest (e.g. boot.efi.j137ap.XXXXXXXX.im4m), to ensure that a compromised hard drive from a different machine with the same Secure Boot model cannot be used in your computer.
@@ -19,7 +19,7 @@ As we can see, there's several layers of trust incorporated into Apple Secure Bo
 * boot.efi will verify the kernelcache to ensure it has not been tampered with
 * apfs.kext and AppleImage4 ensure your System Volume's snapshot has not been tampered with(Only applicable with Big Sur+)
 
-Not all of these verifications are required to boot, but they're all possible for those who want maximum security. Currently information regarding firmware-based Secure Boot is not covered however all Apple Secure Boot options are detailed below.
+Not all of these verifications are required to boot, but they're all possible for those who want maximum security. Currently, information regarding firmware-based Secure Boot is not covered however all Apple Secure Boot options are detailed below.
 
 ## DmgLoading
 
@@ -63,7 +63,7 @@ Currently the following options for `Misc -> Security -> SecureBootModel` are su
 
 ### Special Notes with SecureBootModel
 
-* Generally `Default` is more than adequate to use however if you plan to have use this with ApECID for full security, we recommend setting a proper value(ie. closest to your SMBIOS or versions of macOS you plan to boot) since the `Default` value is likely to be updated in the future.
+* Generally, `Default` is more than adequate to use however if you plan to have use this with ApECID for full security, we recommend setting a proper value(ie. closest to your SMBIOS or versions of macOS you plan to boot) since the `Default` value is likely to be updated in the future.
   * `x86legacy` is not required for normal Mac models without T2's, any of the above values are supported.
 * The list of cached drivers may be different, resulting in the need to change the list of Added or Forced kernel drivers.
   * ie. IO80211Family cannot be injected in this case, as it is already present in the kernelcache
diff --git a/universal/security/filevault.md b/universal/security/filevault.md
index 68d5344b..01c07095 100644
--- a/universal/security/filevault.md
+++ b/universal/security/filevault.md
@@ -1,6 +1,6 @@
 # FileVault
 
-FileVault is macOS's builtin drive encryption, and with OpenCore support for it has been drastically improved compared to the legacy Clover drivers.
+FileVault is macOS's built-in drive encryption, and with OpenCore support for it has been drastically improved compared to the legacy Clover drivers.
 
 To start, you'll need the following .efi drivers:
 
diff --git a/universal/security/password.md b/universal/security/password.md
index ffa189ec..7d0069c1 100644
--- a/universal/security/password.md
+++ b/universal/security/password.md
@@ -9,7 +9,7 @@ With OpenCore 0.6.1 and newer, users are able to set a SHA-512 password to ensur
 
 With OpenCore 0.6.7, a new tool called `ocpasswordgen` was added to aid users in generating passwords.
 
-To start, lets grab OpenCore 0.6.7 or newer and run the `ocpasswordgen` binary under `Utilities/ocpasswordgen/`. It'll prompt you to create a password:
+To start, let's grab OpenCore 0.6.7 or newer and run the `ocpasswordgen` binary under `Utilities/ocpasswordgen/`. It'll prompt you to create a password:
 
 ![](../../images/post-install/security-md/ocpasswordgen.png)
 
diff --git a/universal/security/scanpolicy.md b/universal/security/scanpolicy.md
index e43181fd..89f7aaa6 100644
--- a/universal/security/scanpolicy.md
+++ b/universal/security/scanpolicy.md
@@ -6,59 +6,59 @@ To calculate the ScanPolicy value, you simply add up all the hexadecimal values(
 
 `0x00000001 (bit 0)` — OC\_SCAN\_FILE\_SYSTEM\_LOCK
 
-* restricts scanning to only known file systems defined as a part of this policy. File system drivers may not be aware of this policy, and to avoid mounting of undesired file systems it is best not to load its driver. This bit does not affect dmg mounting, which may have any file system. Known file systems are prefixed with OC_SCAN\_ALLOW\_FS_.
+* Restricts scanning to only known file systems defined as a part of this policy. File system drivers may not be aware of this policy, and to avoid mounting of undesired file systems it is best not to load its driver. This bit does not affect dmg mounting, which may have any file system. Known file systems are prefixed with OC_SCAN\_ALLOW\_FS_.
 
 `0x00000002 (bit 1)` — OC\_SCAN\_DEVICE\_LOCK
 
-* restricts scanning to only known device types defined as a part of this policy. This is not always possible to detect protocol tunneling, so be aware that on some systems it may be possible for e.g. USB HDDs to be recognized as SATA. Cases like this must be reported. Known device types are prefixed with OC_SCAN\_ALLOW\_DEVICE_.
+* Restricts scanning to only known device types defined as a part of this policy. This is not always possible to detect protocol tunneling, so be aware that on some systems it may be possible for e.g. USB HDDs to be recognized as SATA. Cases like this must be reported. Known device types are prefixed with OC_SCAN\_ALLOW\_DEVICE_.
 
 `0x00000100 (bit 8)` — OC\_SCAN\_ALLOW\_FS\_APFS
 
-* allows scanning of APFS file system.
+* Allows scanning of APFS file system.
 
 `0x00000200 (bit 9)` — OC\_SCAN\_ALLOW\_FS\_HFS
 
-* allows scanning of HFS file system.
+* Allows scanning of HFS file system.
 
 `0x00000400 (bit 10)` — OC\_SCAN\_ALLOW\_FS\_ESP
 
-* allows scanning of EFI System Partition file system.
+* Allows scanning of EFI System Partition file system.
 
 `0x00010000 (bit 16)` — OC\_SCAN\_ALLOW\_DEVICE\_SATA
 
-* allow scanning SATA devices.
+* Allow scanning SATA devices.
 
 `0x00020000 (bit 17)` — OC\_SCAN\_ALLOW\_DEVICE\_SASEX
 
-* allow scanning SAS and Mac NVMe devices.
+* Allow scanning SAS and Mac NVMe devices.
 
 `0x00040000 (bit 18)` — OC\_SCAN\_ALLOW\_DEVICE\_SCSI
 
-* allow scanning SCSI devices.
+* Allow scanning SCSI devices.
 
 `0x00080000 (bit 19)` — OC\_SCAN\_ALLOW\_DEVICE\_NVME
 
-* allow scanning NVMe devices.
+* Allow scanning NVMe devices.
 
 `0x00100000 (bit 20)` — OC\_SCAN\_ALLOW\_DEVICE\_ATAPI
 
-* allow scanning CD/DVD devices.
+* Allow scanning CD/DVD devices.
 
 `0x00200000 (bit 21)` — OC\_SCAN\_ALLOW\_DEVICE\_USB
 
-* allow scanning USB devices.
+* Allow scanning USB devices.
 
 `0x00400000 (bit 22)` - OC\_SCAN\_ALLOW\_DEVICE\_FIREWIRE
 
-* allow scanning FireWire devices.
+ * A allow scanning FireWire devices.
 
 `0x00800000 (bit 23)` — OC\_SCAN\_ALLOW\_DEVICE\_SDCARD
 
-* allow scanning card reader devices.
+ * Allow scanning card reader devices.
 
 `0x01000000 (bit 24)` — OC\_SCAN\_ALLOW\_DEVICE\_PCI
 
-* allow scanning devices directly connected to PCI bus (e.g. VIRTIO).
+* Allow scanning devices directly connected to PCI bus (e.g. VIRTIO).
 
 By default, ScanPolicy is given a value of `0x10F0103`(17,760,515) which is the combination of the following:
 
@@ -75,4 +75,4 @@ And lets just say for this example that you want to add OC\_SCAN\_ALLOW\_DEVICE\
 
 `0x00200000` + `0x10F0103` = `0x12F0103`
 
-And converting this to decimal gives us `19,857,667`
+And converting this to decimal gives us `19,857,667`.
diff --git a/universal/security/vault.md b/universal/security/vault.md
index 36d87a5e..4d857013 100644
--- a/universal/security/vault.md
+++ b/universal/security/vault.md
@@ -41,7 +41,7 @@ Now we're ready to run `sign.command`:
 
 **Disabling Vault after setup**:
 
-If you're doing heavy troubleshooting or have the need to disable Vault, the main things to change:
+If you're doing heavy troubleshooting of need to disable Vault, the main things to change:
 
 * Grab a new copy of OpenCore.efi
 * `Misc -> Security -> Vault` set to Optional
diff --git a/universal/sleep.md b/universal/sleep.md
index 935fc635..b6438175 100644
--- a/universal/sleep.md
+++ b/universal/sleep.md
@@ -4,7 +4,7 @@ So to understand how to fix sleep issues in macOS, we need to first look at what
 
 * Incorrectly managed devices(most commonly PCIe based devices)
 
-The reason for this is when devices get an S3 call(or S0 for wake), the driver needs to power down the devices and put into a low state mode(vice versa when waking). Problems arise when such devices don't cooperate with the drivers and the main offenders of these issues are:
+The reason for this is when devices get an S3 call(or S0 for wake), the driver needs to power down the devices and put them into a low state mode(vice versa when waking). Problems arise when such devices don't cooperate with the drivers and the main offenders of these issues are:
 
 * USB Controllers and Devices
 * GPUs
@@ -23,7 +23,7 @@ And there are others that can cause sleep issues that aren't directly(or obvious
 * SMBus
 * TSC
 
-And something many people forget are over and under-clocks:
+And something many people forget is over and under-clocks:
 
 * CPUs
   * AVX often breaks iGPUs and hurt overall stability
@@ -180,7 +180,7 @@ Sleep Wake failure in EFI
 
 **For AMD**:
 
-Fret not, for their is still hope for you as well! [AMDRyzenCPUPowerManagement.kext](https://github.com/trulyspinach/SMCAMDProcessor) can add power management to Ryzen based CPUs. Installation and usage is explained on the repo's README.md
+Fret not, for there is still hope for you as well! [AMDRyzenCPUPowerManagement.kext](https://github.com/trulyspinach/SMCAMDProcessor) can add power management to Ryzen based CPUs. Installation and usage is explained on the repo's README.md
 
 ## Other Culprits
 
@@ -210,7 +210,7 @@ sudo pmset lidwake 0
 
 And set `lidwake 1` to re-enable it.
 
-The latter requires a bit more work. What we'll be doing is trying to nullify semi random key spams that happen on Skylake and newer based HPs though pop up in other OEMs as well. This will also assume that your keyboard is PS2 based and are running [VoodooPS2](https://github.com/acidanthera/VoodooPS2/releases).
+The latter requires a bit more work. What we'll be doing is trying to nullify semi random key spams that happen on Skylake and newer based HPs though pop up in other OEMs as well. This will also assume that your keyboard is PS2 based and is running [VoodooPS2](https://github.com/acidanthera/VoodooPS2/releases).
 
 To fix this, grab [SSDT-HP-FixLidSleep.dsl](https://github.com/acidanthera/VoodooPS2/blob/master/Docs/ACPI/SSDT-HP-FixLidSleep.dsl) and adapt the ACPI pathing to your keyboard(`_CID` value being `PNP0303`). Once this is done, compile and drop into both EFI/OC/ACPI and under config.plist -> ACPI -> Add.
 
@@ -224,7 +224,7 @@ To verify you have working NVRAM, see the [Emulated NVRAM](../misc/nvram.md) pag
 
 ### RTC
 
-This is mainly relevant for Intel 300 series motherboards(Z3xx), specifically that there's 2 issues:
+This is mainly relevant for Intel 300 series motherboards(Z3xx), specifically that there are 2 issues:
 
 * Be default the RTC is disabled(instead using AWAC)
 * The RTC is usually not compatible with macOS
diff --git a/universal/update.md b/universal/update.md
index 8ffd39ca..824cffcb 100644
--- a/universal/update.md
+++ b/universal/update.md
@@ -18,7 +18,7 @@ So the process goes as follows:
 
 ### 2. **Mount your EFI**
 
-* So first, lets mount your hard drive's EFI and make a copy somewhere safe with [MountEFI](https://github.com/corpnewt/MountEFI). We won't be updating the drive's EFI at first, instead we'll be grabbing a spare USB to be our crash dummy. This allows us to keep a working copy of OpenCore in case our update goes south
+* So first, let's mount your hard drive's EFI and make a copy somewhere safe with [MountEFI](https://github.com/corpnewt/MountEFI). We won't be updating the drive's EFI at first, instead we'll be grabbing a spare USB to be our crash dummy. This allows us to keep a working copy of OpenCore in case our update goes south
 
 * For the USB, it must be formatted as GUID. Reason for this is that GUID will automatically create an EFI partition, though this will be hidden by default so you'll need to mount it with MountEFI.
 
@@ -51,8 +51,8 @@ So the process goes as follows:
 
 ![](../images/post-install/update-md/oc-config-compare.png)
 
-* Once you've made the adjustments, to make sure that you config is compliant with the newest release of OpenCore, you can use the OpenCore Utility ocvalidate: this tool will help ensure your config.plist is matching the OpenCore specification of the matching build.
-  * Please note, that `ocvalidate` must match the used OpenCore release and may not be able to detect all configuration flaws present in the file. We recommend to double check your setting with the OpenCore Guide on what to set everything to, otherwise read the [Differences.pdf](https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/Differences/Differences.pdf)  for more in-depth documentation on changes.
+* Once you've made the adjustments, to make sure that your config is compliant with the newest release of OpenCore, you can use the OpenCore Utility ocvalidate: this tool will help ensure your config.plist is matching the OpenCore specification of the matching build.
+  * Please note, that `ocvalidate` must match the used OpenCore release and may not be able to detect all configuration flaws present in the file. We recommend to double-check your setting with the OpenCore Guide on what to set everything to, otherwise read the [Differences.pdf](https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/Differences/Differences.pdf)  for more in-depth documentation on changes.
   * To run `ocvalidate`, `cd` into OpenCore's `Utilties/ocvalidate/` and run `./ocvalidate <insert_config.plist>`. Note you may need to run `chmod +x ocvalidate` for it to execute.
 
 ![](../images/post-install/update-md/ocvalidate.png)
@@ -63,7 +63,7 @@ So the process goes as follows:
 
 ## Updating Kexts
 
-* Updating Kexts is a similar process to updating OpenCore, make a copy of everything and update on a dummy USB in case there's issues
+* Updating Kexts is a similar process to updating OpenCore, make a copy of everything and update on a dummy USB in case there are issues
 
 * The easiest way to update your kexts is via 2 tools:
 
diff --git a/usb/README.md b/usb/README.md
index bf7c110c..de18b27c 100644
--- a/usb/README.md
+++ b/usb/README.md
@@ -11,7 +11,7 @@ So the process of USB mapping is defining your ports to macOS and telling it wha
 * Broken Hot-Plug
 * Even data corruption from `XhciPortLimit`
 
-So now that you know why you should USB map, we can now talk about technical info of USB mapping. This is a section you cannot skip, otherwise all info below will seem like a very broken Russian translation written by a very drunk slav.
+So now that you know why you should USB map, we can now talk about the technical info of USB mapping. This is a section you cannot skip, otherwise all info below will seem like a very broken Russian translation written by a very drunk slav.
 
 So with USB, we need to understand not all ports are the same and that some ports are actually hiding other ports within them! What I mean by this is the following:
 
@@ -24,7 +24,7 @@ Now let's look at a diagram of a USB port to better understand this:
 
 As you can see, the bottom 4 pins are dedicated to USB 2.0 and when the extra 5 pins above are recognized the device will switch to a USB 3.0 mode.
 
-Now with the basic understanding out of the way, we now have to talk about the dreadful 15 port limit.
+Now with the basic understanding out of the way, we have to talk about the dreadful 15 port limit.
 
 ## macOS and the 15 Port Limit
 
@@ -42,7 +42,7 @@ Well this gets into a fun subset of computers, the hexadecimal counting system!
 
 And now when we take into account the quirk `XhciPortLimit`, you can see *why* data corruption can happen. As we're pushing past the 0xF limit and going into someone else's space. So avoid this quirk when possible.
 
-* Note: While the name `XhciPortLimit` may seem that it's limiting the number of XHCI ports, it's in-fact patching the XHCI Port Limit to a higher value.
+* Note: While the name `XhciPortLimit` may seem that it's limiting the number of XHCI ports, it's in fact patching the XHCI Port Limit to a higher value.
 
 > What about USB hubs?
 
diff --git a/usb/amd-mapping/amd.md b/usb/amd-mapping/amd.md
index 2bcef7e6..ac92f232 100644
--- a/usb/amd-mapping/amd.md
+++ b/usb/amd-mapping/amd.md
@@ -49,7 +49,7 @@ So to start off, open [IORegistryExplorer](https://github.com/khronokernel/IOReg
 * AS43
 * PTXH (Commonly associated with AMD Chipset controllers)
 * PTCP (Found on AsRock X399, in ACPI these ports are actually called PXTX but macOS will enumerate them differently)
-* PXSX(This is a generic PCIe device, **double check it's a USB device**)
+* PXSX(This is a generic PCIe device, **double-check it's a USB device**)
 
 The best way to find controllers is by searching for `XHC` and then looking at the results that come up, the parent of all the ports is the USB controller. Do note that many boards have multiple controllers but the port limit is per controller.
 
@@ -76,7 +76,7 @@ Well to kick out these bad maps, we gotta make a plugin kext. For us, that's the
 Now right-click and press `Show Package Contents`, then navigate to `Contents/Info.plist`
 
 ![](../../images/amd-mapping/amd-md/usb-plist.png)
-If the port values don't show in Xcode, right click and select `Show Raw Keys/Values`
+If the port values don't show in Xcode, right-click and select `Show Raw Keys/Values`
 ![](../../images/amd-mapping/amd-md/usb-plist-info.png)
 
 So what kind of data do we shove into this plist? Well, there are a couple of sections to note:
@@ -132,7 +132,7 @@ In this DSDT, we're missing HS02, HS03, HS04, HS05, etc. When this happens, we a
 
 An odd issue with some OEM's ACPI is that they never actually define or properly name the USB ports. And so when macOS's IOService starts scanning and building the ports, they're given a generic name. This makes it difficult to really know where your ports are.
 
-To resolve this, we can simply add names with our USBmap.kext, this is thanks to us matching the USB map based off of the USB port's location instead of by name.
+To resolve this, we can simply add names with our USBmap.kext, this is thanks to us matching the USB map based on the USB port's location instead of by name.
 
 So before you USB map, you'll get something like this:
 
@@ -176,7 +176,7 @@ And once done your USBmap's IOPathMatch should look like this:
 
 ### SSDT Recreation
 
-With the SSDT Recreation method, what we'll be doing is "renaming" the device but in reality creating a brand new device just for macOS that is in the exact same spot as your old USB controller.
+With the SSDT Recreation method, what we'll be doing is "renaming" the device but in reality, creating a brand new device just for macOS that is in the exact same spot as your old USB controller.
 
 To do this, grab the following SSDT:
 
@@ -186,7 +186,7 @@ What you'll want to do is find a controller you want to rename, find its full AC
 
 ![AsRock B450 missing ports](../../images/amd-mapping/amd-md/rename-ssdt.png)
 
-**Note**: In rare cases, macOS isn't able to properly rebuild the USB ports with the new "fake" USB controller. In these situations we need to manually add ports to it that are present in the original controller(ie. HS01, HS02, POT1, etc)
+**Note**: In rare cases, macOS isn't able to properly rebuild the USB ports with the new "fake" USB controller. In these situations, we need to manually add ports to it that are present in the original controller(ie. HS01, HS02, POT1, etc)
 
 > But how do I map a non-standard controller that shows up as PXSX?
 
diff --git a/usb/intel-mapping/intel.md b/usb/intel-mapping/intel.md
index 9343e96f..782205eb 100644
--- a/usb/intel-mapping/intel.md
+++ b/usb/intel-mapping/intel.md
@@ -25,16 +25,16 @@ Here we're greeted with all the possible USB ports in ACPI:
 
 ### Intel USB Mapping
 
-USB mapping on Intel is super easy mainly because both the ACPI is sane and more tools available for the platform. For this guide we'll be using the [USBmap tool](https://github.com/corpnewt/USBMap) from CorpNewt.
+USB mapping on Intel is super easy mainly because both the ACPI is sane and more tools available for the platform. For this guide, we'll be using the [USBmap tool](https://github.com/corpnewt/USBMap) from CorpNewt.
 
 Now open up USBmap.command and select `D.  Discover Ports`:
 
 ![](../../images/post-install/usb-md/usb-map-start.png)
 ![](../../images/post-install/usb-md/mapping.png)
 
-The interface for USBmap is quite simple and easy to grasp so won't go into detail here, the [README.md](https://github.com/corpnewt/USBMap) should do you well enough. The basic idea is insert a device, give it a name to remember the port by, remove and then try another port until you have a whole list of ports you want to keep.
+The interface for USBmap is quite simple and easy to grasp so won't go into detail here, the [README.md](https://github.com/corpnewt/USBMap) should do you well enough. The basic idea is to insert a device, give it a name to remember the port by, remove and then try another port until you have a whole list of ports you want to keep.
 
-* **Note**: USRx(ie. USR1, USR2) ports are not real USB ports, they're specifically [USBR ports](https://software.Intel.com/content/www/us/en/develop/documentation/amt-developer-guide/top/storage-redirection.html) which macOS has no support for(and why real Macs don't have this). These can be excluded from your USB map.
+* **Note**: USRx(ie. USR1, USR2) ports are not real USB ports, they're specifically [USBR ports](https://software.Intel.com/content/www/us/en/develop/documentation/amt-developer-guide/top/storage-redirection.html) that macOS has no support for(and why real Macs don't have this). These can be excluded from your USB map.
 
 Once you're done discovering your ports, select `Press Q then [enter] to stop` then head to `P.  Edit Plist & Create SSDT/Kext` from the main menu.
 
@@ -58,7 +58,7 @@ This will set my Bluetooth to internal, this is super important as macOS expects
 
 Now we can select `K. Build USBMap.kext` and let it build our kext for us.
 
-**Note**: Do not use either the SSDT-UIAC.aml **or** USBInjectAll with the USBmap.kext. This kext we just made should be used by itself with no other USB kexts besides XhciUnsupported if your system needs it. Reason for this is USBInjectAll is no longer being maintained and the USBmap.kext version is how real Macs USB map as well so as close to "Apple Like" as possible to fit the OpenCore mood.
+**Note**: Do not use either the SSDT-UIAC.aml **or** USBInjectAll with the USBmap.kext. This kext we just made should be used by itself with no other USB kexts besides XhciUnsupported if your system needs it. The reason for this is USBInjectAll is no longer being maintained and the USBmap.kext version is how real Macs USB map as well so as close to "Apple Like" as possible to fit the OpenCore mood.
 
 Now reboot and run USBmap again, you should see a lot less ports in your map:
 
diff --git a/usb/manual/manual.md b/usb/manual/manual.md
index d58ab036..0551a301 100644
--- a/usb/manual/manual.md
+++ b/usb/manual/manual.md
@@ -19,7 +19,7 @@ Here we're greeted with all the possible USB ports in ACPI:
 
 ## USB Mapping: The manual way
 
-This section is for those who want to get down into the meats of their hackintosh, to really understand what it's doing and help if there's any issues with USBmap.py and other mapping tools. To start, we'll need a few things:
+This section is for those who want to get down into the meats of their hackintosh, to really understand what it's doing and help if there are any issues with USBmap.py and other mapping tools. To start, we'll need a few things:
 
 * Installed version of macOS
   * This is due to how macOS enumerates ports, trying to map from other OSes makes this difficult
@@ -27,7 +27,7 @@ This section is for those who want to get down into the meats of their hackintos
 * Non-conflicting USB names
   * See previous section: [Checking what renames you need](../system-preparation.md#checking-what-renames-you-need)
 * A USB 2.0 and USB 3.0 device to test with
-  * You must have 2 separate devices as to ensure no mix ups with personalities
+  * You must have 2 separate devices to ensure no mix ups with personalities
 * [IORegistryExplorer.app](https://github.com/khronokernel/IORegistryClone/blob/master/ioreg-302.zip)
   * To view the inner workings of macOS more easily
   * If you plan to use Discord for troubleshooting, [v2.1.0](https://github.com/khronokernel/IORegistryClone/blob/master/ioreg-210.zip) is a bit easier on file size.
@@ -38,15 +38,15 @@ This section is for those who want to get down into the meats of their hackintos
 * [ProperTree](https://github.com/corpnewt/ProperTree)
   * Or any other plist editor
   
-Now with all this out of the way, lets get to USB mapping!
+Now with all this out of the way, let's get to USB mapping!
 
 ## Finding your USB ports
 
-Lets open our previously downloaded [IORegistryExplorer.app](https://github.com/khronokernel/IORegistryClone/blob/master/ioreg-302.zip) and search for our USB controller(s).
+Let's open our previously downloaded [IORegistryExplorer.app](https://github.com/khronokernel/IORegistryClone/blob/master/ioreg-302.zip) and search for our USB controller(s).
 
 The 2 main search terms are `XHC` and `EHC`, but if you have a legacy board with UHCI or OHCI controllers you'll need to adjust. A blanket `USB` search may show too many entries and confuse you.
 
-For this example, lets try and map an Asus X299-E Strix board:
+For this example, let's try and map an Asus X299-E Strix board:
 
 ![](../../images/post-install/manual-md/initial-boot.png)
 
@@ -58,7 +58,7 @@ From the above image we can see 3 USB controllers:
 
 Pay attention that they're individual controllers, as this means **each USB controller has it's own port limit**. So you're not as starved for USB ports as you may think.
 
-Now I personally know which USB controllers match up with which physical ports, problem is it's not always as obvious which ports match with which controllers. So lets try to figure out which is what.
+Now I personally know which USB controllers match up with which physical ports, the problem is it's not always as obvious which ports match with which controllers. So let's try to figure out which is what.
 
 **Note**: The AppleUSBLegacyRoot entry is an entry that lists all active USB controllers and ports, these are not USB controllers themselves so you can outright ignore them.
 
@@ -93,7 +93,7 @@ To start, I'm going to plug a USB device into my front USB 3.1(Type-A) and 3.2(T
 
 ![](../../images/post-install/manual-md/front-io-plugged.png)
 
-Next lets look at IOReg, and we can see where our USB devices fell:
+Next let's look at IOReg, and we can see where our USB devices fell:
 
 | USB-C | USB-A |
 | :--- | :--- |
@@ -104,13 +104,13 @@ Here we see a few things:
 * Front 3.2 Type-C is on the PXSX(2, middle) Controller
 * Front 3.1 Type-A is on the XHCI(3, Bottom) Controller
 
-Now that we have an idea of which ports go to which controller, can can now look into how we USB map.
+Now that we have an idea of which ports go to which controller, can now look into how we USB map.
 
 ### USB-A mapping
 
-As mentioned before, USB 3.x ports are split into 2 personalities: USB 2.0 and USB 3.0. This is to ensure backwards compatibility but macOS itself has difficulties determining which personalities match up to which ports. That's where we come in to help.
+As mentioned before, USB 3.x ports are split into 2 personalities: USB 2.0 and USB 3.0. This is to ensure backward compatibility but macOS itself has difficulties determining which personalities match up to which ports. That's where we come in to help.
 
-So lets take our USB-A port, when we plug in a USB 3.0 device into it we see `XHCI -> SS03` light up. This is the USB 3.0 personality of the port. Now we'll want to plug a USB 2.0 device into that port:
+So let's take our USB-A port, when we plug in a USB 3.0 device into it we see `XHCI -> SS03` light up. This is the USB 3.0 personality of the port. Now we'll want to plug a USB 2.0 device into that port:
 
 | 3.0 Personality | 2.0 Personality |
 | :--- | :--- |
@@ -143,7 +143,7 @@ Note:
 
 ### USB-C mapping
 
-Next lets map our USB-C port, this is where it gets quite tricky as you may have noticed earlier:
+Next let's map our USB-C port, this is where it gets quite tricky as you may have noticed earlier:
 
 | Type | Info | Comments |
 | :--- | :--- | :--- |
@@ -180,7 +180,7 @@ Keep this in mind, as this plays into the Type 255 and getting certain services
 
 #### USRx Ports
 
-When mapping, you may notice some extra ports left over, specifically USR1 and USR2. These ports are known as "USBR" ports, or more specifically [USB Redirection Ports](https://software.Intel.com/content/www/us/en/develop/documentation/amt-developer-guide/top/storage-redirection.html). Use of these is for remote management but real Macs don't ship with USBR devices and so has no support for them OS-wise. You can actually ignore these entries in your USB map:
+When mapping, you may notice some extra ports left over, specifically USR1 and USR2. These ports are known as "USBR" ports, or more specifically [USB Redirection Ports](https://software.Intel.com/content/www/us/en/develop/documentation/amt-developer-guide/top/storage-redirection.html). Use of these is for remote management but real Macs don't ship with USBR devices. So macOS has no support for them OS-wise. You can actually ignore these entries in your USB map:
 
 ![](../../images/post-install/manual-md/usr.png)
 
@@ -189,7 +189,7 @@ When mapping, you may notice some extra ports left over, specifically USR1 and U
 In some rare situations, certain USB ports may not show up in macOS at all. This is likely due to a missing definition in your ACPI tables, and so we have a few options:
 
 * Coffee Lake and older should use [USBInjectAll](https://github.com/Sniki/OS-X-USB-Inject-All/releases)
-  * Don't forget to add this to both EFI/OC/Kexts and you config.plist's kernel -> Add
+  * Don't forget to add this to both EFI/OC/Kexts and your config.plist's kernel -> Add
 * Comet Lake and newer should use SSDT-RHUB
 * AMD systems should also use SSDT-RHUB
 
@@ -204,7 +204,7 @@ Next, open our newly downloaded SSDT with maciASL, you should be presented with
 
 ![](../../images/post-install/manual-md/ssdt-rhub-normal.png)
 
-Now, open IOReg and find the USB controller you want to reset(pay very close attention its the USB controller and not the child RHUB with the same name):
+Now, open IOReg and find the USB controller you want to reset(pay very close attention it's the USB controller and not the child RHUB with the same name):
 
 If you look to the right side, you should see the `acpi-apth` property. Here we're going to need to translate it to something our SSDT can use:
 
@@ -258,7 +258,7 @@ Finally, remember to add this SSDT to both EFI/OC/ACPI and your config.plist und
 
 ## Creating our kext
 
-Its the time you've all been waiting for, we finally get to create our USB map!
+It's the time you've all been waiting for, we finally get to create our USB map!
 
 First off, we'll want to grab a sample USB map kext:
 
@@ -270,7 +270,7 @@ Next right click the .kext, and select `Show Package Contents`. then drill down
 | :--- | :--- |
 | ![](../../images/post-install/manual-md/show-contents.png) | ![](../../images/post-install/manual-md/info-plist.png) |
 
-Now lets open ProperTree and look at this info.plist:
+Now let's open ProperTree and look at this info.plist:
 
 ![](../../images/post-install/manual-md/info-plist-open.png)
 
@@ -280,9 +280,9 @@ Here we see a few sections, under `IOKitPersonalities`:
 * RP07 - PXSX(2)
 * XHCI - XHCI
 
-Each entry here represents a USB controller, specifically the map for each controller. The names of the entry don't matter much however, it's more for book keeping so you know which entry to has which USB map.
+Each entry here represents a USB controller, specifically the map for each controller. The names of the entry don't matter much however, it's more for bookkeeping so you know which entry has which USB map.
 
-Next lets head into the `RP05 - PXSX(1)` entry:
+Next let's head into the `RP05 - PXSX(1)` entry:
 
 ![](../../images/post-install/manual-md/rp05-entry.png)
 
@@ -297,7 +297,7 @@ Here we see a few more important properties:
 
 ### Determining the properties
 
-Determining the value for each property is actually quite straight forward:
+Determining the value for each property is actually quite straightforward:
 
 * [IOPathMatch](#iopathmatch)
 * [IOProviderClass](#ioproviderclass)
@@ -399,12 +399,12 @@ Now that we've gone over how to map your USB ports for a specific controller, yo
 
 ## Cleaning up
 
-Once your saved your USB map's info.plist, remember to add the kext to both your EFI/OC/Kexts and under you config.plist's Kernel -> Add(ProperTree's snapshot can do this for you)
+Once your saved your USB map's info.plist, remember to add the kext to both your EFI/OC/Kexts and under your config.plist's Kernel -> Add(ProperTree's snapshot can do this for you)
 
 Next, remove/disable:
 
 * USBInjectAll.kext(if you're using it)
-  * Reason for this is USBInjectAll actually breaks how Apple builds port maps. So while it's great for initial port mapping, it can break you final USB map
+  * Reason for this is USBInjectAll actually breaks how Apple builds port maps. So while it's great for initial port mapping, it can break your final USB map
 * Kernel -> Quirks -> XhciPortLimit -> False
   * Now that we're finally under the 15 port limit, we no longer need this hacky fix
 
diff --git a/usb/misc/instant-wake.md b/usb/misc/instant-wake.md
index 5d9af9cc..5d7f5287 100644
--- a/usb/misc/instant-wake.md
+++ b/usb/misc/instant-wake.md
@@ -1,6 +1,6 @@
 # GPRW/UPRW/LANC Instant Wake Patch
 
-Similar idea to the "Fixing Shutdown/Restart" section, macOS will instant wake if either USB or power states change while sleeping. To fix this we need to reroute the GPRW/UPRW/LANC calls to a new SSDT, verify you have instant wake issues before trying the below.
+Similar idea to the "Fixing Shutdown/Restart" section, macOS will instantly wake if either USB or power states change while sleeping. To fix this we need to reroute the GPRW/UPRW/LANC calls to a new SSDT, verify you have instant wake issues before trying the below.
 
 Best way to check:
 
diff --git a/usb/misc/keyboard.md b/usb/misc/keyboard.md
index 46e89e08..3f6dcb07 100644
--- a/usb/misc/keyboard.md
+++ b/usb/misc/keyboard.md
@@ -48,9 +48,9 @@ Now with that done, you can compile and add it to your EFI and config.plist. See
 
 Before we get deep into configuring darkwake, it would be best to explain what darkwake is. A great in-depth thread by holyfield can be found here: [DarkWake on macOS Catalina](https://www.insanelymac.com/forum/topic/342002-darkwake-on-macos-catalina-boot-args-darkwake8-darkwake10-are-obsolete/)
 
-In its simplest form, you can think of darkwake as "partial wake", where only certain parts of your hardware are lit up for maintenance tasks while others remain asleep(ie. Display). Reason we may care about this is that darkwake can add extra steps to the wake process like keyboard press, but outright disabling it can make our hack wake randomly. So ideally we'd go through the below table to find an ideal value.
+In its simplest form, you can think of darkwake as "partial wake", where only certain parts of your hardware are lit up for maintenance tasks while others remain asleep(ie. Display). The reason we may care about this is that darkwake can add extra steps to the wake process like keyboard press, but outright disabling it can make our hack wake randomly. So ideally we'd go through the below table to find an ideal value.
 
-Now lets take a look at [IOPMrootDomain's source code](https://opensource.apple.com/source/xnu/xnu-6153.81.5/iokit/Kernel/IOPMrootDomain.cpp.auto.html):
+Now let's take a look at [IOPMrootDomain's source code](https://opensource.apple.com/source/xnu/xnu-6153.81.5/iokit/Kernel/IOPMrootDomain.cpp.auto.html):
 
 ```cpp
 // gDarkWakeFlags
@@ -65,7 +65,7 @@ enum {
 };
 ```
 
-Now lets go through each bit:
+Now let's go through each bit:
 
 | Bit | Name | Comment |
 | :--- | :--- | :--- |
diff --git a/usb/system-preparation.md b/usb/system-preparation.md
index 7bfd0c0b..79e7e587 100644
--- a/usb/system-preparation.md
+++ b/usb/system-preparation.md
@@ -6,7 +6,7 @@ Table of Contents:
 * [Checking what renames you need](#checking-what-renames-you-need)
 * [Parting ways](#parting-ways)
 
-So before we can USB map, we need to set a couple things:
+So before we can USB map, we need to set a couple of things:
 
 * [USBInjectAll](https://github.com/Sniki/OS-X-USB-Inject-All/releases) under both EFI/OC/Kexts and config.plist -> Kernel -> Add
   * We need this kext to make sure any ports not defined in ACPI will still show up in macOS, note that this *shouldn't* be required on Skylake and newer as the USB ports are defined within ACPI.
@@ -16,7 +16,7 @@ So before we can USB map, we need to set a couple things:
   * So we can temporally get around the 15 port limit to map our ports
 * config.plist -> ACPI -> Patch -> EHCI and XHCI ACPI renames
 
-The reason we need these ACPI renames are due to conflicting with Apple's own USB map, fun fact even Apple has to USB map as well! You can actually find Apple's USB map within IOUSBHostFamily.kext -> PlugIns -> AppleUSBHostPlatformProperties.kext in Catalina, though newer Macs actually port map with their ACPI tables instead.
+The reason we need these ACPI renames is due to conflicting with Apple's own USB map, fun fact even Apple has to USB map as well! You can actually find Apple's USB map within IOUSBHostFamily.kext -> PlugIns -> AppleUSBHostPlatformProperties.kext in Catalina, though newer Macs actually port map with their ACPI tables instead.
 
 SMBIOSes that **do not** need the ACPI renames:
 
@@ -120,7 +120,7 @@ ioreg -l -p IOService -w0 | grep -i EHC2
 
 **If nothing returns(like with the right image)**, you don't need any renames.
 
-**If one of the 3 entries return(like with the left image)**, you'll need a rename for whatever returns.
+**If one of the 3 entries returns(like with the left image)**, you'll need a rename for whatever returns.
 
 If you're in the latter camp, you'll now want to add the needed ACPI renames to your config.plist -> ACPI -> Patch, you can find a pre-made file here(note that you'll need to enable the ones you need):