普通视图

昨天以前首页

折腾瑞芯微RV1126嵌入式开发板

2024年7月25日 10:24

2020年前后，当华为海思被美国制裁时，国内安防芯片缺口很大（安防领域，当时海思IPC SoC大约占有70%市场，DVR/NVR SoC大约占有90%市场）。之后群雄逐鹿，瑞芯微也适时推出了两款面向IPC的SoC芯片，RV1126（4K800万IPC）及RV1109（500万IPC)。RV1126采用四核32位ARM Cortex A7架构，有2T算力的NPU，适合用来做视频编解码，跑与视频相关的算法模型。

手边有一块闲置很久的基于RV1126的嵌入式开发板，1G内存，自带8G eMMC硬盘。闲暇之余，想用来安装宝塔面板，搭建nginx等环境，然后跑web应用。厂家提供的固件是基于 buildroot的，如此，需要从源代码开始，编译和配置自己需要各种软件和库。对此我一窍不通，难度太大，只能作罢。

RV1126开发板

最近发现厂家更新了固件，提供了基于Ubuntu的底层固件，之前的想法又冒出来了，试了试，居然成功了，这里做些回顾记录。

刷机

刷机方法与刷安卓手机类似。电脑首先安装usb驱动，瑞芯微有提供驱动安装助手–DriverAssitant_v5.0（下载）。驱动安装好后，开发板通过USB与电脑连接，识别到设备。

瑞芯微的刷机工具–RKDevTool（下载），刷机过程中可能出现的问题与安卓刷机基本一样，包括不限于USB线，设备连接，识别，驱动等方面。

RV1126开发板厂商提供的基于Ubuntu的固件–RV1126-Ubuntu-20.04-firmware_20240227（下载）。

环境搭建配置

刷完机，插上网线，因为设备默认DHCP，搜索查询到设备的IP，然后SSH登录。

SSH 登录

1panel面板

因为时常操作云服务器，此时第一想法是安装宝塔面板。却被提示在线安装的宝塔，不支持这个arm 32位设备。让去试试宝塔5.9。简单搜索了下，不知道去哪弄宝塔5.9的安装包，官方的离线安装服务里可能有旧版的，但要收费。（写此博文时，又在网络搜索一番，发现有好心人搜集整理了旧版本的宝塔，此处）

转念想到何不试试其他的面板程序，比如1panel。1panel面板官网写着支持armv7l服务器架构。试了下，果然安装成功。有宝塔的经验在先，1panel面板的安装，使用上手很快。终端SSH及文件管理，很直观，与宝塔的使用基本一致。

frp

为了方便SSH远程登录，及面板的远程管理以及后续web站点能外网访问，首先用上frp。用一台阿里云香港服务器（2C2G30M）做frp的服务端，配置好。虽然第一次使用frp，因工作原因，对p2p，nat穿透，端口映射，DDNS知识了解很多，所以对frp理解，上手，使用起来很容易。

frp的设计理念可能是要保持服务端配置的精简，统一（在客户端做各种区分），比如保持服务端唯一的对外http端口，https端口，ssh端口等。如果有多个对外服务（比如web应用），只需要在frp客户端做配置即可，通过绑定不同域名来区分不同web应用（而非常规的采用不同端口区分不同web应用），如此思路很清晰，就是有点费域名。:-)

持续将近半个月的frp使用下来，很稳定，速度也很好。当然，这可靠性多半要归我这台2C2G30M的阿里云香港服务器。看网上的讨论，这个系列的阿里云香港服务器很抢手，性价比很高。我比较看重的，回国内延时非常低，在广州ping值延时只有8-9ms，比广州服务器ping值还低。（对于我用来科学上网，非常完美）。

说个题外话，我曾持续（从一个月到一年时间不等）测试各种云的香港服务器（比如狗云，马云，鸡云，草云。当然还有大厂的，腾讯云，华为云，天翼云等），回大陆线路，表现最好最稳定，性价比最高的还是阿里云。

应用

解决了服务器远程管理，外网访问问题。剩下的就是搭建网站了。使用宝塔时，习惯一键安装NMP等环境。1panel也有类似功能，不过其提供的默认web环境是OpenResty，安装时却出了点状况，始终安装失败。

