arch-handbook: Fix a few nits

A couple of typos were noticed during the conversion to one sentence per line, and have now been corrected.

While here, move a manual page reference into the same line as the sentence that refers to it.

1 files changed, 3 insertions, 3 deletions

diff --git a/documentation/content/en/books/arch-handbook/boot/_index.adoc b/documentation/content/en/books/arch-handbook/boot/_index.adoc
index 7f1aceddd3..cca516e445 100644
--- a/documentation/content/en/books/arch-handbook/boot/_index.adoc
+++ b/documentation/content/en/books/arch-handbook/boot/_index.adoc
@@ -69,7 +69,7 @@ FreeBSD supports the CSM boot standard (Compatibility Support Module).
 So CSM is supported (with both GPT and MBR partitioning support) and UEFI booting (GPT is totally supported, MBR is mostly supported).
 It also supports loading files from ext2fs, MSDOS, UFS and ZFS.
 FreeBSD also supports the boot environment feature of ZFS which allows the HOST OS to communicate details about what to boot that go beyond a simple partition as was possible in the past.
-But UEFI is more relevant than the CMS these days.
+But UEFI is more relevant than the CSM these days.
 The example that follows shows booting an x86 computer from an MBR-partitioned hard drive with the FreeBSD [.filename]#boot0# multi-boot loader stored in the very first sector.
 That boot code starts the FreeBSD three-stage boot process.
 
@@ -706,7 +706,7 @@ Recall that `nread` uses memory address `0x8c00` as the transfer buffer to hold
 This address is conveniently chosen.
 Indeed, because [.filename]#boot1# belongs to the first 512 bytes, it ends up in the address range `0x8c00`-`0x8dff`.
 The 512 bytes that follows (range `0x8e00`-`0x8fff`) is used to store the _bsdlabel_ footnote:[Historically known as disklabel.
-If you ever wondered where FreeBSD stored this information, it is in this region. See man:bsdlabel[8]].
+If you ever wondered where FreeBSD stored this information, it is in this region - see man:bsdlabel[8]].
 
 Starting at address `0x9000` is the beginning of the BTX server, and immediately following is the [.filename]#boot2# client.
 The BTX server acts as a kernel, and executes in protected mode in the most privileged level.
@@ -1394,7 +1394,7 @@ Additionally, these sysctls are set by `init_param1()`: `kern.maxswzone, kern.ma
 Then `init386()` prepares the Global Descriptors Table (GDT).
 Every task on an x86 is running in its own virtual address space, and this space is addressed by a segment:offset pair.
 Say, for instance, the current instruction to be executed by the processor lies at CS:EIP, then the linear virtual address for that instruction would be "the virtual address of code segment CS" + EIP.
-For convenience, segments begin at virtual address 0 and end at a 4Gb boundary.
+For convenience, segments begin at virtual address 0 and end at a 4GB boundary.
 Therefore, the instruction's linear virtual address for this example would just be the value of EIP.
 Segment registers such as CS, DS etc are the selectors, i.e., indexes, into GDT (to be more precise, an index is not a selector itself, but the INDEX field of a selector).
 FreeBSD's GDT holds descriptors for 15 selectors per CPU: