huchuan2025/40-Archive/104-OrangePi5Plus/资料/RK3588 ORANGE PI5 PLUS.md

77 KiB
Raw Blame History

有一说一,看了下香橙派 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 显示器并驱动舵机(这得差不多 45Wm2 螺柱高度问题导致不方便使用硅脂散热外。香橙派 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 还有四个摄像头!如果载板是那种刚好覆盖 cm5256g emmc三网口、带点基础扩展然后给 cm5 加上一个散热片我觉得都好不少,非常适合当软路由或者集群计算节点(等下,这玩意不就是友善 R6S 吗?,看了一圈,香橙派几乎所有方案都能在价格或性能超过竞品。橙子,你好强大)

还有整体生态系统也不是很满意,虽然 armbian 还算好用但是瑞芯微的研发力量和香橙派的社区支持不足导致香橙派的生态和树莓派完全没法比。3588 这个 soc 细数起来也是究极抽象8nm 的三星工艺单核a76@2.4ghz,实际 2.2,很难超频)还比不过 14nm 博通工艺a76@2.4ghz,实际可超 3.0npu 的 6t 算力更是由三个注水的 2t 算力的 npu 缝合,堪称乐色。这个离谱玩意用上万转风扇满载都会过热节流,装个 uefi 或者 win10 都会遇上一大堆兼容性问题。想要用上标准的 uefi 镜像或者至少是用上能驱动所有设备的官方的主线内核的镜像更是一件几乎不可能的事情

all-product

额外考虑加装的内容

  • MC 服务器懂的都懂虽然半年不玩了。java 版的 MC 是只需要 JDK 有相应的架构支持就能运行的
  • onlyoffice似乎也没什么用后续可能会做一定的二次开发。但是树莓派的 8g 内存不太够用了
  • Spacejetbrain 公司对标 github 的一站式开发产品,内存消耗大户。已成功耗死这个产品,笑死
  • TeamCity有必要专门在 gitea 之外专门搞一个 cicd 服务器吗?
  • 本地数据库mysql 和 minio 这类的数据库。实测树莓派用 USB SATA 固态的性能并不满足
  • 游戏挂机:模拟器相比原生的效率太低了,增加的功耗完全可以换一个 arm 开发板来跑了
  • 专用下载机:单个企业级机械的功耗就比 3588 高了,整几个消费级机械降点功耗试试
  • 远程环境:目前能够远程访问的桌面环境只有 NAS增加一个访问点用来做备份

稍微有点为了折腾而折腾了,其实很多功能不如直接买一个 NUC 13 Pro。虽然现有负载 + MC 服务器 + 安卓挂机等于 8+8+8=24g但是 32g 的内存感觉还是略微超出需求了,尤其是在安卓 Docker 镜像无法启动需要的游戏的情况下。实际上的最大限制还是在 CPU4x2.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 全核差不多了

  • 迁移前的摸底测试
    • 系统稳定性检测:虽然芯片体质不太好,但是保证散热和供电没问题的情况下稳定性还是可以的
      • CPU 压力测试:更换全金属盔甲和高等级风扇勉强 80 度,好在足够稳定
      • GPU 压力测试:测试了一下 GPU 跑 3D Mark 测试,有接近 14W 的负载。稳定性和有良好散热的桌面级平台一样
      • MEM 压力测试stress 和 memtest86 通过
      • NVME 压力测试fio 4k 深队列随机写入可以维持 1500MB/S
    • 系统依赖检查:开发板的各类驱动想要移植是真的太难了啊,很可能必须用官方的镜像了
      • OPI Debian自编译 kernel 6.1,除了 CAN 总线基本全功能支持
      • Armbian瑞芯微 Kernel 5.10,支持基本功能
      • UEFI Debian12似乎不支持 GPU 和 NPU
    • GPU 依赖检查:太麻烦了,放弃移植驱动到发行版官方内核了
      • redroid: GPU 加速需要 Mali G610 驱动,同时只能用瑞芯微的 5.10 内核。新的 panthor/panforst 比较难搞
      • LLM需要 GPU 驱动
    • NPU 依赖检查:移植难度太大,直接似了。反正就 YOLO 可能用到,还是非必须
    • 网络设备检查AX210 几乎都免驱,太感动了
      • 双 2.5G 网口聚合:单口测试跑了 5T 数据都没有问题,平均速度大于 2.3gbps,这个数据和其他平台的表现一致。多口聚合是基础功能,懒得测试了
      • WIFI 测试:虽然无法接上太好的天线,但是稳定性还是可以的

