LOADING...

加载过慢请开启缓存(浏览器默认开启)

loading

国产通用 ARM Cortex-A 开发板的一些问题

作为软件开发者，接触国产开发板（带的一般是国产通用的 ARM）的第一感觉就是，怎么资料那么难找（找到的也不一定有用），厂家怎么那么封闭（闭源），支持力度怎么那么细微（没有社区反馈交流讨论）等种种问题。这里主要以瑞芯微的 RK3399 （这几年应该是资料最多的了）来举例子，其他诸如全志、晶晨（电视盒子支持好些）对于开发板来说更是灾难。

资料

大多数所谓的资料，基本就是硬件参数描述的规格书，或者是 Linux 软件使用手册，甚至有时候内容都是错误的，如 NanoPC T4 的 WiKi 写道：

sudo upgrade_tool ul MiniLoaderAll.bin
sudo upgrade_tool di -p parameter.txt
sudo upgrade_tool di uboot uboot.img
sudo upgrade_tool di trust trust.img
sudo upgrade_tool di resource resource.img
sudo upgrade_tool di kernel kernel.img
sudo upgrade_tool RD

细心的你会发现，这些其实跟做培训的 Firefly 的 WiKi 是一样，有点不太清楚，是不是 Firefly 跟 Rockchip 合作，然后全部国产厂商都按模抄了，也不测试下能不能用，而这实际上是要简单加上 noreset 的，不然后续的操作都会 failed：

./upgrade_tool ef MiniLoaderAll.bin
./upgrade_tool ul MiniLoaderAll.bin -noreset

./upgrade_tool di -p parameter.txt
./upgrade_tool di -u uboot.img
./upgrade_tool di -t trust.img
./upgrade_tool di -re resource.img
./upgrade_tool di -k kernel.img
./upgrade_tool di -b boot.img
./upgrade_tool di -rootfs rootfs.img

./upgrade_tool rd

当然友善还算有资料，有 WiKi，有 18/19 年的板子镜像 23 年还在更新（虽然我们通常不会去用官方镜像，但是有时候作为参考，或者是他们那边开发设配会解决一些问题，这其实是非常好的），你像 OrangePi，WiKi 也是这两年才有的，镜像基本 19 年的板子就只有 19 年的镜像，当然比起其他国产，香橙派都已经算是佼佼者了，你就知道国产派都是些啥了……

由于 NanoPC T4 使用的是 Rockchip，所以刷机工具也是 Rockchip 提供的，结果 Rockchip 官网的 upgrade_tool 的链接是到 github 的，github 上面又没有该项目了，因为他们从 17 年 开始新的项目 rkdeveloptool，但是你没看错，23 年了，国产板子对国产 U 的资料还是过时的，且说还是国产 U 的步伐还特别慢的情况下……

对于 rkdeveloptool，编译倒是很简单：

emerge -v libgudev libusb
git clone https://github.com/rockchip-linux/rkdeveloptool
cd rkdeveloptool
aclocal
autoreconf -i
autoheader
automake --add-missing
./configure
make

但是哦，在 make 时候会报错，而这编译的 bug 别人在 issue 早给出答案，可是到现在都不修复，也好几年没动静，感觉项目都要黄了，修改 main.cpp 的 covertChipType 函数对 snprintf 的调用：

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wformat-truncation"
snprintf(buffer, sizeof(buffer), "%s", chip);
#pragma GCC diagnostic pop

从板子产商到 U 产商给出的工具链和资料来看，掉坑是情理之中的事。

闭源

基本所有厂商都是有一定的开源项目（如 Rockchip 的 Github，虽然几百年不动）和参与到大型开源项目（如 Linux Kernel，如 FFmpeg），但是你又说不上他们的开源程度，如他们产品对应的 Kernel DTS，还有修改 FFmepg 里的代码却不愿开源，导致无法维护自己的 FFmpeg Fork……

在 19 年以前，Rockchip 还有自己推的 rkmmp，然后需要 Linux 用户/开发者编译后再去调用 API，或者编译他们 Fork 出来的 FFmpeg 和 Hook 的 Chromium。编译 Chromium，那就真的要你机器的老命了，这个编译 FFmpeg 就还好：

