2026-09-14 04:51:45 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文详细记录了作者为小米平板6Pro移植原生Linux的过程，包括选择原生方案的原因、启动流程适配、显示与触控调试等关键步骤，最终成功运行Ubuntu桌面并支持主要硬件。文章提供了具体的技术路径和调试经验，对类似设备移植具有参考价值。 综合评分： 85 文章分类： 实战经验

150亿token：我给小米平板6 Pro移植了原生Linux

原创

yzddMr6 yzddMr6

熵减矩阵

2026年9月13日 23:22 浙江

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

折腾了快一个月，在 AI 的帮助下，我给家里的小米平板 6 Pro 移植了原生 Linux，跑上了 Ubuntu 桌面。

Linux 6.17 内核，Ubuntu 26.04，GNOME 桌面。屏幕、触控、GPU、Wi-Fi、蓝牙、四扬声器和磁吸键盘都能用了，关机再打开，直接进入 Linux。

Codex 客户端也装上了，可以正常对话。

小米平板6 Pro上实际运行的Codex客户端

系统信息里能看到 ARM 处理器、Freedreno 的 FD730，以及我们自己编译的内核。

小米平板6 Pro上的Ubuntu系统信息与磁吸键盘

背景

这件事其实四年前就试过。

2022 年，我从抽屉里翻出一台吃灰的小米 6，想在手机上跑 Docker。先试着重新编译 Android 内核，把缺少的功能打开，折腾半天还是报错。后来换成 postmarketOS，终于跑出了 Hello from Docker!，还专门写了篇手机运行 Docker：从修改内核到刷入原生 Linux。

结果后来一个上游包更新，屏幕直接卡死。我去问维护者什么时候修，过了一周，他回复说不想维护了，太累了。。。。。

我自己又不会改，只能停在那里，小米 6 后来也卖掉了。

我平时有不少想法，但工作之外的精力有限，光是补齐相关知识就得花很长时间，不可能每冒出一个想法，都从头学一遍。

家里正好还有一台小米平板 6 Pro，骁龙 8+ Gen 1，硬件挺不错，装着 Android 却已经用得有些卡了。那就再试一次，看看现在的 AI 能不能帮我把它改成 Linux 电脑。

查了一圈，普通版平板 6 已经有社区移植，Pro 没找到现成的完整方案。这次得自己接着做设备适配了。

最开始给 AI 的要求很简单：先搜资料，研究给这台平板移植 mainline Linux 的方案，最后要能运行 Ubuntu。

最初向AI提出小米平板6 Pro移植需求

至于具体怎么做，我也不知道。代码让 AI 去读、去写，我跟着它了解启动过程、设备树和驱动，看不懂就继续问。先做起来，再边做边学。

为什么选择原生 Linux

我想在这台平板上用完整的桌面程序、开发工具和后台服务，也想自己管理内核和硬件。Android 本来就使用 Linux 内核，但在里面装上 Ubuntu 用户空间，能控制的仍然只是系统的一部分。

现成项目不少，按底层实现可以分成几类：

Droidspaces 这类项目已经可以运行完整的 init 系统，宿主条件满足时也能跑 Docker。但容器共用的仍是 Android 内核。发行版需要的某项内核选项没开，光在容器里装软件补不上，最后还得回头改宿主。

我想干脆自己维护内核，让屏幕、触控和声音接入标准 Linux 软件栈。也不太喜欢厂商系统越来越臃肿，装着一批用不到的服务，后台和权限还得按它的规则来。换成 Linux，开哪些服务、装什么桌面、怎么更新，都可以自己决定。

原生运行也避开了 PRoot 拦截系统调用、QEMU 软件模拟指令的额外开销。不过，这不代表一定比 Android 更快、更省电，驱动和电源管理的适配也会影响表现。我更看重的是能按普通电脑的方式使用它。

