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

docs: unify new and migrated device publication requirements

Browse Source
This commit is contained in:
UniXNU Docs committed 2026-10-25 04:27:51 +08:00
1 parent 8327da0a5f
commit 90a366e001
11 files changed
+255 -38
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

AGENTS.md
+4
View File
@@ -56,6 +56,10 @@ in that order. Tables merge by key; ordinary arrays replace. List every required
component, configuration fragment, and patch series in the effective arrays.
The selected defconfig follows the configuration fragments.
New ports and migrations use the completion checklist and publication steps in
`docs/porting/device-repository.md`. Keep the template and both workflows aligned.
Published device repositories carry the `unixnu` GitHub topic.
Pin SoC and component sources. Inspect `unixnu status --json` before building.
Place generated sources, patched XNU, and outputs in the resolved target tree.
docs/porting/device-repository.md
+96 -1
View File
@@ -11,6 +11,7 @@ Read the [component catalog](/reference/components) before adding a driver.
UniXNU-<device>/
AGENTS.md
README.md
.gitignore
board.toml
porting.toml
.github/workflows/porting-record.yml
@@ -20,13 +21,107 @@ UniXNU-<device>/
patches/xnu/series
proprietary-files.txt
package/
local.toml
local.toml.example
unixnu.lock
```
`local.toml` contains local overrides. `unixnu fetch` writes source pins to
`unixnu.lock`. Component sources come from the catalog, feeds, or local
checkouts. `package/` appears as `kits/<board.kit>` in the assembled tree.
Copy `local.toml.example` to the ignored `local.toml` for machine-specific
overrides. Commit `unixnu.lock` after fetching the selected sources.
## Complete the repository {#completion}
New ports and migrated ports follow the same requirements below. Hardware
values, component selections and verification levels describe the target board.
The [new-port workflow](/porting/) and [migration guide](/porting/migration)
both finish here.
### 1. Complete the tracked files
Use the layout above. For an existing repository, add missing template files
and update existing files in place. Review these groups:
| Files | Required result |
| --- | --- |
| `board.toml`, `porting.toml` | Format 2 board configuration; matching device name, SoC and OS profile; completed hardware inputs; `board.example` absent or false |
| `feeds.toml`, `unixnu.lock`, `.gitmodules` when used | Reviewed source URLs and commits for the SoC, components and submodules; local overrides recorded separately |
| `configs/`, `patches/xnu/series` | Existing defconfig selected by `kernel.defconfig`; complete ordered configuration and patch lists; every referenced file present |
| `dts/` | Board DTS selected by `device_tree.source`, with the chosen SoC include, board resources and reservations |
| `package/`, board code and build recipes | Selected components and board services have build recipes, startup integration and required OS ABI inputs |
| `proprietary-files.txt`, firmware configuration | Required firmware sources and hashes, DSC/FDF integration, partition geometry and image inputs |
| `porting.toml`, `.github/workflows/porting-record.yml` | Every selected component and dependency covered by an area; actual source, host and device results; record check enabled |
| `README.md`, `AGENTS.md` | Board scope, prerequisites, build commands and links to the common guides and device record |
| `.gitignore`, `local.toml.example` | Local override file and generated output directories ignored; example paths documented |
Use the [component catalog](/reference/components) for shared implementations
and [driver adaptation](/porting/drivers) for board interfaces. Fill the template's
`REQUIRED_` values and zero RAM range from hardware sources. Record pending
implementation and verification in the corresponding `porting.toml` areas.
### 2. Resolve and verify
Run from the main UniXNU checkout. Set the device path and its actual defconfig:
```sh
DEVICE_DIR=../UniXNU-myboard
DEFCONFIG=myboard_defconfig
./unixnu defconfig "$DEFCONFIG" -D "$DEVICE_DIR"
./unixnu fetch -D "$DEVICE_DIR"
./unixnu status --json -D "$DEVICE_DIR"
./unixnu tree -D "$DEVICE_DIR"
python3 scripts/porting-record.py check --device "$DEVICE_DIR"
```
Inspect the resolved ARM64, SoC, OS and device profiles, component revisions,
overrides and patch order. The output path is
`out/<device>/<os_profile>/<config>/`, and the device package appears under
`tree/kits/<board.kit>/`. The record checker reports the number of structured
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.
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).
### 3. Publish and label the repository {#publish}
1. Review the device diff and commit the completed files and source pins. For
a new repository, initialize Git with `git -C "$DEVICE_DIR" init -b main`
before committing. Keep local paths in the ignored `local.toml`.
2. Publish the commit to your GitHub repository. With authenticated GitHub CLI,
create a new public repository from the committed directory:
```sh
REPOSITORY=YOUR_OWNER/UniXNU-myboard
gh repo create "$REPOSITORY" --public --source "$DEVICE_DIR" --remote origin --push
```
For an existing repository, push the reviewed branch to its configured remote.
Set `REPOSITORY` to that repository's `OWNER/NAME` for the following commands.
3. Add the **`unixnu` GitHub topic** and verify it:
```sh
gh repo edit "$REPOSITORY" --add-topic unixnu
gh repo view "$REPOSITORY" --json repositoryTopics --jq '.repositoryTopics[].name'
```
The output must include `unixnu`. In GitHub's web interface, use the repository's
**About** settings to edit **Topics**. The topic makes ports discoverable at
[github.com/topics/unixnu](https://github.com/topics/unixnu).
4. Confirm the porting-record workflow passes on the published commit. Official
device branches require its `Porting record` check.
5. To publish the device on the central site, pin that commit in `devices.toml`,
add the English and Chinese device pages, and link them from [Devices](/devices/).
Follow [record publication](/porting/records#publishing-and-reuse) and
[documentation contribution](/contributing/documentation), then run
`npm --prefix docs run build` from UniXNU. Confirm the rendered record uses
the published revision.
**Result:** a published device repository with pinned sources, reproducible
commands, a checked porting record, CI, common-guide links and the `unixnu` topic.
## Profiles
docs/porting/index.md
+24 -13
View File
@@ -2,7 +2,8 @@
UniXNU runs iOS or macOS on ARM64 devices through UEFI. Follow the eight steps
below to collect inputs, select shared support, adapt drivers and build images.
Each step states its expected result.
Each step states its expected result. New and migrated repositories use the
same [completion and publication requirements](/porting/device-repository#completion).
- **Add a device:** start at step 1.
- **Build an existing device:** check its inputs and current support in [Devices](/devices/), then follow [Building](/building).
@@ -53,7 +54,10 @@ new board's codename. Run from the UniXNU repository:
```sh
DEVICE=myboard
cp -R examples/device "../UniXNU-$DEVICE"
DEVICE_DIR="../UniXNU-$DEVICE"
cp -R examples/device "$DEVICE_DIR"
mv "$DEVICE_DIR/configs/example_defconfig" "$DEVICE_DIR/configs/${DEVICE}_defconfig"
mv "$DEVICE_DIR/dts/board.dts" "$DEVICE_DIR/dts/${DEVICE}.dts"
```
Complete these files using the [device repository reference](/porting/device-repository):
@@ -62,10 +66,16 @@ Complete these files using the [device repository reference](/porting/device-rep
and firmware paths. Review the complete component and archive selections.
2. `feeds.toml`: set the SoC repository URL and commit. For another SoC, also
change `board.soc`, `board.soc_source` and the DTS include.
3. Rename `configs/example_defconfig` and `dts/board.dts`; update their references.
3. Set `kernel.defconfig` to `<device>_defconfig` and `device_tree.source` to
`device:dts/<device>.dts` to match the renamed files. Review all configuration
fragments and patch series for the selected SoC and OS.
4. Fill the RAM range, enabled CPUs, peripherals and reservations in the DTS.
5. List required firmware files and their sources in `proprietary-files.txt`.
6. Complete `porting.toml`, the root README and `AGENTS.md` for the board.
Match the record identity to `board.toml`, cover every selected component and
dependency, and set ownership paths to the actual board files.
Keep the copied `.github/workflows/porting-record.yml`, `.gitignore` and
`local.toml.example`; review them with the [completion checklist](/porting/device-repository#completion).
7. Remove `board.example = true` after the required placeholders are filled.
The build commands reject repositories marked as examples.
@@ -140,19 +150,20 @@ Set up [QR log export](/porting/log-capture#firmware-setup) during firmware inte
and save the firmware log before kernel handoff. After storage verification, follow
the same guide through persistent capture, a manual cycle and automated tests.
## 8. Publish the port
## 8. Complete and publish the repository
Validate the record from the main checkout:
Follow [repository completion](/porting/device-repository#completion) in order:
check the tracked files, resolve sources, validate the record, and publish the
reviewed commit. This is also the final procedure for migrated repositories.
```sh
python3 scripts/porting-record.py check --device "../UniXNU-$DEVICE"
```
Add the **`unixnu` GitHub topic** using the [publication commands](/porting/device-repository#publish).
Enable the record workflow and publish the device revision and bilingual pages
through [porting records](/porting/records) and
[documentation contribution](/contributing/documentation).
Publish the device repository and pin its revision in `devices.toml` when adding
it to the central site. Follow [records](/porting/records) and
[documentation contribution](/contributing/documentation). Link the new device
page from [Devices](/devices/) in both languages. Keep the detailed guide in the
main repository and link it from the device README.
**Result:** the repository meets the common format 2 requirements and is
discoverable through the `unixnu` topic. Its record identifies completed and
pending work with source, host and device evidence.
## Related documentation
docs/porting/migration.md
+12 -4
View File
@@ -14,7 +14,9 @@ Follow this guide to convert an existing device repository to format 2. The
result is a pinned SoC source, a board DTS, a complete component selection and
repeatable kernel, firmware and payload commands. A new port starts with
[Port a device](/porting/). An existing format 2 port can use the checks below
to review its configuration.
to review its configuration. Both workflows finish with the same
[repository requirements and publication steps](/porting/device-repository#completion),
including the `unixnu` GitHub topic.
## Before you start
@@ -391,7 +393,8 @@ steps and their required inputs explicit.
## 9. Update the porting record, CI and documentation
Add `porting.toml` and `.github/workflows/porting-record.yml` from the template
when absent; update existing copies in place. Fill the board identity, selected
when absent; update existing copies in place. Merge the template `.gitignore`
rules and add `local.toml.example` with documented local overrides. Fill the board identity, selected
components, source revisions, configuration, procedure and evidence for each
area. Follow [porting records](/porting/records), then run:
@@ -402,8 +405,13 @@ npm --prefix docs run build
Update the device README and root `AGENTS.md` with the current commands and
required reading. Update affected English and Chinese site pages, component
references, CI paths and firmware instructions. Publish device changes, then
pin their commit in UniXNU's `devices.toml` so the site renders that record.
references, CI paths and firmware instructions. Complete the shared
[repository checklist](/porting/device-repository#completion), then follow
[publication](/porting/device-repository#publish) to push the device commit,
add the **`unixnu` GitHub topic**, check CI and pin the site record.
Compare the resolved configuration from step 6 with these requirements and
the inventory from step 1. The completed repository uses the same layout,
source pinning, build interfaces, records and publication steps as a new port.
Use this report when handing the migration to another maintainer or agent:
docs/porting/records.md
+3
View File
@@ -104,6 +104,9 @@ facts, evidence quality, component reuse and the stated completion level.
## Publishing and reuse
Complete the [repository publication steps](/porting/device-repository#publish),
including the `unixnu` GitHub topic, before registering the published revision.
`npm run build` fetches each registered device's pinned `porting.toml` and
`board.toml`, checks them and renders the device page. English and Chinese
pages consume the same record. The record body uses concise English. Site
docs/zh/porting/device-repository.md
+82 -1
View File
@@ -10,6 +10,7 @@
UniXNU-<device>/
AGENTS.md
README.md
.gitignore
board.toml
porting.toml
.github/workflows/porting-record.yml
@@ -19,12 +20,92 @@ UniXNU-<device>/
patches/xnu/series
proprietary-files.txt
package/
local.toml
local.toml.example
unixnu.lock
```
`local.toml` 保存本地覆盖，`unixnu fetch` 将源码版本写入 `unixnu.lock`。组件源码
来自目录、feeds 或本地检出。`package/` 在构建树中成为 `kits/<board.kit>`。
将 `local.toml.example` 复制为 Git 忽略的 `local.toml`，填写本机覆盖路径。
获取所选源码后提交 `unixnu.lock`。
## 完成仓库 {#completion}
新建与迁移后的设备仓库遵循以下相同要求。硬件参数、组件选择和验证等级以目标设备为准。
[新设备流程](/zh/porting/)与[迁移指南](/zh/porting/migration)均在这里完成收尾。
### 1. 完成受版本控制的文件
按上面的布局组织仓库。已有仓库补充缺失的模板文件，直接更新已有文件。逐组核对：
| 文件 | 完成结果 |
| --- | --- |
| `board.toml`、`porting.toml` | 格式 2 设备配置；设备名、SoC、OS profile 一致；硬件输入完整；`board.example` 省略或为 false |
| `feeds.toml`、`unixnu.lock`、使用子模块时的 `.gitmodules` | SoC、组件与子模块的源码 URL 和提交经过核对；本地覆盖单独记录 |
| `configs/`、`patches/xnu/series` | `kernel.defconfig` 指向实际文件；配置片段与补丁顺序完整；引用的文件均存在 |
| `dts/` | `device_tree.source` 指向板级 DTS，包含所选 SoC、板级资源和保留区 |
| `package/`、板级代码和构建配方 | 所选组件与板级服务具备构建配方、启动接入和所需 OS ABI 输入 |
| `proprietary-files.txt`、固件配置 | 固件来源与哈希、DSC/FDF 集成、分区几何和镜像输入完整 |
| `porting.toml`、`.github/workflows/porting-record.yml` | 每个所选组件及依赖都有对应区域；记录实际源码、主机和设备结果；启用记录检查 |
| `README.md`、`AGENTS.md` | 设备范围、前置条件、构建命令，以及通用指南和设备记录链接 |
| `.gitignore`、`local.toml.example` | 忽略本机覆盖文件与生成目录；说明示例路径 |
从[组件目录](/zh/reference/components)选择共享实现，按[驱动适配](/zh/porting/drivers)
实现板级接口。依据硬件资料填写模板中的 `REQUIRED_` 值与零 RAM 范围。
待完成的实现和验证写入对应的 `porting.toml` 区域。
### 2. 解析并验证
在 UniXNU 主仓库执行，填写设备路径和实际 defconfig：
```sh
DEVICE_DIR=../UniXNU-myboard
DEFCONFIG=myboard_defconfig
./unixnu defconfig "$DEFCONFIG" -D "$DEVICE_DIR"
./unixnu fetch -D "$DEVICE_DIR"
./unixnu status --json -D "$DEVICE_DIR"
./unixnu tree -D "$DEVICE_DIR"
python3 scripts/porting-record.py check --device "$DEVICE_DIR"
```
核对解析后的 ARM64、SoC、OS、设备配置层，组件版本、本地覆盖和补丁顺序。
输出路径为 `out/<device>/<os_profile>/<config>/`，设备 package 位于其中的
`tree/kits/<board.kit>/`。记录检查器输出已检查的结构化区域数量；发布前解决报告的错误。
编译[板级 DTS](/zh/porting/device-tree)，再按[构建指南](/zh/building)生成内核、package、
固件、payload 和启动镜像。记录每条命令、版本、输出与结果。按[启动验证](/zh/porting/bring-up)
和[日志抓取](/zh/porting/log-capture)单独记录硬件检查点，并为各区域填写有证据支持的
[完成等级](/zh/porting/records#completion-levels)。
### 3. 发布并设置仓库标签 {#publish}
1. 检查设备改动，提交完整文件和源码固定版本。新仓库在提交前执行
`git -C "$DEVICE_DIR" init -b main`。本机路径保存在 Git 忽略的 `local.toml` 中。
2. 将提交发布到自己的 GitHub 仓库。使用已登录的 GitHub CLI，从已提交的目录创建公开仓库：
```sh
REPOSITORY=YOUR_OWNER/UniXNU-myboard
gh repo create "$REPOSITORY" --public --source "$DEVICE_DIR" --remote origin --push
```
已有仓库将审核后的分支推送到已配置的远程。后续命令的 `REPOSITORY` 使用该仓库的 `OWNER/NAME`。
3. 添加 **`unixnu` GitHub topic** 并确认结果：
```sh
gh repo edit "$REPOSITORY" --add-topic unixnu
gh repo view "$REPOSITORY" --json repositoryTopics --jq '.repositoryTopics[].name'
```
输出应包含 `unixnu`。使用 GitHub 网页时，在仓库的 **About** 设置中编辑 **Topics**。
设备仓库可通过 [github.com/topics/unixnu](https://github.com/topics/unixnu) 查找。
4. 确认已发布提交的移植记录工作流通过。官方设备分支要求 `Porting record` 检查通过。
5. 接入中央站点时，在 `devices.toml` 固定该提交，添加中英文设备页面，并从
[设备列表](/zh/devices/)链接它们。按[记录发布](/zh/porting/records#发布与复用)
和[文档贡献](/zh/contributing/documentation)操作，在 UniXNU 运行
`npm --prefix docs run build`，确认渲染的记录使用已发布版本。
**结果：** 已发布的设备仓库包含源码固定版本、可复现命令、通过检查的移植记录、CI、
通用指南链接和 `unixnu` topic。
## 配置层
docs/zh/porting/index.md
+19 -12
View File
@@ -1,6 +1,6 @@
# 移植设备
UniXNU 通过 UEFI 在 ARM64 设备上运行 iOS 或 macOS。按下面八个步骤准备输入、选择共享支持、适配驱动并构建镜像，每一步都写明完成结果。
UniXNU 通过 UEFI 在 ARM64 设备上运行 iOS 或 macOS。按下面八个步骤准备输入、选择共享支持、适配驱动并构建镜像，每一步都写明完成结果。新建与迁移后的仓库使用相同的[完成与发布要求](/zh/porting/device-repository#completion)。
- **新增设备：** 从步骤 1 开始。
- **构建已有设备：** 在[设备列表](/zh/devices/)确认输入和当前支持范围，再按[构建指南](/zh/building)操作。
@@ -44,17 +44,24 @@ UniXNU 通过 UEFI 在 ARM64 设备上运行 iOS 或 macOS。按下面八个步
```sh
DEVICE=myboard
cp -R examples/device "../UniXNU-$DEVICE"
DEVICE_DIR="../UniXNU-$DEVICE"
cp -R examples/device "$DEVICE_DIR"
mv "$DEVICE_DIR/configs/example_defconfig" "$DEVICE_DIR/configs/${DEVICE}_defconfig"
mv "$DEVICE_DIR/dts/board.dts" "$DEVICE_DIR/dts/${DEVICE}.dts"
```
按[设备仓库参考](/zh/porting/device-repository)完成以下文件：
1. `board.toml`：设置设备名、kit、SoC 来源、OS profile、DTS 入口和固件路径，核对完整组件和归档选择。
2. `feeds.toml`：填写 SoC 仓库 URL 和提交。更换 SoC 时同步修改 `board.soc`、`board.soc_source` 和 DTS include。
3. 重命名 `configs/example_defconfig` 与 `dts/board.dts`，更新引用。
3. 将 `kernel.defconfig` 设为 `<device>_defconfig`，`device_tree.source` 设为
`device:dts/<device>.dts`，与重命名后的文件一致。核对所选 SoC 和 OS 的配置片段与补丁序列。
4. 在 DTS 中填写 RAM、启用的 CPU、外设和保留区。
5. 在 `proprietary-files.txt` 中列出固件文件及来源。
6. 为该设备填写 `porting.toml`、根目录 README 和 `AGENTS.md`。
6. 为该设备填写 `porting.toml`、根目录 README 和 `AGENTS.md`。记录身份与 `board.toml`
一致，覆盖所选组件及依赖，归属路径指向实际板级文件。保留复制的
`.github/workflows/porting-record.yml`、`.gitignore` 和 `local.toml.example`，
按[完成清单](/zh/porting/device-repository#completion)检查。
7. 填好必要占位符后移除 `board.example = true`。构建命令会拒绝标记为示例的仓库。
数组会替换继承值。覆盖组件、归档、配置片段和补丁序列时，保留完整的必需列表。
@@ -118,17 +125,17 @@ Wi-Fi，再处理 DSP、音频和电源。每篇指南列出源码位置、板
在固件阶段先按[日志抓取步骤](/zh/porting/log-capture#firmware-setup)集成二维码导出，
在内核交接前保存固件日志。存储验证完成后，继续该页的持久化抓取、手动循环和自动测试步骤。
## 8. 发布移植
## 8. 完成并发布仓库
从主仓库验证记录：
依次完成[仓库收尾步骤](/zh/porting/device-repository#completion)：核对受版本控制的文件、
解析源码、检查记录、发布审核后的提交。迁移后的仓库也使用这套收尾步骤。
```sh
python3 scripts/porting-record.py check --device "../UniXNU-$DEVICE"
```
按[发布命令](/zh/porting/device-repository#publish)添加 **`unixnu` GitHub topic**，
启用记录工作流，再按[移植记录](/zh/porting/records)和
[文档贡献](/zh/contributing/documentation)发布设备固定版本与中英文页面。
发布设备仓库后，在接入中央站点时将提交固定到 `devices.toml`。
按[记录指南](/zh/porting/records)和[文档贡献](/zh/contributing/documentation)操作，
在两种语言的[设备列表](/zh/devices/)中加入页面链接。详细指南放在主仓库，设备 README 链接到对应指南。
**结果：** 仓库满足统一的格式 2 要求，并可通过 `unixnu` topic 查找。
记录依据源码、主机和设备证据说明已完成与待完成工作。
## 相关文档
docs/zh/porting/migration.md
+3 -3
View File
@@ -4,7 +4,7 @@
格式 2 让多个设备复用 SoC 支持、OS profile 和组件构建配方。共享 SoC 仓库保存控制器资源和平台操作，设备仓库负责板级连接、固件选择和设备策略。公共修复集中维护，其他设备需要提供的输入也有明确位置。组件目录列出实现的硬件范围和 ABI 要求；按设备、OS profile 和配置划分的输出目录保存各自的补丁后内核与生成文件。
本指南将已有设备仓库转换为格式 2。完成后，设备具有固定版本的 SoC 源码、板级 DTS、完整组件选择，以及可重复执行的内核、固件和 payload 构建命令。新设备从[移植设备](/zh/porting/)开始。已有格式 2 设备可按下列检查复核配置。
本指南将已有设备仓库转换为格式 2。完成后，设备具有固定版本的 SoC 源码、板级 DTS、完整组件选择，以及可重复执行的内核、固件和 payload 构建命令。新设备从[移植设备](/zh/porting/)开始。已有格式 2 设备可按下列检查复核配置。两条流程均按相同的[仓库要求和发布步骤](/zh/porting/device-repository#completion)完成，包括添加 `unixnu` GitHub topic。
## 开始前
@@ -308,14 +308,14 @@ mcopy -i "$OUTPUT_DIR/payload/payload.img" \
## 9. 更新适配记录、CI 和文档
缺少 `porting.toml` 或 `.github/workflows/porting-record.yml` 时，从模板补充；已有文件直接更新。填写设备身份、所选组件、源码版本及各部分的配置、操作和证据。按[适配记录指南](/zh/porting/records)完成后运行：
缺少 `porting.toml` 或 `.github/workflows/porting-record.yml` 时，从模板补充；已有文件直接更新。合并模板的 `.gitignore` 规则，并添加说明本机覆盖路径的 `local.toml.example`。填写设备身份、所选组件、源码版本及各部分的配置、操作和证据。按[适配记录指南](/zh/porting/records)完成后运行：
```sh
python3 scripts/porting-record.py check --device "$DEVICE_DIR"
npm --prefix docs run build
```
更新设备 README 和根目录 `AGENTS.md` 中的当前命令与必读文档，同时更新受影响的中英文站点页面、组件引用、CI 路径和固件说明。发布设备改动后，在 UniXNU 的 `devices.toml` 中固定对应提交，供文档站读取记录。
更新设备 README 和根目录 `AGENTS.md` 中的当前命令与必读文档，同时更新受影响的中英文站点页面、组件引用、CI 路径和固件说明。完成统一的[仓库清单](/zh/porting/device-repository#completion)，再按[发布步骤](/zh/porting/device-repository#publish)推送设备提交、添加 **`unixnu` GitHub topic**、检查 CI 并固定站点记录版本。将步骤 6 的解析配置与清单及步骤 1 的输入记录核对。完成后的仓库与新建仓库使用相同的布局、源码固定方式、构建接口、记录和发布步骤。
向其他维护者或 agent 交接时，使用以下报告：
docs/zh/porting/records.md
+3
View File
@@ -97,6 +97,9 @@ python3 scripts/porting-record.py check --device ../UniXNU-sheng --base origin/m
## 发布与复用
按[仓库发布步骤](/zh/porting/device-repository#publish)添加 `unixnu` GitHub topic，
完成发布后再登记固定版本。
`npm run build` 获取注册设备固定版本的 `porting.toml` 和 `board.toml`，检查后生成
设备页。中英文页面使用同一份记录，记录正文使用简洁英语。站点源码和部署保留在 UniXNU。
examples/device/AGENTS.md
+5 -1
View File
@@ -51,7 +51,11 @@ before building the firmware and boot image.
Record commands, revisions, output paths, results, and unresolved inputs.
Report hardware boot, storage, display, input, and GPU results separately.
Update the device revision in UniXNU's devices.toml for publication and keep this README concise.
Finish both new ports and migrations with the same
[repository checklist](https://unixnu.com/porting/device-repository#completion).
Follow [publication](https://unixnu.com/porting/device-repository#publish), add
the `unixnu` GitHub topic, and update the device revision in UniXNU's
`devices.toml`. Keep this README concise.
## Porting record
examples/device/README.md
+4 -3
View File
@@ -8,12 +8,13 @@ hardware inputs before building.
1. Copy this directory to `UniXNU-<device>` and read `AGENTS.md`.
2. Set the board name, description, firmware paths, and complete component selection. Add the shared `UniXNURamDiskDxe` and filesystem dependencies to the firmware DSC and FDF using the [firmware integration guide](https://unixnu.com/porting/uefi-firmware#required-integration).
3. Pin a reviewed SoC commit in `feeds.toml`.
4. Fill the DTS model, compatible values, memory map, CPU selection, and peripherals.
4. Rename `configs/example_defconfig` and `dts/board.dts` for the board, then update `kernel.defconfig` and `device_tree.source`. Fill the DTS model, compatible values, memory map, CPU selection, and peripherals.
5. List firmware sources and hashes in `proprietary-files.txt`.
6. Set partition geometry and payload inputs from the device's records.
7. Complete each area in `porting.toml`, including ownership paths, findings and completion criteria.
7. Match the identity in `porting.toml` to `board.toml`. Cover every selected component and dependency, with board-specific ownership paths, findings and completion criteria.
8. Enable the template CI workflow and require its `Porting record` check on the official device branch.
9. Set `example = false`, select the defconfig, fetch, and inspect `status --json`.
9. Set `example = false`, select the defconfig, fetch, and inspect `status --json`. Commit the generated `unixnu.lock`; keep local overrides in the ignored `local.toml`.
10. Complete the shared [repository checklist](https://unixnu.com/porting/device-repository#completion), build and record results, then follow [publication](https://unixnu.com/porting/device-repository#publish). Add the **`unixnu` GitHub topic** and verify it appears in the repository topics.
The zero memory range and `REQUIRED_` values identify inputs to complete.
`patches/xnu/series` lists board patches in application order. `package/` contains