apt install -y cmake
git clone --depth=1 https://github.com/rockchip-linux/mpp
cd mpp
cmake -DRKPLATFORM=ON -DHAVE_DRM=ON  -DCMAKE_INSTALL_PREFIX=/opt/mpp
make -j6
mpp_syslog_perror=1 ./osal/test/mpp_platform_test
make install

apt install -y libgmp-dev pkg-config libgnutls28-dev libass-dev libbluray-dev libdav1d-dev libdrm-dev libfreetype-dev libfribidi-dev libgsm1-dev libmodplug-dev libmp3lame-dev libopenjp2-7-dev libopenmpt-dev libopus-dev libpulse-dev librsvg2-dev libsoxr-dev libspeex-dev libopencore-amrwb-dev libopencore-amrnb-dev libsmbclient-dev libtheora-dev libv4l-dev libvidstab-dev libvorbis-dev libvpx-dev libwebp-dev libx264-dev libx265-dev  libxml2-dev libxvidcore-dev libgl1-mesa-dev libyuv-dev

git clone -b encoder --depth=1 https://github.com/hbiyik/FFmpeg
cd FFmpeg
PKG_CONFIG_PATH=/opt/mpp/lib/pkgconfig ./configure \
    --prefix=/opt/ffmpeg \
    --disable-debug \
    --disable-static \
    --disable-stripping \
    --enable-fontconfig \
    --enable-gmp \
    --enable-gnutls \
    --enable-gpl \
    --enable-libdav1d \
    --enable-libass \
    --enable-libbluray \
    --enable-libdrm \
    --enable-libfreetype \
    --enable-libfribidi \
    --enable-libgsm \
    --enable-libmodplug \
    --enable-libmp3lame \
    --enable-libopencore_amrnb \
    --enable-libopencore_amrwb \
    --enable-libopenjpeg \
    --enable-libopenmpt \
    --enable-libopus \
    --enable-libpulse \
    --enable-librsvg \
    --enable-libsoxr \
    --enable-libspeex \
    --enable-libtheora \
    --enable-libv4l2 \
    --enable-libvidstab \
    --enable-libvorbis \
    --enable-libvpx \
    --enable-libwebp \
    --enable-libx264 \
    --enable-libx265 \
    --enable-libxcb \
    --enable-libxml2 \
    --enable-libxvid \
    --enable-opengl \
    --enable-shared \
    --enable-version3 \
    --disable-vulkan \
    --enable-libsmbclient \
    --enable-rkmpp
make -j6
make install
LD_LIBRARY_PATH=/opt/ffmpeg/lib:/opt/mpp/lib /opt/ffmpeg/bin/ffmpeg  -encoders | grep -i rk

apt install -y meson
git clone -b v0.35.1 --depth 1 https://github.com/mpv-player/mpv
cd mpv
PKG_CONFIG_PATH=/opt/mpp/lib/pkgconfig:/opt/ffmpeg/lib/pkgconfig meson setup --prefix=/opt/mpv build -Dgl=disabled
PKG_CONFIG_PATH=/opt/mpp/lib/pkgconfig:/opt/ffmpeg/lib/pkgconfig meson setup build
meson compile -C build
meson install -C build
LD_LIBRARY_PATH=/opt/ffmpeg/lib:/opt/mpp/lib /opt/mpv/bin/mpv

这样编译出 MPV 会调用 rkmmp 的 FFmpeg，所以支持 rkmmp 对于 hevc 和 avc1 等的硬件解码，虽然有时候会绿屏。

到了 19 年后，也就是 5.10 之后，内核引入的 Hantro 支持 Rockchip 和 NXP，由于 rkmmp 在 Linux 自能自玩自嗨，所以 Rockchip 开始从 rkmmp 转为 rkvdec + hantro-vpu，于是之前的 Fork 的 FFmpeg 硬件加速用不了，又因为不开源无法继续维护更新为对 Hantro 的支持，所幸的是还有 Fork 出 FFmpeg 使用 v4l2-request 对 Hantro 的支持：