我一直对轻巧的小电脑很感兴趣。ARM 开发板可以用来折腾 Linux，但要拼成一台随身电脑，还得配屏幕、电池、供电、外壳和输入设备。消费级平板已经把这些装好了，处理器、内存和存储也不差。尤其家里就有一台，硬件的钱都不用再花，缺的是 Linux 适配。

发行版选了 Ubuntu，主要是软件和资料好找。现在 ARM64 软件也丰富了，VS Code 就有 Linux ARM64 安装包，常用编译器和命令行工具也能直接安装，不必什么都绕到 x86 模拟上。

安卓设备如何移植 Linux

一开始我问过 AI：移植这件事，到底是按照说明书组装，找别人做好的代码拼起来，还是从 Android 包里逆向？

做到后面发现，几种都要用。社区代码提供同平台的实现，小米的源码和原系统用于查接线、供电时序和初始化命令。资料对不上，或者源码不完整的地方，还得实验、逆向。

小米公开了 liuqin 的厂商内核和设备树。社区 sm8450-mainline/linux 又提供了同平台的内核基础。我们主要补小米平板 6 Pro 的板级适配和缺失功能。

这里采用的是接近上游的内核，加上社区和本项目的设备适配补丁，并非未经修改的上游内核；GPU、无线、DSP 等仍需要厂商固件。

启动内核

手机和平板不能像普通 PC 那样，拿个通用 Ubuntu 镜像就直接装。通用镜像里没有这台设备的内核适配、设备树和固件。

按下电源键以后，最先运行的是芯片里的启动程序，接着是高通 XBL，再到小米 ABL。XBL 负责早期初始化，ABL 负责选择启动槽、加载启动镜像，也提供 Fastboot。

我们保留原厂启动链，从 ABL 加载的内容开始替换。早期自制镜像的启动过程，可以和原厂 Android 对照着看：

&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 上电
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Boot ROM -> 高通 XBL
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 小米 ABL &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 原厂保留
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; +------------+-------------+
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|
&nbsp; &nbsp; &nbsp; &nbsp;原厂 Android &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;早期 Linux 镜像
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|
&nbsp;boot: 厂商内核 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 自制 boot image
&nbsp;vendor_boot: DTB/ramdisk &nbsp; &nbsp; &nbsp; &nbsp;├─ Linux Image
&nbsp;dtbo: 板级 overlay &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ├─ liuqin DTB
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; └─ initramfs
&nbsp; &nbsp; &nbsp; 厂商 Linux 内核 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 项目 Linux 内核
&nbsp; &nbsp; &nbsp; Android init &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/init 准备根系统
&nbsp;Framework / 厂商服务 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; switch_root
&nbsp; &nbsp; &nbsp; &nbsp;HyperOS桌面 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; systemd
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; GDM / GNOME

DTB 是编译后的设备树。内核靠它知道有哪些设备、寄存器地址是多少、谁给谁供电、哪根 GPIO 负责复位。驱动要根据这些信息访问硬件。

早期仅仅让 ABL 接受自制镜像就费了不少工夫。原厂用 boot header v4，DTB 从 vendor_boot 取得。只换 boot 里的内核，并不能保证新内核拿到的是我们自己的设备树。

于是早期镜像采用带显式 DTB 的 v2 格式，把内核、DTB 和 initramfs 一起打包。但小米 ABL 还会执行厂商 DTBO 合并。原厂 overlay 会引用厂商树里的符号，新写的主线设备树没有这套名称，合并失败，内核都还没执行就退回 Fastboot。

最后补上了 ABL 所需的选择信息和符号映射，把厂商 overlay 中引用符号的片段导向专门的隔离节点，让合并通过，同时避免这些片段破坏实际使用的设备描述。这是针对本机 ABL 行为做的适配。

内核开始执行以后，下一件事是拿日志。早期完整显示驱动还没有工作，就先复用 Bootloader 留下的 framebuffer，让 earlycon 把内核日志写到屏幕上。initramfs 里放 BusyBox 和我们自己的 /init，建立 USB NCM 网络，提供远程 Shell，同时把 UFS 块设备保持只读。

