[PATCH] Documentation:Update Documentation/zh_CN/arm64/booting.txt
From: Fu WeiThis is a update of Chinese documentation: Documentation/zh_CN/arm64/booting.txt It is based on the modifications of Documentation/arm64/booting.txt in submission: "a7f8de16". Signed-off-by: Fu Wei --- Documentation/zh_CN/arm64/booting.txt | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/Documentation/zh_CN/arm64/booting.txt b/Documentation/zh_CN/arm64/booting.txt index 1145bf8..c1dd968 100644 --- a/Documentation/zh_CN/arm64/booting.txt +++ b/Documentation/zh_CN/arm64/booting.txt @@ -8,7 +8,7 @@ or if there is a problem with the translation. M: Will Deacon zh_CN: Fu Wei -C: 1926e54f115725a9248d0c4c65c22acaf94de4c4 +C: 55f058e7574c3615dea4615573a19bdb258696c6 - Documentation/arm64/booting.txt 的中文翻译 @@ -20,7 +20,7 @@ Documentation/arm64/booting.txt 的中文翻译 中文版维护者: 傅炜 Fu Wei 中文版翻译者: 傅炜 Fu Wei 中文版校译者: 傅炜 Fu Wei -本文翻译提交时的 Git 检出点为: 1926e54f115725a9248d0c4c65c22acaf94de4c4 +本文翻译提交时的 Git 检出点为: 55f058e7574c3615dea4615573a19bdb258696c6 以下为正文 - @@ -125,18 +125,22 @@ AArch64 内核当前没有提供自解压代码,因此如果使用了压缩内 1 - 4K 2 - 16K 3 - 64K - 位 3-63: 保留。 + 位 3: 内核物理位置 + 0 - 2MB 对齐基址应尽量靠近内存起始处,因为 + 其基址以下的内存无法通过线性映射访问 + 1 - 2MB 对齐基址可以在物理内存的任意位置 + 位 4-63: 保留。 - 当 image_size 为零时,引导装载程序应试图在内核映像末尾之后尽可能 多地保留空闲内存供内核直接使用。对内存空间的需求量因所选定的内核 特性而异, 并无实际限制。 -内核映像必须被放置在靠近可用系统内存起始的 2MB 对齐为基址的 -text_offset 字节处,并从该处被调用。当前,对 Linux 来说在此基址以下的 -内存是无法使用的,因此强烈建议将系统内存的起始作为这个基址。2MB 对齐 -基址和内核映像起始地址之间的区域对于内核来说没有特殊意义,且可能被 -用于其他目的。 +内核映像必须被放置在任意一个可用系统内存 2MB 对齐基址的 text_offset +字节处,并从该处被调用。2MB 对齐基址和内核映像起始地址之间的区域对于 +内核来说没有特殊意义,且可能被用于其他目的。 从映像起始地址算起,最少必须准备 image_size 字节的空闲内存供内核使用。 +注: v4.6 之前的版本无法使用内核映像物理偏移以下的内存,所以当时建议 +将映像尽量放置在靠近系统内存起始的地方。 任何提供给内核的内存(甚至在映像起始地址之前),若未从内核中标记为保留 (如在设备树(dtb)的 memreserve 区域),都将被认为对内核是可用。 -- 2.5.5
[PATCH] Documentation:Update Documentation/zh_CN/arm64/booting.txt
From: Fu Wei This is a update of Chinese documentation: Documentation/zh_CN/arm64/booting.txt It is based on the modifications of Documentation/arm64/booting.txt in submission: "a7f8de16". Signed-off-by: Fu Wei --- Documentation/zh_CN/arm64/booting.txt | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/Documentation/zh_CN/arm64/booting.txt b/Documentation/zh_CN/arm64/booting.txt index 1145bf8..c1dd968 100644 --- a/Documentation/zh_CN/arm64/booting.txt +++ b/Documentation/zh_CN/arm64/booting.txt @@ -8,7 +8,7 @@ or if there is a problem with the translation. M: Will Deacon zh_CN: Fu Wei -C: 1926e54f115725a9248d0c4c65c22acaf94de4c4 +C: 55f058e7574c3615dea4615573a19bdb258696c6 - Documentation/arm64/booting.txt 的中文翻译 @@ -20,7 +20,7 @@ Documentation/arm64/booting.txt 的中文翻译 中文版维护者: 傅炜 Fu Wei 中文版翻译者: 傅炜 Fu Wei 中文版校译者: 傅炜 Fu Wei -本文翻译提交时的 Git 检出点为: 1926e54f115725a9248d0c4c65c22acaf94de4c4 +本文翻译提交时的 Git 检出点为: 55f058e7574c3615dea4615573a19bdb258696c6 以下为正文 - @@ -125,18 +125,22 @@ AArch64 内核当前没有提供自解压代码,因此如果使用了压缩内 1 - 4K 2 - 16K 3 - 64K - 位 3-63: 保留。 + 位 3: 内核物理位置 + 0 - 2MB 对齐基址应尽量靠近内存起始处,因为 + 其基址以下的内存无法通过线性映射访问 + 1 - 2MB 对齐基址可以在物理内存的任意位置 + 位 4-63: 保留。 - 当 image_size 为零时,引导装载程序应试图在内核映像末尾之后尽可能 多地保留空闲内存供内核直接使用。对内存空间的需求量因所选定的内核 特性而异, 并无实际限制。 -内核映像必须被放置在靠近可用系统内存起始的 2MB 对齐为基址的 -text_offset 字节处,并从该处被调用。当前,对 Linux 来说在此基址以下的 -内存是无法使用的,因此强烈建议将系统内存的起始作为这个基址。2MB 对齐 -基址和内核映像起始地址之间的区域对于内核来说没有特殊意义,且可能被 -用于其他目的。 +内核映像必须被放置在任意一个可用系统内存 2MB 对齐基址的 text_offset +字节处,并从该处被调用。2MB 对齐基址和内核映像起始地址之间的区域对于 +内核来说没有特殊意义,且可能被用于其他目的。 从映像起始地址算起,最少必须准备 image_size 字节的空闲内存供内核使用。 +注: v4.6 之前的版本无法使用内核映像物理偏移以下的内存,所以当时建议 +将映像尽量放置在靠近系统内存起始的地方。 任何提供给内核的内存(甚至在映像起始地址之前),若未从内核中标记为保留 (如在设备树(dtb)的 memreserve 区域),都将被认为对内核是可用。 -- 2.5.5
[PATCH] Documentation:Update Documentation/zh_CN/arm64/booting.txt
From: Fu WeiThis is a update of Chinese documentation: Documentation/zh_CN/arm64/booting.txt It is based on the modifications of Documentation/arm64/booting.txt in submission: "61bd93ce", "6c020ea8", "9d372c9f", "6d32ab2d". And improve the format of documentation. Signed-off-by: Fu Wei --- Documentation/zh_CN/arm64/booting.txt | 93 ++- 1 file changed, 58 insertions(+), 35 deletions(-) diff --git a/Documentation/zh_CN/arm64/booting.txt b/Documentation/zh_CN/arm64/booting.txt index 7cd36af..1145bf8 100644 --- a/Documentation/zh_CN/arm64/booting.txt +++ b/Documentation/zh_CN/arm64/booting.txt @@ -6,8 +6,9 @@ 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: Will Deacon -Chinese maintainer: Fu Wei +M: Will Deacon +zh_CN: Fu Wei +C: 1926e54f115725a9248d0c4c65c22acaf94de4c4 - Documentation/arm64/booting.txt 的中文翻译 @@ -15,12 +16,11 @@ Documentation/arm64/booting.txt 的中文翻译 交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻 译存在问题,请联系中文版维护者。 -本文翻译提交时的 Git 检出点为: bc465aa9d045feb0e13b4a8f32cc33c1943f62d6 - 英文版维护者: Will Deacon 中文版维护者: 傅炜 Fu Wei 中文版翻译者: 傅炜 Fu Wei 中文版校译者: 傅炜 Fu Wei +本文翻译提交时的 Git 检出点为: 1926e54f115725a9248d0c4c65c22acaf94de4c4 以下为正文 - @@ -33,9 +33,9 @@ Documentation/arm64/booting.txt 的中文翻译 本文档基于 Russell King 的 ARM 启动文档,且适用于所有公开发布的 AArch64 Linux 内核代码。 -AArch64 异常模型由多个异常级别(EL0 - EL3)组成,对于 EL0 和 EL1 -异常级有对应的安全和非安全模式。EL2 是系统管理级,且仅存在于 -非安全模式下。EL3 是最高特权级,且仅存在于安全模式下。 +AArch64 异常模型由多个异常级(EL0 - EL3)组成,对于 EL0 和 EL1 异常级 +有对应的安全和非安全模式。EL2 是系统管理级,且仅存在于非安全模式下。 +EL3 是最高特权级,且仅存在于安全模式下。 基于本文档的目的,我们将简单地使用‘引导装载程序’(‘boot loader’) 这个术语来定义在将控制权交给 Linux 内核前 CPU 上执行的所有软件。 @@ -56,9 +56,9 @@ AArch64 异常模型由多个异常级别(EL0 - EL3)组成,对于 EL0 和 必要性: 强制 引导装载程序应该找到并初始化系统中所有内核用于保持系统变量数据的 RAM。 -这个操作的执行是设备依赖的。(它可能使用内部算法来自动定位和计算所有 -RAM,或可能使用对这个设备已知的 RAM 信息,还可能使用任何引导装载程序 -设计者想到的匹配方法。) +这个操作的执行方式因设备而异。(它可能使用内部算法来自动定位和计算所有 +RAM,或可能使用对这个设备已知的 RAM 信息,还可能是引导装载程序设计者 +想到的任何合适的方法。) 2、设置设备树数据 @@ -66,10 +66,12 @@ RAM,或可能使用对这个设备已知的 RAM 信息,还可能使用任何 必要性: 强制 -设备树数据块(dtb)必须 8 字节对齐,并位于从内核映像起始算起第一个 512MB -内,且不得跨越 2MB 对齐边界。这使得内核可以通过初始页表中的单个节描述符来 -映射此数据块。 +设备树数据块(dtb)必须 8 字节对齐,且大小不能超过 2MB。由于设备树 +数据块将在使能缓存的情况下以 2MB 粒度被映射,故其不能被置于带任意 +特定属性被映射的 2MB 区域内。 +注: v4.2 之前的版本同时要求设备树数据块被置于从内核映像以下 +text_offset 字节处算起第一个 512MB 内。 3、解压内核映像 - @@ -78,7 +80,7 @@ RAM,或可能使用对这个设备已知的 RAM 信息,还可能使用任何 AArch64 内核当前没有提供自解压代码,因此如果使用了压缩内核映像文件 (比如 Image.gz),则需要通过引导装载程序(使用 gzip 等)来进行解压。 -若引导装载程序没有实现这个需求,就要使用非压缩内核映像文件。 +若引导装载程序没有实现这个功能,就要使用非压缩内核映像文件。 4、调用内核映像 @@ -97,7 +99,7 @@ AArch64 内核当前没有提供自解压代码,因此如果使用了压缩内 u64 res3 = 0;/* 保留 */ u64 res4 = 0;/* 保留 */ u32 magic= 0x644d5241; /* 魔数, 小端, "ARM\x64" */ - u32 res5;/* 保留 (用于 PE COFF 偏移) */ + u32 res5;/* 保留 (用于 PE COFF 偏移) */ 映像头注释: @@ -107,26 +109,36 @@ AArch64 内核当前没有提供自解压代码,因此如果使用了压缩内 - 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 依照内核字节序为 0x8。 - 当 image_size 非零,text_offset 为小端模式且是有效值,应被引导加载程序使用。 - 当 image_size 为零,text_offset 可假定为 0x8。 + 当 image_size 非零,text_offset 为小端模式且是有效值,应被引导加载 + 程序使用。当 image_size 为零,text_offset 可假定为 0x8。 - 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 区域),都将被认为对内核是可用。 在跳转入内核前,必须符合以下状态: @@ -147,13 +159,16 @@ AArch64 内核当前没有提供自解压代码,因此如果使用了压缩内 - 高速缓存、MMU MMU 必须关闭。 - 指令缓存开启或关闭都可以。 +
[PATCH] Documentation:Update Documentation/zh_CN/arm64/booting.txt
From: Fu Wei This is a update of Chinese documentation: Documentation/zh_CN/arm64/booting.txt It is based on the modifications of Documentation/arm64/booting.txt in submission: "61bd93ce", "6c020ea8", "9d372c9f", "6d32ab2d". And improve the format of documentation. Signed-off-by: Fu Wei --- Documentation/zh_CN/arm64/booting.txt | 93 ++- 1 file changed, 58 insertions(+), 35 deletions(-) diff --git a/Documentation/zh_CN/arm64/booting.txt b/Documentation/zh_CN/arm64/booting.txt index 7cd36af..1145bf8 100644 --- a/Documentation/zh_CN/arm64/booting.txt +++ b/Documentation/zh_CN/arm64/booting.txt @@ -6,8 +6,9 @@ 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: Will Deacon -Chinese maintainer: Fu Wei +M: Will Deacon +zh_CN: Fu Wei +C: 1926e54f115725a9248d0c4c65c22acaf94de4c4 - Documentation/arm64/booting.txt 的中文翻译 @@ -15,12 +16,11 @@ Documentation/arm64/booting.txt 的中文翻译 交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻 译存在问题,请联系中文版维护者。 -本文翻译提交时的 Git 检出点为: bc465aa9d045feb0e13b4a8f32cc33c1943f62d6 - 英文版维护者: Will Deacon 中文版维护者: 傅炜 Fu Wei 中文版翻译者: 傅炜 Fu Wei 中文版校译者: 傅炜 Fu Wei +本文翻译提交时的 Git 检出点为: 1926e54f115725a9248d0c4c65c22acaf94de4c4 以下为正文 - @@ -33,9 +33,9 @@ Documentation/arm64/booting.txt 的中文翻译 本文档基于 Russell King 的 ARM 启动文档,且适用于所有公开发布的 AArch64 Linux 内核代码。 -AArch64 异常模型由多个异常级别(EL0 - EL3)组成,对于 EL0 和 EL1 -异常级有对应的安全和非安全模式。EL2 是系统管理级,且仅存在于 -非安全模式下。EL3 是最高特权级,且仅存在于安全模式下。 +AArch64 异常模型由多个异常级(EL0 - EL3)组成,对于 EL0 和 EL1 异常级 +有对应的安全和非安全模式。EL2 是系统管理级,且仅存在于非安全模式下。 +EL3 是最高特权级,且仅存在于安全模式下。 基于本文档的目的,我们将简单地使用‘引导装载程序’(‘boot loader’) 这个术语来定义在将控制权交给 Linux 内核前 CPU 上执行的所有软件。 @@ -56,9 +56,9 @@ AArch64 异常模型由多个异常级别(EL0 - EL3)组成,对于 EL0 和 必要性: 强制 引导装载程序应该找到并初始化系统中所有内核用于保持系统变量数据的 RAM。 -这个操作的执行是设备依赖的。(它可能使用内部算法来自动定位和计算所有 -RAM,或可能使用对这个设备已知的 RAM 信息,还可能使用任何引导装载程序 -设计者想到的匹配方法。) +这个操作的执行方式因设备而异。(它可能使用内部算法来自动定位和计算所有 +RAM,或可能使用对这个设备已知的 RAM 信息,还可能是引导装载程序设计者 +想到的任何合适的方法。) 2、设置设备树数据 @@ -66,10 +66,12 @@ RAM,或可能使用对这个设备已知的 RAM 信息,还可能使用任何 必要性: 强制 -设备树数据块(dtb)必须 8 字节对齐,并位于从内核映像起始算起第一个 512MB -内,且不得跨越 2MB 对齐边界。这使得内核可以通过初始页表中的单个节描述符来 -映射此数据块。 +设备树数据块(dtb)必须 8 字节对齐,且大小不能超过 2MB。由于设备树 +数据块将在使能缓存的情况下以 2MB 粒度被映射,故其不能被置于带任意 +特定属性被映射的 2MB 区域内。 +注: v4.2 之前的版本同时要求设备树数据块被置于从内核映像以下 +text_offset 字节处算起第一个 512MB 内。 3、解压内核映像 - @@ -78,7 +80,7 @@ RAM,或可能使用对这个设备已知的 RAM 信息,还可能使用任何 AArch64 内核当前没有提供自解压代码,因此如果使用了压缩内核映像文件 (比如 Image.gz),则需要通过引导装载程序(使用 gzip 等)来进行解压。 -若引导装载程序没有实现这个需求,就要使用非压缩内核映像文件。 +若引导装载程序没有实现这个功能,就要使用非压缩内核映像文件。 4、调用内核映像 @@ -97,7 +99,7 @@ AArch64 内核当前没有提供自解压代码,因此如果使用了压缩内 u64 res3 = 0;/* 保留 */ u64 res4 = 0;/* 保留 */ u32 magic= 0x644d5241; /* 魔数, 小端, "ARM\x64" */ - u32 res5;/* 保留 (用于 PE COFF 偏移) */ + u32 res5;/* 保留 (用于 PE COFF 偏移) */ 映像头注释: @@ -107,26 +109,36 @@ AArch64 内核当前没有提供自解压代码,因此如果使用了压缩内 - 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 依照内核字节序为 0x8。 - 当 image_size 非零,text_offset 为小端模式且是有效值,应被引导加载程序使用。 - 当 image_size 为零,text_offset 可假定为 0x8。 + 当 image_size 非零,text_offset 为小端模式且是有效值,应被引导加载 + 程序使用。当 image_size 为零,text_offset 可假定为 0x8。 - 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 区域),都将被认为对内核是可用。 在跳转入内核前,必须符合以下状态: @@ -147,13 +159,16 @@ AArch64 内核当前没有提供自解压代码,因此如果使用了压缩内 - 高速缓存、MMU MMU 必须关闭。 - 指令缓存开启或关闭都可以。 + 指令缓存开启或关闭皆可。 已载入的内核映像的相应内存区必须被清理,以达到缓存一致性点(PoC)。 - 当存在系统缓存或其他使能缓存的一致性主控器时,通常需使用虚拟地址维护其缓存,而非 set/way 操作。 + 当存在系统缓存或其他使能缓存的一致性主控器时,通常需使用虚拟地址 + 维护其缓存,而非 set/way 操作。
[PATCH v2] Documentation: Chinese translation of arm64/silicon-errata.txt
From: Fu WeiThis is a Chinese translated version of Documentation/arm64/silicon-errata.txt Signed-off-by: Fu Wei Reviewed-by: Weiwei Jia --- Changelog: v2: Improve the translation of "errata" Take the suggestion from Weiwei Jia, improve the translation. v1: https://lkml.org/lkml/2016/2/13/81 The first version upstream patchset to linux mailing list. Documentation/zh_CN/arm64/silicon-errata.txt | 74 1 file changed, 74 insertions(+) create mode 100644 Documentation/zh_CN/arm64/silicon-errata.txt diff --git a/Documentation/zh_CN/arm64/silicon-errata.txt b/Documentation/zh_CN/arm64/silicon-errata.txt new file mode 100644 index 000..653bf67 --- /dev/null +++ b/Documentation/zh_CN/arm64/silicon-errata.txt @@ -0,0 +1,74 @@ +Chinese translated version of Documentation/arm64/silicon-errata.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. + +M: Will Deacon +zh_CN: Fu Wei +C: 1926e54f115725a9248d0c4c65c22acaf94de4c4 +- +Documentation/arm64/silicon-errata.txt 的中文翻译 + +如果想评论或更新本文的内容,请直接联系原文档的维护者。如果你使用英文 +交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻 +译存在问题,请联系中文版维护者。 + +英文版维护者: Will Deacon +中文版维护者: 傅炜 Fu Wei +中文版翻译者: 傅炜 Fu Wei +中文版校译者: 傅炜 Fu Wei +本文翻译提交时的 Git 检出点为: 1926e54f115725a9248d0c4c65c22acaf94de4c4 + +以下为正文 +- +芯片勘误和软件补救措施 +== + +作者: Will Deacon +日期: 2015年11月27日 + +一个不幸的现实:硬件经常带有一些所谓的“瑕疵(errata)”,导致其在 +某些特定情况下会违背构架定义的行为。就基于 ARM 的硬件而言,这些瑕疵 +大体可分为以下几类: + + A 类:无可行补救措施的严重缺陷。 + B 类:有可接受的补救措施的重大或严重缺陷。 + C 类:在正常操作中不会显现的小瑕疵。 + +更多资讯,请在 infocenter.arm.com (需注册)中查阅“软件开发者勘误 +笔记”(“Software Developers Errata Notice”)文档。 + +对于 Linux 而言,B 类缺陷可能需要操作系统的某些特别处理。例如,避免 +一个特殊的代码序列,或是以一种特定的方式配置处理器。在某种不太常见的 +情况下,为将 A 类缺陷当作 C 类处理,可能需要用类似的手段。这些手段被 +统称为“软件补救措施”,且仅在少数情况需要(例如,那些需要一个运行在 +非安全异常级的补救措施 *并且* 能被 Linux 触发的情况)。 + +对于尚在讨论中的可能对未受瑕疵影响的系统产生干扰的软件补救措施,有一个 +相应的内核配置(Kconfig)选项被加在 “内核特性(Kernel Features)”-> +“基于可选方法框架的 ARM 瑕疵补救措施(ARM errata workarounds via +the alternatives framework)"。这些选项被默认开启,若探测到受影响的CPU, +补丁将在运行时被使用。至于对系统运行影响较小的补救措施,内核配置选项 +并不存在,且代码以某种规避瑕疵的方式被构造(带注释为宜)。 + +这种做法对于在任意内核源代码树中准确地判断出哪个瑕疵已被软件方法所补救 +稍微有点麻烦,所以在 Linux 内核中此文件作为软件补救措施的注册表, +并将在新的软件补救措施被提交和向后移植(backported)到稳定内核时被更新。 + +| 实现者 | 受影响的组件| 勘误编号| 内核配置| +++-+-+-+ +| ARM| Cortex-A53 | #826319 | ARM64_ERRATUM_826319 | +| ARM| Cortex-A53 | #827319 | ARM64_ERRATUM_827319 | +| ARM| Cortex-A53 | #824069 | ARM64_ERRATUM_824069 | +| ARM| Cortex-A53 | #819472 | ARM64_ERRATUM_819472 | +| ARM| Cortex-A53 | #845719 | ARM64_ERRATUM_845719 | +| ARM| Cortex-A53 | #843419 | ARM64_ERRATUM_843419 | +| ARM| Cortex-A57 | #832075 | ARM64_ERRATUM_832075 | +| ARM| Cortex-A57 | #852523 | N/A | +| ARM| Cortex-A57 | #834220 | ARM64_ERRATUM_834220 | +|| | | | +| Cavium | ThunderX ITS| #22375, #24313 | CAVIUM_ERRATUM_22375 | +| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 | -- 2.5.0
[PATCH v2] Documentation: Chinese translation of arm64/silicon-errata.txt
From: Fu Wei This is a Chinese translated version of Documentation/arm64/silicon-errata.txt Signed-off-by: Fu Wei Reviewed-by: Weiwei Jia --- Changelog: v2: Improve the translation of "errata" Take the suggestion from Weiwei Jia, improve the translation. v1: https://lkml.org/lkml/2016/2/13/81 The first version upstream patchset to linux mailing list. Documentation/zh_CN/arm64/silicon-errata.txt | 74 1 file changed, 74 insertions(+) create mode 100644 Documentation/zh_CN/arm64/silicon-errata.txt diff --git a/Documentation/zh_CN/arm64/silicon-errata.txt b/Documentation/zh_CN/arm64/silicon-errata.txt new file mode 100644 index 000..653bf67 --- /dev/null +++ b/Documentation/zh_CN/arm64/silicon-errata.txt @@ -0,0 +1,74 @@ +Chinese translated version of Documentation/arm64/silicon-errata.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. + +M: Will Deacon +zh_CN: Fu Wei +C: 1926e54f115725a9248d0c4c65c22acaf94de4c4 +- +Documentation/arm64/silicon-errata.txt 的中文翻译 + +如果想评论或更新本文的内容,请直接联系原文档的维护者。如果你使用英文 +交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻 +译存在问题,请联系中文版维护者。 + +英文版维护者: Will Deacon +中文版维护者: 傅炜 Fu Wei +中文版翻译者: 傅炜 Fu Wei +中文版校译者: 傅炜 Fu Wei +本文翻译提交时的 Git 检出点为: 1926e54f115725a9248d0c4c65c22acaf94de4c4 + +以下为正文 +- +芯片勘误和软件补救措施 +== + +作者: Will Deacon +日期: 2015年11月27日 + +一个不幸的现实:硬件经常带有一些所谓的“瑕疵(errata)”,导致其在 +某些特定情况下会违背构架定义的行为。就基于 ARM 的硬件而言,这些瑕疵 +大体可分为以下几类: + + A 类:无可行补救措施的严重缺陷。 + B 类:有可接受的补救措施的重大或严重缺陷。 + C 类:在正常操作中不会显现的小瑕疵。 + +更多资讯,请在 infocenter.arm.com (需注册)中查阅“软件开发者勘误 +笔记”(“Software Developers Errata Notice”)文档。 + +对于 Linux 而言,B 类缺陷可能需要操作系统的某些特别处理。例如,避免 +一个特殊的代码序列,或是以一种特定的方式配置处理器。在某种不太常见的 +情况下,为将 A 类缺陷当作 C 类处理,可能需要用类似的手段。这些手段被 +统称为“软件补救措施”,且仅在少数情况需要(例如,那些需要一个运行在 +非安全异常级的补救措施 *并且* 能被 Linux 触发的情况)。 + +对于尚在讨论中的可能对未受瑕疵影响的系统产生干扰的软件补救措施,有一个 +相应的内核配置(Kconfig)选项被加在 “内核特性(Kernel Features)”-> +“基于可选方法框架的 ARM 瑕疵补救措施(ARM errata workarounds via +the alternatives framework)"。这些选项被默认开启,若探测到受影响的CPU, +补丁将在运行时被使用。至于对系统运行影响较小的补救措施,内核配置选项 +并不存在,且代码以某种规避瑕疵的方式被构造(带注释为宜)。 + +这种做法对于在任意内核源代码树中准确地判断出哪个瑕疵已被软件方法所补救 +稍微有点麻烦,所以在 Linux 内核中此文件作为软件补救措施的注册表, +并将在新的软件补救措施被提交和向后移植(backported)到稳定内核时被更新。 + +| 实现者 | 受影响的组件| 勘误编号| 内核配置| +++-+-+-+ +| ARM| Cortex-A53 | #826319 | ARM64_ERRATUM_826319 | +| ARM| Cortex-A53 | #827319 | ARM64_ERRATUM_827319 | +| ARM| Cortex-A53 | #824069 | ARM64_ERRATUM_824069 | +| ARM| Cortex-A53 | #819472 | ARM64_ERRATUM_819472 | +| ARM| Cortex-A53 | #845719 | ARM64_ERRATUM_845719 | +| ARM| Cortex-A53 | #843419 | ARM64_ERRATUM_843419 | +| ARM| Cortex-A57 | #832075 | ARM64_ERRATUM_832075 | +| ARM| Cortex-A57 | #852523 | N/A | +| ARM| Cortex-A57 | #834220 | ARM64_ERRATUM_834220 | +|| | | | +| Cavium | ThunderX ITS| #22375, #24313 | CAVIUM_ERRATUM_22375 | +| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 | -- 2.5.0
[PATCH] Documentation: Chinese translation of arm64/silicon-errata.txt
From: Fu Wei This is a Chinese translated version of Documentation/arm64/silicon-errata.txt Signed-off-by: Fu Wei --- Documentation/zh_CN/arm64/silicon-errata.txt | 74 1 file changed, 74 insertions(+) create mode 100644 Documentation/zh_CN/arm64/silicon-errata.txt diff --git a/Documentation/zh_CN/arm64/silicon-errata.txt b/Documentation/zh_CN/arm64/silicon-errata.txt new file mode 100644 index 000..0584bd6 --- /dev/null +++ b/Documentation/zh_CN/arm64/silicon-errata.txt @@ -0,0 +1,74 @@ +Chinese translated version of Documentation/arm64/silicon-errata.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. + +M: Will Deacon +zh_CN: Fu Wei +C: e835a65f7ab143acf9aee6f9a98ef1c7afd2a835 +- +Documentation/arm64/silicon-errata.txt 的中文翻译 + +如果想评论或更新本文的内容,请直接联系原文档的维护者。如果你使用英文 +交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻 +译存在问题,请联系中文版维护者。 + +英文版维护者: Will Deacon +中文版维护者: 傅炜 Fu Wei +中文版翻译者: 傅炜 Fu Wei +中文版校译者: 傅炜 Fu Wei +本文翻译提交时的 Git 检出点为: e835a65f7ab143acf9aee6f9a98ef1c7afd2a835 + +以下为正文 +- +芯片勘误和软件解决办法 +== + +作者: Will Deacon +日期: 2015年11月27日 + +一个不幸的现实:硬件经常带有一些所谓的“错误(errata)”,致使其在 +某些特定的情况下会违背构架定义的行为。对基于 ARM 的硬件,这些错误 +大体被分为以下几类: + + A 类:无可行解决方法的严重错误。 + B 类:有可接受的解决方法的重大或严重错误。 + C 类:在正常操作中不会显现的小错误。 + +更多资讯,请在 infocenter.arm.com (需注册)中查阅“软件开发者勘误 +笔记”(“Software Developers Errata Notice”)文档。 + +对于 Linux 而言,B 类错误可能需要操作系统的某些特别处理。例如,避免 +一个特殊的代码序列,或是以一种特定的方式配置处理器。在某种不太常见的 +情况下,为将 A 类错误当作 C 类处理,可能需要用类似手段。这些手段被 +统称为“软件解决办法”,且仅在少数情况需要(例如,那些需要一个在非安全 +异常级运行的解决方法 *且* 能被 Linux 触发的情况)。 + +对于尚在讨论中的可能对未受错误影响的系统产生不利影响的软件解决办法, +有一个相应的内核配置(Kconfig)选项被加在 “内核特性(Kernel Features)” +- > “基于可选方案框架的 ARM 错误解决办法(ARM errata workarounds via +the alternatives framework)"。这些选项被默认开启,若探测到受影响的CPU, +补丁将在运行时被打入。对于对系统运行影响较小的解决办法,内核配置选项 +并不存在,且代码以一种避开错误的方式被构造(带注释为宜)。 + +这种做法对于在任意内核源代码树中准确地判断出哪个错误已被软件方法所解决 +稍微有点麻烦,所以这个文件在 Linux 内核中作为软件解决办法的注册表, +并将在新的软件解决办法被提交和反向移植到稳定内核时被更新。 + +| 实现者 | 受影响的组件| 勘误编号| 内核配置| +++-+-+-+ +| ARM| Cortex-A53 | #826319 | ARM64_ERRATUM_826319 | +| ARM| Cortex-A53 | #827319 | ARM64_ERRATUM_827319 | +| ARM| Cortex-A53 | #824069 | ARM64_ERRATUM_824069 | +| ARM| Cortex-A53 | #819472 | ARM64_ERRATUM_819472 | +| ARM| Cortex-A53 | #845719 | ARM64_ERRATUM_845719 | +| ARM| Cortex-A53 | #843419 | ARM64_ERRATUM_843419 | +| ARM| Cortex-A57 | #832075 | ARM64_ERRATUM_832075 | +| ARM| Cortex-A57 | #852523 | N/A | +| ARM| Cortex-A57 | #834220 | ARM64_ERRATUM_834220 | +|| | | | +| Cavium | ThunderX ITS| #22375, #24313 | CAVIUM_ERRATUM_22375 | +| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 | -- 2.5.0
[PATCH] Documentation: Chinese translation of arm64/silicon-errata.txt
From: Fu WeiThis is a Chinese translated version of Documentation/arm64/silicon-errata.txt Signed-off-by: Fu Wei --- Documentation/zh_CN/arm64/silicon-errata.txt | 74 1 file changed, 74 insertions(+) create mode 100644 Documentation/zh_CN/arm64/silicon-errata.txt diff --git a/Documentation/zh_CN/arm64/silicon-errata.txt b/Documentation/zh_CN/arm64/silicon-errata.txt new file mode 100644 index 000..0584bd6 --- /dev/null +++ b/Documentation/zh_CN/arm64/silicon-errata.txt @@ -0,0 +1,74 @@ +Chinese translated version of Documentation/arm64/silicon-errata.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. + +M: Will Deacon +zh_CN: Fu Wei +C: e835a65f7ab143acf9aee6f9a98ef1c7afd2a835 +- +Documentation/arm64/silicon-errata.txt 的中文翻译 + +如果想评论或更新本文的内容,请直接联系原文档的维护者。如果你使用英文 +交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻 +译存在问题,请联系中文版维护者。 + +英文版维护者: Will Deacon +中文版维护者: 傅炜 Fu Wei +中文版翻译者: 傅炜 Fu Wei +中文版校译者: 傅炜 Fu Wei +本文翻译提交时的 Git 检出点为: e835a65f7ab143acf9aee6f9a98ef1c7afd2a835 + +以下为正文 +- +芯片勘误和软件解决办法 +== + +作者: Will Deacon +日期: 2015年11月27日 + +一个不幸的现实:硬件经常带有一些所谓的“错误(errata)”,致使其在 +某些特定的情况下会违背构架定义的行为。对基于 ARM 的硬件,这些错误 +大体被分为以下几类: + + A 类:无可行解决方法的严重错误。 + B 类:有可接受的解决方法的重大或严重错误。 + C 类:在正常操作中不会显现的小错误。 + +更多资讯,请在 infocenter.arm.com (需注册)中查阅“软件开发者勘误 +笔记”(“Software Developers Errata Notice”)文档。 + +对于 Linux 而言,B 类错误可能需要操作系统的某些特别处理。例如,避免 +一个特殊的代码序列,或是以一种特定的方式配置处理器。在某种不太常见的 +情况下,为将 A 类错误当作 C 类处理,可能需要用类似手段。这些手段被 +统称为“软件解决办法”,且仅在少数情况需要(例如,那些需要一个在非安全 +异常级运行的解决方法 *且* 能被 Linux 触发的情况)。 + +对于尚在讨论中的可能对未受错误影响的系统产生不利影响的软件解决办法, +有一个相应的内核配置(Kconfig)选项被加在 “内核特性(Kernel Features)” +- > “基于可选方案框架的 ARM 错误解决办法(ARM errata workarounds via +the alternatives framework)"。这些选项被默认开启,若探测到受影响的CPU, +补丁将在运行时被打入。对于对系统运行影响较小的解决办法,内核配置选项 +并不存在,且代码以一种避开错误的方式被构造(带注释为宜)。 + +这种做法对于在任意内核源代码树中准确地判断出哪个错误已被软件方法所解决 +稍微有点麻烦,所以这个文件在 Linux 内核中作为软件解决办法的注册表, +并将在新的软件解决办法被提交和反向移植到稳定内核时被更新。 + +| 实现者 | 受影响的组件| 勘误编号| 内核配置| +++-+-+-+ +| ARM| Cortex-A53 | #826319 | ARM64_ERRATUM_826319 | +| ARM| Cortex-A53 | #827319 | ARM64_ERRATUM_827319 | +| ARM| Cortex-A53 | #824069 | ARM64_ERRATUM_824069 | +| ARM| Cortex-A53 | #819472 | ARM64_ERRATUM_819472 | +| ARM| Cortex-A53 | #845719 | ARM64_ERRATUM_845719 | +| ARM| Cortex-A53 | #843419 | ARM64_ERRATUM_843419 | +| ARM| Cortex-A57 | #832075 | ARM64_ERRATUM_832075 | +| ARM| Cortex-A57 | #852523 | N/A | +| ARM| Cortex-A57 | #834220 | ARM64_ERRATUM_834220 | +|| | | | +| Cavium | ThunderX ITS| #22375, #24313 | CAVIUM_ERRATUM_22375 | +| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 | -- 2.5.0
[PATCH v2] Documentation:Chinese translation of Documentation/arm64/legacy_instructions.txt
From: Fu Wei This is a Chinese translated version of Documentation/arm64/legacy_instructions.txt It is based on the modifications of Documentation/arm64/legacy_instructions.txt in submission: "587064b6", "bd35a4ad", "2d888f48", "c852f320". Signed-off-by: Fu Wei --- Documentation/zh_CN/arm64/legacy_instructions.txt | 72 +++ 1 file changed, 72 insertions(+) diff --git a/Documentation/zh_CN/arm64/legacy_instructions.txt b/Documentation/zh_CN/arm64/legacy_instructions.txt new file mode 100644 index 000..68362a1 --- /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 +Suzuki K. Poulose +Chinese maintainer: Fu Wei +- +Documentation/arm64/legacy_instructions.txt 的中文翻译 + +如果想评论或更新本文的内容,请直接联系原文档的维护者。如果你使用英文 +交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻 +译存在问题,请联系中文版维护者。 + +本文翻译提交时的 Git 检出点为: bc465aa9d045feb0e13b4a8f32cc33c1943f62d6 + +英文版维护者: Punit Agrawal +Suzuki K. Poulose +中文版维护者: 傅炜 Fu Wei +中文版翻译者: 傅炜 Fu Wei +中文版校译者: 傅炜 Fu Wei + +以下为正文 +- +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 (不支持混合字节序) 在使能这个特性后被热插入系统, +在应用中可能会出现不可预期的结果。 -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] Documentation:Chinese translation of Documentation/arm64/legacy_instructions.txt
From: Fu Wei w...@redhat.com This is a Chinese translated version of Documentation/arm64/legacy_instructions.txt It is based on the modifications of Documentation/arm64/legacy_instructions.txt in submission: 587064b6, bd35a4ad, 2d888f48, c852f320. Signed-off-by: Fu Wei w...@redhat.com --- Documentation/zh_CN/arm64/legacy_instructions.txt | 72 +++ 1 file changed, 72 insertions(+) diff --git a/Documentation/zh_CN/arm64/legacy_instructions.txt b/Documentation/zh_CN/arm64/legacy_instructions.txt new file mode 100644 index 000..68362a1 --- /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.agra...@arm.com +Suzuki K. Poulose suzuki.poul...@arm.com +Chinese maintainer: Fu Wei w...@redhat.com +- +Documentation/arm64/legacy_instructions.txt 的中文翻译 + +如果想评论或更新本文的内容,请直接联系原文档的维护者。如果你使用英文 +交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻 +译存在问题,请联系中文版维护者。 + +本文翻译提交时的 Git 检出点为: bc465aa9d045feb0e13b4a8f32cc33c1943f62d6 + +英文版维护者: Punit Agrawal punit.agra...@arm.com +Suzuki K. Poulose suzuki.poul...@arm.com +中文版维护者: 傅炜 Fu Wei w...@redhat.com +中文版翻译者: 傅炜 Fu Wei w...@redhat.com +中文版校译者: 傅炜 Fu Wei w...@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 (不支持混合字节序) 在使能这个特性后被热插入系统, +在应用中可能会出现不可预期的结果。 -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation:Chinese translation of Documentation/arm64/legacy_instructions.txt
From: Fu Wei This is a Chinese translated version of Documentation/arm64/legacy_instructions.txt It is based on the modifications of Documentation/arm64/legacy_instructions.txt in submission: "587064b6", "bd35a4ad", "2d888f48", "c852f320". Signed-off-by: Fu Wei --- Documentation/zh_CN/arm64/legacy_instructions.txt | 72 +++ 1 file changed, 72 insertions(+) diff --git a/Documentation/zh_CN/arm64/legacy_instructions.txt b/Documentation/zh_CN/arm64/legacy_instructions.txt new file mode 100644 index 000..75b11bf --- /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 +Suzuki K. Poulose +Chinese maintainer: Fu Wei +- +Documentation/arm64/legacy_instructions.txt 的中文翻译 + +如果想评论或更新本文的内容,请直接联系原文档的维护者。如果你使用英文 +交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻 +译存在问题,请联系中文版维护者。 + +本文翻译提交时的 Git 检出点为: bc465aa9d045feb0e13b4a8f32cc33c1943f62d6 + +英文版维护者: Punit Agrawal +Suzuki K. Poulose +中文版维护者: 傅炜 Fu Wei +中文版翻译者: 傅炜 Fu Wei +中文版校译者: 傅炜 Fu Wei + +以下为正文 +- +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 (不支持混合字节序) 在使能这个特性后被热插入系统, +该应用则可能出现不可预期的结果。 -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation:Update Documentation/zh_CN/arm64/booting.txt
From: Fu Wei This is a update of Chinese documentation: Documentation/zh_CN/arm64/booting.txt It is based on the modifications of Documentation/arm64/booting.txt in submission: "a2c1d73b", "cdd78578", "c218bca7", "63f8344c". Signed-off-by: Fu Wei --- Documentation/zh_CN/arm64/booting.txt | 54 +-- 1 file changed, 45 insertions(+), 9 deletions(-) diff --git a/Documentation/zh_CN/arm64/booting.txt b/Documentation/zh_CN/arm64/booting.txt index 6f6d956..7cd36af 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 中文版维护者: 傅炜 Fu Wei 中文版翻译者: 傅炜 Fu Wei @@ -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 起始处的特定偏移(当前是 0x8)。系统 RAM -的起始地址必须是以 2MB 对齐的。 +- 当通过 EFI 启动时, 最初 code0/code1 被跳过。 + res5 是到 PE 文件头的偏移,而 PE 文件头含有 EFI 的启动入口点 (efi_stub_entry)。 + 当 stub 代码完成了它的使命,它会跳转到 code0 继续正常的启动流程。 + +- v3.17 之前,未明确指定 text_offset 的字节序。此时,image_size 为零, + 且 text_offset 依照内核字节序为 0x8。 + 当 image_size 非零,text_offset 为小端模式且是有效值,应被引导加载程序使用。 + 当 image_size 为零,text_offset 可假定为 0x8。 + +- 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 -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation:Update Documentation/zh_CN/arm64/booting.txt
From: Fu Wei w...@redhat.com This is a update of Chinese documentation: Documentation/zh_CN/arm64/booting.txt It is based on the modifications of Documentation/arm64/booting.txt in submission: a2c1d73b, cdd78578, c218bca7, 63f8344c. Signed-off-by: Fu Wei w...@redhat.com --- Documentation/zh_CN/arm64/booting.txt | 54 +-- 1 file changed, 45 insertions(+), 9 deletions(-) diff --git a/Documentation/zh_CN/arm64/booting.txt b/Documentation/zh_CN/arm64/booting.txt index 6f6d956..7cd36af 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.dea...@arm.com 中文版维护者: 傅炜 Fu Wei w...@redhat.com 中文版翻译者: 傅炜 Fu Wei w...@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 起始处的特定偏移(当前是 0x8)。系统 RAM -的起始地址必须是以 2MB 对齐的。 +- 当通过 EFI 启动时, 最初 code0/code1 被跳过。 + res5 是到 PE 文件头的偏移,而 PE 文件头含有 EFI 的启动入口点 (efi_stub_entry)。 + 当 stub 代码完成了它的使命,它会跳转到 code0 继续正常的启动流程。 + +- v3.17 之前,未明确指定 text_offset 的字节序。此时,image_size 为零, + 且 text_offset 依照内核字节序为 0x8。 + 当 image_size 非零,text_offset 为小端模式且是有效值,应被引导加载程序使用。 + 当 image_size 为零,text_offset 可假定为 0x8。 + +- 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 -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation:Chinese translation of Documentation/arm64/legacy_instructions.txt
From: Fu Wei w...@redhat.com This is a Chinese translated version of Documentation/arm64/legacy_instructions.txt It is based on the modifications of Documentation/arm64/legacy_instructions.txt in submission: 587064b6, bd35a4ad, 2d888f48, c852f320. Signed-off-by: Fu Wei w...@redhat.com --- Documentation/zh_CN/arm64/legacy_instructions.txt | 72 +++ 1 file changed, 72 insertions(+) diff --git a/Documentation/zh_CN/arm64/legacy_instructions.txt b/Documentation/zh_CN/arm64/legacy_instructions.txt new file mode 100644 index 000..75b11bf --- /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.agra...@arm.com +Suzuki K. Poulose suzuki.poul...@arm.com +Chinese maintainer: Fu Wei w...@redhat.com +- +Documentation/arm64/legacy_instructions.txt 的中文翻译 + +如果想评论或更新本文的内容,请直接联系原文档的维护者。如果你使用英文 +交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻 +译存在问题,请联系中文版维护者。 + +本文翻译提交时的 Git 检出点为: bc465aa9d045feb0e13b4a8f32cc33c1943f62d6 + +英文版维护者: Punit Agrawal punit.agra...@arm.com +Suzuki K. Poulose suzuki.poul...@arm.com +中文版维护者: 傅炜 Fu Wei w...@redhat.com +中文版翻译者: 傅炜 Fu Wei w...@redhat.com +中文版校译者: 傅炜 Fu Wei w...@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 (不支持混合字节序) 在使能这个特性后被热插入系统, +该应用则可能出现不可预期的结果。 -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation:Update Documentation/zh_CN/arm64/memory.txt
From: Fu Wei This is a update of Chinese documentation:Documentation/zh_CN/arm64/memory.txt It is based on the modifications of Documentation/arm64/memory.txt in submission: "08375198", "4edae01e", "a24637d5", "383c2799". Signed-off-by: Fu Wei --- Documentation/zh_CN/arm64/memory.txt | 65 +++- 1 file changed, 26 insertions(+), 39 deletions(-) diff --git a/Documentation/zh_CN/arm64/memory.txt b/Documentation/zh_CN/arm64/memory.txt index a782704..19b3a52 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 中文版维护者: 傅炜 Fu Wei 中文版翻译者: 傅炜 Fu Wei @@ -26,69 +28,53 @@ Documentation/arm64/memory.txt 的中文翻译 === 作者: Catalin Marinas -日期: 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 级转换表时的内存布局: 起始地址 结束地址大小 用途 --- 007f 512GB 用户空间 +ff80 512GB 内核空间 -ff80 ffbbfffe~240GB vmalloc - -ffbb ffbb 64KB [防护页] - -ffbc ffbd 8GB vmemmap - -ffbe ffbffbbf ~8GB [防护页,未来用于 vmmemap] -ffbffbc0 ffbffbdf 2MB earlyprintk 设备 +AArch64 Linux 在页大小为 4KB,并使用 4 级转换表时的内存布局: -ffbffbe0 ffbffbe0 64KB PCI I/O 空间 - -ffbffbe1 ffbc ~2MB [防护页] - -ffbffc00 ffbf 64MB 模块 - -ffc0 256GB 内核逻辑内存映射 +起始地址 结束地址大小 用途 +--- + 256TB 用户空间 + 256TB 内核空间 -AArch64 Linux 在页大小为 64KB 时的内存布局: +AArch64 Linux 在页大小为 64KB,并使用 2 级转换表时的内存布局: 起始地址 结束地址大小 用途 --- 03ff 4TB 用户空间 +fc00 4TB 内核空间 -fc00 fdfbfffe ~2TB vmalloc - -fdfb fdfb 64KB [防护页] - -fdfc fdfd 8GB vmemmap - -fdfe fdfffbbf ~8GB [防护页,未来用于 vmmemap] -fdfffbc0 fdfffbdf 2MB earlyprintk 设备 +AArch64 Linux 在页大小为 64KB,并使用 3 级转换表时的内存布局: -fdfffbe0 fdfffbe0 64KB PCI I/O 空间 - -fdfffbe1 fdfffbff ~2MB [防护页] +起始地址 结束地址大小 用途 +--- + 256TB 用户空间 + 256TB 内核空间 -fdfffc00 fdff 64MB 模块 -fe00 2TB 内核逻辑内存映射 +更详细的内核虚拟内存布局,请参阅内核启动信息。 4KB 页大小的转换表查找: @@ -102,7 +88,7 @@ fe00 2TB 内核逻辑内存映射 | | | | +-> [20:12] L3 索引 | | | +---> [29:21] L2 索引 | | +-> [38:30] L1 索引 - | +---> [47:39] L0 索引 (未使用) + | +---> [47:39] L0 索引 +-> [63] TTBR0/1 @@ -115,10 +101,11 @@ fe00 2TB 内核逻辑内存映射 | || |
[PATCH] Documentation:Update Documentation/zh_CN/arm64/memory.txt
From: Fu Wei w...@redhat.com This is a update of Chinese documentation:Documentation/zh_CN/arm64/memory.txt It is based on the modifications of Documentation/arm64/memory.txt in submission: 08375198, 4edae01e, a24637d5, 383c2799. Signed-off-by: Fu Wei w...@redhat.com --- Documentation/zh_CN/arm64/memory.txt | 65 +++- 1 file changed, 26 insertions(+), 39 deletions(-) diff --git a/Documentation/zh_CN/arm64/memory.txt b/Documentation/zh_CN/arm64/memory.txt index a782704..19b3a52 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.mari...@arm.com 中文版维护者: 傅炜 Fu Wei w...@redhat.com 中文版翻译者: 傅炜 Fu Wei w...@redhat.com @@ -26,69 +28,53 @@ Documentation/arm64/memory.txt 的中文翻译 === 作者: Catalin Marinas catalin.mari...@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 级转换表时的内存布局: 起始地址 结束地址大小 用途 --- 007f 512GB 用户空间 +ff80 512GB 内核空间 -ff80 ffbbfffe~240GB vmalloc - -ffbb ffbb 64KB [防护页] - -ffbc ffbd 8GB vmemmap - -ffbe ffbffbbf ~8GB [防护页,未来用于 vmmemap] -ffbffbc0 ffbffbdf 2MB earlyprintk 设备 +AArch64 Linux 在页大小为 4KB,并使用 4 级转换表时的内存布局: -ffbffbe0 ffbffbe0 64KB PCI I/O 空间 - -ffbffbe1 ffbc ~2MB [防护页] - -ffbffc00 ffbf 64MB 模块 - -ffc0 256GB 内核逻辑内存映射 +起始地址 结束地址大小 用途 +--- + 256TB 用户空间 + 256TB 内核空间 -AArch64 Linux 在页大小为 64KB 时的内存布局: +AArch64 Linux 在页大小为 64KB,并使用 2 级转换表时的内存布局: 起始地址 结束地址大小 用途 --- 03ff 4TB 用户空间 +fc00 4TB 内核空间 -fc00 fdfbfffe ~2TB vmalloc - -fdfb fdfb 64KB [防护页] - -fdfc fdfd 8GB vmemmap - -fdfe fdfffbbf ~8GB [防护页,未来用于 vmmemap] -fdfffbc0 fdfffbdf 2MB earlyprintk 设备 +AArch64 Linux 在页大小为 64KB,并使用 3 级转换表时的内存布局: -fdfffbe0 fdfffbe0 64KB PCI I/O 空间 - -fdfffbe1 fdfffbff ~2MB [防护页] +起始地址 结束地址大小 用途 +--- + 256TB 用户空间 + 256TB 内核空间 -fdfffc00 fdff 64MB 模块 -fe00 2TB 内核逻辑内存映射 +更详细的内核虚拟内存布局,请参阅内核启动信息。 4KB 页大小的转换表查找: @@ -102,7 +88,7 @@ fe00 2TB 内核逻辑内存映射 | | | | +- [20:12] L3 索引 | | | +--- [29:21] L2 索引 | | +- [38:30] L1 索引 - | +--- [47:39] L0 索引 (未使用) + | +--- [47:39] L0 索引 +- [63] TTBR0/1 @@ -115,10 +101,11 @@ fe00