okooooooo/UniXNU
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(porting): PAC requirements, the Sm8550Platform page and the packaging script

Browse Source 
The arm64e page states that the method needs native PAC hardware, that iPadOS
18 is the last release whose endpoints are arm64, and that a new port should
pick a device that meets the requirements and prefer the iOS or iPadOS 27
profile, whose drivers and patches are the ones under maintenance. Every
optimization in this repository is maintained against both 17 and 27 and is
selected by build parameter alone. sheng's current profile is recorded as
ipados-27.0.1-24A446, with the earlier 26.5.2 profile kept beside it.

Sm8550Platform gets its own page in both languages, and the repository table
lists it.

The device packaging script page defines the mandatory one-command script:
fixed steps, configuration read from TOML only, one shared script text, the
OS target passed as a parameter, and the two required outputs with their
manifest.
This commit is contained in:
UniXNU Docs committed 2026-11-01 05:46:37 +08:00
1 parent 23ed975d34
commit d2666583eb
11 files changed
+289 -12
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

docs/.vitepress/config.mts
+1
View File
@@ -72,6 +72,7 @@ function taskSidebars(prefix: string, zh: boolean) {
]),
group('4. Verify and publish', '4. 验证与发布', [
item('Build and boot', '构建与启动', 'building'),
item('Device packaging script', '设备打包脚本', 'porting/packaging'),
item('Bring-up sequence', '启动验证顺序', 'porting/bring-up'),
item('Log capture and boot tests', '日志抓取与启动测试', 'porting/log-capture'),
item('Porting record', '适配记录', 'porting/records'),
docs/drivers/repositories.md
+1
View File
@@ -29,6 +29,7 @@ These repositories are maintained in the UniXNU organization.
| AirNir | [UniXNU/AirNir](https://github.com/UniXNU/AirNir) | Compiler kit | [AirNir](/drivers/air-nir) |
| AdrenoPM4 | [UniXNU/AdrenoPM4](https://github.com/UniXNU/AdrenoPM4) | GPU command kit | [AdrenoPM4](/drivers/adreno-pm4) |
| AdrenoFirmware | [UniXNU/AdrenoFirmware](https://github.com/UniXNU/AdrenoFirmware) | GPU firmware kit | [AdrenoFirmware](/drivers/adreno-firmware) |
| Sm8550Platform | [UniXNU/UniXNU-sm8550-common](https://github.com/UniXNU/UniXNU-sm8550-common) | SM8550 GPU platform kit | [Sm8550Platform](/drivers/sm8550-platform) |
| DarwinBoot | [UniXNU/DarwinBoot](https://github.com/UniXNU/DarwinBoot) | UEFI loader | [DarwinBoot](/drivers/darwin-boot) |
| VerifiedRoot | [UniXNU/VerifiedRoot](https://github.com/UniXNU/VerifiedRoot) | Root trust tooling | [VerifiedRoot](/drivers/verified-root) |
| ShengPreflight | [UniXNU/ShengPreflight](https://github.com/UniXNU/ShengPreflight) | UEFI preflight | [ShengPreflight](/drivers/sheng-preflight) |
docs/drivers/sm8550-platform.md
+47
View File
@@ -0,0 +1,47 @@
# Sm8550Platform
Start with the [adaptation procedure](/porting/gpu) for board inputs, source changes, build integration and verification order.
SM8550 GPU platform operations: the GMU, the GPU SMMU and the RPMh command database the GPU and its power rails read.
[Source repository](https://github.com/UniXNU/UniXNU-sm8550-common).
The kit is board code, not a driver: the SoC repository supplies it and a board selects it when it enables the Adreno 740 accelerator. The GMU part brings the graphics management unit up and holds its rails; the SMMU part gives the GPU its own stage 1 translation domain; the command database part answers RPMh resource lookups by name.
## Requirements
| Requirement | Meaning |
| --- | --- |
| SoC SM8550 | The register map and the RPMh resource names are the board's own |
| GPU firmware | The GMU and the GPU microcode come from the firmware files the board provisions |
| `ArmSmmu4K` | The SMMU part programs a stage 1 context through the SMMU kit |
| `AdrenoFirmware` | The firmware loader that hands the GMU its images |
Select it in the board configuration:
```toml
[components]
include = ["Sm8550Platform", "Adreno740", "AdrenoMetal", "AdrenoFirmware", "ArmSmmu4K"]
```
The component is built into the kernel as part of the board package (`build_stage = "embedded"`). It produces no separate archive or bundle.
## Sources
| File | Contents |
| --- | --- |
| `ShengGmu.c` | GMU start, halt, memory windows, interrupt and the keepalive vote |
| `ShengGpuSmmu.c` | The GPU's SMMU context, its stage 1 tables and the fault handler |
| `ShengGmuCommandDb.c` | The RPMh command database: resource lookup by name, level and vote |
## Verification
The kit is verified through the drivers that use it: [Adreno 740](/drivers/adreno740) and [Adreno Metal](/drivers/adreno-metal) on a board that reaches the GPU. Record the GMU start result, the SMMU context and the resource votes in the board's `porting.toml` GPU area.
## Integration
```sh
./unixnu build kernel -D ../UniXNU-sheng
```
[Component catalog](/reference/components)
docs/porting/arm64e.md
+16 -6
View File
@@ -5,9 +5,16 @@ meets every [requirement](#requirements) and appears in
[supported devices](#supported-devices). Other devices use the arm64 profile
`ipados-17.7.11-21H461` and the regular [porting steps](/porting/steps).
iPadOS 18 and later ship arm64e user space only. An arm64e profile builds XNU
with pointer authentication (PAC) and links the original arm64e kexts of the
target kernelcache.
iPadOS 18 and later ship arm64e user space only, so arm64 is the last resort
whose endpoints are iOS 17 and iPadOS 18. An arm64e profile builds XNU with
pointer authentication (PAC) and links the original arm64e kexts of the target
kernelcache.
For a new port, choose a device whose CPUs meet the requirements below. Prefer
the iOS or iPadOS 27 profile: its drivers, patches and build recipes are the
ones under active development, and every driver and optimization in this
repository is maintained against both 17 and 27, selected by build parameter
alone.
## Requirements {#requirements}
@@ -26,14 +33,16 @@ Record the result of each check in the device `porting.toml`.
| Device | SoC | OS profile | State |
| --- | --- | --- | --- |
| sheng | SM8550 | `ipados-26.5.2-23F84` | In development |
| sheng | SM8550 | `ipados-27.0.1-24A446` | In development |
| sheng | SM8550 | `ipados-26.5.2-23F84` | Kept as the earlier arm64e profile |
## Profile layout
| Location | Contents |
| --- | --- |
| `profiles/arch/arm64e` | arm64e build configuration, PAC key management and XNU patch series |
| `profiles/os/ipados-26.5.2-23F84` | XNU `12377.121.6` and IPSW pins, prelink roots and OS patches |
| `profiles/os/ipados-27.0.1-24A446` | XNU `12377.121.6` with the Darwin 26 calls, iPadOS 27.0.1 IPSW pins, prelink roots and OS patches |
| `profiles/os/ipados-26.5.2-23F84` | The earlier arm64e profile, same XNU revision and its own IPSW pins |
The OS profile selects its architecture with `[os] arch = "arm64e"`. Profiles
without the key use `profiles/arch/arm64`. Both architectures use the same
@@ -65,7 +74,8 @@ sysctls and the commpage capability words. SM8550 has no SME. The iPadOS
## Procedure
1. Run the [requirement](#requirements) checks on every enabled CPU and record them.
2. Set `board.os_profile = "ipados-26.5.2-23F84"` in the device configuration.
2. Set `board.os_profile = "ipados-27.0.1-24A446"` in the device configuration, or pass
`--os 27` to `./unixnu` for one run.
3. Run `./unixnu fetch` and `./unixnu status --json`. Confirm the arm64e profile, XNU revision and patch order.
4. Build with [Building](/building): kernel, package, firmware, payload, userdata, boot image.
5. Follow the [bring-up order](/porting/bring-up) and record each checkpoint.
docs/porting/device-repository.md
+2
View File
@@ -82,6 +82,8 @@ areas checked. Resolve each reported error before publication.
Compile the [board DTS](/porting/device-tree), then follow
[Building](/building) for kernel, package, firmware, payload and boot image.
The repository also carries the [device packaging script](/porting/packaging)
that produces the same two artifacts from a clean checkout with no edit.
Record each command, revision, output and result. Record hardware checkpoints
separately using [bring-up](/porting/bring-up) and [log capture](/porting/log-capture).
Assign each area its supported [completion level](/porting/records#completion-levels).
docs/porting/packaging.md
+91
View File
@@ -0,0 +1,91 @@
# Device packaging script
**Mandatory for every device repository.** A device repository carries one
packaging script that produces its boot image and its payload from a clean
checkout, with no argument and no edit. Other device repositories copy this
page's structure. They fill in configuration values, never the script.
## Rules
1. **One command, one result.** `scripts/package.sh` in the device repository
builds both artifacts. A second run on the same sources produces byte
identical outputs.
2. **Configuration comes from TOML.** The script reads `board.toml` and the
referenced `feeds.toml`, profile and local file. It contains no device name,
path, size, kernel argument or version as a literal. A value the script
needs but the TOML does not carry is added to `board.toml` first.
3. **The script is shared, not per device.** Device repositories use the same
script text. Boards differ only in their TOML values. A change to the flow
is made once and adopted by every device repository.
4. **The build target is a parameter.** One branch serves every OS profile.
`--os` selects iOS or iPadOS 17, 26 or 27 for that run. There is no per
target branch, and no second copy of a driver, patch or optimization for a
second target.
5. **Every step is named and checked.** A step that fails stops the run with
its name and the command's output. A step that is skipped says so.
## Structure
The script runs these steps in this order. Each one is a function with the
step's name, and each prints a header line before it runs.
| Step | Does | Reads |
| --- | --- | --- |
| `deps` | Clones or updates UniXNU, the device repository, its modules and the UEFI repository; checks each pinned revision | `feeds.toml`, `.gitmodules`, `unixnu.lock` |
| `preflight` | Runs the board's checks and resolves the profiles | `board.toml`, `--os` |
| `patches` | Lists the resolved patch series in application order, then applies it | `patch_series`, profile series |
| `build` | Builds each stage in dependency order, stopping at the first failure | `components`, `kernel`, `firmware` |
| `pack` | Writes the two artifacts and their manifest | `bootimg`, `payload` |
| `verify` | Checks the artifacts against the manifest and reports sizes | the manifest |
## Interface
```sh
scripts/package.sh [--os 17|26|27|PROFILE] [--device DIR] [--out DIR] [--jobs N] [--no-deps] [--check]
```
| Option | Meaning |
| --- | --- |
| `--os` | OS profile for this run. Defaults to `board.os_profile` |
| `--device` | Device repository. Defaults to the directory holding the script |
| `--out` | Output root. Defaults to `out/` in the UniXNU checkout |
| `--jobs` | Parallel jobs for the compile steps |
| `--no-deps` | Skips `deps`, for a machine whose sources are already fetched and pinned |
| `--check` | Runs `deps`, `preflight`, `patches` and `verify` only, and reports what would change |
Every option maps onto a `unixnu` argument. The script adds no logic of its own
to a step that `unixnu` already performs.
## Required outputs
The run writes these files, and the manifest names each one with its size and
SHA-256.
| Output | Contents |
| --- | --- |
| `out/<device>/<os_profile>/<config>/boot.img` | Android boot image: shim, firmware volume, device tree, payload ramdisk |
| `out/<device>/<os_profile>/<config>/payload.img` | The payload volume the boot image carries |
| `out/<device>/<os_profile>/<config>/kernel.macho` | The prelinked kernel the payload boots |
| `out/<device>/<os_profile>/<config>/package.manifest.json` | Build id, OS profile, resolved revisions, patch series, output sizes and hashes |
The boot image must fit the bootloader's partition and the kernel command line
must stay under 1000 bytes. The script refuses both cases before it writes an
image.
## Verification
A packaging run counts as complete when `verify` passes: both artifacts exist,
their hashes match the manifest, the kernel command line is within its limit,
and the boot image is not larger than the partition it is booted from. Booting
the artifact is a separate step with its own record.
## Adoption
For a device repository without the script:
1. Copy `scripts/package.sh` from the reference device repository.
2. Fill `board.toml` until `--check` reports no missing value.
3. Record the outputs in the device's `porting.toml` packaging area.
4. Add the run to the build documentation.
[Build and boot](/building), [Device repository](/porting/device-repository)
docs/zh/drivers/repositories.md
+1
View File
@@ -29,6 +29,7 @@
| AirNir | [UniXNU/AirNir](https://github.com/UniXNU/AirNir) | 编译器 kit | [AirNir](/zh/drivers/air-nir) |
| AdrenoPM4 | [UniXNU/AdrenoPM4](https://github.com/UniXNU/AdrenoPM4) | GPU 命令 kit | [AdrenoPM4](/zh/drivers/adreno-pm4) |
| AdrenoFirmware | [UniXNU/AdrenoFirmware](https://github.com/UniXNU/AdrenoFirmware) | GPU 固件 kit | [AdrenoFirmware](/zh/drivers/adreno-firmware) |
| Sm8550Platform | [UniXNU/UniXNU-sm8550-common](https://github.com/UniXNU/UniXNU-sm8550-common) | SM8550 GPU 平台 kit | [Sm8550Platform](/zh/drivers/sm8550-platform) |
| DarwinBoot | [UniXNU/DarwinBoot](https://github.com/UniXNU/DarwinBoot) | UEFI 加载器 | [DarwinBoot](/zh/drivers/darwin-boot) |
| VerifiedRoot | [UniXNU/VerifiedRoot](https://github.com/UniXNU/VerifiedRoot) | 根信任工具 | [VerifiedRoot](/zh/drivers/verified-root) |
| ShengPreflight | [UniXNU/ShengPreflight](https://github.com/UniXNU/ShengPreflight) | UEFI 预检 | [ShengPreflight](/zh/drivers/sheng-preflight) |
docs/zh/drivers/sm8550-platform.md
+47
View File
@@ -0,0 +1,47 @@
# Sm8550Platform
先按[适配流程](/zh/porting/gpu)准备板级输入、修改源码、接入构建并逐步验证。
SM8550 GPU 平台操作：GMU、GPU SMMU，以及 GPU 及其电源轨读取的 RPMh 命令数据库。
[源码仓库](https://github.com/UniXNU/UniXNU-sm8550-common).
这是板级代码而非驱动：由 SoC 仓库提供，板级在启用 Adreno 740 加速器时选中它。GMU 部分启动图形管理单元并持有其电源轨；SMMU 部分给 GPU 自己的 stage 1 翻译域；命令数据库部分按名称回答 RPMh 资源查询。
## 要求
| 要求 | 含义 |
| --- | --- |
| SoC SM8550 | 寄存器映射和 RPMh 资源名属于该板 |
| GPU 固件 | GMU 和 GPU 微码来自板级提供的固件文件 |
| `ArmSmmu4K` | SMMU 部分通过 SMMU kit 编程 stage 1 上下文 |
| `AdrenoFirmware` | 把镜像交给 GMU 的固件加载器 |
在板级配置中选择它：
```toml
[components]
include = ["Sm8550Platform", "Adreno740", "AdrenoMetal", "AdrenoFirmware", "ArmSmmu4K"]
```
该组件作为板级包的一部分编入内核（`build_stage = "embedded"`），不产生单独的归档或 bundle。
## 源码
| 文件 | 内容 |
| --- | --- |
| `ShengGmu.c` | GMU 启动、停止、内存窗口、中断和 keepalive 投票 |
| `ShengGpuSmmu.c` | GPU 的 SMMU 上下文、其 stage 1 页表和故障处理 |
| `ShengGmuCommandDb.c` | RPMh 命令数据库：按名称、档位与投票查询资源 |
## 验证
该 kit 通过使用它的驱动验证：在到达 GPU 的板级上为 [Adreno 740](/zh/drivers/adreno740) 和 [Adreno Metal](/zh/drivers/adreno-metal)。把 GMU 启动结果、SMMU 上下文和资源投票记录到板级 `porting.toml` 的 GPU 区域。
## 集成
```sh
./unixnu build kernel -D ../UniXNU-sheng
```
[组件目录](/zh/reference/components)
docs/zh/porting/arm64e.md
+10 -5
View File
@@ -3,8 +3,11 @@
**仅适用于受支持的设备。** 只有满足全部[要求](#requirements)并列入[受支持设备](#supported-devices)的设备才能使用本方法。
其他设备使用 arm64 配置 `ipados-17.7.11-21H461` 和常规[移植步骤](/zh/porting/steps)。
iPadOS 18 及以后版本只提供 arm64e 用户空间。arm64e 配置以指针认证（PAC）编译 XNU，
并链接目标 kernelcache 中的原版 arm64e kext。
iPadOS 18 及以后版本只提供 arm64e 用户空间，因此 arm64 是最后的退路，其终点是 iOS 17 和 iPadOS 18。
arm64e 配置以指针认证（PAC）编译 XNU，并链接目标 kernelcache 中的原版 arm64e kext。
新移植应选择满足下列要求的设备。优先使用 iOS 或 iPadOS 27 配置：其驱动、补丁和构建配方
处于持续维护中，本仓库的每个驱动和优化都同时面向 17 和 27 维护，只靠构建参数选择。
## 要求 {#requirements}
@@ -23,14 +26,16 @@ iPadOS 18 及以后版本只提供 arm64e 用户空间。arm64e 配置以指针
| 设备 | SoC | OS 配置 | 状态 |
| --- | --- | --- | --- |
| sheng | SM8550 | `ipados-26.5.2-23F84` | 开发中 |
| sheng | SM8550 | `ipados-27.0.1-24A446` | 开发中 |
| sheng | SM8550 | `ipados-26.5.2-23F84` | 保留为其早期 arm64e 配置 |
## 配置结构
| 位置 | 内容 |
| --- | --- |
| `profiles/arch/arm64e` | arm64e 编译配置、PAC 密钥管理和 XNU 补丁系列 |
| `profiles/os/ipados-26.5.2-23F84` | XNU `12377.121.6` 与 IPSW 固定版本、预链接根组件和 OS 补丁 |
| `profiles/os/ipados-27.0.1-24A446` | XNU `12377.121.6` 加 Darwin 26 调用、iPadOS 27.0.1 IPSW 固定版本、预链接根组件和 OS 补丁 |
| `profiles/os/ipados-26.5.2-23F84` | 先前的 arm64e 配置，同一 XNU 修订与各自的 IPSW 固定版本 |
OS 配置用 `[os] arch = "arm64e"` 选择架构。没有该项的配置使用 `profiles/arch/arm64`。
两种架构使用相同的组件，arm64e 构建把它们编译为 arm64e。
@@ -56,7 +61,7 @@ SM8550 没有 SME。iPadOS 26.5.2 的 dyld cache 在以 SME 命名的函数中
## 操作步骤
1. 在每个启用的 CPU 上完成[要求](#requirements)中的检查并记录结果。
2. 在设备配置中设置 `board.os_profile = "ipados-26.5.2-23F84"`。
2. 在设备配置中设置 `board.os_profile = "ipados-27.0.1-24A446"`，或对单次运行给 `./unixnu` 传 `--os 27`。
3. 运行 `./unixnu fetch` 和 `./unixnu status --json`，确认 arm64e 配置、XNU 版本和补丁顺序。
4. 按[构建](/zh/building)依次构建内核、package、固件、payload、userdata 和启动镜像。
5. 按[启动验证顺序](/zh/porting/bring-up)记录每个检查点。
docs/zh/porting/device-repository.md
+2 -1
View File
@@ -73,7 +73,8 @@ python3 scripts/porting-record.py check --device "$DEVICE_DIR"
`tree/kits/<board.kit>/`。记录检查器输出已检查的结构化区域数量；发布前解决报告的错误。
编译[板级 DTS](/zh/porting/device-tree)，再按[构建指南](/zh/building)生成内核、package、
固件、payload 和启动镜像。记录每条命令、版本、输出与结果。按[启动验证](/zh/porting/bring-up)
固件、payload 和启动镜像。设备仓库还带有[设备打包脚本](/zh/porting/packaging)，
从干净检出、无需修改即可产出同样两项产物。记录每条命令、版本、输出与结果。按[启动验证](/zh/porting/bring-up)
和[日志抓取](/zh/porting/log-capture)单独记录硬件检查点，并为各区域填写有证据支持的
[完成等级](/zh/porting/records#completion-levels)。
docs/zh/porting/packaging.md
+71
View File
@@ -0,0 +1,71 @@
# 设备打包脚本
**每个设备仓库必须遵守。** 设备仓库只带一个打包脚本，从干净检出、不带参数、不需要修改即可产出启动镜像和 payload。
其他设备仓库照搬本页的结构，只填写配置值，不修改脚本本身。
## 规则
1. **一条命令，两项产物。** 设备仓库的 `scripts/package.sh` 同时构建两项产物。同一份源码第二次运行产出的字节完全相同。
2. **配置来自 TOML。** 脚本读取 `board.toml` 及其引用的 `feeds.toml`、配置文件和本地文件。脚本里不出现设备名、路径、尺寸、内核参数或版本的字面值。脚本需要而 TOML 没有的值，先加进 `board.toml`。
3. **脚本是共享的，不按设备各写一份。** 各设备仓库使用同一份脚本文本，差异只在 TOML 取值。流程改动只改一次，由所有设备仓库采用。
4. **构建目标是参数。** 单一分支服务所有 OS 配置。`--os` 为本次运行选择 iOS 或 iPadOS 17、26、27。不存在按目标拆分的分支，也不存在为第二个目标另存一份的驱动、补丁或优化。
5. **每一步都有名字和检查。** 失败的一步以其名称和命令输出终止本次运行；被跳过的一步要说明原因。
## 结构
脚本按下列顺序执行。每一步是一个同名函数，运行前打印一行标题。
| 步骤 | 作用 | 读取 |
| --- | --- | --- |
| `deps` | 克隆或更新 UniXNU、设备仓库、其模块和 UEFI 仓库，并校验每个固定版本 | `feeds.toml`、`.gitmodules`、`unixnu.lock` |
| `preflight` | 运行板级检查并解析配置 | `board.toml`、`--os` |
| `patches` | 按应用顺序列出解析后的补丁系列，然后应用 | `patch_series`、各配置的系列 |
| `build` | 按依赖顺序构建各阶段，遇到第一个失败即停止 | `components`、`kernel`、`firmware` |
| `pack` | 写出两项产物及其清单 | `bootimg`、`payload` |
| `verify` | 按清单校验产物并报告尺寸 | 清单 |
## 接口
```sh
scripts/package.sh [--os 17|26|27|PROFILE] [--device DIR] [--out DIR] [--jobs N] [--no-deps] [--check]
```
| 选项 | 含义 |
| --- | --- |
| `--os` | 本次运行的 OS 配置，默认取 `board.os_profile` |
| `--device` | 设备仓库，默认为脚本所在目录 |
| `--out` | 输出根目录，默认为 UniXNU 检出中的 `out/` |
| `--jobs` | 编译阶段的并行任务数 |
| `--no-deps` | 跳过 `deps`，用于源码已获取并固定版本的本机 |
| `--check` | 只运行 `deps`、`preflight`、`patches` 和 `verify`，报告将会发生的变化 |
每个选项都对应一个 `unixnu` 参数。`unixnu` 已经完成的步骤，脚本不再添加自己的逻辑。
## 必需产物
本次运行写出下列文件，清单为每个文件记录尺寸和 SHA-256。
| 产物 | 内容 |
| --- | --- |
| `out/<device>/<os_profile>/<config>/boot.img` | Android 启动镜像：shim、固件卷、设备树、payload ramdisk |
| `out/<device>/<os_profile>/<config>/payload.img` | 启动镜像携带的 payload 卷 |
| `out/<device>/<os_profile>/<config>/kernel.macho` | payload 启动的预链接内核 |
| `out/<device>/<os_profile>/<config>/package.manifest.json` | 构建标识、OS 配置、解析后的版本、补丁系列、产物尺寸与哈希 |
启动镜像必须放得进引导加载程序的分区，内核命令行必须保持在 1000 字节以内。两种情况脚本在写镜像之前就拒绝。
## 验证
一次打包运行以 `verify` 通过为完成：两项产物存在，哈希与清单一致，内核命令行在限制之内，启动镜像不大于它所来自的分区。
启动该产物是另一步，另行记录。
## 采用
给尚无该脚本的设备仓库：
1. 从参考设备仓库复制 `scripts/package.sh`。
2. 填写 `board.toml`，直到 `--check` 不再报告缺失值。
3. 把产物记录到设备 `porting.toml` 的 packaging 区域。
4. 把运行方式加入构建文档。
[构建与启动](/zh/building)、[设备仓库](/zh/porting/device-repository)