这时只有一个很小的 Linux 环境，但电脑可以连进去看 dmesg，失败后也有证据留下。早期测试优先从 RAM 临时启动，不覆盖能启动的原系统。拿到这条调试通道，后面的工作才不用一直盯着黑屏猜。

内核能启动以后，还要让桌面接上硬件。以图形为例，Android 的显示合成依赖 SurfaceFlinger、Hardware Composer（HWC）等组件；Ubuntu 这边则由 GNOME 的 Mutter 管理窗口与合成，通过 Mesa 和内核的 DRM/KMS 接口使用 GPU、输出画面。

Android 显示路径（简化）

应用画面 -> SurfaceFlinger -> HWC / 厂商显示接口
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;厂商显示驱动
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; DPU / DSI -> 屏幕

Ubuntu 图形路径（简化）

应用 -- Wayland 提交画面 --> Mutter
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; +-- Mesa/Freedreno -- DRM 驱动 --> GPU 合成
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; +-- DRM/KMS -------- 显示驱动 --> DPU / DSI
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;屏幕

Ubuntu 触控输入路径

触控硬件 -> 内核驱动 -> input / evdev -> libinput -> Mutter -> 应用

设备树：描述寄存器、供电、中断等，供内核创建设备、匹配驱动
固件：由驱动或加载服务装入 GPU、DSP、无线等处理器执行

Mesa 的 Freedreno 驱动负责 Adreno 的用户态图形支持；libinput负责处理输入事件，两条路径在桌面合成器这里汇合。驱动、固件和用户态组件都接好，桌面才能真正使用这些硬件。

系统识别还闹过一个乌龙：开头照片里的虚拟化一栏显示 vm-other。排查发现，设备树中的 Gunyah 节点触发了 systemd 的识别，桌面还因此走错过电源键处理逻辑。Ubuntu 实际由 ABL 引导，运行我们自己的内核，并没有套在 Android 虚拟机里。

显示和触控

前期最难的就是这两个，来来回回修了不知道多少次。

屏幕在出厂竖屏坐标下是 1800×2880。为了传输高分辨率、高刷新率画面，它用了两路 DSI，还有 DSC 显示流压缩。GPU 负责渲染，DPU 负责显示合成和输出，DSC 把画面压缩，再由 DSI 发给面板。

花屏阶段的照片是这样的：

显示适配过程中的整屏彩色噪点

最迷惑的是，日志不一定报错。显示控制器已经 active，刷新率正确，压缩参数发了，背光也亮着，画面还是一团糟。

后来对照厂商配置和社区代码，发现一个错误把另一个错误的修复效果盖住了。

先是 DPU 的资源分配。厂商使用两个 Layer Mixer、两个 DSC 编码器和两个输出接口，也就是记录里的 2:2:2。当时社区代码中的实验路径选了 4:4:2。但在当时未启用 virtual plane 的配置下，输入 plane 最多只能向两个 Mixer 提供有效像素。

当时的错误组合

输入 plane ── 有效像素 ──> Mixer 0、1 ──┐
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;├─> 四个 DSC ─> 两路 DSI ─> 花屏
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;无有效来源 &nbsp; Mixer 2、3 ──┘

修正后的分配

输入画面 ─> 两个 Mixer ─> 两个 DSC ─> 两路 DSI ─> 面板

后面的 DSC 并不知道像素对不对，它照样把收到的内容压缩成合法码流。DSI 也可以正常传输这些数据。所以“没有协议错误”和“画面正确”，在这里是两回事。

把拓扑改对以后，文字终于能看清一些了，但屏幕上还剩两条竖直噪声带。

文字已经可读，但两条噪声带仍然存在

这才露出第二个问题：DSC 的分包。

每路 DSI 负责 900 像素宽，其中包含两个 450 像素宽的压缩 slice。厂商要求每个包带两个 slice，社区实现却把 slice_per_pkt 固定为 1，和面板预期对不上。

