diff options
Diffstat (limited to 'Documentation/zh_CN/arm64')
-rw-r--r-- | Documentation/zh_CN/arm64/booting.txt | 54 | ||||
-rw-r--r-- | Documentation/zh_CN/arm64/legacy_instructions.txt | 72 | ||||
-rw-r--r-- | Documentation/zh_CN/arm64/memory.txt | 65 |
3 files changed, 143 insertions, 48 deletions
diff --git a/Documentation/zh_CN/arm64/booting.txt b/Documentation/zh_CN/arm64/booting.txt index 6f6d956ac1c9..7cd36af11e71 100644 --- a/Documentation/zh_CN/arm64/booting.txt +++ b/Documentation/zh_CN/arm64/booting.txt @@ -15,6 +15,8 @@ Documentation/arm64/booting.txt 的中文翻译 交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻 译存在问题,请联系中文版维护者。 +本文翻译提交时的 Git 检出点为: bc465aa9d045feb0e13b4a8f32cc33c1943f62d6 + 英文版维护者: Will Deacon <will.deacon@arm.com> 中文版维护者: 傅炜 Fu Wei <wefu@redhat.com> 中文版翻译者: 傅炜 Fu Wei <wefu@redhat.com> @@ -88,22 +90,44 @@ AArch64 内核当前没有提供自解压代码,因此如果使用了压缩内 u32 code0; /* 可执行代码 */ u32 code1; /* 可执行代码 */ - u64 text_offset; /* 映像装载偏移 */ - u64 res0 = 0; /* 保留 */ - u64 res1 = 0; /* 保留 */ + u64 text_offset; /* 映像装载偏移,小端模式 */ + u64 image_size; /* 映像实际大小, 小端模式 */ + u64 flags; /* 内核旗标, 小端模式 * u64 res2 = 0; /* 保留 */ u64 res3 = 0; /* 保留 */ u64 res4 = 0; /* 保留 */ u32 magic = 0x644d5241; /* 魔数, 小端, "ARM\x64" */ - u32 res5 = 0; /* 保留 */ + u32 res5; /* 保留 (用于 PE COFF 偏移) */ 映像头注释: +- 自 v3.17 起,除非另有说明,所有域都是小端模式。 + - code0/code1 负责跳转到 stext. -映像必须位于系统 RAM 起始处的特定偏移(当前是 0x80000)。系统 RAM -的起始地址必须是以 2MB 对齐的。 +- 当通过 EFI 启动时, 最初 code0/code1 被跳过。 + 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。 + +- flags 域 (v3.17 引入) 为 64 位小端模式,其编码如下: + 位 0: 内核字节序。 1 表示大端模式,0 表示小端模式。 + 位 1-63: 保留。 + +- 当 image_size 为零时,引导装载程序应该试图在内核映像末尾之后尽可能多地保留空闲内存 + 供内核直接使用。对内存空间的需求量因所选定的内核特性而异, 且无实际限制。 + +内核映像必须被放置在靠近可用系统内存起始的 2MB 对齐为基址的 text_offset 字节处,并从那里被调用。 +当前,对 Linux 来说在此基址以下的内存是无法使用的,因此强烈建议将系统内存的起始作为这个基址。 +从映像起始地址算起,最少必须为内核释放出 image_size 字节的空间。 + +任何提供给内核的内存(甚至在 2MB 对齐的基地址之前),若未从内核中标记为保留 +(如在设备树(dtb)的 memreserve 区域),都将被认为对内核是可用。 在跳转入内核前,必须符合以下状态: @@ -124,8 +148,12 @@ AArch64 内核当前没有提供自解压代码,因此如果使用了压缩内 - 高速缓存、MMU MMU 必须关闭。 指令缓存开启或关闭都可以。 - 数据缓存必须关闭且无效。 - 外部高速缓存(如果存在)必须配置并禁用。 + 已载入的内核映像的相应内存区必须被清理,以达到缓存一致性点(PoC)。 + 当存在系统缓存或其他使能缓存的一致性主控器时,通常需使用虚拟地址维护其缓存,而非 set/way 操作。 + 遵从通过虚拟地址操作维护构架缓存的系统缓存必须被配置,并可以被使能。 + 而不通过虚拟地址操作维护构架缓存的系统缓存(不推荐),必须被配置且禁用。 + + *译者注:对于 PoC 以及缓存相关内容,请参考 ARMv8 构架参考手册 ARM DDI 0487A - 架构计时器 CNTFRQ 必须设定为计时器的频率,且 CNTVOFF 必须设定为对所有 CPU @@ -141,6 +169,14 @@ AArch64 内核当前没有提供自解压代码,因此如果使用了压缩内 在进入内核映像的异常级中,所有构架中可写的系统寄存器必须通过软件 在一个更高的异常级别下初始化,以防止在 未知 状态下运行。 + 对于拥有 GICv3 中断控制器的系统: + - 若当前在 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。 + 以上对于 CPU 模式、高速缓存、MMU、架构计时器、一致性、系统寄存器的 必要条件描述适用于所有 CPU。所有 CPU 必须在同一异常级别跳入内核。 @@ -170,7 +206,7 @@ AArch64 内核当前没有提供自解压代码,因此如果使用了压缩内 ARM DEN 0022A:用于 ARM 上的电源状态协调接口系统软件)中描述的 CPU_ON 调用来将 CPU 带入内核。 - *译者注:到文档翻译时,此文档已更新为 ARM DEN 0022B。 + *译者注: ARM DEN 0022A 已更新到 ARM DEN 0022C。 设备树必须包含一个 ‘psci’ 节点,请参考以下文档: Documentation/devicetree/bindings/arm/psci.txt diff --git a/Documentation/zh_CN/arm64/legacy_instructions.txt b/Documentation/zh_CN/arm64/legacy_instructions.txt new file mode 100644 index 000000000000..68362a1ab717 --- /dev/null +++ b/Documentation/zh_CN/arm64/legacy_instructions.txt @@ -0,0 +1,72 @@ +Chinese translated version of Documentation/arm64/legacy_instructions.txt + +If you have any comment or update to the content, please contact the +original document maintainer directly. However, if you have a problem +communicating in English you can also ask the Chinese maintainer for +help. Contact the Chinese maintainer if this translation is outdated +or if there is a problem with the translation. + +Maintainer: Punit Agrawal <punit.agrawal@arm.com> + Suzuki K. Poulose <suzuki.poulose@arm.com> +Chinese maintainer: Fu Wei <wefu@redhat.com> +--------------------------------------------------------------------- +Documentation/arm64/legacy_instructions.txt 的中文翻译 + +如果想评论或更新本文的内容,请直接联系原文档的维护者。如果你使用英文 +交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻 +译存在问题,请联系中文版维护者。 + +本文翻译提交时的 Git 检出点为: bc465aa9d045feb0e13b4a8f32cc33c1943f62d6 + +英文版维护者: Punit Agrawal <punit.agrawal@arm.com> + Suzuki K. Poulose <suzuki.poulose@arm.com> +中文版维护者: 傅炜 Fu Wei <wefu@redhat.com> +中文版翻译者: 傅炜 Fu Wei <wefu@redhat.com> +中文版校译者: 傅炜 Fu Wei <wefu@redhat.com> + +以下为正文 +--------------------------------------------------------------------- +Linux 内核在 arm64 上的移植提供了一个基础框架,以支持构架中正在被淘汰或已废弃指令的模拟执行。 +这个基础框架的代码使用未定义指令钩子(hooks)来支持模拟。如果指令存在,它也允许在硬件中启用该指令。 + +模拟模式可通过写 sysctl 节点(/proc/sys/abi)来控制。 +不同的执行方式及 sysctl 节点的相应值,解释如下: + +* Undef(未定义) + 值: 0 + 产生未定义指令终止异常。它是那些构架中已废弃的指令,如 SWP,的默认处理方式。 + +* Emulate(模拟) + 值: 1 + 使用软件模拟方式。为解决软件迁移问题,这种模拟指令模式的使用是被跟踪的,并会发出速率限制警告。 + 它是那些构架中正在被淘汰的指令,如 CP15 barriers(隔离指令),的默认处理方式。 + +* Hardware Execution(硬件执行) + 值: 2 + 虽然标记为正在被淘汰,但一些实现可能提供硬件执行这些指令的使能/禁用操作。 + 使用硬件执行一般会有更好的性能,但将无法收集运行时对正被淘汰指令的使用统计数据。 + +默认执行模式依赖于指令在构架中状态。正在被淘汰的指令应该以模拟(Emulate)作为默认模式, +而已废弃的指令必须默认使用未定义(Undef)模式 + +注意:指令模拟可能无法应对所有情况。更多详情请参考单独的指令注释。 + +受支持的遗留指令 +------------- +* SWP{B} +节点: /proc/sys/abi/swp +状态: 已废弃 +默认执行方式: Undef (0) + +* CP15 Barriers +节点: /proc/sys/abi/cp15_barrier +状态: 正被淘汰,不推荐使用 +默认执行方式: Emulate (1) + +* SETEND +节点: /proc/sys/abi/setend +状态: 正被淘汰,不推荐使用 +默认执行方式: Emulate (1)* +注:为了使能这个特性,系统中的所有 CPU 必须在 EL0 支持混合字节序。 +如果一个新的 CPU (不支持混合字节序) 在使能这个特性后被热插入系统, +在应用中可能会出现不可预期的结果。 diff --git a/Documentation/zh_CN/arm64/memory.txt b/Documentation/zh_CN/arm64/memory.txt index a782704c1cb5..19b3a52d5d94 100644 --- a/Documentation/zh_CN/arm64/memory.txt +++ b/Documentation/zh_CN/arm64/memory.txt @@ -15,6 +15,8 @@ Documentation/arm64/memory.txt 的中文翻译 交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻 译存在问题,请联系中文版维护者。 +本文翻译提交时的 Git 检出点为: bc465aa9d045feb0e13b4a8f32cc33c1943f62d6 + 英文版维护者: Catalin Marinas <catalin.marinas@arm.com> 中文版维护者: 傅炜 Fu Wei <wefu@redhat.com> 中文版翻译者: 傅炜 Fu Wei <wefu@redhat.com> @@ -26,69 +28,53 @@ Documentation/arm64/memory.txt 的中文翻译 =========================== 作者: Catalin Marinas <catalin.marinas@arm.com> -日期: 2012 年 02 月 20 日 本文档描述 AArch64 Linux 内核所使用的虚拟内存布局。此构架可以实现 页大小为 4KB 的 4 级转换表和页大小为 64KB 的 3 级转换表。 -AArch64 Linux 使用页大小为 4KB 的 3 级转换表配置,对于用户和内核 -都有 39-bit (512GB) 的虚拟地址空间。对于页大小为 64KB的配置,仅 -使用 2 级转换表,但内存布局相同。 +AArch64 Linux 使用 3 级或 4 级转换表,其页大小配置为 4KB,对于用户和内核 +分别都有 39-bit (512GB) 或 48-bit (256TB) 的虚拟地址空间。 +对于页大小为 64KB的配置,仅使用 2 级转换表,有 42-bit (4TB) 的虚拟地址空间,但内存布局相同。 -用户地址空间的 63:39 位为 0,而内核地址空间的相应位为 1。TTBRx 的 +用户地址空间的 63:48 位为 0,而内核地址空间的相应位为 1。TTBRx 的 选择由虚拟地址的 63 位给出。swapper_pg_dir 仅包含内核(全局)映射, -而用户 pgd 仅包含用户(非全局)映射。swapper_pgd_dir 地址被写入 +而用户 pgd 仅包含用户(非全局)映射。swapper_pg_dir 地址被写入 TTBR1 中,且从不写入 TTBR0。 -AArch64 Linux 在页大小为 4KB 时的内存布局: +AArch64 Linux 在页大小为 4KB,并使用 3 级转换表时的内存布局: 起始地址 结束地址 大小 用途 ----------------------------------------------------------------------- 0000000000000000 0000007fffffffff 512GB 用户空间 +ffffff8000000000 ffffffffffffffff 512GB 内核空间 -ffffff8000000000 ffffffbbfffeffff ~240GB vmalloc - -ffffffbbffff0000 ffffffbbffffffff 64KB [防护页] - -ffffffbc00000000 ffffffbdffffffff 8GB vmemmap - -ffffffbe00000000 ffffffbffbbfffff ~8GB [防护页,未来用于 vmmemap] -ffffffbffbc00000 ffffffbffbdfffff 2MB earlyprintk 设备 +AArch64 Linux 在页大小为 4KB,并使用 4 级转换表时的内存布局: -ffffffbffbe00000 ffffffbffbe0ffff 64KB PCI I/O 空间 - -ffffffbffbe10000 ffffffbcffffffff ~2MB [防护页] - -ffffffbffc000000 ffffffbfffffffff 64MB 模块 - -ffffffc000000000 ffffffffffffffff 256GB 内核逻辑内存映射 +起始地址 结束地址 大小 用途 +----------------------------------------------------------------------- +0000000000000000 0000ffffffffffff 256TB 用户空间 +ffff000000000000 ffffffffffffffff 256TB 内核空间 -AArch64 Linux 在页大小为 64KB 时的内存布局: +AArch64 Linux 在页大小为 64KB,并使用 2 级转换表时的内存布局: 起始地址 结束地址 大小 用途 ----------------------------------------------------------------------- 0000000000000000 000003ffffffffff 4TB 用户空间 +fffffc0000000000 ffffffffffffffff 4TB 内核空间 -fffffc0000000000 fffffdfbfffeffff ~2TB vmalloc - -fffffdfbffff0000 fffffdfbffffffff 64KB [防护页] - -fffffdfc00000000 fffffdfdffffffff 8GB vmemmap - -fffffdfe00000000 fffffdfffbbfffff ~8GB [防护页,未来用于 vmmemap] -fffffdfffbc00000 fffffdfffbdfffff 2MB earlyprintk 设备 +AArch64 Linux 在页大小为 64KB,并使用 3 级转换表时的内存布局: -fffffdfffbe00000 fffffdfffbe0ffff 64KB PCI I/O 空间 - -fffffdfffbe10000 fffffdfffbffffff ~2MB [防护页] +起始地址 结束地址 大小 用途 +----------------------------------------------------------------------- +0000000000000000 0000ffffffffffff 256TB 用户空间 +ffff000000000000 ffffffffffffffff 256TB 内核空间 -fffffdfffc000000 fffffdffffffffff 64MB 模块 -fffffe0000000000 ffffffffffffffff 2TB 内核逻辑内存映射 +更详细的内核虚拟内存布局,请参阅内核启动信息。 4KB 页大小的转换表查找: @@ -102,7 +88,7 @@ fffffe0000000000 ffffffffffffffff 2TB 内核逻辑内存映射 | | | | +-> [20:12] L3 索引 | | | +-----------> [29:21] L2 索引 | | +---------------------> [38:30] L1 索引 - | +-------------------------------> [47:39] L0 索引 (未使用) + | +-------------------------------> [47:39] L0 索引 +-------------------------------------------------> [63] TTBR0/1 @@ -115,10 +101,11 @@ fffffe0000000000 ffffffffffffffff 2TB 内核逻辑内存映射 | | | | v | | | | [15:0] 页内偏移 | | | +----------> [28:16] L3 索引 - | | +--------------------------> [41:29] L2 索引 (仅使用 38:29 ) - | +-------------------------------> [47:42] L1 索引 (未使用) + | | +--------------------------> [41:29] L2 索引 + | +-------------------------------> [47:42] L1 索引 +-------------------------------------------------> [63] TTBR0/1 + 当使用 KVM 时, 管理程序(hypervisor)在 EL2 中通过相对内核虚拟地址的 一个固定偏移来映射内核页(内核虚拟地址的高 24 位设为零): |