mirror of
https://github.com/AetherDroid/android_kernel_samsung_on5xelte.git
synced 2025-09-05 16:07:46 -04:00
Fixed MTP to work with TWRP
This commit is contained in:
awab228
commit
f6dfaef42e
50820 changed files with 20846062 additions and 0 deletions
183
Documentation/zh_CN/arm64/booting.txt
Normal file
183
Documentation/zh_CN/arm64/booting.txt
Normal file
|
|
@ -0,0 +1,183 @@
|
|||
Chinese translated version of Documentation/arm64/booting.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: Will Deacon <will.deacon@arm.com>
|
||||
Chinese maintainer: Fu Wei <wefu@redhat.com>
|
||||
---------------------------------------------------------------------
|
||||
Documentation/arm64/booting.txt 的中文翻译
|
||||
|
||||
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
|
||||
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
|
||||
译存在问题，请联系中文版维护者。
|
||||
|
||||
英文版维护者： Will Deacon <will.deacon@arm.com>
|
||||
中文版维护者： 傅炜 Fu Wei <wefu@redhat.com>
|
||||
中文版翻译者： 傅炜 Fu Wei <wefu@redhat.com>
|
||||
中文版校译者： 傅炜 Fu Wei <wefu@redhat.com>
|
||||
|
||||
以下为正文
|
||||
---------------------------------------------------------------------
|
||||
启动 AArch64 Linux
|
||||
==================
|
||||
|
||||
作者: Will Deacon <will.deacon@arm.com>
|
||||
日期: 2012 年 09 月 07 日
|
||||
|
||||
本文档基于 Russell King 的 ARM 启动文档，且适用于所有公开发布的
|
||||
AArch64 Linux 内核代码。
|
||||
|
||||
AArch64 异常模型由多个异常级别（EL0 - EL3）组成，对于 EL0 和 EL1
|
||||
异常级有对应的安全和非安全模式。EL2 是系统管理级，且仅存在于
|
||||
非安全模式下。EL3 是最高特权级，且仅存在于安全模式下。
|
||||
|
||||
基于本文档的目的，我们将简单地使用‘引导装载程序’（‘boot loader’）
|
||||
这个术语来定义在将控制权交给 Linux 内核前 CPU 上执行的所有软件。
|
||||
这可能包含安全监控和系统管理代码，或者它可能只是一些用于准备最小启动
|
||||
环境的指令。
|
||||
|
||||
基本上，引导装载程序（至少）应实现以下操作：
|
||||
|
||||
1、设置和初始化 RAM
|
||||
2、设置设备树数据
|
||||
3、解压内核映像
|
||||
4、调用内核映像
|
||||
|
||||
|
||||
1、设置和初始化 RAM
|
||||
-----------------
|
||||
|
||||
必要性: 强制
|
||||
|
||||
引导装载程序应该找到并初始化系统中所有内核用于保持系统变量数据的 RAM。
|
||||
这个操作的执行是设备依赖的。（它可能使用内部算法来自动定位和计算所有
|
||||
RAM，或可能使用对这个设备已知的 RAM 信息，还可能使用任何引导装载程序
|
||||
设计者想到的匹配方法。）
|
||||
|
||||
|
||||
2、设置设备树数据
|
||||
---------------
|
||||
|
||||
必要性: 强制
|
||||
|
||||
设备树数据块（dtb）必须 8 字节对齐，并位于从内核映像起始算起第一个 512MB
|
||||
内，且不得跨越 2MB 对齐边界。这使得内核可以通过初始页表中的单个节描述符来
|
||||
映射此数据块。
|
||||
|
||||
|
||||
3、解压内核映像
|
||||
-------------
|
||||
|
||||
必要性: 可选
|
||||
|
||||
AArch64 内核当前没有提供自解压代码，因此如果使用了压缩内核映像文件
|
||||
（比如 Image.gz），则需要通过引导装载程序（使用 gzip 等）来进行解压。
|
||||
若引导装载程序没有实现这个需求，就要使用非压缩内核映像文件。
|
||||
|
||||
|
||||
4、调用内核映像
|
||||
-------------
|
||||
|
||||
必要性: 强制
|
||||
|
||||
已解压的内核映像包含一个 64 字节的头，内容如下：
|
||||
|
||||
u32 code0; /* 可执行代码 */
|
||||
u32 code1; /* 可执行代码 */
|
||||
u64 text_offset; /* 映像装载偏移 */
|
||||
u64 res0 = 0; /* 保留 */
|
||||
u64 res1 = 0; /* 保留 */
|
||||
u64 res2 = 0; /* 保留 */
|
||||
u64 res3 = 0; /* 保留 */
|
||||
u64 res4 = 0; /* 保留 */
|
||||
u32 magic = 0x644d5241; /* 魔数, 小端, "ARM\x64" */
|
||||
u32 res5 = 0; /* 保留 */
|
||||
|
||||
|
||||
映像头注释：
|
||||
|
||||
- code0/code1 负责跳转到 stext.
|
||||
|
||||
映像必须位于系统 RAM 起始处的特定偏移（当前是 0x80000）。系统 RAM
|
||||
的起始地址必须是以 2MB 对齐的。
|
||||
|
||||
在跳转入内核前，必须符合以下状态：
|
||||
|
||||
- 停止所有 DMA 设备，这样内存数据就不会因为虚假网络包或磁盘数据而
|
||||
被破坏。这可能可以节省你许多的调试时间。
|
||||
|
||||
- 主 CPU 通用寄存器设置
|
||||
x0 = 系统 RAM 中设备树数据块（dtb）的物理地址。
|
||||
x1 = 0 (保留，将来可能使用)
|
||||
x2 = 0 (保留，将来可能使用)
|
||||
x3 = 0 (保留，将来可能使用)
|
||||
|
||||
- CPU 模式
|
||||
所有形式的中断必须在 PSTATE.DAIF 中被屏蔽（Debug、SError、IRQ
|
||||
和 FIQ）。
|
||||
CPU 必须处于 EL2（推荐，可访问虚拟化扩展）或非安全 EL1 模式下。
|
||||
|
||||
- 高速缓存、MMU
|
||||
MMU 必须关闭。
|
||||
指令缓存开启或关闭都可以。
|
||||
数据缓存必须关闭且无效。
|
||||
外部高速缓存（如果存在）必须配置并禁用。
|
||||
|
||||
- 架构计时器
|
||||
CNTFRQ 必须设定为计时器的频率，且 CNTVOFF 必须设定为对所有 CPU
|
||||
都一致的值。如果在 EL1 模式下进入内核，则 CNTHCTL_EL2 中的
|
||||
EL1PCTEN (bit 0) 必须置位。
|
||||
|
||||
- 一致性
|
||||
通过内核启动的所有 CPU 在内核入口地址上必须处于相同的一致性域中。
|
||||
这可能要根据具体实现来定义初始化过程，以使能每个CPU上对维护操作的
|
||||
接收。
|
||||
|
||||
- 系统寄存器
|
||||
在进入内核映像的异常级中，所有构架中可写的系统寄存器必须通过软件
|
||||
在一个更高的异常级别下初始化，以防止在 未知 状态下运行。
|
||||
|
||||
以上对于 CPU 模式、高速缓存、MMU、架构计时器、一致性、系统寄存器的
|
||||
必要条件描述适用于所有 CPU。所有 CPU 必须在同一异常级别跳入内核。
|
||||
|
||||
引导装载程序必须在每个 CPU 处于以下状态时跳入内核入口：
|
||||
|
||||
- 主 CPU 必须直接跳入内核映像的第一条指令。通过此 CPU 传递的设备树
|
||||
数据块必须在每个 CPU 节点中包含一个 ‘enable-method’ 属性，所
|
||||
支持的 enable-method 请见下文。
|
||||
|
||||
引导装载程序必须生成这些设备树属性，并在跳入内核入口之前将其插入
|
||||
数据块。
|
||||
|
||||
- enable-method 为 “spin-table” 的 CPU 必须在它们的 CPU
|
||||
节点中包含一个 ‘cpu-release-addr’ 属性。这个属性标识了一个
|
||||
64 位自然对齐且初始化为零的内存位置。
|
||||
|
||||
这些 CPU 必须在内存保留区（通过设备树中的 /memreserve/ 域传递
|
||||
给内核）中自旋于内核之外，轮询它们的 cpu-release-addr 位置（必须
|
||||
包含在保留区中）。可通过插入 wfe 指令来降低忙循环开销，而主 CPU 将
|
||||
发出 sev 指令。当对 cpu-release-addr 所指位置的读取操作返回非零值
|
||||
时，CPU 必须跳入此值所指向的地址。此值为一个单独的 64 位小端值，
|
||||
因此 CPU 须在跳转前将所读取的值转换为其本身的端模式。
|
||||
|
||||
- enable-method 为 “psci” 的 CPU 保持在内核外（比如，在
|
||||
memory 节点中描述为内核空间的内存区外，或在通过设备树 /memreserve/
|
||||
域中描述为内核保留区的空间中）。内核将会发起在 ARM 文档（编号
|
||||
ARM DEN 0022A：用于 ARM 上的电源状态协调接口系统软件）中描述的
|
||||
CPU_ON 调用来将 CPU 带入内核。
|
||||
|
||||
*译者注:到文档翻译时，此文档已更新为 ARM DEN 0022B。
|
||||
|
||||
设备树必须包含一个 ‘psci’ 节点，请参考以下文档：
|
||||
Documentation/devicetree/bindings/arm/psci.txt
|
||||
|
||||
|
||||
- 辅助 CPU 通用寄存器设置
|
||||
x0 = 0 (保留，将来可能使用)
|
||||
x1 = 0 (保留，将来可能使用)
|
||||
x2 = 0 (保留，将来可能使用)
|
||||
x3 = 0 (保留，将来可能使用)
|
||||
127
Documentation/zh_CN/arm64/memory.txt
Normal file
127
Documentation/zh_CN/arm64/memory.txt
Normal file
|
|
@ -0,0 +1,127 @@
|
|||
Chinese translated version of Documentation/arm64/memory.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: Catalin Marinas <catalin.marinas@arm.com>
|
||||
Chinese maintainer: Fu Wei <wefu@redhat.com>
|
||||
---------------------------------------------------------------------
|
||||
Documentation/arm64/memory.txt 的中文翻译
|
||||
|
||||
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
|
||||
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
|
||||
译存在问题，请联系中文版维护者。
|
||||
|
||||
英文版维护者： Catalin Marinas <catalin.marinas@arm.com>
|
||||
中文版维护者： 傅炜 Fu Wei <wefu@redhat.com>
|
||||
中文版翻译者： 傅炜 Fu Wei <wefu@redhat.com>
|
||||
中文版校译者： 傅炜 Fu Wei <wefu@redhat.com>
|
||||
|
||||
以下为正文
|
||||
---------------------------------------------------------------------
|
||||
Linux 在 AArch64 中的内存布局
|
||||
===========================
|
||||
|
||||
作者: Catalin Marinas <catalin.marinas@arm.com>
|
||||
日期: 2012 年 02 月 20 日
|
||||
|
||||
本文档描述 AArch64 Linux 内核所使用的虚拟内存布局。此构架可以实现
|
||||
页大小为 4KB 的 4 级转换表和页大小为 64KB 的 3 级转换表。
|
||||
|
||||
AArch64 Linux 使用页大小为 4KB 的 3 级转换表配置，对于用户和内核
|
||||
都有 39-bit (512GB) 的虚拟地址空间。对于页大小为 64KB的配置，仅
|
||||
使用 2 级转换表，但内存布局相同。
|
||||
|
||||
用户地址空间的 63:39 位为 0，而内核地址空间的相应位为 1。TTBRx 的
|
||||
选择由虚拟地址的 63 位给出。swapper_pg_dir 仅包含内核（全局）映射，
|
||||
而用户 pgd 仅包含用户（非全局）映射。swapper_pgd_dir 地址被写入
|
||||
TTBR1 中，且从不写入 TTBR0。
|
||||
|
||||
|
||||
AArch64 Linux 在页大小为 4KB 时的内存布局：
|
||||
|
||||
起始地址 结束地址 大小 用途
|
||||
-----------------------------------------------------------------------
|
||||
0000000000000000 0000007fffffffff 512GB 用户空间
|
||||
|
||||
ffffff8000000000 ffffffbbfffeffff ~240GB vmalloc
|
||||
|
||||
ffffffbbffff0000 ffffffbbffffffff 64KB [防护页]
|
||||
|
||||
ffffffbc00000000 ffffffbdffffffff 8GB vmemmap
|
||||
|
||||
ffffffbe00000000 ffffffbffbbfffff ~8GB [防护页，未来用于 vmmemap]
|
||||
|
||||
ffffffbffbc00000 ffffffbffbdfffff 2MB earlyprintk 设备
|
||||
|
||||
ffffffbffbe00000 ffffffbffbe0ffff 64KB PCI I/O 空间
|
||||
|
||||
ffffffbffbe10000 ffffffbcffffffff ~2MB [防护页]
|
||||
|
||||
ffffffbffc000000 ffffffbfffffffff 64MB 模块
|
||||
|
||||
ffffffc000000000 ffffffffffffffff 256GB 内核逻辑内存映射
|
||||
|
||||
|
||||
AArch64 Linux 在页大小为 64KB 时的内存布局：
|
||||
|
||||
起始地址 结束地址 大小 用途
|
||||
-----------------------------------------------------------------------
|
||||
0000000000000000 000003ffffffffff 4TB 用户空间
|
||||
|
||||
fffffc0000000000 fffffdfbfffeffff ~2TB vmalloc
|
||||
|
||||
fffffdfbffff0000 fffffdfbffffffff 64KB [防护页]
|
||||
|
||||
fffffdfc00000000 fffffdfdffffffff 8GB vmemmap
|
||||
|
||||
fffffdfe00000000 fffffdfffbbfffff ~8GB [防护页，未来用于 vmmemap]
|
||||
|
||||
fffffdfffbc00000 fffffdfffbdfffff 2MB earlyprintk 设备
|
||||
|
||||
fffffdfffbe00000 fffffdfffbe0ffff 64KB PCI I/O 空间
|
||||
|
||||
fffffdfffbe10000 fffffdfffbffffff ~2MB [防护页]
|
||||
|
||||
fffffdfffc000000 fffffdffffffffff 64MB 模块
|
||||
|
||||
fffffe0000000000 ffffffffffffffff 2TB 内核逻辑内存映射
|
||||
|
||||
|
||||
4KB 页大小的转换表查找：
|
||||
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
| | | | | |
|
||||
| | | | | v
|
||||
| | | | | [11:0] 页内偏移
|
||||
| | | | +-> [20:12] L3 索引
|
||||
| | | +-----------> [29:21] L2 索引
|
||||
| | +---------------------> [38:30] L1 索引
|
||||
| +-------------------------------> [47:39] L0 索引 (未使用)
|
||||
+-------------------------------------------------> [63] TTBR0/1
|
||||
|
||||
|
||||
64KB 页大小的转换表查找：
|
||||
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
| | | | |
|
||||
| | | | v
|
||||
| | | | [15:0] 页内偏移
|
||||
| | | +----------> [28:16] L3 索引
|
||||
| | +--------------------------> [41:29] L2 索引 (仅使用 38:29 )
|
||||
| +-------------------------------> [47:42] L1 索引 (未使用)
|
||||
+-------------------------------------------------> [63] TTBR0/1
|
||||
|
||||
当使用 KVM 时, 管理程序（hypervisor）在 EL2 中通过相对内核虚拟地址的
|
||||
一个固定偏移来映射内核页（内核虚拟地址的高 24 位设为零）:
|
||||
|
||||
起始地址 结束地址 大小 用途
|
||||
-----------------------------------------------------------------------
|
||||
0000004000000000 0000007fffffffff 256GB 在 HYP 中映射的内核对象
|
||||
52
Documentation/zh_CN/arm64/tagged-pointers.txt
Normal file
52
Documentation/zh_CN/arm64/tagged-pointers.txt
Normal file
|
|
@ -0,0 +1,52 @@
|
|||
Chinese translated version of Documentation/arm64/tagged-pointers.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: Will Deacon <will.deacon@arm.com>
|
||||
Chinese maintainer: Fu Wei <wefu@redhat.com>
|
||||
---------------------------------------------------------------------
|
||||
Documentation/arm64/tagged-pointers.txt 的中文翻译
|
||||
|
||||
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
|
||||
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
|
||||
译存在问题，请联系中文版维护者。
|
||||
|
||||
英文版维护者： Will Deacon <will.deacon@arm.com>
|
||||
中文版维护者： 傅炜 Fu Wei <wefu@redhat.com>
|
||||
中文版翻译者： 傅炜 Fu Wei <wefu@redhat.com>
|
||||
中文版校译者： 傅炜 Fu Wei <wefu@redhat.com>
|
||||
|
||||
以下为正文
|
||||
---------------------------------------------------------------------
|
||||
Linux 在 AArch64 中带标记的虚拟地址
|
||||
=================================
|
||||
|
||||
作者: Will Deacon <will.deacon@arm.com>
|
||||
日期: 2013 年 06 月 12 日
|
||||
|
||||
本文档简述了在 AArch64 地址转换系统中提供的带标记的虚拟地址及其在
|
||||
AArch64 Linux 中的潜在用途。
|
||||
|
||||
内核提供的地址转换表配置使通过 TTBR0 完成的虚拟地址转换（即用户空间
|
||||
映射），其虚拟地址的最高 8 位（63:56）会被转换硬件所忽略。这种机制
|
||||
让这些位可供应用程序自由使用，其注意事项如下：
|
||||
|
||||
(1) 内核要求所有传递到 EL1 的用户空间地址带有 0x00 标记。
|
||||
这意味着任何携带用户空间虚拟地址的系统调用（syscall）
|
||||
参数 *必须* 在陷入内核前使它们的最高字节被清零。
|
||||
|
||||
(2) 非零标记在传递信号时不被保存。这意味着在应用程序中利用了
|
||||
标记的信号处理函数无法依赖 siginfo_t 的用户空间虚拟
|
||||
地址所携带的包含其内部域信息的标记。此规则的一个例外是
|
||||
当信号是在调试观察点的异常处理程序中产生的，此时标记的
|
||||
信息将被保存。
|
||||
|
||||
(3) 当使用带标记的指针时需特别留心，因为仅对两个虚拟地址
|
||||
的高字节，C 编译器很可能无法判断它们是不同的。
|
||||
|
||||
此构架会阻止对带标记的 PC 指针的利用，因此在异常返回时，其高字节
|
||||
将被设置成一个为 “55” 的扩展符。
|
||||
Loading…
Add table
Add a link
Reference in a new issue