1800 像素宽的一帧
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|
&nbsp; &nbsp; +----+----+
&nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; |
&nbsp;DSI 0 &nbsp; &nbsp; &nbsp;DSI 1
&nbsp;900px &nbsp; &nbsp; &nbsp;900px
&nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; |
450 + 450 &nbsp;450 + 450
&nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; |
每包2片 &nbsp; &nbsp; 每包2片 &nbsp; &nbsp; &nbsp; &nbsp;必须与面板的打包方式一致

这个修复其实之前就试过。当时拓扑还错着，屏幕怎么改都花，于是它被记成“没有效果”。拓扑修好以后，再把相同的分包修复加回来，两条噪声带才消失。

一次实验没改善画面，不足以证明改动没用。这次就是另一个错误还没修好，提前把有效方案否决了。

屏幕修好了，触控又死了。

NT36532 是集成显示与触控的 TDDI 芯片，两者共享复位及部分内部状态。早期 Linux 还没有完全接管显示，触控是在 ABL 留下的硬件状态里工作的。后来主线面板驱动重新复位屏幕，触控侧也跟着复位，原来的“触控正常”就失效了。

起初以为是 IRQ、GPIO 或者桌面的输入配置。往下查才发现，SPI 能通信，固件也能下载，版本号都读得出来，但固件始终卡在 A0，没有进入扫描状态。没有扫描，自然没有触摸数据，更不会产生中断。

面板 reset
&nbsp; &nbsp; |
触控固件重新加载
&nbsp; &nbsp; |
状态初始化 -> 校准 -> 正常扫描 -> IRQ -> input事件 -> 桌面
&nbsp; &nbsp; ^
&nbsp; &nbsp; 当时卡在这里，后面的环节一起没有数据

最后反汇编本机的厂商触控模块，逐个比较实际 SPI 事务，才发现社区驱动把两段命令截短了。

&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 状态清理 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; CRC enable
厂商模块 &nbsp; &nbsp; 60 00 00 00 00 00 00 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;50 AE 00
社区实现 &nbsp; &nbsp; 60 00 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 50 AE
长度 &nbsp; &nbsp; &nbsp; &nbsp; 7字节 -> 2字节 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;3字节 -> 2字节

函数名字一样，调用顺序也差不多，差的是实际发出的长度和字节。恢复厂商的完整帧以后，固件从 A0 进入 A1、A3，中断和触摸事件都回来了。

修复的是社区携带的非上游 Novatek 驱动。随后还要处理关屏、重载和移除驱动时的顺序，避免第一次能用，重新初始化后又出问题。

从最小环境到 Ubuntu

图形和输入先放在最小 Weston 环境里验证，确认能用后，再换成完整的 GNOME 桌面。这样排查时不用同时面对整套桌面服务。

最早的图形环境就一个终端窗口：

最小图形环境里的root终端

后来画面才变成了熟悉的 Ubuntu 桌面：

Ubuntu GNOME桌面及快捷设置

网络、声音、传感器和键盘也要继续补。无线要核对固件和板级配置；四扬声器需要音频路由、保护固件和本机校准；自动旋转则要从 SLPI 传感器 DSP 上运行的 SSC 服务取数据，再交给用户态服务，通知 GNOME 调整方向。修完内核驱动，往往还有用户态的配置和服务要接。

早期 Ubuntu 的根文件系统放在 RAM 里，重启后改动会消失。后来把内部存储上的 userdata 重新安排为 ext4 根分区，软件和设置才可以持久保存。启动时由 initramfs 挂载根分区，再交给 systemd，接着启动 GDM 和 GNOME。

最后还得把匹配的内核、模块、固件和系统服务打进安装包，处理首次开机的账户设置。我们实验时手动改过的东西，要变成构建脚本和配置，让后来的人可以直接安装。

成果展示

现在可以在平板上打开 VS Code，浏览本机目录，用桌面编辑器和终端工作了。