折腾前的准备

其实最重要的问题是要有心理准备,香橙派这种开发板如果只是想跑起来那非常简单,但是如果想把它玩明白,那就要折腾非常多。树莓派累计出货了 4600 万台,香橙派能有到它的零头(百万)就不错了。虽然香橙派在国外也有一些知名度,但生态和树莓派那种可以挑三拣四的积累没得比

虽然一直嘲笑勃砼(博通)的东西比起其他家是大火炉但是和在机顶盒领域都是弟中之弟的瑞芯微比半导体领域比三星3588 还真是三星代工)排名靠前,能做 800G 交换机和 PCIE5.0 Switch 的博通那是真的老大哥 Pro Plus Max Ultra

简单介绍一下瑞芯微的这个 35888nm 工艺,搭载四核 A76+四核 A55 的八核 CPUMali 610 的 GPU,内置 6T 算力的 NPU、一个 PCIe3.0x4 通道、三个 SATA/PCIe2.0x1 复通的通道。USB、emmc 之类的意义不大的东西我就不说了

然后 3588 的 CPU 分配是 A55 四个核一个簇(0-3)A76 每两个核一个簇(4-5,6-7)。和 Intel 的大核在前正好相反,这样子性能会有问题,因为很多任务是写死 CPU0 的,只能跑在小核

rk3588-datasheet

找到了一份 Rock5B 的 CPUIO 分配图,非常齐全。注意这不是香橙派的,只是用来看 3588 有什么接口!

香橙派没有 PD 协商,把 rock5b 拿来做 usb3.0 的通道拿去给 2.5g 网卡了

rock5b-detail

折腾 3588 前需要预先准备一些东西。如果上了固态,一定要买一个 5V4A 的电源,很多问题都是电源导致的!

  1. SD 卡、EMMC、固态 U 盘NVME。用来装系统的存储介质。最好有 NVME性能对其他介质是降维打击而且 3588 也带得起来这么高的 IO
  2. 一个至少能输出 5V4A 的非快充优质充电器,和 C 口的供电线。虽然我固态顺序读写、CPU 网口满载进行压力测试 5V3A 的也撑得住
  3. USB3.0 的拓展坞,最好能同时兼容 A 口和 C 口,用来避免兼容问题
  4. 购买一个主动散热器或者是带散热器的外壳,被动散热对于动不动 10W 的发热完全压不住。同时为 NVME 准备莱德尔 90000 导热垫(足够柔软且便于散热)
  5. 串口链接能看到很多信息,非常方便。建议买一个 usb 转 ch340 的线,然后使用 mobaxterm 链接串口
  6. 如果准备使用 M2 固态的话,需要准备一个 M3 内径0.5mm 厚度的尼龙/金属垫圈,还有柔软的导热垫(莱德尔 90000 效果比较好)。使用金属外壳时,可以使用 1.5mm 厚的导热垫把热量导出到外壳底面,效果很好
  7. 效果最好的金属铠甲外壳也就只能把 3588 压到不降频而已,如果想要能够把温度不会降频,可以买一个 3010 的 5v 双滚珠风扇,转速在 5000-9000 就行。固定螺丝的规格是 15mm 的 m3 螺丝,再买点垫片垫高通风降低一点风噪。如果要使用 PWM 调速,需要系统支持 GPIO 并购买 xh1.25mm 的接口,直接全速运行就买两个杜邦线母头的那种接口即可