1panel的理念是一切皆docker。安装的所有应用均是基于docker的。安装OpenResty失败，起初以为是docker镜像源，网络问题。不过，这个很快排除了。

前段时间网络上讨论很多，docker hub及国内的众多加速服务在国内完全无法用，当然解决办法也很多。我比较喜欢的办法，对于个人用户，可以将常用的镜像通过GitHub action同步到阿里云容器镜像服务 ACR，然后选择公开或者私有，需要时从ACR拉取容器镜像。（见 docker_image_pusher）

这种方法，我使用多次，国内服务器上拉取容器镜像，速度很快，也稳定可靠。当然，更常规的做法是使用docker hub镜像加速，比如1panel提供的临时加速地址：https://docker.1panel.live 。目前大环境下，国内的docker hub镜像站几乎都关了。我上面提到的docker image pusher方法对于个人用户是非常实用的。

排除网络问题，查看日志，发现安装OpenResty失败的原因是因为1panel商店里上架的这个版本不支持我使用的armv7l处理器。此时恍然大悟，然后又有点忧心。相较于x86，armv7l算比较小众，很多docker应用可能没有适配。如果通过1panel自带的商店安装，估计很多安装不了。如此，对于这个开发版使用1panel面板作用不大了。当然1G内存，外加4核心处理器，本身有点鸡肋和尴尬。也只能用来跑些简单的web应用。

找到问题以后，手动安装了nginx/1.18.0，PHP 7.4.3-4ubuntu2.23 (cli)，这样能来跑静态及PHP站点了。

目前这个开发板上运行的web应用有：

1panel面板
frp
Pi Dashboard
twikoo（实验）
uptime-kuma
blog（节点之一）

之前在网友小宋的博客看见介绍的用来监控树莓派状态的应用Pi Dashboard，UI比较好看，起初试了在云服务器上跑，但是x86的服务器获取不到CPU温度。如今这个是arm的开发版，安排上。

通过docker安装的twikoo，uptime-kuma可以成功运行。

作为我这个hexo博客节点之一（目前我这个博客节点有：阿里云广州，华为云北京，京东云北京，海外netlify以及此开发板的香港服务器frp反代）。通过Github action构建，然后分发到不同节点服务器上，方法参见我之前的博文：博客网站更新总结-2023–Github-action及通过GitHub Action将博客网站等静态文件同步到云服务器。

考虑停电，断网，设备重启等意外情况，给相关程序加上开机启动，进程守护。同时因为只有1G内存，加上定时任务，定时清理内存，缓存。此时1panel面板的价值作用体现了。

前面提到frp是通过不同域名区分不同网站的，最后各web网站的访问地址是域名+端口，比如one.jiangyu.org:8090，two.jiangyu.org:8090。给这些源站套上CDN，就能不带端口，直接用绑定的CDN域名访问对应的web站点。只是这样一来，就更费域名了。:-)

还有一个问题。绑定CDN以后，我习惯强制https，如此需要给CDN上传SSL证书。如今SSL证书有效期已缩短到90天（我曾在6个月前的博文 SSL证书，部署及相关知识中总结过与SSL证书相关的知识，彼时证书有效期还多是1年，半年不到普遍都是90天了），如果自己的VPS部署站点，开启https，申请SSL证书，然后绑定，不断更新，这都能自动化完成。可是在CDN应用里，需要自己上传SSL证书，如果过期，需要重新再上传新的证书。如果使用的是大厂CDN，这个问题比较好解决，厂家开放了各种api，基于此很多大神帮忙造好了轮子，SSL证书申请，上传到CDN，部署，更新都能通过脚本自动化完成。可是对于小厂CDN，一般没开放api或者没有现成的造好的轮子，需要自己频繁手动更新SSL证书，是个大问题。

最近看到有某CDN小厂提供了名为证书无忧的服务，能很好解决上述问题。在CDN配置里，第一次先上传自己的SSL证书，在证书到期前，会自动更新有效期为 90 天的免费证书。目前公测期间这个功能免费，以后可能每次成功更新证书收费1-2元。这是个很好的功能，不知道会不会有其他CDN厂家跟进。