apt install -y libgmp-dev pkg-config libgnutls28-dev libass-dev libbluray-dev libdav1d-dev libdrm-dev libfreetype-dev libfribidi-dev libgsm1-dev libmodplug-dev libmp3lame-dev libopenjp2-7-dev libopenmpt-dev libopus-dev libpulse-dev librsvg2-dev libsoxr-dev libspeex-dev libopencore-amrwb-dev libopencore-amrnb-dev libsmbclient-dev libtheora-dev libv4l-dev libvidstab-dev libvorbis-dev libvpx-dev libwebp-dev libx264-dev libx265-dev  libxml2-dev libxvidcore-dev libgl1-mesa-dev libyuv-dev libudev-dev libxss-dev libxinerama-dev libxpresent-dev libzimg-dev

git clone -b v4l2-request-n6.0 --depth 1 https://github.com/jernejsk/FFmpeg.git
./configure \
    --prefix=/opt/ffmpeg \
    --disable-debug \
    --disable-static \
    --disable-stripping \
    --enable-fontconfig \
    --enable-gmp \
    --enable-gnutls \
    --enable-gpl \
    --enable-libdav1d \
    --enable-libass \
    --enable-libbluray \
    --enable-libfreetype \
    --enable-libfribidi \
    --enable-libgsm \
    --enable-libmodplug \
    --enable-libmp3lame \
    --enable-libopencore_amrnb \
    --enable-libopencore_amrwb \
    --enable-libopenjpeg \
    --enable-libopenmpt \
    --enable-libopus \
    --enable-libpulse \
    --enable-librsvg \
    --enable-libsoxr \
    --enable-libspeex \
    --enable-libtheora \
    --enable-libv4l2 \
    --enable-libvidstab \
    --enable-libvorbis \
    --enable-libvpx \
    --enable-libwebp \
    --enable-libx264 \
    --enable-libx265 \
    --enable-libxcb \
    --enable-libxml2 \
    --enable-libxvid \
    --enable-opengl \
    --enable-shared \
    --enable-version3 \
    --disable-vulkan \
    --enable-libsmbclient \
    --enable-libudev \
    --enable-libdrm \
    --enable-v4l2-request
make -j6
make install
LD_LIBRARY_PATH=/opt/ffmpeg/lib /opt/ffmpeg/bin/ffmpeg

apt install -y meson liblua5.2-dev
git clone -b v0.35.1 --depth 1 https://github.com/mpv-player/mpv
cd mpv
PKG_CONFIG_PATH=/opt/ffmpeg/lib/pkgconfig meson setup --prefix=/opt/mpv build -Dlua=enabled
meson compile -C build
meson install -C build
LD_LIBRARY_PATH=/opt/ffmpeg/lib /opt/mpv/bin/mpv --hwdec=drm

但是这里有个大问题，就是 Chromium 里头的播放不支持硬件加速，另外，截止到 23 年，RK3399 也只是对 h264/avc1 有硬件加速，h265/hevc 等都不支持，矩阵图可参考 Mainline Hardware Decoding，而且像 rkmmp 一样有时候会出现绿屏。

大多数人使用 Linux 做 Home Server 或者是 NAS 都是使用 Armbian，媒体 OS 则可能是 Lakka 等，这些 OS 发行版都是跟着 Kernel 的 Mainline 走，结果就是现在都是只支持 Hantro 那一套，所以对硬件解码很是残缺，但是你会看到即使是 23 年 B 站每次都会一大堆人在评论树莓派的时候强调自己用 Armbian （而非用 Android）的 RK3399 解码多强，如果不是水军，那就是网络空口自嗨党，导致你不熟悉行情，很容易被那些无知者误导。

Rochchip 从 rkmmp 到 rkvdec + hantro 的转换，你 Google 到的资料也只是 Armbian 论坛对于这些硬件解码发展不解，做出总结的一条帖子，你才知道已经不是 rkmmp，其它基本没信息渠道可以获取。当然，国产 U 嘛，可能需要的是百度查询而非 Google，但是查询结果出来的瑞芯微 23 年的硬件加速文章，基本都是 rkmmp，你就知道，你要走的路是多歪多曲了……

