> For the complete documentation index, see [llms.txt](https://book.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.bsdcn.org/4.3-bsd-unix-cao-zuo-xi-tong-she-ji-yu-shi-xian/di-wu-bu-fen-xi-tong-yun-xing/13.1.-gai-shu.md).

# 13.1 概述

计算机上电时，CPU 上没有任何程序在运行。要启动一个程序，必须先把它映像从存储设备装入内存。许多微处理器系统自动启动驻留在可编程只读存储器（PROM）等非易失存储设备中的程序。程序映像装入后，必须引导 CPU 从装入程序的第一个内存位置开始执行。把程序 **自举**（bootstrap）到运行状态的过程，用于启动 CPU 上运行的任何程序。

本章考察 UNIX 内核（或任何其他类似程序）如何被自举，然后研究初始化阶段系统的运作——从 **冷启动** 到可以运行用户态程序的那一点。最后一节考察与启动过程相关的话题：配置内核装入映像、关闭运行中的系统、调试系统故障。

UNIX 内核只是一个程序，尽管很大。与任何 UNIX 程序一样，它的二进制映像装在文件系统的文件里，直到被装入并启动。4.3BSD 假定内核的可执行映像装在指定为根文件系统的文件系统中名为 **vmunix** 的文件里。在机器上自举 UNIX 时，先装入并启动一个名为 **boot** 的特殊程序。**boot** 程序的任务是装入并初始化一个程序的可执行映像、启动它运行。**boot** 可以来自与它自举的文件相同的存储设备，也可以从机器的控制台处理器专门为自举支持的存储设备装入。

**boot** 程序把待自举程序的二进制映像读进主存，然后初始化 CPU，使装入的程序得以启动。经 **boot** 装入的程序启动时虚拟地址转换和硬件中断都被禁止；装入的程序负责启用这些设施和它打算使用的任何其他硬件（如 I/O 设备）。

UNIX 内核被 **boot** 程序装入后，为进入正常运行状态经历若干阶段软硬件初始化。第一阶段负责初始化 CPU 的状态，包括运行时栈和虚拟内存映射。内存映射（含虚拟地址转换）在启动过程的早期启用，以尽量减少必须编写的专用汇编语言代码。虚拟内存映射启用后，系统先做依赖机器的初始化，再做独立于机器的初始化。依赖机器的操作包括建立虚拟内存页表和配置 I/O 设备；独立于机器的动作包括挂载根文件系统和初始化无数系统数据结构。这一次序是必要的，因为许多独立于机器的初始化依赖 I/O 设备被妥善初始化。

内核的独立于机器部分设置完毕，系统进入可运行状态：创建系统进程并置为可运行，从文件系统调入用户级程序执行。此时系统已准备好运行正常的应用。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://book.bsdcn.org/4.3-bsd-unix-cao-zuo-xi-tong-she-ji-yu-shi-xian/di-wu-bu-fen-xi-tong-yun-xing/13.1.-gai-shu.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.