其他

这个开发板尺寸100 x 60mm，比树莓派略大，买来一个树莓派的亚格力外壳（外壳整体尺寸与这个开发板相当），重新钻孔，保护起来。买外壳时，看见店家有与外壳配套的散热风扇，也买了一个。测试了一段时间，对比发现，这个5V 0.2A的小风扇能给CPU降温5-6℃。不过因为RV1126这颗SoC面向的是安防，消费类IPC领域，低功耗，温度控制这块做得比较好。即使不加散热风扇，在室温30℃时，一般负载下运行时的最高温度也只在50℃上下，离会降频的85℃还很远。

这个开发板有个40pin 的 gpio接口，厂家文档说兼容树莓派的接口，除此没有更多资料。本来想着如同树莓派一样，接几个诸如温度，湿度这样的传感器，调试一下，资料欠缺，需要补的课很多，只能暂时作罢。

通过GitHub Action将博客网站等静态文件同步到云服务器

天一生水

2024年6月4日 10:59

原文

之前在博客网站更新总结-2023一文中简单提到过，借助Github action（使用easingthemes/ssh-deploy）将hexo静态博客同步到云服务器，实现自动化部署。

最近在折腾mkdocs，再次使用到通过Github Action将自动生成的静态文件部署到云服务器功能。这里做些详细总结，笔记。

将文件同步到远端服务器，可以使用ftp，sftp，ssh等协议。对于云服务器，通过ssh协议同步文件是很好的选择。这里我介绍的easingthemes/ssh-deploy即是利用Liunx/Unix下的rsync（remote synchronize）工具，借助ssh协议，实现本地端（Github）与云服务器端的文件同步。

在Github marketplace商店里能搜索到很多与easingthemes/ssh-deploy类似的同步工具，原理及使用大同小异。

ssh-deploy代码示例

采用ssh-deploy同步文件的代码示例：（可任意命名为.github/workflow/ci.yml）

## 部署到服务器
- name: Deploy to VPS
  uses: easingthemes/ssh-deploy@main
  env:
    # 托管在Github里的远程VPS服务器.ssh文件下的私钥id_rsa
    SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY_BJ_IPC }}
    # rsync的同步命令参数
    ARGS: "-avzr --delete"
    # Github workplace里生成的静态文件目录，即需要同步到远端VPS的文件/文件夹。
    SOURCE: "./site/"
    # VPS IP地址。也可以如同id_rsa私钥一样，托管在Github，然后采用动态参数，比如${{ secrets.SSH_IP }}
    REMOTE_HOST: 1.1.1.1
    # VPS默认用户名root。
    REMOTE_USER: root
    # 需要同步到的VPS目录
    TARGET: /www/wwwroot/ipc

以上，Github action与远程VPS连接，采用ssh方式登录（通过私钥），rsync同步文件。

为安全，将私钥托管到Github，然后采用变量表达（比如secrets.SSH_PRIVATE_KEY_BJ_IPC ）。如此，VPS的IP地址，用户名，同步的目录等参数均可托管到Github，然后采用此种变量表达，以避免明文暴露。

托管VPS的私钥

生成公私钥

登录vps，键入以下命令，生成公私钥。在.ssh目录下，会生成两个文件，id_rsa 为私钥，id_rsa.pub 为公钥。

1	ssh-keygen -m PEM -t rsa -b 4096

键入以下命令，将公钥导入authorized_keys文件

1 2	[root@host ~]$ cd .ssh [root@host .ssh]$ cat id_rsa.pub >> authorized_keys

如此便完成了公钥的安装。为了保证连接成功，确保以下文件权限正确：

1 2	[root@host .ssh]$ chmod 600 authorized_keys [root@host .ssh]$ chmod 700 ~/.ssh

配置ssh，打开密钥登录功能。
编辑 /etc/ssh/sshd_config 文件，进行如下设置：

1
2
3

RSAAuthentication yes
PubkeyAuthentication yes
PermitRootLogin yes

重启 SSH 服务：

1	sshd restart