社区

国内的产品，即使有社区，也是一潭死水，所以真不怪很多国产厂商为啥没有社区。倒是这两年，OrangePi 开始傍上 Armbian 社区，看 Armbian 脸来发展，或许也是种无奈却不错的出路吧。

系统/架构

这个不算是国产 U 和 Board 的问题，但是先得明确 ARM 是不是适合自己玩或者当生产。除了硬解的问题，loader 比较封闭外，其实 ARM 对于系统很多的支持并没有想象中那么好（每个人玩的不太一样，大多数网民是倾向于随口说说一个主观认知而已），我自己再玩的过程，可能就会遇见：

  1. Retroarch 和 PPSSPP 等都没有 Linux ARM 官方二进制，虽然可以自己编译，那其实就是官方暂时并不 Care，所以可能出现问题，就不好处理了
  2. 像 Chez 这些，只对 ARM 32 位支持，而现在的 U 基本都是 64 位的
  3. BSD 对 ARM 的支持虽然早，但是力度不够，特别是 armv7（这里不分 32/64 来说），即使 FreeBSD 去年开始要重视 ARM，也只是对 ARM 64 位（非所有 64 位）的，起步估计从 RK3399 开始

性能/功耗

随随便便百度功耗 RK3399，都能给你从厂商到各个大 V 给你的宣传 ARM 或者 RK3399 的口号，高性能低功耗的。所以普罗大众都在说 ARM 功耗多好多好，要他们给出和 x86 能耗比优劣的时候，基本都给不出，还要强调不能比，就跟被洗脑的自干五一样。

严格来讲，是不能比，但很多时候我们的比较都非严格的，大概的对比才能得出性能和功耗来跟 x86 比利弊，如果一味强调功耗小不能比，那你是不是笔记本低压 U 不能和你台式 U 比性能能差值，一味强调跨架构不能比，你现在苹果 M2 不能和农企牙膏厂低压 U 比能耗。而实际上果子和牙膏厂网上的对比一大堆，只有说道这些基于 ARM 公版的 Crotex-A U 时，总爱抛出不能比，我们低功耗，不能比，而实际上，低个毛线。

简单做个功耗使用：

  1. 老笔电 Thinkpad T440s，i5-4200U 这 14 工艺落后的低压 U，包括屏幕，日常轻量使用 6-10W，待机 2W，播放高清电影 10-15W
  2. NanoPC T4，RK3399 火龙，日常使用，有时卡顿 4-12W，待机 3W，播放硬解电影 5-10W，软解电影 10-12W，有时候自动重启

对比 13 年牙膏厂的低压 U，RK3399 性能差几倍情况下，功耗却相差无几。

ARM 和 x86 也只能以理论来说，ARM 才更有能耗比，但是现在架构复杂，ARM 不是非常 r，x86 也不是非常 c，所以他们的实际差别不大，加上 x86 的成熟，很多通用计算机的场景（如 Home Server），x86 是更具优势的，更低的功耗，更好的软件支持，还能有更好的 ACPI。

除此之外，ARM 各自的能耗比也不能定为一致，ARM 和 ARM 之间的差距可不是一般的大，它们会受到工艺，7nm 肯定比 22nm 有更好能耗比，但是大多数国产通用 ARM 都是工艺比较落后的，去年出货的 RK3588 就以 7nm 和新 ARM 架构，以同功耗 4 倍性能于老前辈 RK3399，当然数值我是看评测的，我并没有高贵的 RK3588。除了工艺，还要看谁设计的，高通的 8G1 就远超 RK3588，至于苹果这种 M1/M2 的，大概是以后几代基于公版 ARM 大发展才能追得的上初代 M1 车位灯的吧（作为一个果黑，也不得不佩服果子的 U）。所以并不能纯看架构就得出能耗比多好，要具体到产品，有实际的数值支撑。