help. Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.
-Maintainer: Will Deacon <will.deacon@arm.com>
-Chinese maintainer: Fu Wei <wefu@redhat.com>
+M: Will Deacon <will.deacon@arm.com>
+zh_CN: Fu Wei <wefu@redhat.com>
+C: 1926e54f115725a9248d0c4c65c22acaf94de4c4
---------------------------------------------------------------------
Documentation/arm64/booting.txt 的中文翻译
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题，请联系中文版维护者。
-本文翻译提交时的 Git 检出点为： bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
-
英文版维护者： Will Deacon <will.deacon@arm.com>
中文版维护者： 傅炜 Fu Wei <wefu@redhat.com>
中文版翻译者： 傅炜 Fu Wei <wefu@redhat.com>
中文版校译者： 傅炜 Fu Wei <wefu@redhat.com>
+本文翻译提交时的 Git 检出点为： 1926e54f115725a9248d0c4c65c22acaf94de4c4
以下为正文
---------------------------------------------------------------------
本文档基于 Russell King 的 ARM 启动文档，且适用于所有公开发布的
AArch64 Linux 内核代码。
-AArch64 异常模型由多个异常级别（EL0 - EL3）组成，对于 EL0 和 EL1
-异常级有对应的安全和非安全模式。EL2 是系统管理级，且仅存在于
-非安全模式下。EL3 是最高特权级，且仅存在于安全模式下。
+AArch64 异常模型由多个异常级（EL0 - EL3）组成，对于 EL0 和 EL1 异常级
+有对应的安全和非安全模式。EL2 是系统管理级，且仅存在于非安全模式下。
+EL3 是最高特权级，且仅存在于安全模式下。
基于本文档的目的，我们将简单地使用‘引导装载程序’（‘boot loader’）
这个术语来定义在将控制权交给 Linux 内核前 CPU 上执行的所有软件。
必要性: 强制
引导装载程序应该找到并初始化系统中所有内核用于保持系统变量数据的 RAM。
-è¿\99个æ\93\8dä½\9cç\9a\84æ\89§è¡\8cæ\98¯è®¾å¤\87ä¾\9dèµ\96ç\9a\84。（它可能使用内部算法来自动定位和计算所有
-RAM，或可能使用对这个设备已知的 RAM 信息，还可能使用任何引导装载程序
-设计者想到的匹配方法。）
+è¿\99个æ\93\8dä½\9cç\9a\84æ\89§è¡\8cæ\96¹å¼\8få\9b 设å¤\87è\80\8cå¼\82。（它可能使用内部算法来自动定位和计算所有
+RAM，或可能使用对这个设备已知的 RAM 信息，还可能是引导装载程序设计者
+想到的任何合适的方法。）
2、设置设备树数据
必要性: 强制
-设备树数据块（dtb）必须 8 字节对齐，并位于从内核映像起始算起第一个 512MB
-内，且不得跨越 2MB 对齐边界。这使得内核可以通过初始页表中的单个节描述符来
-映射此数据块。
+设备树数据块（dtb）必须 8 字节对齐，且大小不能超过 2MB。由于设备树
+数据块将在使能缓存的情况下以 2MB 粒度被映射，故其不能被置于带任意
+特定属性被映射的 2MB 区域内。
+注： v4.2 之前的版本同时要求设备树数据块被置于从内核映像以下
+text_offset 字节处算起第一个 512MB 内。
3、解压内核映像
-------------
AArch64 内核当前没有提供自解压代码，因此如果使用了压缩内核映像文件
（比如 Image.gz），则需要通过引导装载程序（使用 gzip 等）来进行解压。
-若引导装载程序没有实现这个需求，就要使用非压缩内核映像文件。
+若引导装载程序没有实现这个功能，就要使用非压缩内核映像文件。
4、调用内核映像
u64 res3 = 0; /* 保留 */
u64 res4 = 0; /* 保留 */
u32 magic = 0x644d5241; /* 魔数, 小端, "ARM\x64" */
- u32 res5; /* 保留 （用于 PE COFF 偏移） */
+ u32 res5; /* 保留 （用于 PE COFF 偏移） */
映像头注释：
- code0/code1 负责跳转到 stext.
- 当通过 EFI 启动时， 最初 code0/code1 被跳过。
- res5 是到 PE 文件头的偏移，而 PE 文件头含有 EFI 的启动入口点 （efi_stub_entry）。
- 当 stub 代码完成了它的使命，它会跳转到 code0 继续正常的启动流程。
+ res5 是到 PE 文件头的偏移，而 PE 文件头含有 EFI 的启动入口点
+ （efi_stub_entry）。当 stub 代码完成了它的使命，它会跳转到 code0
+ 继续正常的启动流程。
- v3.17 之前，未明确指定 text_offset 的字节序。此时，image_size 为零，
且 text_offset 依照内核字节序为 0x80000。
- 当 image_size 非零，text_offset 为小端模式且是有效值，应被引导加载程序使用。
- 当 image_size 为零，text_offset 可假定为 0x80000。
+ 当 image_size 非零，text_offset 为小端模式且是有效值，应被引导加载
+ 程序使用。当 image_size 为零，text_offset 可假定为 0x80000。
- flags 域 (v3.17 引入) 为 64 位小端模式，其编码如下：
位 0: 内核字节序。 1 表示大端模式，0 表示小端模式。
- 位 1-63: 保留。
-
-- 当 image_size 为零时，引导装载程序应该试图在内核映像末尾之后尽可能多地保留空闲内存
- 供内核直接使用。对内存空间的需求量因所选定的内核特性而异, 且无实际限制。
-
-内核映像必须被放置在靠近可用系统内存起始的 2MB 对齐为基址的 text_offset 字节处，并从那里被调用。
-当前，对 Linux 来说在此基址以下的内存是无法使用的，因此强烈建议将系统内存的起始作为这个基址。
-从映像起始地址算起，最少必须为内核释放出 image_size 字节的空间。
-
-任何提供给内核的内存（甚至在 2MB 对齐的基地址之前），若未从内核中标记为保留
+ 位 1-2: 内核页大小。
+ 0 - 未指定。
+ 1 - 4K
+ 2 - 16K
+ 3 - 64K
+ 位 3-63: 保留。
+
+- 当 image_size 为零时，引导装载程序应试图在内核映像末尾之后尽可能
+ 多地保留空闲内存供内核直接使用。对内存空间的需求量因所选定的内核
+ 特性而异, 并无实际限制。
+
+内核映像必须被放置在靠近可用系统内存起始的 2MB 对齐为基址的
+text_offset 字节处，并从该处被调用。当前，对 Linux 来说在此基址以下的
+内存是无法使用的，因此强烈建议将系统内存的起始作为这个基址。2MB 对齐
+基址和内核映像起始地址之间的区域对于内核来说没有特殊意义，且可能被
+用于其他目的。
+从映像起始地址算起，最少必须准备 image_size 字节的空闲内存供内核使用。
+
+任何提供给内核的内存（甚至在映像起始地址之前），若未从内核中标记为保留
(如在设备树（dtb）的 memreserve 区域），都将被认为对内核是可用。
在跳转入内核前，必须符合以下状态：
- 高速缓存、MMU
MMU 必须关闭。
- 指令缓存开启或关闭都可以。
+ 指令缓存开启或关闭皆可。
已载入的内核映像的相应内存区必须被清理，以达到缓存一致性点（PoC）。
- 当存在系统缓存或其他使能缓存的一致性主控器时，通常需使用虚拟地址维护其缓存，而非 set/way 操作。
+ 当存在系统缓存或其他使能缓存的一致性主控器时，通常需使用虚拟地址
+ 维护其缓存，而非 set/way 操作。
遵从通过虚拟地址操作维护构架缓存的系统缓存必须被配置，并可以被使能。
- 而不通过虚拟地址操作维护构架缓存的系统缓存（不推荐），必须被配置且禁用。
+ 而不通过虚拟地址操作维护构架缓存的系统缓存（不推荐），必须被配置且
+ 禁用。
- *译者注：对于 PoC 以及缓存相关内容，请参考 ARMv8 构架参考手册 ARM DDI 0487A
+ *译者注：对于 PoC 以及缓存相关内容，请参考 ARMv8 构架参考手册
+ ARM DDI 0487A
- 架构计时器
CNTFRQ 必须设定为计时器的频率，且 CNTVOFF 必须设定为对所有 CPU
在进入内核映像的异常级中，所有构架中可写的系统寄存器必须通过软件
在一个更高的异常级别下初始化，以防止在 未知 状态下运行。
- 对于拥有 GICv3 中断控制器的系统：
- - 若当前在 EL3 ：
+ 对于拥有 GICv3 中断控制器并以 v3 模式运行的系统：
+ - 如果 EL3 存在：
ICC_SRE_EL3.Enable (位 3) 必须初始化为 0b1。
ICC_SRE_EL3.SRE (位 0) 必须初始化为 0b1。
- 若内核运行在 EL1：
ICC_SRE_EL2.Enable (位 3) 必须初始化为 0b1。
ICC_SRE_EL2.SRE (位 0) 必须初始化为 0b1。
+ - 设备树（DT）或 ACPI 表必须描述一个 GICv3 中断控制器。
+
+ 对于拥有 GICv3 中断控制器并以兼容（v2）模式运行的系统：
+ - 如果 EL3 存在：
+ ICC_SRE_EL3.SRE (位 0) 必须初始化为 0b0。
+ - 若内核运行在 EL1：
+ ICC_SRE_EL2.SRE (位 0) 必须初始化为 0b0。
+ - 设备树（DT）或 ACPI 表必须描述一个 GICv2 中断控制器。
以上对于 CPU 模式、高速缓存、MMU、架构计时器、一致性、系统寄存器的
必要条件描述适用于所有 CPU。所有 CPU 必须在同一异常级别跳入内核。
projects / GitHub / moto-9609 / android_kernel_motorola_exynos9610.git / commitdiff