From owner-svn-doc-all@freebsd.org Thu Sep 5 19:40:44 2019 Return-Path: Delivered-To: svn-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 39620D178C; Thu, 5 Sep 2019 19:40:44 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46PWJD1Xdfz4HfQ; Thu, 5 Sep 2019 19:40:44 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 1985F9208; Thu, 5 Sep 2019 19:40:44 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id x85JehWE001071; Thu, 5 Sep 2019 19:40:43 GMT (envelope-from bcr@FreeBSD.org) Received: (from bcr@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id x85JehB2001070; Thu, 5 Sep 2019 19:40:43 GMT (envelope-from bcr@FreeBSD.org) Message-Id: <201909051940.x85JehB2001070@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bcr set sender to bcr@FreeBSD.org using -f From: Benedict Reuschling Date: Thu, 5 Sep 2019 19:40:43 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r53376 - head/en_US.ISO8859-1/books/arch-handbook/boot X-SVN-Group: doc-head X-SVN-Commit-Author: bcr X-SVN-Commit-Paths: head/en_US.ISO8859-1/books/arch-handbook/boot X-SVN-Commit-Revision: 53376 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2019 19:40:44 -0000 Author: bcr Date: Thu Sep 5 19:40:43 2019 New Revision: 53376 URL: https://svnweb.freebsd.org/changeset/doc/53376 Log: Cleanup some textproc/igor warnings where possible: - wrap long lines - spelling Event: vBSDcon FreeBSD Hackathon Modified: head/en_US.ISO8859-1/books/arch-handbook/boot/chapter.xml Modified: head/en_US.ISO8859-1/books/arch-handbook/boot/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/arch-handbook/boot/chapter.xml Thu Sep 5 19:36:06 2019 (r53375) +++ head/en_US.ISO8859-1/books/arch-handbook/boot/chapter.xml Thu Sep 5 19:40:43 2019 (r53376) @@ -51,17 +51,18 @@ $FreeBSD$ booting system initialization This chapter is an overview of the boot and system - initialization processes, starting from the BIOS (firmware) - POST, to the first user process creation. Since the initial + initialization processes, starting from the + BIOS (firmware) POST, to + the first user process creation. Since the initial steps of system startup are very architecture dependent, the IA-32 architecture is used as an example. The &os; boot process can be surprisingly complex. After - control is passed from the BIOS, a considerable amount of - low-level configuration must be done before the kernel can be - loaded and executed. This setup must be done in a simple and - flexible manner, allowing the user a great deal of customization - possibilities. + control is passed from the BIOS, a + considerable amount of low-level configuration must be done + before the kernel can be loaded and executed. This setup must + be done in a simple and flexible manner, allowing the user a + great deal of customization possibilities. @@ -116,10 +117,10 @@ F5 Disk 2 boot2 - This prompt will appear if the user - presses a key just after selecting an OS to boot - at the boot0 - stage. + This prompt will appear if the user + presses a key just after selecting an OS to boot at + the boot0 + stage. >>FreeBSD/i386 BOOT Default: 1:ad(1,a)/boot/loader boot: @@ -241,12 +242,12 @@ FreeBSD clang version 3.3 (tags/RELEASE_33/final 18350 partitions . + xlink:href="http://en.wikipedia.org/wiki/Master_boot_record">. boot0 resides in the filesystem as /boot/boot0. It is a small 512-byte file, and it is exactly what &os;'s installation procedure wrote to - the hard disk's MBR if you chose the bootmanager - option at installation time. Indeed, + the hard disk's MBR if you chose the + bootmanager option at installation time. Indeed, boot0 is the MBR. @@ -895,9 +896,9 @@ read_key: Register %bx holds the memory address where the MBR will be loaded. The instruction pushing %cs onto the stack is very - interesting. In this context, it accomplishes nothing. However, as - we will see shortly, boot2, in conjunction - with the BTX server, also uses + interesting. In this context, it accomplishes nothing. + However, as we will see shortly, boot2, in + conjunction with the BTX server, also uses xread.1. This mechanism will be discussed in the next section. @@ -1000,9 +1001,10 @@ main.3: boot1 are 512 bytes each, so they fit exactly in one disk sector. boot2 is much bigger, holding both - the BTX server and the boot2 client. - Finally, a file called simply boot is 512 - bytes larger than boot2. This file is a + the BTX server and the + boot2 client. Finally, a file called + simply boot is 512 bytes larger than + boot2. This file is a concatenation of boot1 and boot2. As already noted, boot0 is the file written to the absolute @@ -1065,7 +1067,7 @@ main.3: This is necessary for legacy reasons. Interested readers should see . - and concludes with a jump to the starting point of the + and concludes with a jump to the starting point of the BTX server:
@@ -1252,8 +1254,7 @@ seta20.3:
<filename>sys/boot/i386/boot2/boot2.h</filename> - - #define XREADORG 0x725 + #define XREADORG 0x725
Recall that boot1 was relocated (i.e., @@ -1332,7 +1333,7 @@ seta20.3: BTX server. This file, which takes exactly 16 sectors, or 8192 bytes, is what is actually written to the beginning of the &os; slice - during instalation. Let us now proceed to study the + during installation. Let us now proceed to study the BTX server program. The BTX server prepares a simple @@ -1461,14 +1462,14 @@ init: cli # Disable interrupts Recall that boot1 was originally loaded to address 0x7c00, so, with this memory - initialization, that copy effectively dissapeared. However, + initialization, that copy effectively disappeared. However, also recall that boot1 was relocated to 0x700, so that copy is still in memory, and the BTX server will make use of it. Next, the real-mode IVT (Interrupt Vector - Table is updated. The IVT is an array of + Table is updated. The IVT is an array of segment/offset pairs for exception and interrupt handlers. The BIOS normally maps hardware interrupts to interrupt vectors 0x8 to @@ -1599,18 +1600,19 @@ init.4: movb $_ESP0H,TSS_ESP0+1(%di) # Set ESP0
Note that a value is given for the Privilege Level 0 stack - pointer and stack segment in the TSS. This is needed because, - if an interrupt or exception is received while executing - boot2 in Privilege Level 3, a change to - Privilege Level 0 is automatically performed by the processor, - so a new working stack is needed. Finally, the I/O Map Base - Address field of the TSS is given a value, which is a 16-bit - offset from the beginning of the TSS to the I/O Permission - Bitmap and the Interrupt Redirection Bitmap. + pointer and stack segment in the TSS. This + is needed because, if an interrupt or exception is received + while executing boot2 in Privilege Level 3, + a change to Privilege Level 0 is automatically performed by the + processor, so a new working stack is needed. Finally, the I/O + Map Base Address field of the TSS is given a + value, which is a 16-bit offset from the beginning of the + TSS to the I/O Permission Bitmap and the + Interrupt Redirection Bitmap. - After the IDT and TSS are created, the processor is ready to - switch to protected mode. This is done in the next - block: + After the IDT and TSS + are created, the processor is ready to switch to protected mode. + This is done in the next block:
<filename>sys/boot/i386/btx/btx/btx.S</filename> @@ -1633,20 +1635,22 @@ init.8: xorl %ecx,%ecx # Zero
First, a call is made to setpic to - program the 8259A PIC (Programmable Interrupt Controller). - This chip is connected to multiple hardware interrupt sources. - Upon receiving an interrupt from a device, it - signals the processor with the appropriate interrupt vector. + program the 8259A PIC (Programmable Interrupt + Controller). This chip is connected to multiple hardware + interrupt sources. Upon receiving an interrupt from a device, + it signals the processor with the appropriate interrupt vector. This can be customized so that specific interrupts are associated with specific interrupt vectors, as explained before. - Next, the IDTR (Interrupt Descriptor Table Register) and - GDTR (Global Descriptor Table Register) are loaded with the - instructions lidt and lgdt, respectively. These registers are - loaded with the base address and limit address for the IDT and - GDT. The following three instructions set the Protection Enable - (PE) bit of the %cr0 register. This - effectively switches the processor to - 32-bit protected mode. Next, a long jump is made to + Next, the IDTR (Interrupt Descriptor Table + Register) and GDTR (Global Descriptor Table + Register) are loaded with the instructions + lidt and lgdt, + respectively. These registers are loaded with the base address + and limit address for the IDT and + GDT. The following three instructions set + the Protection Enable (PE) bit of the %cr0 + register. This effectively switches the processor to 32-bit + protected mode. Next, a long jump is made to init.8 using segment selector SEL_SCODE, which selects the Supervisor Code Segment. The processor is effectively executing in CPL 0, the most privileged level, after @@ -1656,10 +1660,10 @@ init.8: xorl %ecx,%ecx # Zero privilege level of 0. Our last code block is responsible for loading the - TR (Task Register) with the segment selector for the TSS we created - earlier, and setting the User Mode environment before passing - execution control to the boot2 - client. + TR (Task Register) with the segment selector + for the TSS we created earlier, and setting + the User Mode environment before passing execution control to + the boot2 client.
<filename>sys/boot/i386/btx/btx/btx.S</filename> @@ -1698,17 +1702,18 @@ init.9: push $0x0 # general Note that the client's environment include a stack segment selector and stack pointer (registers %ss and - %esp). Indeed, once the TR is loaded with - the appropriate stack segment selector (instruction - ltr), the stack pointer is calculated and - pushed onto the stack along with the stack's segment selector. - Next, the value 0x202 is pushed onto the - stack; it is the value that the EFLAGS will get when control is - passed to the client. Also, the User Mode code segment selector - and the client's entry point are pushed. Recall that this entry - point is patched in the BTX header at link time. Finally, - segment selectors (stored in register %ecx) - for the segment registers + %esp). Indeed, once the + TR is loaded with the appropriate stack + segment selector (instruction ltr), the stack + pointer is calculated and pushed onto the stack along with the + stack's segment selector. Next, the value + 0x202 is pushed onto the stack; it is the + value that the EFLAGS will get when control is passed to the + client. Also, the User Mode code segment selector and the + client's entry point are pushed. Recall that this entry + point is patched in the BTX header at link + time. Finally, segment selectors (stored in register + %ecx) for the segment registers %gs, %fs, %ds and %es are pushed onto the stack, along with the value at %edx (0xa000). Keep in mind the various values @@ -1726,12 +1731,12 @@ init.9: push $0x0 # general various segment registers. Five values still remain on the stack. They are popped when the iret instruction is executed. This instruction first pops - the value that was pushed from the BTX header. This value is a - pointer to boot2's entry point. It is - placed in the register %eip, the instruction - pointer register. Next, the segment selector for the User - Code Segment is popped and copied to register - %cs. Remember that + the value that was pushed from the BTX + header. This value is a pointer to boot2's + entry point. It is placed in the register + %eip, the instruction pointer register. + Next, the segment selector for the User Code Segment is popped + and copied to register %cs. Remember that this segment's privilege level is 3, the least privileged level. This means that we must provide values for the stack of this privilege level. This is why the processor, besides @@ -1760,9 +1765,10 @@ init.9: push $0x0 # general loader, and then further to the kernel. Some nodes of this structures are set by boot2, the rest by the loader. This structure, among other information, contains the - kernel filename, BIOS harddisk geometry, BIOS drive number for - boot device, physical memory available, envp - pointer etc. The definition for it is: + kernel filename, BIOS harddisk geometry, + BIOS drive number for boot device, physical + memory available, envp pointer etc. The + definition for it is: /usr/include/machine/bootinfo.h: struct bootinfo { @@ -1795,8 +1801,10 @@ struct bootinfo { ino_t lookup(char *filename) and int xfsread(ino_t inode, void *buf, size_t nbyte) are used to read the content of a file into - memory. /boot/loader is an ELF binary, but - where the ELF header is prepended with a.out's struct + memory. /boot/loader is an + ELF binary, but where the + ELF header is prepended with + a.out's struct exec structure. load() scans the loader's ELF header, loading the content of /boot/loader into memory, and passing the @@ -1811,10 +1819,11 @@ struct bootinfo { <application>loader</application> Stage - loader is a BTX client as well. - I will not describe it here in detail, there is a comprehensive - manpage written by Mike Smith, &man.loader.8;. The underlying - mechanisms and BTX were discussed above. + loader is a + BTX client as well. I will not describe it + here in detail, there is a comprehensive man page written by + Mike Smith, &man.loader.8;. The underlying mechanisms and + BTX were discussed above. The main task for the loader is to boot the kernel. When the kernel is loaded into memory, it is being called by the