平板上实际启动的VS Code与磁吸键盘

GNOME 的触摸体验比我预想的好。切换工作区、弹出屏幕键盘，还有支持手势的应用里滑动和缩放，用起来都挺顺手。自动旋转接通以后，拿起来竖着看，放回键盘上横着用，也符合平时用平板的习惯。

键盘我特意选了不带触摸板的版本，带触摸板那款会多出一截。11 英寸，薄薄一片，加一块紧凑的键盘，放进包里就能带走。桌面应用、终端和后台服务都在这套 Linux 里，这就是我一直想要的小电脑。

主要硬件支持情况整理如下，后续进展以项目支持表为准：

| 功能 | 状态 | 说明 | | — | — | — | | 显示与手动亮度 | ✅ 可用 | 双 DSI / DSC，2880×1800，120Hz，KTZ8866 背光 | | GPU | ✅ 可用 | Adreno 730 / Freedreno / Mesa；部分应用仍需兼容设置 | | 触控 | ✅ 可用 | NT36532，点击、滑动和手势 | | 磁吸键盘 | ✅ 可用 | 普通键、音量键和重新吸附；挂起恢复未完整覆盖 | | UFS 存储 | ✅ 可用 | ext4 持久系统与软件包安装 | | Wi-Fi、蓝牙 | ✅ 可用 | 2.4GHz、5GHz 联网和日常蓝牙使用 | | 四扬声器 | ✅ 可用 | 立体声、音量控制、本机校准；音质仍在调整 | | 自动旋转 | ✅ 可用 | 首次启动、登录界面、桌面旋转和键盘横屏 | | 电源键、音量键 | ✅ 可用 | 灭亮屏、电源菜单与音量调整 | | 电池与基础充电 | ✅ 可用 | 电脑 USB 供电功率有限，高负载时可能净放电 | | H.264 硬解 | ✅ 可用 | 用户态解码已验证；浏览器硬解和其他格式未验证 | | USB | 🟡 部分支持 | NCM 与 High-Speed 设备模式可用；充电后重连仍有问题，USB 3.x、OTG 不支持，外接显示未验证 | | 挂起与恢复 | 🟡 部分支持 | 基础恢复已验证，外设恢复和深休眠功耗继续测试 | | 摄像头、麦克风、自动亮度、小米快充 | ❌ 不支持 | 尚未完成对应接入 | | 手写笔、其余传感器、RTC 离线保持 | 🧪 未验证 | 尚未完成对应实测 |

目前装的是 Ubuntu 单系统。A/B 启动槽给双启动留了一些可能，后面还想研究 Android 和 Ubuntu 共存，处理好两套系统的数据布局和切换。

开发中的一些经验

这次我花了不少精力调整和 AI 协作的方式。代码可以让它写，但任务怎么拆、真机怎么测、会话断了怎么接着做，都得安排。一个项目持续几周，这些问题会反复碰到。

按功能拆分任务，隔离上下文

一开始试过让主 Agent 负责调度，蓝牙、Wi-Fi、触控分别交给子 Agent。我要求主 Agent 不干具体工作，只负责分配和汇总。

想法挺好，实际跑起来经常串线。子任务混入不相关上下文，主 Agent 调度着调度着又自己下场改代码。设备只有一台，一条任务正在测键盘，另一条任务把机器重启了，这轮测试就白做了。

后来改成一个功能对应一个会话。接着做就先读这条线的记录，完成以后再合并改动。代码研究、日志分析可以并行，操作真机必须排好顺序。我也更容易看清哪条线卡住、什么时候需要自己配合。

提前明确项目规范

先调研、讨论路线，上游有的实现优先用。每次改代码用 Git 记录，完成一小块就提交，别等一堆功能混在一起，才发现不知道是哪次改坏的。

代码差异由 Git 保存，为什么这么改、如何验证、哪些实验失败过，写进文档。新 Agent 接手时，还要确认真机跑的是哪个版本，不能拿刚编译的代码去解释旧镜像的日志。