5-plus-uboot

香橙派的硬件

我把官方的硬件参数说明存了一份下来,这个介绍还是很齐全的

条目 说明
主控芯片 Rockchip RK3588(8nm LP 制程)
CPU • 8 核 64 位处理器
• 4 个 Cortex-A76 和 4 个 Cortex-A55 及独立的 NEON 协处理器
• Cortex-A76 主频 2.4GHzCortex-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-CDP 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 LANRTL8125BG)
扩展口 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 键1xRECOVERY1x 开关机键
供电 支持 Type-C 供电5V@4A
红外接收器 1x 红外接收管
LED RGB LED 侧发光
FAN 5V FAN
RTC 2PINRTC 备用电池
调试 3Pin 调试串口UART
支持的操作系统 Orangepi OSDroid、Orangepi OSArch、Orangepi OSOH、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

5-plus-front

5-plus-back

5-plus-gpio

到手后的摸底测试

先在 U 盘上写了个 Armbian 镜像,测试了一下硬件是否存在问题

补充!

测试了一下,只用 5V3A 的供电的话存在严重的问题。在散热良好的情况下3588 待机功耗 7W都是插座端效率可能有 85%),单烤 CPU 整机功耗就达到了最高 16WP41 做 4K 多线程深队列写入(大核满载) 20W整机功耗完全有能力达到 30W 乃至是 40WGPIO 的电源输出、和摄像头、edp 驱动和大功率 USB 设备也需要耗电)

建议不要使用 USB 接口为移动硬盘和拓展坞供电,不要的设备尽可能全部拔掉,比如 SSH 时可以把接收器和 HDMI 拔了

5-plus-stress-power

作为预期的高性能中控节点,如果按照预期的把 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