到这里还有一个很重要的步骤：需要将私钥转换成pem格式：

1	ssh-keygen -p -f ~/.ssh/id_rsa -m pem

打开id_rsa，看看开头是不是—–BEGIN RSA PRIVATE KEY—–

托管私钥

Github里配置私钥。对应的项目仓库，Settings-> Security-> Secrets and variables-> Action-> Secrets将私钥托管在此处。

Github action托管私钥

选择New repository secret。

Name，自己命名，比如上述代码里命名为 SSH_PRIVATE_KEY_BJ_IPC，秘钥变量即为secrets.SSH_PRIVATE_KEY

1	SSH_PRIVATE_KEY: ${{ SSH_PRIVATE_KEY_BJ_IPC }}

Secret，将上述id_rsa文件（—-BEGIN RSA PRIVATE KEY—–开头的），全部复制粘贴。即完成了私钥托管。

rsync参数

easingthemes/ssh-deploy使用Linux rsync工具来同步文件。在rsync主页对其使用，常见参数有详细介绍，这里选择重要的命令参数总结在下面：

Short	Long	Description
-a	–archive	归档模式，表示以递归方式传输文件，并保持所有属性，它等同于-r、-l、-p、-t、-g、-o、-D 选项。-a 选项后面可以跟一个 –no-(OPTION)，表示关闭 -r、-l、-p、-t、-g、-o、-D 中的某一个，比如-a –no-l 等同于 -r、-p、-t、-g、-o、-D 选项。
-v	–verbose	表示打印一些信息，比如文件列表、文件数量等。
-z	–compress	传输过程中进行压缩。
-r	–recursive	表示以递归模式处理子目录。如果单独传一个文件不需要加 -r 选项，但是传输目录时必须加。
-l	–links	表示保留软连接。
-L	–copy-links	表示像对待常规文件一样处理软连接。如果是 SRC 中有软连接文件，则加上该选项后，将会把软连接指向的目标文件复制到 DEST。
-p	–perms	保持文件权限。
-t	–times	保持文件时间信息。
-g	–group	保持文件属组信息。
-o	–owner	保持文件属主信息
-D	–devices –specials	保持设备文件信息。
-u	–update	把 DEST 中比 SRC 还新的文件排除掉，不会覆盖。
	–delete	删除 DEST 中 SRC 没有的文件。
	–exclude=	排除不需要传输的文件，等号后面跟文件名，可以是通配符模式（如 *.txt）。
	–progress	显示同步的过程状态，比如同步的文件数量、同步的文件传输速度等。

rsync是增量备份同步，速度和可靠性都很好。
值得一提的是使用–delete这一选项，SRC中的文件及文件夹的任何改变都会同步到DEST，同时DEST中的如果有新增文件，使用–delete同步，DEST新增的这些文件会被删除。

Cache

在使用Github action生成mkdocs站点，然后托管到VPS过程中，发现每次mkdocs的deploy的时间都很久，看日志，大部分时间都花在了安装mkdocs的依赖库及环境上，而这些明显是可以缓存的。搜索了下，果然Github有cache action可以实现对环境及依赖库文件的缓存。Github cache action有中文的说明文档，但对如我一样的new hand，使用配置太过复杂，看了文档也不知道怎么用。一时陷入僵局。想到自己在同样通过Github action部署hexo时，deploy速度明显比mkdocs要快（Github action的workflows借鉴自网络，当时没深究），起初以为是hexo部署本身就要比mkdocs快。看了下对应的Github action的workflows文件，发现有个名为c-hive/gha-yarn-cache的Github action，恰恰就是用来缓存依赖库及环境文件的（最初我以为是来缓存生成的hexo静态文件的）。

看看gha-yarn-cache给自己的介绍：

1-liner yarn install cache for GitHub Actions.
GitHub Action caches improve build times and reduce network dependencies. However, writing the correct cache logic is tricky. You need to understand how the cache action (keys and restore keys) work. Did you know you’re not supposed to cache the node_modules folder? The setup is different per OS and takes a lot of space in your workflows. Not anymore!

哈哈，恰恰是对于像我这样不知道如何使用配置 Github cache action的new hand的。马上使用之。