我不需要亲自看懂每一行驱动，但得能追溯它做过什么。不然会话一断，又把否决过的方案试一遍，时间和 token 全花在绕圈上。

规范也要分场景。临时验证假设，和制作正式安装包，需要的检查不一样。实验只改一项配置，就没必要顺手重建整套 Ubuntu；来源、运行版本和回退办法仍要核实。后期我经常让它检查，有没有重复验证，或者为了满足自己写的规则又造了一层东西。

让 Agent 自己完成构建和上机测试

最开始是它白天写代码，遇到需要验证的地方就等我。我回来按说明看屏幕、按键、听声音，再把结果告诉它。

效率很低，质量也不太行。有些问题它自己就能查出来，却等我试过以后才发现。一个晚上被叫去按几次键，第二天又来一轮，人也不可能一直守在旁边。

尤其是进入 Fastboot。早期有 ADB，可以让它自己切到测试环境；换成 Linux 后，软件进入 Fastboot 的路径没接好，得我手动操作。编译完没人按键，后面就全停住了。

还有过设备失联、我正好要出门的情况：

早期测试依赖人工恢复的对话记录

于是我让它先停下其他功能，把 Linux 自动进入 Fastboot 做出来。查到最后，问题在重启原因的写入：驱动按 4 字节写，本机对应的 NVMEM 单元只接受 1 字节，写入失败，Bootloader 就收不到正确的启动模式。

修好以后，正常情况下它可以自己完成一轮构建、启动和检查：

构建候选镜像 -> Linux 进入 Fastboot -> 临时启动
&nbsp; &nbsp; &nbsp; &nbsp;^ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|
&nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;USB 调试通道上线
&nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|
&nbsp; &nbsp; &nbsp; &nbsp;+------- 保存日志、判断结果 <--------+

失联或无法恢复时停止，保留已有日志
需要手、眼、耳确认的项目，集中安排人工验收

屏幕有没有异常、按键有没有响应、音量和音质怎么样，这些仍然我来测。它能自己检查的先做完，最后把需要人的项目列在一起，集中配合，比每做一点就喊我过去好太多。

不要让人类的参与成为 AI 的瓶颈，多想想你能为 AI 做什么。

通过追问和交叉审查排查问题

以前看到黑屏只知道是黑屏，现在至少会问：内核还活着吗，USB 有没有，渲染出的图已经坏了，还是输出到面板才出错？

第一性原理、奥卡姆剃刀、苏格拉底式追问、对抗性审查，这几个“咒语”我用得很多。具体就是让它拿出依据，把调用链查完整，解释为什么排除了其他可能。它陷在一个方向里时，我会追问：这个前提真的验证过吗，还有没有更简单的解释？

我不懂的实现，就让另一个 Agent 从反方向检查。有一轮显示候选在上机前被查出面板回调不完整，关屏可能调用空函数指针，当时就停掉了。

它说修好了，我还会问实际测到了哪里。节点出现、程序返回成功、屏幕正确，是不同程度的验证。听它解释这些差别，我也逐渐知道该看什么、该问什么。

不同模型的使用体会

这个项目需要反复读代码、编内核、上真机，没有一套针对这台设备的现成答案可以直接照着跑。我把手里能用到的几个顶尖模型基本都试了一遍。

Fable 5

Fable 5 是真的聪明。最难的触控和显示问题，GPT-5.6 来来回回试了很多轮都没解决，最后交给 Fable，三下五除二就搞定了。在这种难题上的智力确实很强。

但它的问题也很明显，就是不够严谨。第一次就没考虑好安全回滚，直接把机器搞挂，需要人工恢复。前期用 GPT-5.6 做的那些轮次，还没出现过这种情况。

还有额度太少，经常刚进入状态就用完了，后面就退订了。

GPT-5.6

GPT-5.6 同样是顶尖聪明，而且绝大多数活其实都是 GPT 干的。它最大的特点就是靠谱，想事情比较周全，改危险的东西之前会先考虑怎么回滚。