意料之外的问题

  1. 3588 是真的热啊,虽然听上去就 10w 左右的 TDP手机的散热模组都能压。但是根据测试结果需要一个正经的散热器。像是那种塞一个 1cm 厚的导热垫的这种糊弄事的散热器很容易高负载下过热,换成万转风扇也会温度突破 80 度。好在有南桥散热器规格的孔位,官网现在也在推这个散热器
  2. 抽到的这个处理器是真的霉逼3588 号称大核能 2400 MHz但是实际上工艺水平不稳定瑞芯微用的是 pvtm 管理实际频率,等级分为(0-7,对应 2256-2400MHz),我这两个大核的簇只有 3-4(2200/2250 MHz 的频率),算是大雷。也许换了散热器后可以尝试超频(后面发现 pmtv 很麻烦,得改 dtb
  3. ARM 的 IO 能力也是真的抠脚,我的 NAS 上在虚拟机里操作一个次一级的 PCIe4.0 固态(写入 2G/SP41 缓内写入 6G/S) DD 大文件能有 1.6G3588 只有 800M。好在 fio 测试,还是可以跑满 3.0x4 的带宽
  4. 各个系统对于设备的适配不一致,很有可能选择的系统没有 USB2.0/3.0 的驱动,这就有个巨大的问题。可能你的键鼠需要接入一个 USB3.0 的拓展坞,或者是 USB 硬盘 只能插在 2.0 的接口

3588-stress

如果更换 3010 的 5v 风扇(CFM 3.6),是可以把满载 stress cpu 的温度从 84 度的略微降频变成 70 度顶着功耗上限运行,但是要注意,风扇不用买万转的,太吵了!

软件兼容性方面也有坑

  1. UEFI 驱动有半年没更新了,可能需要去 Github 仓库的 Action 里下载最新的 nightly 版本的固件来修复 BUG。甚至不一定能修复
  2. RK3588 恐怖的 IO 设备数量也带来了恐怖的适配难度。如果想要使用标准 uefi 启动镜像,那要做好比普通主机多出来的接口全不能用的心理准备(emmc、edp、dsi 等)

当前瑞芯微提供支持(NPU)的内核是 5.10/6.16.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 散热器(没有那么大的空间)

5plus-m2

随手找了个金属螺丝刀盒压了上去甚至硅脂都没用效果居然意外的不错。fio 最高压力 4K 多线程写入把盘写满也就最高温度 70 度

5-plus-max-stress

p41-stress-q32t8

用莱德尔 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/S4K 多线程读取只有 15MB/S4k 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.0x13588 强大的 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 个小时

5-plus-iperf

也顺手测试了一下内网环回的转发速度,主要的限制还是 CPU 性能不够,四路并发时 CPU 就跑满了。我的 5900X 双通道 3200MHz 12 路并发跑满也就 30%的 cpu 占用,此时的转发率以及有 30GB/s 了

5-plus-iperf-local

手头上这个 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 颗粒

micron-memory-datasheet

由于 DDR 的全称是双倍数据率同步动态随机存取存储器,缩写是 DDR SDRAM也就是说这个颗粒能跑到 4266 MHz 的传输速度(也就是你买的内存的标称频率)。按照系统内 2112 MHz 的运行频率,那应该是实际工作在 4224 MHz 频率上

再找了一下这个颗粒的说明手册,得到了一些有意思的结果。比如说这个颗粒号称每个通道能传输 8.53GB/s 的数据3588 支持四通道的 LPDDR4(实际等于桌面端 DDR4 的单通道,非常整蛊),理论有 34.12GB/s 的数据传输速度。在 SBC Bench 里实测 memset 的速度有 30GB/s 左右,基本和理论一致

micron-dram-features

我上 mouser 上查了一下报价,出货规格大概是 1360 一盘,总价¥917,500.34。折合到每个 32G 的开发板上的价格就是 1349。估计这个价格应该有很大的水分,不然就几乎是亏本白做了,官方承认确实是涨疯了,自 23 年下半年涨了一倍的价格

系统评估

硬件测试没问题了,还得选择到底需要什么系统。开发板的驱动不像 PC 那么兼容,需要仔细斟酌并付出努力去移植程序

整体来看其实就两条路子,要么为了兼容性使用香橙派/瑞芯微的镜像/内核,要么直接用发行版的官方镜像手动适配驱动等内容

可以兼容的系统

注意: UEFI 镜像在香橙派 5 PLUS 的引导阶段默认不支持 USB2.0,也就是说你想要键鼠就需要先插一个 USB3.0 的扩展坞,再把键鼠接上去。也缺少了 8k 输出和各种扩展 IO 的支持,但是对看中 3588 性能而购买的用户来说不重要

我只找了些我知道的

  1. 本家镜像: 一般我反正没测试。理论上应该是支持最好的GPU、NPU、HDMI 8K 输出和 HDMI 接收、GPIO
  2. 原生适配: 使用 Uboot做了原生兼容可以直接刷到存储媒介上至少可以启动GPU 和 NPU 理论上打完驱动就可以支持)
    1. Armbian针对 Arm 开发板的一个发行版,在开发板里非常常见
    2. Oracle LinuxRHEL 的甲骨文再发行版,可以理解为 CentOS
    3. OpenWRT是不是有点太大材小用了
    4. 其他由于精力限制Debian 和 Ubuntu 应该也有,但是我没有测试
  3. 标准 UEFI: 把标准的 uefi 写入 sd 卡或者 spi flash 后就可以绕过 uboot 限制,像正常主板一样使用 iso 安装操作系统了,当然,系统必须支持 arm设备基本可以工作但是只有 1080p 输出具体的可以看下面的说明。GPU、NPU 驱动就要你自己搞了)
    1. Debian/Ubuntu可以正常安装
    2. Centos/RHEL/Rocky可以正常安装
    3. Windows on Arm可以正常引导但是因为没有 nvme 驱动(无语),我测试了几个硬盘盒也没法转接,所以兼容性存疑。但是还是可以用的
    4. ESXi未测试应该也可以但是需要一个 USB 网卡
    5. Proxmox Arm佛西大佬编译的版本应该也没问题
    6. memtest86一个被广泛用于消费级和企业级进行深度内存测试的机器。没想到居然能直接使用但是遇上了我之前说的小核在前的识别问题只使用了 A55 的小核

