Appearance
香橙派 5 Plus 折腾笔记
有一说一，看了下香橙派 5 Plus 的文档，虽然不如树莓派社区，但是还是比较齐全的（至少都能用）
由于这个玩意的 IO 相比树莓派强太多了，因此在考虑正经的把一些服务迁移到上面去
目前考虑通过 TF 卡的 UEFI(spi flash 也行?)启动系统，emmc 拿去直通或者当 hypervistor 的系统盘，M2 接入 2T 的 P41 做存储空间。两个 2.5G 的网卡则是做 bond。这样理论上能有 625MiB/S 的传输速度。wifi 的 pcie2.0x1 还可以拿去给 sata 扩展卡做 aib，不过这个多少有点丧心病狂了
软件方面考虑需要调用 gpu(游戏加速，云手机)和 npu(图像识别或者跑大模型?) ，可能无法直接使用 ESXi，而是使用 qemu 或者国内编译的 pve arm 版。似乎 pve 可以使用 sysfsdev 来直通 npu，不确定可靠性
日志
- 2024-01-16 有霉逼买了个一月后才能发货的期货，我不说是谁
- 2024-03-02 意外的到了，真的遥遥无期啊。我都做好拖到三月底的准备了
- 2024-03-16 差不多折腾完了，只能说生态还是不太行
- 2024-03-19 由于官方系统是安卓魔改，甚至包含了一个 ADB，所以我改回了 Armbian 的系统
写在 2024-07-01
香橙派折腾了这么久，目前已经进入承载应用的开发和维护期了，整体对这个板子还是非常满意的。并不是因为买了香橙派强说好，我一直是认为用户无论如何都是厂商的爹，任何一点不满意都要表达出来
除了一些设计上的小问题，如 5V4A 的供电上限导致无法带 nvme 的同时点亮 4K 显示器并驱动舵机（这得差不多 45W），m2 螺柱高度问题导致不方便使用硅脂散热外。香橙派 5 plus 的价格和设计都做到了开发板里的最优解，有相对便宜的 32g 版本，同容量的比其他家便宜。而且最关键的是把 3588 的拓展以一种非常合适的方式用尽了，三条 pcie3.0 分别给了两个 2.5g 网口和一个 m2 的 wifi 接口（可以扩展成 pcie）。视频和 usb 接口也基本上都拉全了
但是我这里并不是在吹香橙派十全十美，除了设计上的小瑕疵外。香橙派围绕着这个瑞芯微的这个 3588/3588s 芯片在螺狮壳里做道场，搞出来了一堆崽子：5 5b 5plus 5pro 5max 5ultra。一系列乱七八糟的型号里，5 plus 才是这个系列无法超越的巅峰(因为 3588 没阉割，5 plus 又拉的最全)，颇有一种管杀不管埋的感觉。尤其是点名批评配套的被动散热外壳，买了两个外壳铜柱都脱落了，散热效果也和没有一样。新出了个 3588s 的 cm5 也是一脉相承的神秘，内存 16g 的同时存储只有可怜的 32g 板载 emmc，载板也只有一个和 5 plus 差不多大小的大板，但是拉出来一个千兆、两个 2.5g 还有四个摄像头！如果载板是那种刚好覆盖 cm5（256g emmc），三网口、带点基础扩展然后给 cm5 加上一个散热片我觉得都好不少，非常适合当软路由或者集群计算节点（
等下，这玩意不就是友善 R6S 吗？，看了一圈，香橙派几乎所有方案都能在价格或性能超过竞品。橙子，你好强大）还有整体生态系统也不是很满意，虽然 armbian 还算好用，但是瑞芯微的研发力量和香橙派的社区支持不足导致香橙派的生态和树莓派完全没法比。3588 这个 soc 细数起来也是究极抽象，8nm 的三星工艺单核（a76@2.4ghz，实际 2.2，很难超频）还比不过 14nm 博通工艺（a76@2.4ghz，实际可超 3.0），npu 的 6t 算力更是由三个注水的 2t 算力的 npu 缝合，堪称乐色。这个离谱玩意用上万转风扇满载都会过热节流，装个 uefi 或者 win10 都会遇上一大堆兼容性问题。想要用上标准的 uefi 镜像或者至少是用上能驱动所有设备的官方的主线内核的镜像更是一件几乎不可能的事情
额外考虑加装的内容
- MC 服务器：懂的都懂，虽然半年不玩了。java 版的 MC 是只需要 JDK 有相应的架构支持就能运行的
- onlyoffice：似乎也没什么用，后续可能会做一定的二次开发。但是树莓派的 8g 内存不太够用了
- Space：
jetbrain 公司对标 github 的一站式开发产品，内存消耗大户。已成功耗死这个产品，笑死 - TeamCity：有必要专门在 gitea 之外专门搞一个 cicd 服务器吗？
- 本地数据库：mysql 和 minio 这类的数据库。实测树莓派用 USB SATA 固态的性能并不满足
- 游戏挂机：模拟器相比原生的效率太低了，增加的功耗完全可以换一个 arm 开发板来跑了
- 专用下载机：单个企业级机械的功耗就比 3588 高了，整几个消费级机械降点功耗试试
- 远程环境：目前能够远程访问的桌面环境只有 NAS，增加一个访问点用来做备份
稍微有点为了折腾而折腾了，其实很多功能不如直接买一个 NUC 13 Pro。虽然现有负载 + MC 服务器 + 安卓挂机等于 8+8+8=24g，但是 32g 的内存感觉还是略微超出需求了，尤其是在安卓 Docker 镜像无法启动需要的游戏的情况下。实际上的最大限制还是在 CPU，4x2.4g 的 A76 还是有点孱弱的
如果不像我一样追求把扩展压榨到极致的话，买一个树莓派或者是 8/16g 的香橙派 5 pro 会更合适一些。核心的性能基本一致，外设只剩一个 pcie2.0x1 和自带的千兆网，对于日常的负载而言，这个带宽给普通固态来说完全够用了
后面使用虚拟化的 win 镜像 + ARM 原生的 CPUZ 做了一个测试。根据以往对虚拟化程序的损耗的测试，基本和原生系统保持一致
CPUZ: 大核/小核/全核 230/61/1127。与这个分数类似的是 AMD 的 FX8300。正巧也是 8c8t 的推土机（CPU 的架构，非常的菜。所以当年 AMD 也被戏称为农企）
作为对比，入门的 12100 的分数是 660/3300，是 3588 的三倍，还支持 192G DDR5 和 28 条完整的 pcie4.0。而我的 13900KS 的 cpuz 分数接近 1000/500/17000，光是一个大核分数就和 3588 全核差不多了
- 迁移前的摸底测试
- [x] 系统稳定性检测：虽然芯片体质不太好，但是保证散热和供电没问题的情况下稳定性还是可以的
- CPU 压力测试：更换全金属盔甲和高等级风扇勉强 80 度，好在足够稳定
- GPU 压力测试：测试了一下 GPU 跑 3D Mark 测试，有接近 14W 的负载。稳定性和有良好散热的桌面级平台一样
- MEM 压力测试：stress 和 memtest86 通过
- NVME 压力测试：fio 4k 深队列随机写入可以维持 1500MB/S
- [x] 系统依赖检查：开发板的各类驱动想要移植是真的太难了啊，很可能必须用官方的镜像了
- OPI Debian：自编译 kernel 6.1，除了 CAN 总线基本全功能支持
- Armbian：瑞芯微 Kernel 5.10，支持基本功能
- UEFI Debian12：似乎不支持 GPU 和 NPU
- [x] GPU 依赖检查：太麻烦了，放弃移植驱动到发行版官方内核了
- redroid: GPU 加速需要 Mali G610 驱动，同时只能用瑞芯微的 5.10 内核。新的 panthor/panforst 比较难搞
- LLM：需要 GPU 驱动
- [ ]
NPU 依赖检查：移植难度太大，直接似了。反正就 YOLO 可能用到，还是非必须 - [x] 网络设备检查：AX210 几乎都免驱，太感动了
- 双 2.5G 网口聚合：单口测试跑了 5T 数据都没有问题，平均速度大于 2.3gbps，这个数据和其他平台的表现一致。多口聚合是基础功能，懒得测试了
- WIFI 测试：虽然无法接上太好的天线，但是稳定性还是可以的
- [x] 系统稳定性检测：虽然芯片体质不太好，但是保证散热和供电没问题的情况下稳定性还是可以的
折腾前的准备
其实最重要的问题是要有心理准备，香橙派这种开发板如果只是想跑起来那非常简单，但是如果想把它玩明白，那就要折腾非常多。树莓派累计出货了 4600 万台，香橙派能有到它的零头(百万)就不错了。虽然香橙派在国外也有一些知名度，但生态和树莓派那种可以挑三拣四的积累没得比
虽然一直嘲笑勃砼(博通)的东西比起其他家是大火炉，但是和在机顶盒领域都是弟中之弟的瑞芯微比，半导体领域比三星（艹，3588 还真是三星代工）排名靠前，能做 800G 交换机和 PCIE5.0 Switch 的博通那是真的老大哥 Pro Plus Max Ultra
简单介绍一下瑞芯微的这个 3588，8nm 工艺，搭载四核 A76+四核 A55 的八核 CPU，Mali 610 的 GPU，内置 6T 算力的 NPU、一个 PCIe3.0x4 通道、三个 SATA/PCIe2.0x1 复通的通道。USB、emmc 之类的意义不大的东西我就不说了
然后 3588 的 CPU 分配是 A55 四个核一个簇(0-3)，A76 每两个核一个簇(4-5,6-7)。和 Intel 的大核在前正好相反，这样子性能会有问题，因为很多任务是写死 CPU0 的，只能跑在小核
找到了一份 Rock5B 的 CPUIO 分配图，非常齐全。注意这不是香橙派的，只是用来看 3588 有什么接口！
香橙派没有 PD 协商，把 rock5b 拿来做 usb3.0 的通道拿去给 2.5g 网卡了
折腾 3588 前需要预先准备一些东西。如果上了固态，一定要买一个 5V4A 的电源，很多问题都是电源导致的！
- SD 卡、EMMC、固态 U 盘，NVME。用来装系统的存储介质。最好有 NVME，性能对其他介质是降维打击，而且 3588 也带得起来这么高的 IO
- 一个至少能输出 5V4A 的非快充优质充电器，和 C 口的供电线。虽然我固态顺序读写、CPU 网口满载进行压力测试 5V3A 的也撑得住
- USB3.0 的拓展坞，最好能同时兼容 A 口和 C 口，用来避免兼容问题
- 购买一个主动散热器或者是带散热器的外壳，被动散热对于动不动 10W 的发热完全压不住。同时为 NVME 准备莱德尔 90000 导热垫(足够柔软且便于散热)
- 串口链接能看到很多信息，非常方便。建议买一个 usb 转 ch340 的线，然后使用 mobaxterm 链接串口
- 如果准备使用 M2 固态的话，需要准备一个 M3 内径，0.5mm 厚度的尼龙/金属垫圈，还有柔软的导热垫（莱德尔 90000 效果比较好）。使用金属外壳时，可以使用 1.5mm 厚的导热垫把热量导出到外壳底面，效果很好
- 效果最好的金属铠甲外壳也就只能把 3588 压到不降频而已，如果想要能够把温度不会降频，可以买一个 3010 的 5v 双滚珠风扇，转速在 5000-9000 就行。固定螺丝的规格是 15mm 的 m3 螺丝，再买点垫片垫高通风降低一点风噪。如果要使用 PWM 调速，需要系统支持 GPIO 并购买 xh1.25mm 的接口，直接全速运行就买两个杜邦线母头的那种接口即可
香橙派的硬件
我把官方的硬件参数说明存了一份下来，这个介绍还是很齐全的
| 条目 | 说明 |
|---|---|
| 主控芯片 | Rockchip RK3588(8nm LP 制程） |
| CPU | • 8 核 64 位处理器 • 4 个 Cortex-A76 和 4 个 Cortex-A55 及独立的 NEON 协处理器 • Cortex-A76 主频 2.4GHz，Cortex-A55 主频 1.8GHz |
| GPU | • 集成 ARM Mali-G610 • 内置 3D GPU • 兼容 OpenGL ES1.1/2.0/3.2、OpenCL 2.2 和 Vulkan 1.2 |
| NPU | 内嵌的 NPU 支持 INT4/INT8/INT16/FP16 混合运算，算力高达 6Top |
| PMU | RK806-1 |
| RAM | 4GB/8GB/16GB/32GB （LPDDR4/4x） |
| 存储 | • QSPI Nor FLASH: 16MB/32MB • MicroSD 卡插槽: up to 128GB • eMMC 闪存插座，可外接 16GB/32GB/64GB/128GB/256GB eMMC 模块 • 用于 NVMe SSD (PCIe 3.0 x4) 的 M.2 2280 插槽高达 2,000 MB/s |
| USB | 2xUSB3.0； 2xUSB2.0； 1xType-C |
| 视频输出 | • 2x HDMI 2.1 输出，高达 8K@60FPS • 1x Type-C（DP 1.4A）输出，高达 8K@30FPS • 1x HDMI 输入，高达 4K@60FPS • 1 x MIPI DSI 4 Lane 输出，高达 4K@60Hz |
| TP 接口 | 1x6Pin FPC 插座 |
| 摄像头 | 1xMIPI CSI 4 Lane |
| 音频 | CODEC:ES8388 • 1x3.5mm 耳机孔音频输入/输出 • 1xMIC 输入 • 1xHDMI 2.1 eARC • 1x 扬声器 |
| 以太网 | 2xPCIe 2.5G LAN（RTL8125BG) |
| 扩展口 | 40Pin 双排插针，具有以下复用功能： UART、 I2C、SPI、 CAN、I2S、PDM、AUDDSM、SDIO、PWM、GPIO。 |
| PCIe M.2 M-KEY Socket | M.2 connector M key (bottom) for NVMe with PCIe 3.0 x4 lanes 2280 SSD 固态硬盘 |
| PCIe M.2 E-KEY Socket | M.2 connector E key (top) for connectivity with PCIe 2.0 x1/PCM/UART/USB2.0，支持 2230 Wi-Fi6 /BT 模块 |
| 按键 | 1x MaskROM 键，1xRECOVERY，1x 开关机键 |
| 供电 | 支持 Type-C 供电，5V@4A |
| 红外接收器 | 1x 红外接收管 |
| LED | RGB LED 侧发光 |
| FAN | 5V FAN |
| RTC | 2PIN：RTC 备用电池 |
| 调试 | 3Pin 调试串口（UART） |
| 支持的操作系统 | Orangepi OS（Droid）、Orangepi OS（Arch）、Orangepi OS（OH）、Ubuntu22.04、Debian11、Android12 |
后面我检查了一下官方的兼容性列表，发现这里面居然还有硬件看门狗。虽然几乎不会用到，但是这个拓展完全可以说一句应有尽有了
香橙派 5 plus 对 3588 的通道分配我认为是非常合理的，3.0x4 给 M.2 Nvme，然后三个 2.0x1 分别给了无线网卡和两个 2.5g 网卡。有三个 HDMI 接口，一个可以输入做采集用，剩下的两个其中一个可以输出 8K，一个可以输出 4K。有两个 USB 2.0，两个 USB 3.0 A 口和一个 USB 3.0 C 口(带 DP 显示输出)，甚至还有红外接收器！这个扩展砍掉一半都把树莓派 5 按在地上反复摩擦
但是也不是没有不好的地方，比如说供电是直接走的 5V4A，没有 PD，这也就导致了需要采用非快充的充电头，否则有可能握手有问题(实测 5V3A 也能凑合)。当然，用了 PD 的 Rock 5b 也有 PD 兼容性的问题，也需要选择充电头，armbian 还提示很多发行版的 PD 协议损坏，最好改成 5V 固定电压供电..., 各有问题吧。实测香橙派也需要考虑充电器兼容性，最好还是购买无快充的充电头，否则也可能握不上手，或者功率高了被断电
香橙派 5 Plus 20W 的供电上限和其他家开发板的 30W 还是相差甚远，也没有 POE 之类方便一线通的供电方式。但是看在香橙派 32G 内存比别家 16G 内存还便宜，扩展也更多的情况下，这并不是特别大的问题（注：购买树莓派同款的 5V5A 充电头只要 30）
到手后的摸底测试
先在 U 盘上写了个 Armbian 镜像，测试了一下硬件是否存在问题
补充！
测试了一下，只用 5V3A 的供电的话存在严重的问题。在散热良好的情况下，3588 待机功耗 7W（都是插座端，效率可能有 85%），单烤 CPU 整机功耗就达到了最高 16W，P41 做 4K 多线程深队列写入（大核满载） 20W。整机功耗完全有能力达到 30W 乃至是 40W（GPIO 的电源输出、和摄像头、edp 驱动和大功率 USB 设备也需要耗电）
建议不要使用 USB 接口为移动硬盘和拓展坞供电，不要的设备尽可能全部拔掉，比如 SSH 时可以把接收器和 HDMI 拔了
作为预期的高性能中控节点，如果按照预期的把 20 个容器、常驻数据库、MC 服务端、手游挂机迁移到主机上，再把长期 500 Mbps 的视频采集转码以及 NPU 的识别加速部署上去。大核全部满载，磁盘高压力都很正常
但是压力测试的场景日常使用也只有极少数场景会遇到，而且由于 3588 是 SOC 设计，CPU、NPU、GPU 共享相同的总功耗（如果一起运行甚至会更容易达到温度上限而降频，功耗反而低了）。所以考虑要耗电的设备其实只有 SOC+网卡+固态，全满载 20W 的电源输入可以满足。但是像是 GPIO、edp、csi、dsi 等接口如果还想输出功率那就可能不够了，我还是想接入一些摄像头、采集卡和舵机云台做全机房设备集成显示和监控的
使用插座功率计记录了一下各个部件满载增加的功率，可以作为功耗参考
- 插上固态后系统待机：6W
- 大核满载：6W
- 小核满载：1W
- NVME 满载：7W
- 单个网卡满载：0.25W
- EDP 显示屏：10W(便携显示器)
- 外壳风扇: 0.5W
- 自购 3010 万转风扇: 1.2W
意料之外的问题
- 3588 是真的热啊，虽然听上去就 10w 左右的 TDP，手机的散热模组都能压。但是根据测试结果，需要一个正经的散热器。像是那种塞一个 1cm 厚的导热垫的这种糊弄事的散热器很容易高负载下过热，换成万转风扇也会温度突破 80 度。好在有南桥散热器规格的孔位，官网现在也在推这个散热器
- 抽到的这个处理器是真的霉逼，3588 号称大核能 2400 MHz，但是实际上工艺水平不稳定，瑞芯微用的是 pvtm 管理实际频率，等级分为(0-7,对应 2256-2400MHz)，我这两个大核的簇只有 3-4(2200/2250 MHz 的频率)，算是大雷。也许换了散热器后可以尝试超频（后面发现 pmtv 很麻烦，得改 dtb）
- ARM 的 IO 能力也是真的抠脚，我的 NAS 上在虚拟机里操作一个次一级的 PCIe4.0 固态(写入 2G/S，P41 缓内写入 6G/S) DD 大文件能有 1.6G，3588 只有 800M。好在 fio 测试，还是可以跑满 3.0x4 的带宽
- 各个系统对于设备的适配不一致，很有可能选择的系统没有 USB2.0/3.0 的驱动，这就有个巨大的问题。可能你的键鼠需要接入一个 USB3.0 的拓展坞，或者是 USB 硬盘 只能插在 2.0 的接口
如果更换 3010 的 5v 风扇(CFM 3.6)，是可以把满载 stress cpu 的温度从 84 度的略微降频变成 70 度顶着功耗上限运行，但是要注意，风扇不用买万转的，太吵了！
软件兼容性方面也有坑
- UEFI 驱动有半年没更新了，可能需要去 Github 仓库的 Action 里下载最新的 nightly 版本的固件来修复 BUG。甚至不一定能修复
- RK3588 恐怖的 IO 设备数量也带来了恐怖的适配难度。如果想要使用标准 uefi 启动镜像，那要做好比普通主机多出来的接口全不能用的心理准备(emmc、edp、dsi 等)
当前瑞芯微提供支持(NPU)的内核是 5.10/6.1（6.1 的社区驱动还没适配），香橙派官方编译最新的镜像内核是 6.1(Debian 12)。6.8 内核已经正式 release 了，提供了 HDMI IN 功能的支持，Linux 的官方 GPU 驱动得到 6.10 了。而 3588 开发板 22 年底就批量铺货了，如果想要 GPU 稳定可用，估计得等到 24 年底了
2019 年瑞芯微在春季发布 3588 的计划图，预计 2020 年一季度发布，然后跳票到 2021 年底，2022 年底大量铺货。此时骁龙 8gen2 都发布了。本来就拖了很久才生产出来，品控还不稳定。8nm 的 A76@2.4GHz（实际 2.2 左右）打树莓派的 16nm A76@2.4GHz（可以艹到 2.6，后期稳 2.6，艹 2.8）单核都打不过。硬生生的把一手好牌打得稀烂，还不如学 nvidia 的 orin 换个 A78 的大核
另附：最近跟进了下相关内容，瑞芯微在 23 年 Q4 提供了 6.1 内核的更新，速度不算太慢。但是社区驱动这些还没有适配 6.1，比如 GPU 驱动和一些配套镜像的代码。不过主线代码支持似乎一直有
在找瑞芯微的内核的时候意外的看到了知乎对瑞芯微的评价，其中包括了内部没有成文的规章制度、老板拖欠工资、老员工因为吃到了上市红利所以人浮于事等问题。嗯，怎么说呢，很符合我对国产作坊的想象(对管理方式的统称)。认识的一些做 AI 的朋友也对瑞芯微的芯片评价不高
瑞芯微的内核是自己魔改过的类安卓内核，在安全和通用性上存在问题。6.1 之后的新内核则是从主线 fork 的，安全性提升了不少。但是 Debian 无法直接启动 dtb 模式，需要研究下如何使用 dtb 模式启动
测试记录
先来跑个自带的 sbc-bench 看看，复制过来发现太长了，接近 1200 行。我只截取了比较重要的部分并添加了些注释
bash
# 系统当前状态
Status of performance related governors found below /sys (w/o cpufreq):
dmc: performance / 2112 MHz (rknpu_ondemand dmc_ondemand userspace powersave performance simple_ondemand / 528 1068 1560 2112)
fb000000.gpu: simple_ondemand / 300 MHz (rknpu_ondemand dmc_ondemand userspace powersave performance simple_ondemand / 300 400 500 600 700 800 900 1000)
fdab0000.npu: rknpu_ondemand / 300 MHz (rknpu_ondemand dmc_ondemand userspace powersave performance simple_ondemand / 300 400 500 600 700 800 900 1000)
sbc-bench v0.9.64
Results validation:
* Advertised vs. measured max CPU clockspeed: -3.9% before, -4.7% after -> https://tinyurl.com/32w9rr94
* Background activity (%system) OK
* No throttling
# 内存性能测试，测试了大小核的三个簇
Memory performance (all 3 CPU clusters measured individually):
memcpy: 6677.4 MB/s (Cortex-A55)
memset: 21676.6 MB/s (Cortex-A55)
memcpy: 12074.3 MB/s (Cortex-A76)
memset: 29732.6 MB/s (Cortex-A76)
memcpy: 12267.4 MB/s (Cortex-A76)
memset: 29545.0 MB/s (Cortex-A76)
# 7-zip测试分数
7-zip total scores (3 consecutive runs): 16192,16369,16287, single-threaded: 3120
# OpenSSL测试分数
OpenSSL results (all 3 CPU clusters measured individually):
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 154242.10k 461033.90k 906364.84k 1207234.90k 1335869.44k 1346180.44k (Cortex-A55)
aes-128-cbc 597969.10k 1230754.65k 1614263.64k 1740175.70k 1790896.81k 1796303.53k (Cortex-A76)
aes-128-cbc 603944.42k 1246063.98k 1634928.90k 1762499.93k 1814227.63k 1819656.19k (Cortex-A76)
aes-192-cbc 146903.45k 411204.48k 741911.38k 931708.93k 1005816.49k 1011591.85k (Cortex-A55)
aes-192-cbc 562396.50k 1107877.48k 1378774.61k 1452938.24k 1495228.42k 1498136.58k (Cortex-A76)
aes-192-cbc 569357.15k 1121656.34k 1396361.98k 1473024.68k 1514487.81k 1517540.69k (Cortex-A76)
aes-256-cbc 142854.01k 378533.78k 641382.57k 778625.71k 830114.47k 834267.82k (Cortex-A55)
aes-256-cbc 553813.29k 986681.07k 1195845.89k 1258682.03k 1281982.46k 1284429.14k (Cortex-A76)
aes-256-cbc 560697.79k 999045.91k 1211211.01k 1273202.69k 1298516.65k 1300987.90k (Cortex-A76)
# 一些系统信息
Unable to upload full test results. Please copy&paste the below stuff to pastebin.com and
provide the URL. Check the output for throttling and swapping please.
sbc-bench v0.9.64 Orange Pi 5 Plus (Sun, 17 Mar 2024 16:03:14 +0800)
Distributor ID: Debian
Description: Armbian 24.2.1 bookworm
Release: 12
Codename: bookworm
Build system: https://github.com/armbian/build, 24.2.1, Orange Pi 5 Plus, rockchip-rk3588, rk35xx
/usr/bin/gcc (Debian 12.2.0-14) 12.2.0
Uptime: 16:03:14 up 2 days, 16:20, 2 users, load average: 1.09, 1.06, 1.03, 47.2°C, 86294460
Linux 5.10.160-legacy-rk35xx (orangepi5-plus) 03/17/24 _aarch64_ (8 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
7.17 0.00 2.76 0.38 0.00 89.69
Device tps kB_read/s kB_wrtn/s kB_dscd/s kB_read kB_wrtn kB_dscd
mmcblk0 2.07 0.02 1054.62 0.00 4352 244277248 0
mmcblk1 0.00 0.01 0.00 0.00 3304 0 0
nvme0n1 26.66 843.47 1520.01 0.00 195369172 352072492 0
total used free shared buff/cache available
Mem: 31Gi 949Mi 30Gi 19Mi 183Mi 30Gi
Swap: 0B 0B 0B
# 接下来的都是测试细项，没什么好说的
##########################################################################
Executing benchmark on cpu4 (Cortex-A76):
tinymembench v0.4.9-nuumio (simple benchmark for memory throughput and latency)
CFLAGS:
bandwidth test min repeats (-b): 2
bandwidth test max repeats (-B): 3
bandwidth test mem realloc (-M): no (-m for realloc)
latency test repeats (-l): 3
latency test count (-c): 1000000
==========================================================================
== Memory bandwidth tests ==
==========================================================================
C copy backwards : 11633.4 MB/s (2)
C copy backwards (32 byte blocks) : 11614.9 MB/s (3, 0.3%)
C copy backwards (64 byte blocks) : 11614.6 MB/s (2)
C copy : 11864.5 MB/s (2)
C copy prefetched (32 bytes step) : 12150.7 MB/s (3, 1.0%)
C copy prefetched (64 bytes step) : 12170.4 MB/s (2)
C 2-pass copy : 3881.0 MB/s (2)
C 2-pass copy prefetched (32 bytes step) : 5563.7 MB/s (2)
C 2-pass copy prefetched (64 bytes step) : 7132.2 MB/s (3, 1.2%)
C scan 8 : 1120.6 MB/s (2)
C scan 16 : 2239.3 MB/s (2)
C scan 32 : 4472.3 MB/s (2)
C scan 64 : 8908.4 MB/s (2)
C fill : 29729.2 MB/s (3, 0.6%)
C fill (shuffle within 16 byte blocks) : 29728.1 MB/s (2)
C fill (shuffle within 32 byte blocks) : 29704.1 MB/s (3, 0.6%)
C fill (shuffle within 64 byte blocks) : 29629.7 MB/s (3, 2.4%)
---
libc memcpy copy : 12074.3 MB/s (2)
libc memchr scan : 16184.0 MB/s (2)
libc memset fill : 29732.6 MB/s (3, 1.4%)
---
NEON LDP/STP copy : 12107.4 MB/s (2)
NEON LDP/STP copy pldl2strm (32 bytes step) : 12074.0 MB/s (3, 0.4%)
NEON LDP/STP copy pldl2strm (64 bytes step) : 12085.2 MB/s (3, 1.2%)
NEON LDP/STP copy pldl1keep (32 bytes step) : 12087.8 MB/s (2)
NEON LDP/STP copy pldl1keep (64 bytes step) : 12084.1 MB/s (2)
NEON LD1/ST1 copy : 12056.2 MB/s (2)
NEON LDP load : 18588.8 MB/s (2)
NEON LDNP load : 17754.2 MB/s (2)
NEON STP fill : 29642.3 MB/s (3, 3.3%)
NEON STNP fill : 29718.5 MB/s (2)
ARM LDP/STP copy : 12086.8 MB/s (2)
ARM LDP load : 18204.1 MB/s (2)
ARM LDNP load : 17120.1 MB/s (2)
ARM STP fill : 29702.6 MB/s (3, 0.5%)
ARM STNP fill : 29553.2 MB/s (3, 2.0%)
==========================================================================
== Memory latency test ==
== ==
== Average time is measured for random memory accesses in the buffers ==
== of different sizes. The larger is the buffer, the more significant ==
== are relative contributions of TLB, L1/L2 cache misses and SDRAM ==
== accesses. For extremely large buffer sizes we are expecting to see ==
== page table walk with several requests to SDRAM for almost every ==
== memory access (though 64MiB is not nearly large enough to experience ==
== this effect to its fullest). ==
==========================================================================
block size : single random read / dual random read
1024 : 0.0 ns / 0.0 ns
2048 : 0.0 ns / 0.0 ns
4096 : 0.0 ns / 0.0 ns
8192 : 0.0 ns / 0.0 ns
16384 : 0.0 ns / 0.0 ns
32768 : 0.0 ns / 0.0 ns
65536 : 0.1 ns / 0.0 ns
131072 : 1.3 ns / 1.6 ns
262144 : 2.7 ns / 2.9 ns
524288 : 5.9 ns / 7.0 ns
1048576 : 12.5 ns / 13.5 ns
2097152 : 18.1 ns / 17.8 ns
4194304 : 40.4 ns / 57.2 ns
8388608 : 80.2 ns / 106.3 ns
16777216 : 102.2 ns / 123.5 ns
33554432 : 113.5 ns / 130.0 ns
67108864 : 120.3 ns / 133.6 ns
##########################################################################
# 测试真实频率，两个大核基本和2400MHz的标称频率比起来都少了150MHz
Testing maximum cpufreq again, still under full load. System health now:
Time cpu0u4u6 load %cpu %sys %usr %nice %io %irq Temp
16:18:19: 1800/2352/2352MHz 8.01 79% 1% 77% 0% 0% 0% 70.2°C
Checking cpufreq OPP for cpu0-cpu3 (Cortex-A55):
Cpufreq OPP: 1800 Measured: 1772 (1772.460/1772.326/1771.948) (-1.6%)
Checking cpufreq OPP for cpu4-cpu5 (Cortex-A76):
Cpufreq OPP: 2352 Measured: 2242 (2243.821/2242.675/2241.866) (-4.7%)
Checking cpufreq OPP for cpu6-cpu7 (Cortex-A76):
Cpufreq OPP: 2352 Measured: 2272 (2272.560/2272.332/2272.133) (-3.4%)
##########################################################################
# 内存频率测试，基本上都工作在4224MHz
DRAM clock transitions since last boot (232554170 ms ago):
/sys/devices/platform/dmc/devfreq/dmc:
From : To
: 528000000106800000015600000002112000000 time(ms)
528000000: 0 0 0 2432280 22904363
1068000000: 6852 0 0 61234 560666
1560000000: 0 0 0 0 0
*2112000000: 2425428 68086 0 0 209086403
Total transition : 4993880
##########################################################################
# 调了两个比较高温的测试项目，温度表现还好
Thermal source: /sys/class/hwmon/hwmon0/ (soc_thermal)
System health while running tinymembench:
Time cpu0u4u6 load %cpu %sys %usr %nice %io %irq Temp
16:05:31: 1800/2352/2352MHz 1.91 15% 2% 6% 0% 0% 0% 48.1°C
16:08:32: 1800/2352/2352MHz 2.02 12% 0% 12% 0% 0% 0% 60.1°C
System health while running 7-zip multi core benchmark:
Time cpu0u4u6 load %cpu %sys %usr %nice %io %irq Temp
16:15:55: 1800/2352/2352MHz 2.05 15% 2% 6% 0% 0% 0% 57.3°C
16:18:19: 1800/2352/2352MHz 8.01 79% 1% 77% 0% 0% 0% 70.2°C
##########################################################################
SoC guess: Rockchip RK3588 (35881000)
DMC gov: performance (2112 MHz)
DT compat: rockchip,rk3588-orangepi-5-plus
rockchip,rk3588
Compiler: /usr/bin/gcc (Debian 12.2.0-14) 12.2.0 / aarch64-linux-gnu
Userland: arm64
Kernel: 5.10.160-legacy-rk35xx/aarch64
CONFIG_HZ=300
CONFIG_HZ_300=y
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_PREEMPT_VOLUNTARY=y
cpu cpu0: leakage=11
cpu cpu0: pvtm=1448
cpu cpu0: pvtm-volt-sel=2
cpu cpu4: leakage=9
cpu cpu4: pvtm=1658
cpu cpu4: pvtm-volt-sel=3
cpu cpu6: leakage=10
cpu cpu6: pvtm=1674
cpu cpu6: pvtm-volt-sel=3
mali fb000000.gpu: leakage=15
rockchip-dmc dmc: leakage=36
rockchip-dmc dmc: leakage-volt-sel=1
RKNPU fdab0000.npu: leakage=8
##########################################################################
# 没什么用的说明，这里提示了这个内核是瑞芯微混合了安卓进行编译的模型
Kernel 5.10.160 is not latest 5.10.212 LTS that was released on 2024-03-06.
See https://endoflife.date/linux for details. It is somewhat likely that
a lot of exploitable vulnerabilities exist for this kernel as well as many
unfixed bugs.
But this version string doesn't matter since this is not an official LTS Linux
from kernel.org. This device runs a Rockchip vendor/BSP kernel.
This kernel is based on a mixture of Android GKI and other sources. Also some
community attempts to do version string cosmetics might have happened, see
https://tinyurl.com/2p8fuubd for example. To examine how far away this 5.10.160
is from an official LTS of same version someone would have to reapply Rockchip's
thousands of patches to a clean 5.10.160 LTS.
##########################################################################
Results validation:
* Advertised vs. measured max CPU clockspeed: -3.9% before, -4.7% after -> https://tinyurl.com/32w9rr94
* Background activity (%system) OK
* No throttling
Status of performance related governors found below /sys (w/o cpufreq):
* dmc: performance / 2112 MHz (rknpu_ondemand dmc_ondemand userspace powersave performance simple_ondemand / 528 1068 1560 2112)
* fb000000.gpu: simple_ondemand / 300 MHz (rknpu_ondemand dmc_ondemand userspace powersave performance simple_ondemand / 300 400 500 600 700 800 900 1000)
* fdab0000.npu: rknpu_ondemand / 300 MHz (rknpu_ondemand dmc_ondemand userspace powersave performance simple_ondemand / 300 400 500 600 700 800 900 1000)
Status of performance related policies found below /sys:
* /sys/devices/platform/fb000000.gpu/power_policy: [coarse_demand] always_on
* /sys/module/pcie_aspm/parameters/policy: [default] performance powersave powersupersave
| Orange Pi 5 Plus | ~2290 | 5.10 | Ubuntu 12 (bookworm) tampered by Armbian 24.2.1 bookworm arm64 | 16280 | 3120 | 1300990 | 12270 | 29730 | - | |以下是 unixbenchmark 的结果
bash
Benchmark Run: Sun Mar 17 2024 17:24:19 - 17:52:20
0 CPUs in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 35008241.9 lps (10.0 s, 7 samples)
Double-Precision Whetstone 6433.0 MWIPS (9.9 s, 7 samples)
Execl Throughput 3343.4 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 523829.5 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 151520.3 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 1265305.6 KBps (30.0 s, 2 samples)
Pipe Throughput 1149132.2 lps (10.0 s, 7 samples)
Pipe-based Context Switching 90836.2 lps (10.0 s, 7 samples)
Process Creation 2281.5 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 3603.7 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 2412.6 lpm (60.0 s, 2 samples)
System Call Overhead 1152655.6 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 35008241.9 2999.8
Double-Precision Whetstone 55.0 6433.0 1169.6
Execl Throughput 43.0 3343.4 777.5
File Copy 1024 bufsize 2000 maxblocks 3960.0 523829.5 1322.8
File Copy 256 bufsize 500 maxblocks 1655.0 151520.3 915.5
File Copy 4096 bufsize 8000 maxblocks 5800.0 1265305.6 2181.6
Pipe Throughput 12440.0 1149132.2 923.7
Pipe-based Context Switching 4000.0 90836.2 227.1
Process Creation 126.0 2281.5 181.1
Shell Scripts (1 concurrent) 42.4 3603.7 849.9
Shell Scripts (8 concurrent) 6.0 2412.6 4021.0
System Call Overhead 15000.0 1152655.6 768.4
========
System Benchmarks Index Score 972.9在硬件设计上，香橙派 5 Plus 也有些瑕疵。M2 硬盘位是倾斜的，固定端比接口矮了 1mm，这就导致了上 nvme 的时候无法使用散热垫(没有变厚度的导热垫)，需要使用一个 m3 的垫圈垫高。最好使用莱德尔 90000 这种非常柔软的硅胶垫来避免对压弯固态 PCB 板
测试时光是 dd 一个大文件顺序读写，P41 在室温 20 度的时候就飙到了 80 度，撞上了温度墙。而我找到的所有外壳都没有考虑这个问题，也没法直接加成品 M2 散热器(没有那么大的空间)
随手找了个金属螺丝刀盒压了上去，甚至硅脂都没用，效果居然意外的不错。fio 最高压力 4K 多线程写入把盘写满也就最高温度 70 度
用莱德尔 90000 把硬盘的热量导出到外壳底部的铝板后，4k 多线程深队列读取跑满 3100MB/S 的最终温度也只有 70 度
P41 在 FIO 测试的时候硬盘温度会到 84 度，写入速度从 3200MB/S 掉到 1200MB/S。不过这是一个非常极端的长时间 4k 多线程深队列写入。如果只是从外部输入，3588 的两个 2.5g 网口加起来都没法写入这么多
bash
fio -filename=/dev/nvme0n1 -direct=1 -iodepth 32 -thread -rw=randwrite -ioengine=libaio -bs=4k -size=100G -numjobs=16 -runtime=3600 -group_reporting -name=test硬盘读取测试，win 下是找的测试(7900X+CDM)，linux 下是用的 fio。arm 机器 4K 多线程随机写入实际也能跑满 3.0x4 的带宽，750k IOPS。即使是过热了也有 300k IOPS
补充：在将系统安装到 NVMe 后，测试读写速度有一定降低。fio 测试裸磁盘的性能会比倒了一手文件系统更快，可以考虑换成性能更高的文件系统，但是 Ext4 降低的幅度也不算多
| 项目(MB/S) | X64 读 | X64 写 | ARM 读 | ARM 写 | 实际读 | 实际写 |
|---|---|---|---|---|---|---|
| SEQ1M Q8T1 | 7127 | 6744 | 3151 | 3072 | 3127 | 3069 |
| SEQ128K Q32T1 | 7131 | 6763 | 3148 | 3049 | 3120 | 2974 |
| RND4K Q32T16 | 5842 | 2018 | 3084 | 2038 | 2490 | 1461 |
| RND4K Q1T1 | 68 | 335 | 71 | 231 | 68 | 166 |
测试一下官方送的 emmc，系统内显示大小 232g。FIO 空盘读取 320MB/S，写入 274MB/S。满盘读取不变，写入 26MB/S，4K 多线程读取只有 15MB/S，4k IOPS，但是 4k 单线程能有 40MB/S 10k IOPS，很奇怪
这速度确实是菜的不行，可惜 3588 不支持 ufs（但增加高速通道也要成本，不如直接给 PCIe）。emmc 对上 ufs 就像是 SATA 对上 NVME，被吊锤
bash
root@armbian:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 1 57.3G 0 disk
├─sda1 8:1 1 256M 0 part /boot
└─sda2 8:2 1 56.5G 0 part /var/log.hdd
/
mtdblock0 31:0 0 16M 0 disk
mmcblk0 179:0 0 233G 0 disk
mmcblk0boot0 179:32 0 4M 1 disk
mmcblk0boot1 179:64 0 4M 1 disk
zram0 254:0 0 15.5G 0 disk [SWAP]
zram1 254:1 0 50M 0 disk /var/log
nvme0n1 259:0 0 1.8T 0 disk使用 lspci 看不到多少 pcie 设备，这个比较可惜。这么看 ESXi 只能直通固态、两个板载网卡还有 WiFi 网卡位置的 PCIe 2.0x1，3588 强大的 GPU 和 NPU 以及其他 IO 被完全浪费了
bash
root@armbian:~# lspci -nnk
0000:00:00.0 PCI bridge [0604]: Rockchip Electronics Co., Ltd RK3588 [1d87:3588] (rev 01)
Kernel driver in use: pcieport
0000:01:00.0 Non-Volatile memory controller [0108]: SK hynix Platinum P41 NVMe Solid State Drive 2TB [1c5c:1959]
Subsystem: SK hynix Platinum P41/PC801 NVMe Solid State Drive [1c5c:1959]
0002:20:00.0 PCI bridge [0604]: Rockchip Electronics Co., Ltd RK3588 [1d87:3588] (rev 01)
Kernel driver in use: pcieport
0002:21:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6 AX210/AX211/AX411 160MHz [8086:2725] (rev 1a)
Subsystem: Intel Corporation Wi-Fi 6 AX210 160MHz [8086:0024]
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
0003:30:00.0 PCI bridge [0604]: Rockchip Electronics Co., Ltd RK3588 [1d87:3588] (rev 01)
Kernel driver in use: pcieport
0003:31:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller [10ec:8125] (rev 05)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller [10ec:8125]
Kernel driver in use: r8125
Kernel modules: r8169, pgdrv
0004:40:00.0 PCI bridge [0604]: Rockchip Electronics Co., Ltd RK3588 [1d87:3588] (rev 01)
Kernel driver in use: pcieport
0004:41:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller [10ec:8125] (rev 05)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller [10ec:8125]
Kernel driver in use: r8125
Kernel modules: r8169, pgdrv顺带使用了 iperf 做了一下压力测试，和内网的一台虚拟机连续压测了 5 个小时
也顺手测试了一下内网环回的转发速度，主要的限制还是 CPU 性能不够，四路并发时 CPU 就跑满了。我的 5900X 双通道 3200MHz 12 路并发跑满也就 30%的 cpu 占用，此时的转发率以及有 30GB/s 了
手头上这个 5 Plus 32G 的颗粒是镁光的，上面的丝印是2AC77 D8CBG。按照通行的解释，第一个代码意思是这个颗粒是 22 年第 1-2 周生产的，在中国台湾生产并封装
第二行解码后料号是MT53E4G32D8CY-046 WT:C，查阅镁光的料号说明和数据表后可知这个是移动端的 LPDDR4、1.1V 的 VDDQ 电压、4G 字长 32 字宽、8-die 堆叠、O Package 2133 MHz 频率、无线操作温度(–25°C to +85°C)的正式版 C Die 颗粒
由于 DDR 的全称是双倍数据率同步动态随机存取存储器，缩写是 DDR SDRAM，也就是说这个颗粒能跑到 4266 MHz 的传输速度（也就是你买的内存的标称频率）。按照系统内 2112 MHz 的运行频率，那应该是实际工作在 4224 MHz 频率上
再找了一下这个颗粒的说明手册，得到了一些有意思的结果。比如说这个颗粒号称每个通道能传输 8.53GB/s 的数据，3588 支持四通道的 LPDDR4(实际等于桌面端 DDR4 的单通道，非常整蛊)，理论有 34.12GB/s 的数据传输速度。在 SBC Bench 里实测 memset 的速度有 30GB/s 左右，基本和理论一致
我上 mouser 上查了一下报价，出货规格大概是 1360 一盘，总价¥917,500.34。折合到每个 32G 的开发板上的价格就是 1349。估计这个价格应该有很大的水分，不然就几乎是亏本白做了，官方承认确实是涨疯了，自 23 年下半年涨了一倍的价格
系统评估
硬件测试没问题了，还得选择到底需要什么系统。开发板的驱动不像 PC 那么兼容，需要仔细斟酌并付出努力去移植程序
整体来看其实就两条路子，要么为了兼容性使用香橙派/瑞芯微的镜像/内核，要么直接用发行版的官方镜像手动适配驱动等内容
可以兼容的系统
注意: UEFI 镜像在香橙派 5 PLUS 的引导阶段默认不支持 USB2.0，也就是说你想要键鼠就需要先插一个 USB3.0 的扩展坞，再把键鼠接上去。也缺少了 8k 输出和各种扩展 IO 的支持，但是对看中 3588 性能而购买的用户来说不重要
我只找了些我知道的
- 本家镜像: 一般，我反正没测试。理论上应该是支持最好的（GPU、NPU、HDMI 8K 输出和 HDMI 接收、GPIO）
- 原生适配: 使用 Uboot，做了原生兼容，可以直接刷到存储媒介上（至少可以启动，GPU 和 NPU 理论上打完驱动就可以支持）
- Armbian：针对 Arm 开发板的一个发行版，在开发板里非常常见
- Oracle Linux：RHEL 的甲骨文再发行版，可以理解为 CentOS
- OpenWRT：是不是有点太大材小用了
- 其他：由于精力限制，Debian 和 Ubuntu 应该也有，但是我没有测试
- 标准 UEFI: 把标准的 uefi 写入 sd 卡或者 spi flash 后就可以绕过 uboot 限制，像正常主板一样使用 iso 安装操作系统了，当然，系统必须支持 arm（设备基本可以工作，但是只有 1080p 输出，具体的可以看下面的说明。GPU、NPU 驱动就要你自己搞了）
- Debian/Ubuntu：可以正常安装
- Centos/RHEL/Rocky：可以正常安装
- Windows on Arm：可以正常引导，但是因为没有 nvme 驱动(无语)，我测试了几个硬盘盒也没法转接，所以兼容性存疑。但是还是可以用的
- ESXi：未测试，应该也可以，但是需要一个 USB 网卡
- Proxmox Arm：佛西大佬编译的版本，应该也没问题
- memtest86：一个被广泛用于消费级和企业级进行深度内存测试的机器。没想到居然能直接使用，但是遇上了我之前说的小核在前的识别问题，只使用了 A55 的小核
原生系统的兼容性支持
看这个文档就知道至少香橙派官方对软件支持的态度还算良好
UEFI 下的兼容性
UEFI 在 5 plus 上想要修改设置必须写入 nor flash，要不然无法指定引导、频率被锁到只有 1/3、还无法修改成设备树模式
我测试在打开 acpi+设备树兼容或设备树模式时，debian 安装镜像直接无法操控，系统也无法启动。比较麻烦
除非特殊说明，否则所有 3588 平台都适用
| Device | Status | Notes |
|---|---|---|
| USB 3 / 2.0 / 1.1 | 🟢 工作 | 仅限主机模式，连接到 Type-C USB 设备只能在一个方向上工作 |
| PCIe 3.0 (RK3588) | 🟢 工作 | 不支持 PCIe 拆分 |
| PCIe 2.1 | 🟢 工作 | |
| SATA | 🟢 工作 | |
| SD/eMMC | 🟢 工作 | |
| HDMI output | 🟡 部分可用 | 单显示器，模式限制为 1080p 60 Hz |
| DisplayPort output (USB-C) | 🟡 部分可用 | 固定为 1080p 60 Hz 的模式，仅适用于 Type-C 端口的一个方向 |
| eDP output | 🟡 部分可用 | 禁用，需要手动配置，具体取决于平台和面板。 |
| DSI output | 🔴 不工作 | |
| GMAC Ethernet | 🔴 不工作 | 仅供操作系统使用 |
| Realtek PCIe Ethernet | 🟢 工作 | 某些平台未设置 MAC 地址，在这种情况下，网络可能无法正常工作 |
| UART | 🟢 工作 | UART2 控制台提供 1500000 波特率 |
| GPIO | 🟡 部分可用 | 仅支持读、写和 alt 功能 |
| I2C | 🟢 工作 | |
| SPI | 🟢 工作 | |
| PWM | 🟢 工作 | |
| SPI NOR Flash | 🟢 工作 | |
| HYM8563 real-time clock | 🟢 工作 | |
| 风扇 | 🟢 工作 | 大多数平台都受支持 |
| 状态指示灯 | 🟢 工作 | |
| 稳压器 (RK806, RK860) | 🟢 工作 | |
| FUSB302 USB Type-C Controller | 🔴 不工作 | PD 协商和连接器方向切换是必需的 |
测试的 OS
| OS | Version | Tested/supported hardware | Notes |
|---|---|---|---|
| Windows | 10 (1904x), 11 | ||
| NetBSD | 10 | Display, UART, USB, PCIe (incl. NVME), SATA, eMMC, GMAC Ethernet | |
| VMware ESXi Arm Fling | >= 1.12 | Display, USB | PCIe 设备将在启动时挂起，需要在设置中禁用或将端口留空。检测到 GMAC 以太网，但无法正常工作。 |
| Linux | tested Ubuntu 22.04, kernel 5.15.0-75-generic | Display, UART, USB, PCIe (incl. NVME & Ethernet), SATA | 要获得完整的硬件功能，请使用支持 RK3588 的内核并切换到设备树模式。 |
使用 ACPI 时的其他限制：PCIe 交换机后面的设备无法正常工作（例如，Mixtile Blade 3 上的两个 NIC）。GMAC 仅限于千兆速度（即没有 10/100）
注：使用设备树模式而不是 ACPI 时在 Armbian 系统下可以使用大部分设备
系统的安装
SPI NOR Flash 有可能被被缩写成
SPI NOR/NOR Flash/SPI Flash/NOR等，这个存储起到了常见主板的 BIOS 的作用。以下简称为 NOR使用 RK DEV TOOLS 进行 Maskrom 级别的刷写一定需要把无关设备拔掉，不然一到需要写入 loader 的步骤就会因为 loader 启动设备而无法继续
默认的 NOR 里存储了 uboot 固件(arm 以手机为主，硬件都是定死的，没有支持通用的 UEFI 的动力)。3588 的 BootROM 会按照 NOR、EMMC、TF 卡的顺序查找设备是否可以启动，但是 NOR 里的 uboot 固件也会按照预先定义的顺序(似乎可以换)去查找 TF 卡、EMMC、NVME、U 盘上有没有设备可以启动系统。所以一般来说，开发板的启动顺序就是 NOR 的 uboot 的启动顺序
如果使用传统的 TF 卡装 UEFI 启动的方式，使用 ESXi 启动虚拟机的流程就会非常抽象。系统 Loader -> NOR的uboot固件 -> TF卡的UEFI固件 -> NVMe里的ESXi系统 -> ESXi系统模拟UEFI -> 虚拟机启动
我是先按照由难到易的顺序来折腾系统的，先是使用 UEFI 启动了 win11、rhel 和 debian，最后才是安装的原生支持的 armbian。但是为了方便理解，我还是按照由易到难得顺序来介绍吧
这里按照默认启动优先级来介绍下(仔细想想看完全没必要啊，看下文就知道了)
- NOR Flash：板载的一个闪存，适合用来装引导。UEFI 想要更改配置必须写入 NOR
- TF 卡：性能比较差，建议只装 UFEI 引导或测试
- EMMC：大号 TF 卡，可以做系统或者当备份
- NVME：最推荐的方式，可能需要一个启动盘
- USB：性能区间比较大，有的不如 TF 卡，有的接近 SATA 固态
除了板载的 NOR 没法拔下来写入以外，存储介质的写入方式惊人的一致
- 拔下来转接成 USB 在电脑写入：U 盘、TF 卡、EMMC 和 NVME。tf 卡读卡器还是比较常见的，但是 nvme 和 emmc 的可能需要专门去买
- 先刷一个 Linux，然后系统内 DD：所有的存储介质都可以，linux 下把镜像解压好然后直接 dd 写入就行，非常万能。参考命令
dd if=镜像路径 of=/dev/设备路径 bs=1M - 使用 RK DEV TOOL：应该也能写所有介质。用 RK 官方的工具，进入 maskrom 模式写入
Armbian
armbian 有 debian 和 ubuntu 内核的两种版本。我测试的是 debian 内核，gpu 驱动也能正常使用，但是还是建议没有折腾能力的使用 ubuntu 版本的内核
这个有一个很离谱的地方，官方的支持页面给的是 5/5b 的安装 iso。如果你直接装上去，就会发现没有 5 plus 上的 2.5g 网卡和设备的驱动。需要阅读内容后点一个不明显的链接才能跳到下载页面，甚至没有仅命令行的界面，只有带桌面版本的镜像。而且我的 U 盘只能插在 USB2.0 里上启动
然后找一个 u 盘，插上电脑。用软件烧录到存储媒介上，插到香橙派上。然后插电，按一下开机键就大功告成
整体体验感觉挺不错的，可以作为 raspi-os 平替
装了个 cockpit，也算是体验了一把企业级运维（RHEL 自带）
最后为了测试 GPU 性能试着播放了下 BiliBli 弹幕最高的视频，播放还挺流畅的
Debian 12
众多 Debian 系 Linux 发行版之源(Ubuntu、Armbian、RaspberryOS 等)，正宗自由系统。有原生和 UEFI 两种版本，我是直接用的 UEFI 版本，还没来得及测试所有的设备都是否支持
自带 6.1 的 kernel 要比 5.10 新不少，但是也缺少了专用的驱动
顺带测试了一下 btop，还挺花里胡哨的。但是不如 s-tui 的方便监控温度
由于缺乏自带的设备树驱动，所以无法使用 s-tui 查看温度！
RedHat Enterprise Linux
既然都有了 UEFI，怎么能不玩一下 RHEL 来玩玩呢。RHEL 是 CentOS、Rocky Linux 等服务器的上游，这些都是以稳定(陈旧)著称的发行版。安装体验和正常主板上安装差不多
之前的树莓派 4B 我也是和这台一样选择配置成一台服务器预设，但是这次体验了一轮 debian 系的便捷（大概）后，我反而对 RHEL 不满了起来
首先是所谓的稳定，RHEL 内核还停留在老旧的 5.14，而 debian 的内核已经更新到了 6.1，还有成熟的主线内核镜像。有太多合适的新功能被添加到了新内核里（AMD 的新 cpu 调度器、3588 的 GPU 驱动、香橙派的 HDMI IN）。其次所谓的企业级软件源，这里头其实缺少了太多的软件，以至于被逼出来一个由 RHEL 的上游测试项目 Fedora 所维护的 EPEL(Extra Packages for Enterprise Linux) 源，这就不企业级了。至于无休止的 SELINUX 导致无法启动？这权当是为了安全的小菜而已
其实还有难安装 docker 和一些其他小问题，但是和以上的问题比起来，那还是小巫见大巫了
Windows
我先后尝试了直写 nvme，usb+nvme，usb+sata 三种方式都没法成功加载。不确定是不是 5 plus 就是无法兼容 win
可以安装，但是没有支持的设备
换 windows on arm 软件，会卡在准备设备阶段
反复尝试了了几次，结果都是蓝屏
ESXi
还没来得及测试，UEFI 固件官方测试列表里有，理论上是支持的。但是驱动实在是太匮乏了，EMMC、GPU 无法被利用、板载的两个 PCIe 网卡也无法使用
memtest86
一个专门用来测试内存的最小化系统。很好安装，直接用官方的烧录器写到 U 盘然后在 UEFI 中启动就行
但是也不是没有问题，首先就是我提到的小核在前导致只调用了小核的问题，导致测试的时候速度非常慢。其次由于硬件支持的不完整，所以也识别不出来 CPU 信息和内存信息
怀疑是 arm 服务器厂家付费做 arm 版本支持，因为没有对常见的大小核 arm 做一些优化，应该是给做了标准 UEFI 支持的 全大核 ARM 服务器用的
我看测试跑了快一晚上没跑完一轮，之前系统内的一些内存测试长时间跑也没有什么问题，我就取消了
Android
本人折腾到凌晨四点，试了各种官方刷系统的方法均被击毙。望周不知
官方给的镜像存在问题，无法直接写到 tf 卡或者 spi+nvme。这部分的说明太少了，需要仔细研究一下
找了大佬指导了一下，需要把 tf 卡和 emmc 全部拔掉才能正常的通过 rk-dev 写入系统
整体界面还挺花里胡哨的，看了一下该有的接口也都有，不错不错
尝试播放了一下 b 站弹幕最多的辣个视频，轻松秒杀
不知道为什么，这回可以碧蓝航线启动了，但是原神不行(喜)
PVE on Armbian
官方仓库，还做了龙芯的适配 -> jiangcuo/Proxmox-Port
由于 3588 的设备树驱动在 UEFI 下不好移植，因此我就直接用 armbian 来安装了，注意需要安装 debian 内核的 armbian！
首先，先安装 Armbian。然后按照佛西大佬给的说明进行 pve 软件包的安装
这里必须要注意/etc/hosts里的 hostname 不能乱写，要和在/etc/hostname里的内容保持一致，不然 SSL 证书无法验证
安装完成后需要使用 apt 安装openvswitch-switch，再新建一个虚拟网桥桥接对应的网口，不然 win 下虚拟机无法上网
虚拟机要注意机型和设备的选择
- CPU 必须配置绑核，因为 KVM 不知道大小核该如何调度。只能全大核或全小核
- bios 需要是 UEFI，机型必须不是 Q35
- 虚拟显卡需要是
ramfb - 硬盘、虚拟光驱和网口需要是
virito scsi，虚拟网卡也需要是virito。不过我用 iscsi 挂载 virtio 驱动 ISO 时 win 下无法读取，换成 sata 后可以读取
win11 on Arm
需要下载一个 virtio-win 的驱动包，里面带了 ARM 的驱动。需要安装 vitscsi 目录下的磁盘驱动和 net-kvm 目录下的网卡驱动
win11 不兼容 arm 版本 PVE 的虚拟 TPM，所以需要使用注册表大法绕过 TPM 检查
不过安装还是很快的，看来 NVMe 还是比 USB 固态硬盘强多了
在折腾了这么久之后，终于可以来一句Win神！启动！了
win11 自带了 arm 转 x64 的模拟器，但是会对本来就孱弱的性能造成雪上加霜的影响。好在大部分的系统应用都是 arm 原生的，转译也就打 7 折水平
其实这个原生的 CPUZ 也反馈了为什么树莓派 4B 装 win 会卡。3588 的单核原生效率约等于 E5V2，等于树莓派 4B 4 核加一块，就这都会经常 4 核满载。四个小核的性能和树莓派 4B 差不多，在 win11 下连截个图都要反应 10 秒以上。尤其是我记得以前测试 ESXi 下安装 win10，转译后的单核分数似乎只有 20-50 之间
以下 CPUZ ARM 版和 CDM 磁盘测试是原生的，其他的都是系统转译后的分数。整体来说相当于一个 n5105，但是转译后性能接近 j4125？多核分数和 10W 功率的 N100 基本一致，但是单核 N100 有 350
又双叒叕跑了超电磁炮做测试，在打开 edge 的一瞬间就感觉到了卡顿。这还是在 win11 的全部系统组件几乎都是原生 arm 的情况下，所以我决定放弃 arm 下的 windows 环境作为远程桌面对象
外设测试
如无特殊说明，均是在 Armbian 上测试的
3588 的 IO 实在是太多了，完全没法全部测试一遍。别的不说 CAN 和 UART 都不好搞
bash
root@orangepi5-plus:~# ls /dev
ashmem gpiochip0 kmsg mpp_service rtc tty19 tty37 tty55 vcs vcsu6
autofs gpiochip1 kvm mqueue rtc0 tty2 tty38 tty56 vcs1 vendor_storage
block gpiochip2 log mtd0 shm tty20 tty39 tty57 vcs2 vhci
btrfs-control gpiochip3 loop0 mtd0ro snd tty21 tty4 tty58 vcs3 vhost-net
bus gpiochip4 loop1 mtdblock0 stderr tty22 tty40 tty59 vcs4 vhost-vsock
cec0 gpiochip5 loop2 net stdin tty23 tty41 tty6 vcs5 video0
cec1 hdmirx_hdcp loop3 null stdout tty24 tty42 tty60 vcs6 video-dec0
char hugepages loop4 nvme0 sw_sync tty25 tty43 tty61 vcsa video-enc0
console hwrng loop5 nvme0n1 tty tty26 tty44 tty62 vcsa1 watchdog
cpu_dma_latency i2c-0 loop6 nvme0n1p1 tty0 tty27 tty45 tty63 vcsa2 watchdog0
crypto i2c-1 loop7 nvme0n1p2 tty1 tty28 tty46 tty7 vcsa3 zero
cuse i2c-10 loop-control port tty10 tty29 tty47 tty8 vcsa4 zram0
disk i2c-11 mali0 ppp tty11 tty3 tty48 tty9 vcsa5 zram1
dma_heap i2c-3 mapper ptmx tty12 tty30 tty49 ttyFIQ0 vcsa6
dri i2c-6 mem pts tty13 tty31 tty5 ttyS9 vcsu
drm_dp_aux0 i2c-7 mmcblk0 ram0 tty14 tty32 tty50 ubi_ctrl vcsu1
fb0 i2c-9 mmcblk0boot0 random tty15 tty33 tty51 uhid vcsu2
fd iio:device0 mmcblk0boot1 rfkill tty16 tty34 tty52 uinput vcsu3
full initctl mmcblk0rpmb rga tty17 tty35 tty53 urandom vcsu4
fuse input mmcblk1 rkspi-dev2 tty18 tty36 tty54 v4l vcsu5作为对比，以下是 6.1 的 debian12 在 UEFI 模式下的设备
bash
root@debian:~# ls /dev/
autofs hidraw1 loop7 ptmx stderr tty2 tty34 tty49 tty63 vcs3 vcsu5
block hidraw2 loop-control pts stdin tty20 tty35 tty5 tty7 vcs4 vcsu6
bsg hugepages mapper random stdout tty21 tty36 tty50 tty8 vcs5 vfio
btrfs-control hwrng mem rfkill tty tty22 tty37 tty51 tty9 vcs6 vga_arbiter
bus initctl mqueue rtc tty0 tty23 tty38 tty52 ttyS0 vcsa vhost-net
char input net rtc0 tty1 tty24 tty39 tty53 ttyS1 vcsa1 vhost-vsock
console kmsg ng0n1 sda tty10 tty25 tty4 tty54 ttyS2 vcsa2 zero
core kvm null sdb tty11 tty26 tty40 tty55 ttyS3 vcsa3
cpu_dma_latency log nvme0 sdb1 tty12 tty27 tty41 tty56 uhid vcsa4
cuse loop0 nvme0n1 sdc tty13 tty28 tty42 tty57 uinput vcsa5
disk loop1 nvme0n1p1 sg0 tty14 tty29 tty43 tty58 urandom vcsa6
fb0 loop2 nvme0n1p2 sg1 tty15 tty3 tty44 tty59 usb vcsu
fd loop3 nvme0n1p3 sg2 tty16 tty30 tty45 tty6 userfaultfd vcsu1
full loop4 port shm tty17 tty31 tty46 tty60 vcs vcsu2
fuse loop5 ppp snapshot tty18 tty32 tty47 tty61 vcs1 vcsu3
hidraw0 loop6 psaux snd tty19 tty33 tty48 tty62 vcs2 vcsu4对比一下少了这么多的设备，一想到要移植这么多驱动我就头大。debian 又没法直接用 dtb 模式安装
bash
python armbian-dev - debian-dev # 伪代码，对比了一下设备
# 内存加密这些东西无所谓
ashmem
zram0 zram1
crypto dma_heap dri drm_dp_aux0
ram0
# GPIO控制
gpiochip0 gpiochip1 gpiochip2 gpiochip3 gpiochip4 gpiochip5
i2c-0 i2c-1 i2c-10 i2c-11 i2c-3 i2c-6 i2c-7 i2c-9
rkspi-dev2
iio:device0
# HDMi设备
hdmirx_hdcp
video-dec0 video-enc0 video0
cec0 cec1
# gpu 设备
mali0
mpp_service
rga
v4l
# EMMC和SD卡
mmcblk0 mmcblk0boot0 mmcblk0boot1 mmcblk0rpmb mmcblk1
# SPI NOR
mtd0 mtd0ro mtdblock0
# 看门狗
watchdog watchdog0
# 存储硬件信息
vendor_storage
# 杂项
vhci
sw_sync
ttyFIQ0 ttyS9
ubi_ctrl串口测试
找一个 ch340 转 usb 的芯片，或者用集成的线也行。然后按照官方说明书的把线序对上，装好 ch340 驱动。直接开机就行
这个方法能看到更多的底层信息，也能进入 UEFI 界面或者是动态显示 top 之类的变化信息。确实是有一种相见恨晚的感觉
GPU
目前没有找到在 UEFI 下驱动 gpu 的方式，有点可惜
驱动安装
3588 的 Mali G610 驱动太折磨了，一共有三种
- panfork：性能还可以的驱动，但是不更新了，只能适配 5.10 内核
- panforst：Linux kernel 兼容驱动，目前看性能还行。预计 6.10+合并入主线内核
- Arm 官方驱动：好像只有安卓系统有
如果想要使用 redroid 的话，必须要使用瑞芯微的 5.10 内核，所以只能要么用 panfork、要么用官方系统。先用 armbian 内 5.10 内核跑一下 redroid 的测试吧
redroid 测试
Remote-Android，GPU 加速的 Docker Android 镜像。也叫 Android in Container 方案(云手机)
使用 5.10 内核启动 redroid 倒是很简单，直接安装预编译好的两个包，然后一键启动就行
这个镜像需要提取一个瑞芯微的固件放到/lib/firmware目录下面，从 docker 目录下下载一个就行
bash
# 这个是ubuntu的，其他系统可以直接去仓库下载安装的两个包，然后本地安装
sudo add-apt-repository ppa:liujianfeng1994/panfork-mesa
sudo add-apt-repository ppa:liujianfeng1994/rockchip-multimedia
sudo apt update
sudo apt dist-upgrade
sudo apt install mali-g610-firmware rockchip-multimedia-config可以一键启动 docker，然后 exec 进去把/vendor/etc/firmware下的 mali_csffw.bin 复制到共享路径里，然后再移动到宿主机的/lib/firmware目录下
bash
docker run -d -p 5555:5555 -v ~/redroid-data:/data --name redroid --privileged cnflysky/redroid-rk3588:13.0.0-latest androidboot.redroid_height=1920 androidboot.redroid_width=1080看安兔兔跑分的结果，确实是使用了 GPU。跑分大概是 8/12fps，接近我骁龙 8+的 K50U 的一半分数
跑一个 3D Mark Wild Life 压力测试看下稳定性，毕竟要 24 小时挂机的游戏的。实测由于没有电池+散热给力，稳定性 99.5%+，在台式机显卡里都是非常好的水平了。就是性能只有 8gen3 的 1/3 - 1/4 水平(1200 vs 4200)，接近骁龙 865
不知道为什么，碧蓝航线无法启动，似乎是缺少了设备
突然想起来我以前有三蹦子账号，冤甚，起冬！
跑到蒙德挂机了差不多 12 小时，一共加起来 48 小时，原神也没闪退。看来稳定性还是可用的。测试了一下，碧蓝档案也可以启动，甚至是云游戏。悲甚
能启动的就真的是能启动，很多游戏我就进了登录界面，除非原本就有共通账号，不然不会试玩
- 启动！
- [x] 原神
- [x] 崩坏三
- [x] 崩坏·星穹铁道
- [x] 明日方舟
- [x] 尘白禁区
- [x] 碧蓝档案
- [x] FGO
- [x] 战双·帕弥什
- [x] 公主连结 R
- [x] BiliBili
- [x] Todesk
- [x] Rustdesk
- [x] NTQQ
- 寄！
- [ ] 碧蓝航线
这里我要点名一个缩写为 blhx 的游戏，这么多游戏里就它一个打不开。查了 LOG 也看不出来到底是需要什么东西，有好心群友折腾了半天也跑不出来，看来不是个例
2024-04-30 注：最近觉得 cpu 性能不够，寻找 arm 替换方案，发现 cx8gen3 和 oracle 云的 arm 机器也跑不了，3588 换 panthor 驱动 + wayland 渲染的安卓模拟方案也还是跑不了。黄鸡的 0.5 个程序员是真的麻
视频输入
可以用来当采集卡，配合 typec 数据传输口 的 OTG 模式当 IPKVM，就是得研究一下视频的输入和转发、USB 设备的模拟怎么搞
bash
root@orangepi5-plus:~# ls /dev/ |grep video
video0
video-dec0
video-enc0
root@orangepi5-plus:~# v4l2-ctl -d /dev/video0 -V -D
Driver Info:
Driver name : rk_hdmirx
Card type : rk_hdmirx
Bus info : fdee0000.hdmirx-controller
Driver version : 5.10.160
Capabilities : 0x84201000
Video Capture Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04201000
Video Capture Multiplanar
Streaming
Extended Pix Format
Format Video Capture Multiplanar:
Width/Height : 640/480
Pixel Format : 'BGR3' (24-bit BGR 8-8-8)
Field : None
Number of planes : 1
Flags : 0x00000080
Colorspace : sRGB
Transfer Function : Default
YCbCr/HSV Encoding: Unknown (0x000000ff)
Quantization : Default
Plane 0 :
Bytes per Line : 1920
Size Image : 921600红外输入
这个东西有点抽象，比较适合电视盒子。由于我实在是想不出来有什么用，甚至不能当温度传感器，所以就测试了一下能否正常识别
bash
root@orangepi5-plus:~# evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: febf0030.pwm
/dev/input/event1: rk805 pwrkey
/dev/input/event2: rockchip-dp0 rockchip-dp0
/dev/input/event3: rockchip-hdmi0 rockchip-hdmi0
/dev/input/event4: rockchip-hdmi1 rockchip-hdmi1
/dev/input/event5: rockchip-hdmiin rockchip-hdmiin
/dev/input/event6: headset-keys
/dev/input/event7: rockchip-es8388 Headset
/dev/input/event8: adc-keys
Select the device event number [0-8]: 0
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x524b product 0x6 version 0x100
Input device name: "febf0030.pwm"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 2 (KEY_1)
Event code 3 (KEY_2)
Event code 4 (KEY_3)
Event code 5 (KEY_4)
Event code 6 (KEY_5)
Event code 7 (KEY_6)
Event code 8 (KEY_7)
Event code 9 (KEY_8)
Event code 10 (KEY_9)
Event code 11 (KEY_0)
Event code 28 (KEY_ENTER)
Event code 102 (KEY_HOME)
Event code 103 (KEY_UP)
Event code 105 (KEY_LEFT)
Event code 106 (KEY_RIGHT)
Event code 108 (KEY_DOWN)
Event code 113 (KEY_MUTE)
Event code 114 (KEY_VOLUMEDOWN)
Event code 115 (KEY_VOLUMEUP)
Event code 116 (KEY_POWER)
Event code 139 (KEY_MENU)
Event code 143 (KEY_WAKEUP)
Event code 158 (KEY_BACK)
Event code 217 (KEY_SEARCH)
Event code 388 (KEY_TEXT)
Properties:
Testing ... (interrupt to exit)迁移笔记
原本看到瑞芯微提供了 6.1 的 RKNN 工具以及已经有人成功运行了 Panfork，我准备尝试一下 6.1 内核是否满足需求。结果发现官方的内核甚至开了 ADB，可以免密码以 root 身份执行代码，Redorid 也无法运行
好吧，那还是切换回 Armbian + Debian minimum + 5.10 内核的选择吧。接下来就该迁移应用了
基础环境的准备
首先最基础的，就是要配置包管理的镜像了，这里我测试过清华源访问的是最快的，也有可能是接入了高校联盟
那么直接按照官方说明，把/etc/apt/source.list里头的镜像地址换成清华源的，然后apt update && apt upgrade一下，升级下环境
然后就是要准备软件环境了，因为我常用的应用主要是 Python 和 Java 写的，所以需要准备一下。python 没什么好说的，安装python-is-python3和python3-pip这两个包就行。一个是因为旧有的 python2 已经被移除，一个是 python 的包管理软件，然后也把 pypi 源换成清华的。java 则是参考我之前的测试结果，选了 zing 发行版的 jdk，这个性能比较强（最后还是选了 graalvm17，zing 在预热阶段 cpu 消耗 3588 根本撑不住，启动速度比 graalvm 差了一大截）
再把 Docker 配置一下，curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun一条命令直接安装 docker
再看看有没有缺什么包，然后把被精简的包和好用的工具安装一下
bash
apt install bash-completion # 缺少的命令行自动补全
apt install btop s-tui screen # 非常好用的监控工具
apt install cockpit # 管理面板，可以按需选择 cockpit-拓展包
apt install armbian-config # armbian 管理工具，最小化系统缺少这个管理硬件最后把用来免密登陆的私钥写入.ssh/authroized_keys文件内，就大功告成了
bash
# 关闭自带的resolved服务，和adguard home冲突
sudo systemctl disable systemd-resolved
sudo systemctl stop systemd-resolved
sudo unlink /etc/resolv.conf
sudo touch /etc/resolv.conf
sudo systemctl restart NetworkManager后面因为 smb 有问题（redroid 会导致重启后 smb 认证失败，可能是权限问题），所以我重装了一次系统。因为先期迁移做好了准备，所以重新打包+重装+部署的时间加起来都没有一个小时
迁移 && 改造
我之前部署在树莓派上的程序主要分为三部分
- docker 内的镜像
- 以 root 身份安装的关键原生应用，如 nginx 和 cloudflare 的代理这种
- 以用户身份部署的统一管理格式的应用，比如说 QQ 机器人和 DDNS 之类的
Docker 这种容器的好解决，把 compose 文件和数据目录复制过来即可。但我准备把 2、3 中非必要的程序全部替换成镜像。这个就又要涉及到迁移改造了，多少有亿点点麻烦
2、3 主要是把 nginx、cloudflare、vscode、ddns、samba 这些组件替换成容器来方便管理，简化运维压力。然后还要新增 watchtower 和 dockge 等服务用来新增和管理 compose 文件
docker 容器的迁移比较简单，首先把/data 目录下所有需要用的文件打包一份作为全量备份包。然后在根据顺序来分批迁移，因为涉及到 IP 地址的变化等问题，所以有一定顺序
首先迁移没有依赖的 minio、mysql 这些孤立服务，然后是最好同时只存在一份的 Prometheus 和 grafana 数据采集，最后是 dns 解析和代理服务，然后 dhcp 里的地址解析进行改造。docker 服务就算是迁移好了
然后像是 cloudflare tunnel、VSCode 和 ddns 这些有成熟的 docker 选择的也简单，samba 和 nginx 这些就比较麻烦了。需要研究如何实现一个比较优雅的方式
其他增补配置
zram 看了一下说明，原理类似 ksm，算是新特性，就不关闭了。但是默认会把信息写到内存再倒一手磁盘，这个在有高性能的磁盘的情况下就没必要了
bash
# 禁用zram的/var/log
/etc/default/armbian-ramlog #将ENABLED=true改为false
/etc/cron.d/armbian-truncate-logs # 注释
/etc/cron.daily/armbian-ram-logging # 注释总结
需要特别感谢一下香橙派开发群里的群友和义工@WillzenZou的支持，不然很多东西我都无法折腾出来
3588 这个芯片算是 19 年以来（写到这才反应过来为什么都在挤牙膏）难得有重大变革的 SBC 领域的新产品。而香橙派 5 Plus 也把它的潜力发挥到的极致，尽管还有没用上 A78 大核和总供电上限没那么高的不足，但是整体还是一个非常优秀的产品
可惜的是，除了产品之外的问题也依然有很多，毕竟出货量和受众面都没树莓派那么多。依然有缺乏社区支持、内核陈旧以及被瑞芯微和 GPU 驱动捆绑内核版本的问题，这个在很大程度上限制了我对新内核的尝试。不过还在官方的系统也还能用
希望在未来能有更多性能更强劲的开发板可供选择吧，比如搭载 20T 算力 NPU 的昇腾开发板(4+1 个 A55 核心，也比较难顶，310 切下来的)。我其实比较期待 NV 的下一代开发平台(2000T 算力，巨贵)Thor AGX 或者是瑞芯微是否会推出性能更强的芯片
不过至少在目前，我还是先研究下如何把现有的服务迁移并利用好香橙派 5 Plus 那更强的 IO 吧