不过它有时候确实慢。一个问题来来回回对比、测试、改驱动，烧了巨量 token，还是卡在那里。做得越久，过度设计的问题也越明显：到处做一致性检查、写严格的校验，连临时实验也搞得很复杂。

GPT-6

后来换到 GPT-6，感觉好了很多，也解决了一些 GPT-5.6 反复卡住的问题。

它对复杂问题的建模能力很强。后期安装、回退和系统集成的事情越来越多，需要同时考虑几个部分，不能只盯着一处驱动改。哪些还需要查，哪些可以复用，哪里只改一个小地方就够了，它的判断更到位，没那么容易绕进一大堆额外工作里。

Kimi K3

一开始把 K3 接在 Claude Code 里，真觉得它有点笨，还没上真机，本地 QEMU 环境就失败了好几次。后来换成 Kimi Code，发现表现很不一样。

我又看了 K3 技术报告，它专门提到对思维历史的敏感性：训练时使用了保留思维历史的模式，运行它的 Agent 工具需要正确回传这些内容。报告推荐使用已验证兼容的工具，比如 Kimi Code，也提醒不要在会话中途从其他模型切到 K3。

K3技术报告中关于思维历史与Agent工具兼容性的说明

声音就是后来它解决的一个问题。GPT 已经让扬声器出声，但音量一直小。我反复反馈了好几次，强行放大以后又尖又薄，后来交给 Kimi 接着查。

响度最后是保留功放保护和本机校准，把仍有较大衰减的数字增益调到合适位置，才达到我的预期。至于“不如 Android 浑厚”，它还发现 DSP 用的是 Cirrus 默认调音，原厂有按四颗喇叭位置分别准备的调音文件，这部分还要继续适配。

同一个模型，换个运行它的工具，体验能差这么多，也挺有意思。

综合能力、稳定性和额度，我现在已经 ALL IN GPT，退订 Claude 了。

用量

让 AI 核对本地日志后，写稿时累计记录了 145.2 亿 token，跨度约 25 天。统计包含缓存读取在内的输入和输出，大部分来自多轮上下文读取。

| 客户端 | 累计记录的 token | | — | — | | Codex | 122.23 亿 | | Claude Code | 17.51 亿 | | Kimi Code | 5.46 亿 | | 合计 | 145.20 亿 |

感谢“Reset 之父” Tibo 不断重置额度，才能在这么短的时间里蹬这么多，把移植一直推下去。

最后

本次项目涉及到的所有安装包、设备适配、内核修改和构建工具都已经开源。想自己编译、改功能，或者接着修剩下的问题，可以从这两个仓库开始：

• github.com/yzddmr6/xiaomipad-6pro-mainline：设备配置、用户态适配、构建和安装工具、使用文档。
• github.com/yzddmr6/linux-sm8450-liuqin：内核源码和设备适配。

刷机前请先看安装指南，备份数据并核对支持的分区布局。当前只验证了已知的 256GB 布局，不能直接套到其他容量或改过分区的设备上。

感谢 sm8450-mainline、Linux Qualcomm、Freedreno 等社区已有的工作。感兴趣的朋友欢迎 Star，发现问题可以提 Issue，也欢迎一起修剩下的坑。

话说有 AI 真的是好起来了。想要的软件可以自己写，想看的图片、视频也可以自己生成，很多以前只能想想的东西，现在都能动手试一试。

这几年，一边使用 AI，一边看着它的能力边界被推开，也发现自己能做的事情比过去多了。曾经因为不会、因为一个人做不完而搁下的想法，又有了实现的可能。

有时间、有 token，就可以从一个想法出发，边做边学，一点点把它变成现实。AI 的进步让人兴奋，也因为它把更多创造的机会，交到了每一个有想法的人手里。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：熵减矩阵 yzddMr6 yzddMr6《150亿token：我给小米平板6 Pro移植了原生Linux》