原生系统的兼容性支持

看这个文档就知道至少香橙派官方对软件支持的态度还算良好

native-support

UEFI 下的兼容性

UEFI 在 5 plus 上想要修改设置必须写入 nor flash,要不然无法指定引导、频率被锁到只有 1/3、还无法修改成设备树模式

我测试在打开 acpi+设备树兼容或设备树模式时debian 安装镜像直接无法操控,系统也无法启动。比较麻烦

除非特殊说明,否则所有 3588 平台都适用

uefi-menu

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 没法拔下来写入以外,存储介质的写入方式惊人的一致

  1. 拔下来转接成 USB 在电脑写入U 盘、TF 卡、EMMC 和 NVME。tf 卡读卡器还是比较常见的,但是 nvme 和 emmc 的可能需要专门去买
  2. 先刷一个 Linux然后系统内 DD所有的存储介质都可以linux 下把镜像解压好然后直接 dd 写入就行,非常万能。参考命令dd if=镜像路径 of=/dev/设备路径 bs=1M
  3. 使用 RK DEV TOOL应该也能写所有介质。用 RK 官方的工具,进入 maskrom 模式写入

Armbian

armbian 有 debian 和 ubuntu 内核的两种版本。我测试的是 debian 内核gpu 驱动也能正常使用,但是还是建议没有折腾能力的使用 ubuntu 版本的内核

这个有一个很离谱的地方,官方的支持页面给的是 5/5b 的安装 iso。如果你直接装上去就会发现没有 5 plus 上的 2.5g 网卡和设备的驱动。需要阅读内容后点一个不明显的链接才能跳到下载页面,甚至没有仅命令行的界面,只有带桌面版本的镜像。而且我的 U 盘只能插在 USB2.0 里上启动

armbian-install

然后找一个 u 盘,插上电脑。用软件烧录到存储媒介上,插到香橙派上。然后插电,按一下开机键就大功告成

整体体验感觉挺不错的,可以作为 raspi-os 平替

armbian-neofetch

装了个 cockpit也算是体验了一把企业级运维RHEL 自带)

armbian-cockpit

最后为了测试 GPU 性能试着播放了下 BiliBli 弹幕最高的视频,播放还挺流畅的

armbian-bilibili

Debian 12

众多 Debian 系 Linux 发行版之源(Ubuntu、Armbian、RaspberryOS 等),正宗自由系统。有原生和 UEFI 两种版本,我是直接用的 UEFI 版本,还没来得及测试所有的设备都是否支持

debian12-install

自带 6.1 的 kernel 要比 5.10 新不少,但是也缺少了专用的驱动

debian12-debian12-info

顺带测试了一下 btop还挺花里胡哨的。但是不如 s-tui 的方便监控温度

debian12-btop

由于缺乏自带的设备树驱动,所以无法使用 s-tui 查看温度!

RedHat Enterprise Linux

既然都有了 UEFI怎么能不玩一下 RHEL 来玩玩呢。RHEL 是 CentOS、Rocky Linux 等服务器的上游,这些都是以稳定(陈旧)著称的发行版。安装体验和正常主板上安装差不多

rhel-language

rhel-install-menu

之前的树莓派 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 和一些其他小问题,但是和以上的问题比起来,那还是小巫见大巫了

rhel-jobs-select

Windows

我先后尝试了直写 nvmeusb+nvmeusb+sata 三种方式都没法成功加载。不确定是不是 5 plus 就是无法兼容 win

可以安装,但是没有支持的设备

win11-install

换 windows on arm 软件,会卡在准备设备阶段

win11-prepare

反复尝试了了几次,结果都是蓝屏

win11-blue-screen

ESXi

还没来得及测试UEFI 固件官方测试列表里有理论上是支持的。但是驱动实在是太匮乏了EMMC、GPU 无法被利用、板载的两个 PCIe 网卡也无法使用

memtest86

一个专门用来测试内存的最小化系统。很好安装,直接用官方的烧录器写到 U 盘然后在 UEFI 中启动就行

memtest86-status

但是也不是没有问题,首先就是我提到的小核在前导致只调用了小核的问题,导致测试的时候速度非常慢。其次由于硬件支持的不完整,所以也识别不出来 CPU 信息和内存信息

memtest86-test

怀疑是 arm 服务器厂家付费做 arm 版本支持,因为没有对常见的大小核 arm 做一些优化,应该是给做了标准 UEFI 支持的 全大核 ARM 服务器用的

我看测试跑了快一晚上没跑完一轮,之前系统内的一些内存测试长时间跑也没有什么问题,我就取消了

memtest86-time

memtest86-finish

Android

本人折腾到凌晨四点,试了各种官方刷系统的方法均被击毙。望周不知

官方给的镜像存在问题,无法直接写到 tf 卡或者 spi+nvme。这部分的说明太少了需要仔细研究一下

找了大佬指导了一下,需要把 tf 卡和 emmc 全部拔掉才能正常的通过 rk-dev 写入系统

整体界面还挺花里胡哨的,看了一下该有的接口也都有,不错不错

android-boot-1

android-boot-2

android-boot-3

尝试播放了一下 b 站弹幕最多的辣个视频,轻松秒杀

android-bilibili-max-bullet

不知道为什么,这回可以碧蓝航线启动了,但是原神不行(喜)

android-blhx-ys

PVE on Armbian

官方仓库,还做了龙芯的适配 -> jiangcuo/Proxmox-Port

pve-webui

由于 3588 的设备树驱动在 UEFI 下不好移植,因此我就直接用 armbian 来安装了,注意需要安装 debian 内核的 armbian

首先,先安装 Armbian。然后按照佛西大佬给的说明进行 pve 软件包的安装

这里必须要注意/etc/hosts里的 hostname 不能乱写,要和在/etc/hostname里的内容保持一致,不然 SSL 证书无法验证

安装完成后需要使用 apt 安装openvswitch-switch,再新建一个虚拟网桥桥接对应的网口,不然 win 下虚拟机无法上网

虚拟机要注意机型和设备的选择

  1. CPU 必须配置绑核,因为 KVM 不知道大小核该如何调度。只能全大核或全小核
  2. bios 需要是 UEFI机型必须不是 Q35
  3. 虚拟显卡需要是ramfb
  4. 硬盘、虚拟光驱和网口需要是 virito scsi,虚拟网卡也需要是 virito。不过我用 iscsi 挂载 virtio 驱动 ISO 时 win 下无法读取,换成 sata 后可以读取
win11 on Arm

pve-win11-conf

需要下载一个 virtio-win 的驱动包,里面带了 ARM 的驱动。需要安装 vitscsi 目录下的磁盘驱动和 net-kvm 目录下的网卡驱动

win11 不兼容 arm 版本 PVE 的虚拟 TPM所以需要使用注册表大法绕过 TPM 检查

pve-win11-install

pve-win11-reg

不过安装还是很快的,看来 NVMe 还是比 USB 固态硬盘强多了

在折腾了这么久之后,终于可以来一句Win神启动

pve-win11-logo

win11 自带了 arm 转 x64 的模拟器,但是会对本来就孱弱的性能造成雪上加霜的影响。好在大部分的系统应用都是 arm 原生的,转译也就打 7 折水平

pve-win11-status

其实这个原生的 CPUZ 也反馈了为什么树莓派 4B 装 win 会卡。3588 的单核原生效率约等于 E5V2等于树莓派 4B 4 核加一块,就这都会经常 4 核满载。四个小核的性能和树莓派 4B 差不多,在 win11 下连截个图都要反应 10 秒以上。尤其是我记得以前测试 ESXi 下安装 win10转译后的单核分数似乎只有 20-50 之间

以下 CPUZ ARM 版和 CDM 磁盘测试是原生的,其他的都是系统转译后的分数。整体来说相当于一个 n5105但是转译后性能接近 j4125多核分数和 10W 功率的 N100 基本一致,但是单核 N100 有 350

pve-win11-bench

又双叒叕跑了超电磁炮做测试,在打开 edge 的一瞬间就感觉到了卡顿。这还是在 win11 的全部系统组件几乎都是原生 arm 的情况下,所以我决定放弃 arm 下的 windows 环境作为远程桌面对象

pve-win11-test

外设测试

如无特殊说明,均是在 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 内核
  • panforstLinux kernel 兼容驱动,目前看性能还行。预计 6.10+合并入主线内核
  • Arm 官方驱动:好像只有安卓系统有

如果想要使用 redroid 的话,必须要使用瑞芯微的 5.10 内核,所以只能要么用 panfork、要么用官方系统。先用 armbian 内 5.10 内核跑一下 redroid 的测试吧

redroid 测试

Remote-AndroidGPU 加速的 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 的一半分数

gpu-redroid-antutu3d

gpu-redroid-antutu-status

跑一个 3D Mark Wild Life 压力测试看下稳定性,毕竟要 24 小时挂机的游戏的。实测由于没有电池+散热给力,稳定性 99.5%+,在台式机显卡里都是非常好的水平了。就是性能只有 8gen3 的 1/3 - 1/4 水平(1200 vs 4200),接近骁龙 865

gpu-redroid-wle

gpu-redroid-3dmark-status

不知道为什么,碧蓝航线无法启动,似乎是缺少了设备

突然想起来我以前有三蹦子账号,冤甚,起冬!

redroid-genshin

redroid-bh3

跑到蒙德挂机了差不多 12 小时,一共加起来 48 小时,原神也没闪退。看来稳定性还是可用的。测试了一下,碧蓝档案也可以启动,甚至是云游戏。悲甚

能启动的就真的是能启动,很多游戏我就进了登录界面,除非原本就有共通账号,不然不会试玩

  • 启动!
    • 原神
    • 崩坏三
    • 崩坏·星穹铁道
    • 明日方舟
    • 尘白禁区
    • 碧蓝档案
    • FGO
    • 战双·帕弥什
    • 公主连结 R
    • BiliBili
    • Todesk
    • Rustdesk
    • NTQQ
  • 寄!
    • 碧蓝航线

这里我要点名一个缩写为 blhx 的游戏,这么多游戏里就它一个打不开。查了 LOG 也看不出来到底是需要什么东西,有好心群友折腾了半天也跑不出来,看来不是个例

2024-04-30 注:最近觉得 cpu 性能不够,寻找 arm 替换方案,发现 cx8gen3 和 oracle 云的 arm 机器也跑不了3588 换 panthor 驱动 + wayland 渲染的安卓模拟方案也还是跑不了。黄鸡的 0.5 个程序员是真的麻

gpu-redroid-all-game

视频输入

可以用来当采集卡,配合 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-python3python3-pip这两个包就行。一个是因为旧有的 python2 已经被移除,一个是 python 的包管理软件,然后也把 pypi 源换成清华的。java 则是参考我之前的测试结果,选了 zing 发行版的 jdk这个性能比较强(最后还是选了 graalvm17zing 在预热阶段 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 认证失败,可能是权限问题),所以我重装了一次系统。因为先期迁移做好了准备,所以重新打包+重装+部署的时间加起来都没有一个小时

迁移 && 改造

我之前部署在树莓派上的程序主要分为三部分

  1. docker 内的镜像
  2. 以 root 身份安装的关键原生应用,如 nginx 和 cloudflare 的代理这种
  3. 以用户身份部署的统一管理格式的应用,比如说 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 吧