TLog

Android折腾重启报set_policy_failed:/data/adb

2026-02-05T20:10:11+08:00

TL;DR: 修改init脚本，把 init.usb.rc 中 encryption=Require 改成encryption=DeleteIfNecessary，在system分区中应用修改，再重启。

起因¶

调试 KernelSU，把 /data/adb 删了，manager创建了个新的。结果就这样。

原理¶

File based encryption. init脚本会在开机时配置/创建所需要的文件目录结构，但若所设加密策略与实际不匹配，就会报错要求擦除数据。

以LineageOS 23.0为例，

见 system/core/init/builtins.cpp：

    if (IsFbeEnabled()) {
        if (!FscryptSetDirectoryPolicy(ref_basename, options.fscrypt_action, options.target)) {
            return reboot_into_recovery(
                    {"--prompt_and_wipe_data", "--reason=set_policy_failed:"s + options.target});
        }
    }

又见 system/core/init/fscrypt_init_extensions.cpp：

bool FscryptSetDirectoryPolicy(const std::string& ref_basename, FscryptAction action,
                               const std::string& dir) {
    if (action == FscryptAction::kNone) {
        return true;
    }
    if (SetPolicyOn(ref_basename, dir) || action == FscryptAction::kAttempt) {
        return true;
    }
    if (action == FscryptAction::kDeleteIfNecessary) {
        LOG(ERROR) << "Setting policy failed, deleting: " << dir;
        delete_dir_contents(dir);
        return SetPolicyOn(ref_basename, dir);
    }
    return false;
}

而 init.usb.rc 中有：

on post-fs-data
    ...(skip)
    mkdir /data/adb 0700 root root encryption=Require

导致 /data/adb 出加密配置问题时系统会提示擦除数据。

幸好有办法在遇到错误时删掉整个目录……不然从备份恢复也够麻烦的……

为我的监控摄像头适配Thingino

2026-01-20T15:47:26+08:00

契机¶

因为一些原因，得到了一部“双目云台摄像头”。因为讨厌原系统依赖的云平台和私有软件，故尝试刷机/修改系统。这篇文章是根据进度日报对整个过程的复盘。

设备分析¶

摄像头型号： LY-SM-YT40
- 完全看不出名堂
厂商：合肥岭雁科技（linkintec）
生产企业：深圳市乔安科技（Jooan）
云平台：移动爱家

拆解过程概要¶

按压底部二维码的贴纸，发现两处可能的螺丝位，撕开（表扬一下，贴纸质量不错）符合预期。卸下螺丝，便能卸下摄像头的下半部分，暴露出本体与下部副摄像头的连接排线。解开排线，彻底分离下半部分外壳。

将云台轻轻旋转对齐至中位，发现四个螺丝孔位，推测它们固定了上半部分外壳，卸下后验证了想法。轻轻拆除上半部分外壳。

摄像头电路主体在云台半球后方暴露出来。为保证稳定性，云台电机和电源部分点有红色胶水。暂时可以不拆线路。观察发现云台上半球是直接扣进转轴，轻掰转轴两侧支架、取下半球。

卸下电机和散热硅胶块块，暴露出了SoC本体和NAND存储器，可以确认平台为Ingenic T40XP。

进一步拆解发现，靠近中间的两颗螺丝是镜头模组固定螺丝，而周边三颗螺丝才是主板固定螺丝。

固件备份¶

首先尝试了从串口终端直接备份，但被u-boot和系统双重密码挡下。又尝试了官方推荐的ingenic-cloner，但似乎没有现成的配置，并且电脑USB不认这台设备。手上也没有合适的工装。只好选择拆芯片上编程器来备份固件。

NAND型号为FORESEE F35SQA001G，容量128MiB，采用CH341A和 SNANDer 进行备份。备份速度挺慢的。重复备份操作，得到两份备份，对比确认读取无误。

snander -r dump.bin
snander -r dump2.bin

固件拆解¶

根据u-boot启动日志可见分区表（也可以从dump里的u-boot env中找到），对比binwalk结果判断，可以按它分割固件。

Creating 8 MTD partitions on "sfc_nand":
0x000000000000-0x000000100000 : "boot"
0x000000100000-0x000000200000 : "bootenv"
0x000000200000-0x000000600000 : "kernel"
0x000000600000-0x000001200000 : "rootfs"
0x000001200000-0x000001a00000 : "appfs"
0x000001a00000-0x000004c00000 : "config"
0x000004c00000-0x000005400000 : "appfs1"
0x000005400000-0x000005500000 : "confbak"

编写python脚本（也可以直接dd）处理固件，拆分各个分区。经检查，rootfs存放了系统通用基础组件，而appfs存放了streamer等服务的主程序。系统为busybox init。rootfs和appfs均为squashfs，可以通过squashfuse进行挂载。

其它次要分区有UBI格式的，处理起来比较繁琐，但若只是提取文件，可以使用ubi_reader：

uvx --from ubi_reader ubireader_extract_files ubi_partition_image.bin

从init脚本来看，rootfs在启动时仅仅是加载了WiFi驱动、设定一些性能参数，随后将控制权交给appfs的jzstart.sh进一步加载特定sensor驱动、启动主程序。

后续分析发现，部分设备GPIO配置明文存储在全局配置文件config.org（json，后缀表示origin）中，推测是为了方便复用相关软件。

修改固件获取shell¶

linux kernel的入口点由u-boot env给的cmdline确认，而它们恰巧又在bootenv分区，故我选择修改了bootenv分区的内容。编写了一个脚本，将txt格式的boot env转换成binary格式。头部四个字节是后续所有字节的CRC32值。

将cmdline中init=/linuxrc修改为init=/bin/sh，得到了修改后的bootenv分区，一样通过snander刷入NAND芯片：

# NAND写入前要擦除，snander不会自动处理
snander -e -a 0x000000100000 -l 0x000000100000
snander -w modded_env.bin -a 0x0000000000100000 -l 0x0000000000100000

虽然获取了shell，但没什么用处，只是导出了一份设备树。

初步适配Thingino¶

理解Thingino¶

Thingino使用Buildroot2构建，对每个摄像头都有自己的配置。我在ArchLinux上创建了个Ubuntu 24.04的rootfs用于环境搭建。复制了一份摄像头配置，参考项目文档开始编译。而测试发现master分支难以编译，须选用stable分支进行适配。

GROUP环境变量可以用来选择摄像头配置文件夹。比如默认是camera，但设置了GROUP之后，就会变成camera-$GROUP，方便区分不同状况的摄像头配置。而camera-exp就属于测试中的摄像头配置。

有了在u-boot env和设备配置文件中找到的GPIO信息，初步配置得以完成。

编译并安装¶

跳过编译过程。

由于开源版u-boot暂时缺少对NAND flash的支持，我便将NAND换成了16MiB的NOR flash，反正都能用。 ¯\(ツ)/¯

但是启动不了……每次启动后，u-boot会在清除env分区时将整个flash清空……花了点时间定位问题，是flash擦除页面大小和分区没有对齐，根源在flash驱动内部状态overflow。修好擦除大小问题后，成功通过串口看到了Thingino后台（不放图了，按F键进入failsafe模式）。

适配摄像头组件¶

到目前为止，设备能跑Thingino，但是摄像头、照明、联网功能全部失灵，需要适配/修复。

按钮和指示灯¶

按钮¶

按钮有两个，reset和call/通话。

按钮也好找，因为按钮是输入量，直接所有的GPIO读一遍，按住按钮再读一遍，就能找到了。

另外reset这个按钮有在配置里写出来。

指示灯¶

这个难搞，纯猜的。配置里有写照明灯的GPIO，之前有测出按钮的GPIO，猜了个范围，试了下，没想到猜对了。

不敢轻易将所有GPIO设置为输出试一遍就是怕不小心玩坏什么。

WiFi¶

WiFi是ATBM6012BX，这点可以通过3点轻松判断：

拆包检查既有驱动
查看芯片丝印
lsusb查看PID:VID

真没想到这里的WiFi竟然走USB。

WiFi模块的电源有个开关，很巧的是这个GPIO写在了原厂固件配置里。轻松配置好。但是在系统启动后遇到了意料之外的错误：

[   62.812011] atbm6012bx 1-1:1.0: Direct firmware load for /lib/firmware/atbm6012bx_fw.bin failed with error -2

不对呀，固件明明一起打包进去了，怎么会找不到？（-2代表-ENOENT，no such file or directory）没办法，clone一份kernel源码看看问题。找到drivers/base/firmware_class.c中这样写：

/* direct firmware loading support */
static char fw_path_para[256];
static const char * const fw_path[] = {
    fw_path_para,
    "/lib/firmware/updates/" UTS_RELEASE,
    "/lib/firmware/updates",
    "/lib/firmware/" UTS_RELEASE,
    "/lib/firmware"
};

原来固件默认加载位置就那么几个（fw_path_para也只是多自定义一个）……而WiFi模块驱动里写的固件名称是个绝对路径，相当于路径重复了两遍……

就先临时打个补丁改下吧。然后就好了，嗯。

摄像头传感器（sensor）¶

研究一番发现摄像头传感器走的是MIPI CSI，在预期之中。一开始是一点头绪都没有，就尝试直接把原厂驱动插进去看看能不能用。有点曲折的是我还不怎么会用buildroot。总之想办法塞进去后，它能用。

不过实际上是我先尝试逆向。使用Ghidra反编译原厂sensor驱动的内核模块后，提取sensor初始化参数，发现自己的逆向驱动有图像却很暗，非常不爽，感觉功亏一篑。折腾许久，甚至用Ghidra逆向了自己的内核模块，才发现程序流程出现了意外的分支，究其根源是switch-case中漏掉了一个break (XoX)

中间本想通过加载已有源代码来加快分析，但是加载所需配置非常头疼，完全搞不懂，所以没有一个header加载成功过…… QvQ

我的摄像头有两个sensor，也是逆向了才知道，主摄和副摄的数据线正好和SoC自己的顺序反过来。

尝试了用一个内核驱动服务多个同款sensor，结果不行，似乎因为共享内存问题，内核会Oops。还是别Oops为好，不差这点体积。

总之sensor驱动也就搞定了。然后我也成了Ghidra初级用户。

云台电机¶

云台用的是5线四相步进电机。从原厂固件中的脚本分析，电机的引脚同样写在设备全局配置中。对比了下既有配置，竟然还找到一款类似产品，Jooan出品。不过还是得测试。

SDK中4.4内核的电机版本与Thingino不兼容，我尝试把3.10的直接复制过去，发现用不了，怎么办呢？只好在结合4.4既有基础上从3.10的电机驱动程序那边引入对应的功能。

结果改着改着，发现原来3.10的电机驱动程序里藏了几个核心bug，也难怪直接复制之后不能用。主要问题包括：

把所有相位都通电当成了上电正常状态
遗漏的逻辑反转判断
在spinlock和interrupt上下文中使用不安全的gpio_direction_output()

在4.4内核的既有代码算法有点意思，会计算最大公约数、将斜方向移动分成相同的小段，尝试解决运动抖动的问题。可惜光这样还不够，抖动会在每一个小段的末尾发生，因为移动距离较短的方向会不断加减速。我的解决方法是，在每个小段上，将运动较短方向上的触发时机均匀地分散开，与较长的对齐，尽量保证两边消耗的时间相同。算法细节就不提了，没什么含量（还花了我不少时间，脑子不行叻）。不过interrupt上下文内不能做除法，就因为除以零会触发中断，这点算是学到了。

其它组件¶

运气比较好，什么IR-CUT、红外管之类的东西在配置里有写，我只需要测试一下就好。

不过关于扬声器GPIO，我一开始以为它是信号输出引脚，可实际是功放的开关，让我研究了半天。

优化调整¶

云台活动范围¶

云台电机的步进角为5.625/64，转一周是4096步，搞不懂为什么厂家固件参数给到了4200，实在难绷，余量留太多。

于是我根据限位器的角度测算了大致活动范围的步进数，应该差不多了，没必要转到底。

夜间模式自动切换¶

当前Thingino的日夜自动切换由prudynt控制，原理是观察sensor的exposure并与预设阈值判断。算是一种非常简单的防抖/滤波算法。就是……exsposure的范围太小了啦！1万哪里够啊，我这边最大值都56万了！通常数值是5万上下！

所以就，想办法把这个值的合法范围扩大到了100万。

结语¶

也没什么好说的，就是逐渐熟悉项目，逐渐适应项目，发现一个又一个问题，解决一个又一个问题。不久之后会忘光的吧，所以写点东西记录一下。

在这里丢一个编译好的固件。目前只有一个摄像头能用，而且禁用了Telegram Bot。录像够用，动作检测也是，够用。

家里云网络基础设施

2025-07-20T17:55:46+08:00

前言¶

不是哥们，你真的需要读这个？好好好，~~看来你的需求和我一样扭曲~~。

开门见山，我想要内网可控的DNS、CA、双栈网络，让每一个内网主机/服务都能有任意数量的FQDN用。在此基础上能有一定流量统计能力就好。

我曾用ArchLinux搓了个路由器，使用的是N3450 CPU的矿渣。那时候iptables仍是大众首选。因为种种维护难题、加法做太多（All in Boom），这套系统最终被淘汰，而我也转向使用专用路由器/固件。但是SOHO级路由器的能力……懂的都懂。我也试过往OpenWRT里丢一些专用的DNS、DHCP配置，让内网访问更便捷，但经常出现奇奇怪怪的小问题。虽然可靠性不是问题、不会断网，但用着总感觉很憋屈。我内网有不少依赖内部域名的服务，需要更可靠、更灵活的DNS。

这次使用某个ARM开发板构建自己的家里云网络核心路由器，OS选用Armbian。为什么这次不用ArchLinux？因为我不打算追新，也不想自己单独维护一份内核，或者引入什么莫名奇妙的兼容问题（没错我遇到过）。实话说我不怎么喜欢Debian的一些设计偏好，不过习惯了也还行。

这是我使用Armbian构建家庭路由器的过程整理，并不包含中间踩坑调试过程。实际操作过程中，会有不少相互耦合的服务。开始吧！

欢迎电邮提问&留言！（不过M$挺容易吃邮件的啊……）

操作环境¶

某ARM开发板
至少要有两个网口，有三个会轻松不少
Armbian(Debian Bookworm)

筋骨：网络划分¶

真的有人这么划分家庭网络么……

首先需要明白自己需要何种形式的网络结构。我的家里云设计比较扁平：使用一台核心路由器、网管交换机，划分3个VLAN，分别用于网络基建、家庭、实验网络。

- 调制解调器接入设备（光猫也是猫 (^ΦωΦ^) ）
|
- 路由器（本文重点）
|
- 网管交换机
  \_ Infra(wired)
  |_ Home(wired & AP)
  |_ Lab(wired)

Armbian默认采用Netplan配置网络。Netplan会为配置好的后端（systemd-networkd和NetworkManager）动态生成运行时配置。以systemd-networkd为例，系统默认配置位于/usr/lib/systemd/network，Netplan生成的配置会放在/run/systemd/network，而用户可以在/etc/systemd/network自由编写自己的特殊配置、配置覆盖等等。应用优先级从低到高依次为/usr/lib、/run、/etc。因此在配置合理的情况下，Netplan不会和用户自定义的systemd-networkd配置产生冲突。

有了Netplan，我的网络配置可以非常declarative：

# /etc/netplan/60-my-network-structure.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enmetaport0:
      match:
        # MAC address matcher is more robust
        name: "en*"
        macaddress: "00:00:00:aa:bb:cc"
      # set a custom interface name
      # take care of the prefix, so the rule can be matched again when
      # re-applying the config
      set-name: enmetaport0
  vlans:
    vlan-infra:
      id: 1
      link: enmetaport0
      addresses:
        - "10.101.0.1/16"
        - "fcf4:abcd::1/112"
    vlan-home:
      id: 2
      link: enmetaport0
      addresses:
        - "10.102.0.1/16"
        - "fcf4:aeae::1/64"
    vlan-lab:
      id: 23
      link: enmetaport0
      addresses:
        - "10.123.0.1/16"
        - "fcf4:dfdf::1/64"

之后netplan try试试看，没问题就netplan apply即时应用，当然重启一下也行。

杂音：PPPoE接入ISP¶

听说PPPoE太老了不适合云原生所以没有存在的价值。

Netplan和systemd-networkd并不支持对PPP上网的直接配置。好在这部分手写也不是问题。

配置上游接口¶

在netplan里激活需要用到的上游接口，这样PPP服务脚本那里可以省掉启用接口的步骤：

# /etc/netplan/60-pppoe-interface.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enupstream0:
      # it's a different port/interface!
      match:
        name: "en*"
        macaddress: "00:00:00:aa:bb:cd"
      set-name: enupstream0

可以先netplan apply一下。后面测试PPP需要用到这个接口。

配置PPP服务¶

首先安装ppp包：

apt install -y ppp

配置PPP服务。要写一份PPP配置及一份systemd服务脚本。

PPP配置¶

先来看PPP配置/etc/ppp/peers/enupstream0：

# /etc/ppp/peers/enupstream0
# debug mode
#debug

user "your account name / phone number"
password "your account password"

# bind interface
plugin rp-pppoe.so enupstream0

# Ensure a PID entry with specified linkname is made pppoe
# e.g. /run/ppp-enupstream0.pid
linkname enupstream0

# specifiy interface number, e.g. ppp0, ppp101
unit 101

usepeerdns
persist
# retry 10 times before reporting error(exit)
maxfail 10
defaultroute
hide-password
noauth

我的配置文件命名和网络接口一样，这是我的习惯，同时也方便后面的服务脚本套用这个名字。上面直接将密码写在了配置中，并没有遵循一些文章的推荐方式。我的上游用的是PAP验证，而非CHAP，若按推荐配置将密码存放到单独文件，还会因为验证配置文件名不同踩坑。总体上直接写单独一个配置里更好维护（家宽也不怕漏密码）。

之前运行过netplan apply的话，这里可以运行pon enupstream0启用服务测试一下。如果路由器自己能上网，那PPPoE大概没什么问题了。随后可以poff停止pppd服务，因为后面要用systemd让pppd成为一个正经的服务。

让pppd成为一个正经的systemd服务¶

写个服务脚本，网上抄的加点佐料，绑定对应网络接口和配置文件：

# /etc/systemd/system/pppd@.service
[Unit]
Description=PPP link to %I
BindsTo=sys-subsystem-net-devices-$I.device
After=sys-subsystem-net-devices-$I.device
After=systemd-networkd.service

[Service]
Type=notify
ExecStart=/usr/sbin/pppd call %I nodetach up_sdnotify
Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target

然后可以用systemctl enable --now pppd@enupstream0启用这个pppd服务并激活自启动。

获取IPv6并分配前缀¶

我的ISP提供了一个::/60前缀，可以直接通过DHCPv6/RA来获得，并不涉及PPPoE，但是相关配置需对应PPP的接口。之前ppp配置里写的是unit 101，那这里的接口就是ppp101。

先启用ppp101上的DHCPv6，虽说ppp101其实也不需要前缀，但下列配置最后一节还是给它分配了个：

# /etc/systemd/network/30-ppp101-ipv6.network
[Match]
Name=ppp101
Type=ppp

[Network]
DHCP=ipv6
DefaultRouteOnDevice=true
# necessary, to avoid messing with interface
KeepConfiguration=static
LinkLocalAddressing=ipv6
IPv6AcceptRA=yes

[DHCP]
RouteMetric=100
UseMTU=true

[DHCPv6]
# to hide our real hostname :P, explictly set one
Hostname=gate

# Don't use most of the other DHCP info
[DHCPv6]
#UseAddress=false
#UseDNS=false
UseNTP=false
UseHostname=false
UseDomains=false

# The lines below are optional, to also assign an address in the delegated prefix
# to the upstream interface.
[Network]
KeepConfiguration=yes
DHCPPrefixDelegation=yes
[DHCPPrefixDelegation]
UplinkInterface=:self
SubnetId=0
Announce=no

随后即可为我的实验网接口分配一个::/64前缀，还是公网，足够我的小网络用了。此配置是对netplan生成配置的自定义覆盖（注意文件路径）。

# /etc/systemd/network/10-netplan-vlan-lab.network.d/ipv6-pd.conf
[Network]
# we are the router, ignore others
IPv6AcceptRA=no
DHCPv6PrefixDelegation=yes

# Uncomment below if networkd should handle DHCP and RA
# e.g. you don't use dnsmasq as the DHCP server
#[Network]
#IPv6SendRA=yes
#DHCPServer=yes

# Delegated prefix
# use :auto or specify the interface, e.g. ppp0, ppp101
[DHCPPrefixDelegation]
UplinkInterface=ppp101
SubnetId=1
Announce=yes
Token=::1

# Optional custom local prefix
[IPv6Prefix]
Prefix=fcf4:dfdf::/64
Assign=yes
Token=::1

此时用systemctl restart systemd-networkd来重载配置。如果内网lab接口获取到了前缀，就说明配置成功啦！

连结：做个路由器吧！¶

Linux路由器，宁有种乎？

前面配置好后，Armbian并不会直接变成路由器的样子。为了对下游网络提供服务，需要开启转发功能、启用DHCP/DNS服务等等操作。

开启路由转发¶

需要打开一些内核功能。添加一个新的sysctl配置：

# /etc/sysctl.d/90-enable-ip-forwarding.conf
# This is IP forwarding
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

随后刷新配置（参考/etc/sysctl.d/README.sysctl）：

service procps force-reload

转发功能启用口扌立！

用dnsmasq作DHCP/DNS服务器¶

由于我的网络存在多个下游接口、划分了多个子网，同时开启多个dnsmasq实例是更合适的选择。此处以lab网络为例，介绍启用多dnsmasq实例的方法。

我计划将实例配置安置在/etc/dnsmasq.instance.d。我需要按Debian的风格为每个实例配置好配置文件所在目录：

# 总之先干掉单独的dnsmasq服务
systemctl mask dnsmasq

# 为vlan-lab实例编写基本配置
# 类似/etc/default/dnsmasq，不过仅保留了配置目录设置
cat << EOF > /etc/default/dnsmasq.vlan-lab
# setup config dir, and config blacklists
CONFIG_DIR=/etc/dnsmasq.instance.d/vlan-lab,.dpkg-dist,.dpkg-old,.dpkg-new
EOF

# 激活服务开机自启动，但是先别启动
systemctl enable dnsmasq@vlan-lab

然后点一份dnsmasq配置。dnsmasq必须只绑定到特定接口，并避免回环接口，不然会占用端口资源，导致其它实例无法启动。

# /etc/dnsmasq.instance.d/vlan-lab/main.conf
# Net prefix delegation is handled by systemd-networkd
# Dnsmasq only handles address allocation(DHCP) and hostname resolution
port=53
interface=vlan-lab
# do not bind loopback, otherwise other instance will fail to start
except-interface=lo
# the static addresses given to vlan-lab
listen-address=10.123.0.1
listen-address=fcf4:dfdf::1
#bind-interfaces
bind-dynamic

#no-hosts
#addn-hosts=/etc/banner_add_hosts
#expand-hosts
domain=lab
local=/lab/
resolv-file=/etc/resolv.conf

# IPv4
dhcp-range=10.123.100.0,10.123.200.0,255.255.0.0,1h
# router, DHCPv4, btw IPv6 uses RA not DHCPv6
# 0.0.0.0 is a special address referencing the machine dnsmasq runs on
dhcp-option=3,0.0.0.0
# DNS
dhcp-option=6,0.0.0.0

# IPv6
enable-ra
# custom prefix
dhcp-range=fcf4:dfdf::1:0, fcf4:dfdf::ffff:ffff, slaac, 64, 1h
# the prefix previously delegated
dhcp-range=::1:0, ::ffff:ffff, constructor:vlan-lab, slaac, 64, 1h
# RA on vlan-lab, interval 30 seconds, router lifetime is 1200
ra-param=vlan-lab,30,1200
# DNS, it will make the firewall rules very difficult to write if [::] is used,
# since one interface can have multiple independent IPv6 addresses.
dhcp-option=option6:dns-server,fcf4:dfdf::1

# Never forward plain names (without a dot or domain part)
domain-needed
# Never forward addresses in the non-routed address spaces.
bogus-priv

随后可以启动服务了：systemctl start dnsmasq@vlan-lab。其它实例的配置方法相同。DHCP能自动分发配置，我可太喜欢它了。

开启NAT¶

内网设备用内网地址无法直接上网，需要NAT。这一步用nftables实现。可以在/etc/nftables.conf中添加下面的内容：

table inet simple_srcnat
flush table inet simple_srcnat
delete table inet simple_srcnat
table inet simple_srcnat {

    define INTERNAL_NORMAL_IFS = {
        "vlan-home",
        "vlan-lab",
    }

    define INTERNAL_CRITICAL_IFS = {
        "vlan-infra"
    }

    define INTERNAL_IFS = {
        $INTERNAL_NORMAL_IFS,
        $INTERNAL_CRITICAL_IFS,
    }

    define OUTGOING_IFS = {
        "enupstream0",
        "ppp101"
    }

    chain forward {
        type filter hook forward priority mangle; policy accept;

        # MSS clamp
        iifname "ppp101" tcp flags syn tcp option maxseg size set rt mtu
        oifname "ppp101" tcp flags syn tcp option maxseg size set rt mtu
    }

    chain postrouting {
        type nat hook postrouting priority srcnat; policy accept;

        oifname $INTERNAL_CRITICAL_IFS drop

        # masquerade local addresses
        oifname $OUTGOING_IFS ip saddr 10.0.0.0/8 masquerade
        oifname $OUTGOING_IFS ip6 saddr fcf4::/16 masquerade
    }
}

使用nft -f /etc/nftables.conf加载配置。

简单说，上面的table启用了vlan-home和vlan-lab上所有内网地址的NAT，丢弃所有外部主动发往基建网络vlan-infra的包，并在ppp出口应用MSS钳制。

有了NAT，下游设备就能通过路由器中继上网啦。

我的名字我做主：掌控自己的DNS¶

姓名能给人力量，但也是强大的束缚。

改造网络很大一部分原因是要设立自己的私有DNS服务器，以便灵活建设内网服务。我选了home.internal做内网服务主要使用的域。

设立自己的权威DNS之Knot DNS¶

Knot DNS是一款开源的权威DNS服务软件。它不会像dnsmasq、smartdns之类向上游递归查询。用它就可以设立自己的内网顶级域名。为了保证兼容性，我打算拿下整个.internal顶级域名（事实是如果只拿部分二级域名，中间的递归DNS服务还是会把请求发到外部的根DNS去）。

Knot DNS服务配置，建议结合Knot DNS配置文档一同阅读。简单说，配置了监听端口，各个二级域名配置文件的位置，以及管理DNS的key。

# /etc/knot/knot.conf

# server listen at 5553
server:
    rundir: "/run/knot"
    user: knot:knot
    listen: [ 0.0.0.0@5553, ::@5553 ]

log:
  - target: syslog
    any: info

database:
    storage: "/var/lib/knot"

# some keys for standard DNS operations
key:
  - id: naive
    algorithm: hmac-sha512
    secret: generate-your-own!

  - id: home
    algorithm: hmac-sha512
    secret: generate-your-own!

# access control, for safety
acl:
  - id: deny_all
    deny: on

  - id: address_only
    action: update
    update-type: [A, AAAA]

  - id: naive_key
    action: update
    key: naive

  - id: home_key
    action: update
    key: home

# zone template. zones defined in `zone:` can use templates here and bring
# their own overrides
template:
  - id: default
    storage: "/var/lib/knot"
    file: "%s.zone"
    acl: address_only
    acl: naive_key

zone:
  - domain: INTERNAL
    acl: deny_all

  - domain: infra.INTERNAL
    acl: deny_all

  - domain: home.INTERNAL
    acl: address_only
    acl: home_key

生成key可以用keymgr，会和Knot DNS一起装好，举个例子（别用这个key！）：

# keymgr -t home hmac-sha512
# hmac-sha512:home:cVE3CZ0twnAmf6C7suhr8nJQTtdqo8RVmJkOC0WL5luandWazPrY7AtQJAEkE86HwzOcTla187fInNYZ5KkpPg==
key:
  - id: home
    algorithm: hmac-sha512
    secret: cVE3CZ0twnAmf6C7suhr8nJQTtdqo8RVmJkOC0WL5luandWazPrY7AtQJAEkE86HwzOcTla187fInNYZ5KkpPg==

key的作用是管理DNS记录。如果没有相关需求，其实也可以忽略。不过我后面需要自己设立一个内网DDNS服务。

为了让DNS工作正常，还需要添加SOA记录。

# /var/lib/knot/internal.zone
internal.       30      SOA     ns.infra.internal.  nomail.ns.infra.internal. 2025071601 3600 15 86400 3600
internal.       30      NS      ns.infra.internal.

# /var/lib/knot/infra.internal.zone
infra.internal.       30      SOA     ns.infra.internal.  nomail.ns.infra.internal. 2025071601 3600 15 86400 3600
infra.internal.       30      NS      ns.infra.internal.

# /var/lib/knot/home.internal.zone
home.internal.       30      SOA     ns.infra.internal.  nomail.ns.infra.internal. 2025071601 3600 15 86400 3600
home.internal.       30      NS      ns.infra.internal.

虽然配置好了权威DNS，但实际上内网设备还不会用它，需要别的伙伴帮一把。

用smartdns做中间件分流域名解析¶

做就要做彻底。要避免内网DNS请求发送到意外的地方去，就让smartdns处理好分流。

先开个smartdns在5552端口上，将内网域名和公网域名分流到各自的DNS，同时让smartdns自己应答：

# /etc/smartdns/smartdns.conf
# smartdns configuration

bind [::]:5552

# this name is the name of this server
# the optimal address of current host will be sent if querying this one
server-name ns.infra.internal
# same with above, but can be specified multiple times
ddns-domain anything.ns.infra.internal

server 119.29.29.29
server 223.5.5.5

# internal zone is handled by knot at 5553
server 127.0.0.1:5553 -group internal_knot -exclude-default-group

### Support wildcard or main domain matching
### /*.example.com/ (does not include example.com)
### /example.com/ (include example.com)
### also read: https://github.com/pymumu/smartdns/issues/1659
# including: infra.internal, home.internal
nameserver /internal/internal_knot
# somehow setting rr-ttl-min is required, otherwise the ttl will be set to 600
domain-rules /internal/ -no-cache -no-serve-expired -response-mode fastest-response -rr-ttl-min 30 -speed-check-mode none

再用nftables把内网指向本机53的流量劫持过来（不然端口分配有得烦），用IP来判断是不是发给内网的DNS请求：

# in /etc/nftables.conf
table inet simple_port_forward
flush table inet simple_port_forward
delete table inet simple_port_forward
table inet simple_port_forward {
    define INTERNAL_INTERFACES = {
        "vlan-home",
        "vlan-lab",
        "vlan-infra"
    }

    chain local_hijack {
        # Hijack DNS requests sent to this router
        # redirect dns requests to smartdns instead of dnsmasq
        # smartdns will forward back per subnet resolution to dnsmasq
        tcp dport 53 redirect to :5552
        udp dport 53 redirect to :5552
    }

    chain prerouting {
        # priority: dstnat
        type nat hook prerouting priority -100 ;

        # internal requests sent to this router
        iifname $INTERNAL_INTERFACES ip daddr & 255.0.255.255 == 10.0.0.1 jump local_hijack
        iifname $INTERNAL_INTERFACES ip6 daddr & ffff::ffff:ffff:ffff:ffff == fcf4::1 jump local_hijack
    }
}

使用nft -f /etc/nftables.conf加载配置。

这样smartdns就全权负责局域网的所有DNS请求啦，一切尽在掌握！

注意当经由路由器上的dnsmasq向smartdns请求所配置的ddns-domain、server-name时会让结果变成回环地址，所以不建议让dnsmasq做下游直接和客户端交互。

让本机的systemd-resolved也转发internal tld请求到自己的Knot DNS¶

因为netplan/systemd-networkd，路由器自己默认用的DNS服务器是systemd-resolved，本机要特殊考虑一下。

新增配置文件，让路由器自己也用smartdns查询：

# /etc/systemd/resolved.conf.d/dns_internal.conf
[Resolve]
DNS=127.0.0.1:5552
Domains=~.internal.

部分保留dnsmasq的主机名查询能力¶

只需而且只能保留本地域名的查询能力，毕竟我们有smartdns了，还要避免干扰它。

在/etc/smartdns/smartdns.conf中添加下面的内容，将局域网域名的查询分流到各个dnsmasq。注意IP地址要匹配，之前配置的dnsmasq相当于直接绑了IP。

# in /etc/smartdns/smartdns.conf
# Some requests are forwarded to related dnsmasq instance

#server 10.101.0.1:53 -group dq_infra -exclude-default-group
server 10.102.0.1:53 -group dq_home -exclude-default-group
server 10.123.0.1:53 -group dq_lab -exclude-default-group

domain-rules /home/ -g dq_home -no-cache -no-serve-expired
nameserver /home/dq_home
domain-rules /lab/ -g dq_lab -no-cache -no-serve-expired
nameserver /lab/dq_lab

设立自己的DDNS服务¶

直接用TSIG key对客户端的要求有点高，略微麻烦。看到别人自己搓了个restful API的DDNS服务，我也搓了一个，从http请求中获取key和需要更新的域名、并直接取请求来源的IP地址，自动更新域名信息。对于我的内网来说，足够好用了。我的参考实现：ddns-server.py。

参考Config：

# config.toml
knot_key = "hmac-sha512:home:your_key_data“

参考更新指令：

# generate a new token, can be reused later
curl http://ns.infra.internal:5561/new_token/prefix.home.internal/the_super_token
# update DNS A record, the new ip address is the request source address
curl -4 http://ns.infra.internal:5561/update_ddns/test_name/the_token

都给完整源码了，看两眼呗，也不长不是么。

后备隐藏能源：用NUT管理UPS¶

Backup UPS可不是Backup！

在连接UPS的机器上装nut，在被UPS保护的机器上装nut-client。

nut的默认配置已经能实现低电量自动关机，在配置好nut-server和upsmon监控的上游后，不需要额外配置upssched之类的东西。

upsmon的脚本可选，用于手动处理某些UPS事件，除非和其它系统集成，通常用不上，毕竟服务都有systemd之类的东西管理。

不过需要写个关机脚本自动关断UPS，这个脚本没在软件包里。Armbian用systemd，所以可以照抄下面的脚本（flag文件的位置要改）。UPS会在收到关机请求后等待所设置的delay后再关闭。

#!/usr/bin/env bash
# this file is /lib/systemd/system-shutdown/nut-killpower
# do remember to chmod 755 on it
# read `man systemd-poweroff.service` for more information

# set accordingly, see /etc/nut/upsmon.conf
KILL_POWER_FLAG=/run/nut/killpower
# action is either "halt", "poweroff", "reboot" or "kexec"
ACTION=$1

[ "_$ACTION" = "_poweroff" ] || exit 0
[ -e "$KILL_POWER_FLAG" ] || exit 0
upsdrvctl shutdown

结语：懒得写了¶

后续我进一步部署了Step CA、node_exporter+Prometheus等服务，适当完善了防火墙配置。内网ACME HTTPS和简单的流量统计也都有了。

在具体的实施中，有些配置细节，例如配置文件拆分（nftables、smartdns），想全部写到文章里显得冗杂。

家里云搞那么复杂干嘛啊，哎呀不写了不写了。

主要参考资料¶

https://lars.hupel.info/articles/personal-dyndns/
https://blog.sww.moe/post/soft-router-network
https://major.io/p/dhcpv6-prefix-delegation-with-systemd-networkd/
https://wiki.debian.org/IPv6PrefixDelegation
https://wiki.archlinux.org/title/Router
https://briandouglas.ie/sqlite-defaults/

为Pixel 4a开启DeviceAsWebcam功能

2025-01-10T22:37:23+08:00

反正已经在自行修改编译Android系统了，目的就是围绕自己的需求做功能改进。功能多多益善嘛。尽管本来只是想实现USB NCM网络共享……

记录发泄一下頭の痛み……

切入点？几乎是无头苍蝇¶

一开始我只是想把老手机的RNDIS实现改为USB-NCM。恰巧在过程中看到了部分（后证实无用）用configfs配置USB UVC gadget的init脚本、加上调试时看到了UVC组件的警告日志，受到吸引，想为旧手机Pixel 4a实现这个功能，发挥余热。

我依稀记得支持Oneplus 7的YAAP有实现过相关功能，而两款手机差不多处于同一时代，应该有参考的价值。在GitHub组织项目下乍一搜索，好像没看到什么有趣的东西。但是在搜索引擎上发现了Android官方的相关文档。看起来……只要把提到的东西都实现就好？

一步步探索¶

内核4.14，老东西啊，得慢慢整整。

linux开启必要的config¶

就是把驱动里有关USB gadget、Function FS以及UVC的部分启用嘛，没什么大不了的！

启用prop、修改init脚本¶

起初我以为内核开了相关功能就能自动支持，我错了。

为启用Device as Webcam功能，需要设置 ro.usb.uvc.enabled=true，这样相关菜单才会在设置里显示出来。调试的时候我就先用Magisk/KernelSU的模块功能凑合凑合了。

改init就比较讨厌了，完全没有相关经验，只能凭借自己的编程直觉猜猜猜。事实上由于自己对Android编译系统如何将这些脚本导入并不了解，我围着错误的遗留脚本修改了很久！为了使用兼容的USB PID/VID，我在GitHub上搜索了相关代码commit，也顺带在yaap的仓库里发现了可以参考的脚本。各位的风格不尽相同，我尽量参考。

在HAL中加入UVC gadget支持¶

官方文档中的案例给的是AIDL HAL的例子，但是Pixel 4a使用的是HIDL。我不清楚如何从HIDL迁移到AIDL，好在发现二者的代码结构类似。最后我以相当hacky的方式在代码中插入旧版接口中不存在的常量/枚举类对应值，强行兼容相关接口。

不仅要改 device/google/sunfish，还要改 hardware/google/pixel 把遗漏的case补上。

为什么只是改HIDL而非迁移AIDL？

看起来Pixel 4a USB HAL的gadget部分用到了私有库，被标记为proprietary。目前已经是拆分后的样子，部分USB HAL迁移到了AIDL，但gadget部分仍然是HIDL。 Pixel系列还有另外几部设备状况相同。

V4L2节点黑名单¶

部分系统视频组件（摄像头、编码器等等）也和V4L2一样使用 /dev/videoN 节点暴露出来，而Device as Webcam服务要找的端点是gadget模块初始化后新创建的节点。服务会顺序遍历所有节点，寻找并选择能输出视频流的节点。为了避免报错（实际摄像头节点被占用）和错用（用了转码节点之类），需要把既有能找到的所有节点屏蔽掉，这就是本节所述黑名单。

此黑名单可用rro overlay的形式覆盖 com.android.DeviceAsWebcam 服务暴露的配置。

说起来我一开始一直以为程序调用的V4L2节点是现有的，浪费了不少时间调试。

对于Pixel 4a，需在 android_code_root/device/google/sunfish 添加对应修改，可以仿照既有例子改改、GitHub搜索类似例子。最后的黑名单（res/raw/ignored_v4l2_nodes.json）：

[
    "/dev/video0",
    "/dev/video1",
    "/dev/video2",
    "/dev/video32",
    "/dev/video33",
    "/dev/video34"
]

有预览了，但是不认V4L2节点¶

日志里看不到什么错误，甚至提到打开了相关的File Descriptor。检查服务程序代码发现预览和视频编码传输在两个线程上运行。

上位机dmesg一直报 Failed to query (GET_DEF) UVC control 2 on unit 2: -110。超时？怕不是单纯没反应。

直觉告诉我服务无声忽略了内部错误。

内存不足？内存怎么会不足？¶

在logcat中有发现：

Unable to request V4L2 buffers from gadget driver: Out of memory

检查邻近日志，发现 swiotlb buffer is full，这又是什么？在网上寻找到相关案例后，明白了这是个USB相关的缓存，默认就16MB，好像会影响一些设备使用。不管了，先试试看，临时提升缓存容量到128MB：

su -c "echo 128 > /sys/module/usbcore/parameters/usbfs_memory_mb"

报错消失了，晚点一起丢init脚本里。

还是不行？没有输出？¶

是我init脚本没写对？还是我漏了什么配置？

反复尝试后再度检查服务代码，原来Device as Webcam服务用到了老内核驱动尚未完全实现的VIDIOC ioctl接口。

怎么办？不知道，但是可以大力出奇迹。查找主线内核相关commit，然后疯狂cherry pick，不好一次合并就多pick一些，多多pick，多多pick……

唉不是，你这内核怎么有非主线的UVC功能实现？扬了！Revert！

终于，大力成功奇迹，我也终于让USB有了视频输出。关键commit是实现VIDIOC_ENUM_*

终于在上位机上看到视频输出了¶

我欣喜若狂，开始pick pick pick更多commit，却不知道危机正在靠近……

也就pick了数十个UVC gadget相关的commit……也许不算多……

中途拔USB线就panic？¶

我有印象！大概率是驱动释放太快、内存释放出了问题！Pick: usb: gadget: uvc: allow for application to cleanly shutdown

怎么没输出了？危机来临！¶

从有到无了，怎么办？Bisect！不过由于中间commit很乱，所以遇到了不少需要调整commit顺序保证编译通过的状况。

谁竟想结果是scatter gather多线程性能优化完全用不了。用不了用不了，用不了就扬了！总体尝试了四条路线：

维持原状（OK）
在没有sg的基础上合并新功能（OK，极麻烦，难解耦）
- 甚至让我整出了protocol error
在既有UVC1.5的基础上实现VIDIOC_ENUM_*（NG，后面甚至带来modem crash，没有panic）
直接在最新状况下用hack的方式强制走普通模式（OK，参考yaap得来的结果）

这编译内核真的累啊，不知道为什么每次编译要固定16分钟，像是没有增量编译，测试起来非常考验人心态。

偶尔用一段时间后会panic？¶

要是有日志看就好了……等等，android有pstore！panic日志可以在 /sys/fs/pstore/* 找到，发现了下面的内容：

[  903.307954] c5   1126 SMP: failed to stop secondary CPUs 0-7
[  903.908145] c5   1126 set_restart_msg: set restart msg = `KP: HwBinder:1113_1 PC:__pi_strcmp+0x88/0x154 LR:uvc_alloc+0x1f4/0x3b4'

uvc_alloc？emm，搜索后发现是自己漏了一个fix。之前提到的实现VIDIOC必须功能的commit引入了问题，修复用的patch是usb: gadget: uvc: don’t put item still in use。

感叹：内核折磨人¶

内核折磨人啊(´；ω ；｀)

来看看输出～哎不是，红蓝颜色通道怎么反了啊！¶

好不容易有了信号，想照照人、却成了Avatar？而且还只在上位机、预览没事？

就是那种，把OpenCV BGR当RGB处理的感觉。幸运的是包括YAAP的维护者在内有几位开发者已经摸清了问题点：高通设备上用硬件加速编码会带来颜色问题，包括RB通道翻转。

恐怕DeviceAsWebcam这个程序就只是为了Tensor平台……

OBS上的小问题¶

通常用QV4L2来测试摄像头应该是够用。分辨率、编码均能正常调整，就是帧率好像没有真的变过。

但是在OBS这边，每次修改摄像头配置后，摄像头输出都会卡住，需要重载UVC功能/重插USB线，尽管手机上的预览还是没有问题。

暂时找不到问题根源。

总结¶

改kernel config、打开功能
修uvc gadget驱动、补全API
hack HIDL、强兼UVC
编init脚本、初始化节点
改DeviceAsWebcam服务、适配qcom平台

学到了：

git log -G
git rebase –update-refs
git workspace

又及：

cherry pick时的信条：相信开发者（实际WTF）
~~什么叫垂直整合、全栈开发啊~~

<( _ _ )><(=- . -=)><(=~ O ~=)>……<(=- . -=)>

累了。纯发泄。

podman使用及与systemd集成

2024-12-29T11:27:07+08:00

曾经不喜欢docker而将podman视为替代。脱离docker依赖后又渐渐懒得用podman了。如今因为偷懒重拾podman，发现它成长超乎我想象，非常符合我现在部署各种服务的需求。

这里简单记录一下。

开端¶

部署Perplexica，实在不想往虚拟机环境里塞更多难以管理的环境了。项目提供的是docker，而我又不喜欢docker，于是重拾Podman，顺带学习一下。

不喜欢docker哪些点？

其实就一点：深度依赖守护进程。这引发了下列问题：

临时修改配置很繁琐
还是个root级别服务，不够安全
重量级程序

懒到极致¶

podman-docker¶

太懒了，直接照抄docker的命令！用到podman-docker直接包裹podman、试图兼容docker命令行。目前来看podman发展下来并不想完全兼容docker命令行，不过多数命令的格式仍然相同。

但是选择这种非原生操作仍然会引入不确定因素。

podman-compose¶

podman-compose是第三方为podman编写的docker-compose。虽然和docker-compose有不少差异，但是主要功能类似。

podman-compose up -d，哎，服务就起来了。但是这里暗藏玄机，在后面会一一显现。

systemd集成¶

手搓systemd配置用podman compose启动服务发现问题¶

先说结果：和我想的不太一样，不能用老方法。

不能用系统服务配置以非root身份开启容器，会遇到一些crun运行环境问题。
即便解决了前述问题，crun仍会fallback cgroupfs（因为systemd）。
这也不是大问题，但是容器启动后service会挂掉，类似于用户登出带走了所有程序。
情况类似，就算登陆用户后手动直接启动的容器也会在登出后被停止。

我就不想把折腾再写一遍了 |ω・`）

这里就引出了几个问题：

以用户身份启动容器需要什么条件？
如何用systemd以用户身份启动容器？

在尝试过程中，发现日志里有提示：

The cgroupv2 manager is set to systemd but there is no systemd user session available
For using systemd, you may need to log in using a user session
Alternatively, you can enable lingering with: `loginctl enable-linger 1000` (possibly as root)
Falling back to --cgroup-manager=cgroupfs

看起来像是要维护一个session。linger又是什么？这个问题晚点再答。

尝试podlet（失败）¶

赶时间，所以在网上直接找podman、systemd集成的相关文章。其中就有讲到podlet。

因为compose配置文件不能完美兼容、现有pod使用了尚未支持的参数，podlet无法生成合适的服务配置。因而无法使用podlet。暂时搁置。

不过如果启用单个容器还是可以看看podlet的。

遵循podman-compose提示¶

在折腾途中，发现podman-compose有一个systemd指令，直接在perplexica的源码文件夹里执行看看：

Perplexica bash> podman-compose systemd      

you can use systemd commands like enable, start, stop, status, cat
all without `sudo` like this:

        systemctl --user enable --now 'podman-compose@perplexica'
        systemctl --user status 'podman-compose@perplexica'
        journalctl --user -xeu 'podman-compose@perplexica'

and for that to work outside a session
you might need to run the following command *once*

        sudo loginctl enable-linger 'user'

you can use podman commands like:

        podman pod ps
        podman pod stats 'pod_perplexica'
        podman pod logs --tail=10 -f 'pod_perplexica'

有不少有趣的东西哎：

一个compose相当于k8s里面的pod，这点我之前完全忽略了（生疏了）。
随系统启动的服务可以只用某个用户自己配置的服务。前提是 enable-linger。

Note

按理从文档看应该要逐渐deprecate podman-compose，但是目前看来还是很好用的嘛！

systemd user service 简述¶

由systemd管理的Linux系统为每个用户提供了管理自己服务的方法，user instance。通过user instance，用户可以自行管理自己的user service。用户自定义的服务配置文件通常位于 $XDG_CONFIG_PATH/systemd/user，暂且忽略由系统提供的用户服务模板。

每次用户登陆（创建新会话）时，会创建一个systemd user instance并启动用户激活的服务。给几个现实中还算常见的例子：

单用户下的pipewire守护进程
gpg-agent
appimagelauncherd
代理服务，随用户登陆启动

可以读 ArchWiki 了解更多。

linger？¶

通常情况下，用户服务只会在用户创建首个活跃会话（也就是登陆）时自动启动，并在用户登出全部会话后自动停止。

这挺智能的不是吗？但是对于想使用专用非root用户、借由podman-compose启动容器的我来说是个问题。可能出于类似的原因，systemd自233版本后提供了 loginctl enable-linger。

用户被标记linger后，其用户服务会随系统启动一并启动，并且不会因为用户登出而停止。

podman-compose与systemd集成¶

需要先装个服务模板，根据提示，以root用户执行执行下面一条命令：

podman-compose systemd -a create-unit

服务模板会写至 /etc/systemd/user/podman-compose@.service。

接着进一步根据提示，注册所需要的compose服务。在docker-compose.yaml所在位置执行命令注册服务（配置会被写入 $XDG_CONFIG_PATH/containers/compose/projects）：

podman-compose systemd -a register

最后激活并启动服务，标记用户为linger

# 注意名称替换
systemctl --user enable --now 'podman-compose@perplexica'
# 下面的指令只需执行一次
sudo loginctl enable-linger "$USER"

之后可以重启机器验证一下容器是否正常启动。

探寻¶

podlet & quadlet¶

看起来使用quadlet是大势所趋，就想看看它到底是什么。

rootless是podman精华的一部分。但是podman没有daemon！它需要一个daemon维护容器启停，aka orchestrator。而这时的orchestrator可以是systemd，毕竟它已经管了一堆服务了。

systemd支持systemd-generator来更灵活地从其它配置文件生成systemd的服务配置。安装podman会同时安装一个generator配置，其会调用 quadlet 生成正确的systemd服务配置。quadlet并不在通常的可执行文件位置（*/bin之类），用户通常无需手动运行它。对于podman quadlet，generator会将quadlet配置转换为合适的systemd服务配置。

那podlet是干什么的？简单说它可以从现有的podman命令、compose文件、container或pod生成quadlet配置文件（*.container 文件），丢进合适的位置重载后就能用啦。不过看起来podlet功能不甚完善，至少在compose场景下有很多不兼容之处。

一些小问题¶

容器连接宿主¶

对于docker，有个 host.docker.internal 用来连接宿主机。只不过需要配置一下 extra_hosts，增加 'host.docker.internal:host-gateway'。

与docker类似，podman提供了 host.containers.internal 来连接宿主，而且不需要任何额外配置。迁移时需要注意。

如果服务认hostname，那还要格外注意呀！

结语¶

现在我部署服务大多在母机上开容器再手动配置环境、改写systemd配置文件，偶尔在必要的时候开个虚拟机。既然podman可以轻松与systemd集成，那未来向podman容器迁移也不错？用起来比nix简单不少，也有一定的reproducibility。

k8s？一个人用的私有云要什么k8s啊增加心智负担 (ノ=Д=)ノ┻━┻

用FreeCAD做刚体和流体的物理仿真

2024-06-08T12:23:08+08:00

太长不读版：把FreeCAD插件CfdOF用到的软件用Nix打包好，得到可靠的软件环境后，分别做了亚克力弹性组件和导风漏斗的物理仿真。

大量篇幅给了nix软件打包，想读物理仿真实战可以直接从目录跳过去。

一切的起源：自制导风漏斗反射了风扇气流¶

想用12cm机箱风扇做一个排风系统，直接用FreeCAD凭感觉建了个导风漏斗模型，但没想到用3D打印的实物测试发现，风扇的气流几乎都从扇叶末端的缝隙中反射出来了，变得很诡异。

FreeCAD作为一款强大的参数建模工具，。据闻有一些公司在基于FreeCAD做二次开发。听从业网友说，“SolidWorks能做的FreeCAD也能做，做不了的都不能做，平时工作用UG多，FreeCAD缺点在运行卡顿”。这个软件也很自然地成为了以ArchLinux为主力操作系统的我所使用的机械设计软件。

我以前用FreeCAD做过亚克力模型的刚体仿真，自然而然就会想怎样用FreeCAD做流体仿真。实际上我几乎没有流体力学相关知识，想先把软件环境搭建起来，之后应该船到桥头自然直吧！

首先是失败的工作环境配置尝试！¶

我使用的是ArchLinux。FreeCAD在官方软件源里有，直接可以装，CfdOF工作台也可以通过Addon-Manager安装，所以比较麻烦的地方是安装CfdOF依赖的流体计算软件。

CfdOF依赖的流体分析相关软件包括：

OpenFOAM，流体动力学计算软件
cfmesh，算是OpenFOAM的附件，CfdOF维护者（oliveroxtoby）提供了一份能配合最新OpenFOAM编译的版本
hisa，也算是OpenFOAM的附件，源码貌似也源自CfdOF维护者（oliveroxtoby）另外提供的渠道，但是改没改过不知道

初次尝试：直接在Arch上安装OpenFOAM AUR包¶

作为忠实的Arch用户，我一定会去看AUR的。不过由于见到过AUR包捆绑了一堆“垃圾”的案例，我还是对AUR包进行了审核。

一看有不少OpenFOAM的用户软件包：openfoam-org、openfoam-com、openfoam-com-precice、openfoam-com-git、openfoam-9-org。怎么办呢，直接看最近更新过的把，想办法装新的。

去看openfoam-org的评论区，看到有人报编译问题，尚无明确解答。此外看到软件维护者置顶了说，在arch4edu仓库（类似archlinuxcn）有预编译版本。再一看软件编译依赖还有其它的AUR包，我有些不愿意自己编译。

我知道能用yay、paru之类的装，但是看了下OpenFOAM官方仓库编译说明里写的1小时编译时间，我选择暂时搁置这一路径。

尝试偷懒：希望能直接用`arch4edu`仓库编译好的软件包¶

参考arch4edu的官方说明，我给自己的Arch加上了arch4edu仓库。随后我直接就装上了openfoam-org。

走这步需要在终端开FreeCAD，因为OpenFOAM套件环境要source一个脚本加载。软件包也在/etc/profile.d加了那个脚本，但我暂时不想重新登陆。先试试，按下面列出的指令操作：

source /etc/profile.d/openfoam-11.sh
ofoam # 这是个加载环境的指令，实际是 source /opt/OpenFOAM/OpenFOAM-11/etc/bashrc
freecad

暂时不管加载环境时可能的报错（后面发现也不用管），加载CfdOF工作台后，进入preferences，左侧栏选择CfdOF，在其中找到Run dependency checker的按钮，点击检查运行环境。告诉我这个：

Checking CFD workbench dependencies...
Checking FreeCAD version
FreeCAD version: 0.21
Checking for OpenFOAM:
System: Linux
Runtime: Posix
OpenFOAM directory: /opt/OpenFOAM/OpenFOAM-11
Running  echo $WM_PROJECT_VERSION
Executing: echo $WM_PROJECT_VERSION
11
OpenFOAM installation found, but unable to run command: 'PySide6.QtCore.QProcess' object has no attribute 'Timedout'

命令行显示的错误：

  File "/home/user/.local/share/FreeCAD/Mod/CfdOF/./CfdOF/CfdConsoleProcess.py", line 153, in waitForFinished
    if self.process.error() != self.process.Timedout:
                               ^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'PySide6.QtCore.QProcess' object has no attribute 'Timedout'

Why? 搞不明白。怎么会有个Python+QT的报错？总之这看上去很不妙啊……这条路大概率行不通，或者走到最后会很麻烦(´_>`)。

果断把相关包删了，把arch4edu移除，也不想试别的了。因为我知道有一种方法能更稳定地复现环境——nix。

完美可复现的开发环境：使用nix-shell¶

这一步也一波三折，但还是成功了！

基本的nix-shell环境¶

官方教程用shell.nix的实现声明式shell环境写得不错，比直接在搜索引擎里搜nix-shell tutorial找到的东西靠谱。正式写配置前最好再通读一遍nix基本语法。

由于搜索引擎的搜索质量不佳，我一开始这样写nix：

# freecad-cfd.nix
{ pkgs ? import <nixpkgs> {} }:
pkgs.mkShell {
    # nativeBuildInputs is usually what you want -- tools you need to run
    nativeBuildInputs = [ pkgs.freecad ];
}

但我想，这样还得在系统里配置nix-channel，不算完全固定的配置，于是根据前面提到的教程改成了下面这样：

# freecad-cfd.nix
let
  nixpkgs_ball = fetchTarball {
    url = "https://github.com/NixOS/nixpkgs/tarball/nixos-24.05";
    sha256 = "1q7y5ygr805l5axcjhn0rn3wj8zrwbrr0c6a8xd981zh8iccmx0p";
  };
  pkgs = import nixpkgs_ball { config = { allowUnfree = true; }; };
in
pkgs.mkShell {
    # nativeBuildInputs is usually what you want -- tools you need to run
    nativeBuildInputs = [ pkgs.freecad ];
}

区别在于，前者需要输入参数，后者不接受参数并自行定义了用到的数据（从网络获取，并锁定了内容的哈希值）。

如何获取内容哈希值

nix计算哈希的方法和命令行工具（sha256sum）不同。对于fetchTarball这种会自动解压的操作，可以使用nix-prefetch-url --unpack $url命令来获取内容哈希值。当然也可以直接写个错的哈希值，看错误报告写的实际哈希值是什么（可能会以哈希类型-开头，比如sha256-，可以一起复制），再添进配置。

同理把nixgl也在下面加上，这个我也是读了前述教程才明白怎么配置。

# freecad-cfd.nix
let
  nixpkgs_ball = fetchTarball {
    url = "https://github.com/NixOS/nixpkgs/tarball/nixos-24.05";
    sha256 = "1q7y5ygr805l5axcjhn0rn3wj8zrwbrr0c6a8xd981zh8iccmx0p";
  };
  nixgl_ball = fetchTarball {
    url = "https://github.com/nix-community/nixGL/tarball/310f8e49a149e4c9ea52f1adf70cdc768ec53f8a";
    sha256 = "1crnbv3mdx83xjwl2j63rwwl9qfgi2f1lr53zzjlby5lh50xjz4n";
  };
  pkgs = import nixpkgs_ball { config = { allowUnfree = true; }; };
  nixgl = import nixgl_ball {};
in
pkgs.mkShell {
    # nativeBuildInputs is usually what you want -- tools you need to run
    nativeBuildInputs = [
        pkgs.freecad
        nixgl.nixGLIntel # Mesa OpenGL implementation (intel, amd, nouveau, ...).
    ];
    # 看到nixgl仓库有人开issue提到了这个，nix-shell workaround
    shellHook = ''
        export LD_LIBRARY_PATH=$(nixGLIntel printenv LD_LIBRARY_PATH):$LD_LIBRARY_PATH
        '';
}

nixGL wrapper的选择

可以读一下nixGL官方仓库的介绍，选用合适自己的wrapper。此处所用的是适用于Intel显卡、AMD显卡、或Nouveau驱动下NVIDIA显卡的wrapper。

用下面的指令构建并进入所配置的shell环境，运行FreeCAD，如果FreeCAD正常运行就算小功告成！

# 运行后会构建并打开一个shell环境
nix-shell freecad-cfd.nix
# 要让图形系统正常工作，需要套个nixgl
nixGLIntel freecad

打包OpenFOAM¶

看了OpenFOAM官方的编译说明，挺简洁的，但是没写编译环境依赖。于是我参考两个AUR包（主要是openfoam-com）、在nix这边复（照）现（抄）了一遍编译流程。除了kahip、adios之类的辅助工具尚没有在nixpkgs里的包，其它基本都有。由于nix包的位置不固定，需要多写一小段shell脚本打印openfoam的环境位置，方便其它程序使用。我直接在nixpkgs里找包来抄stdenv.mkDerivation的用法。

# openfoam/default.nix
{ lib, stdenv
, cmake
, boost
, bzip2
, cgal
, fftw
, flex
, openmpi
, paraview
, parmetis
, scotch
, zlib
}:

stdenv.mkDerivation rec {
  pname = "openfoam";
  version = "2312";

  src = fetchTarball {
    url = "https://develop.openfoam.com/Development/openfoam/-/archive/OpenFOAM-v${version}/openfoam-OpenFOAM-v${version}.tar.gz";
  };

  buildInputs = [ boost cgal paraview parmetis scotch openmpi fftw zlib ];
  nativeBuildInputs = [ cmake bzip2 flex ];

  configurePhase = ''
    echo "# Preferences for arch-linux
    export WM_COMPILER_TYPE=system
    export WM_MPLIB=SYSTEMOPENMPI
    # End" \
    > etc/prefs.sh

    ./bin/tools/foamConfigurePaths \
      -adios adios-system \
      -boost boost-system \
      -cgal cgal-system \
      -fftw fftw-system \
      -metis metis-system \
      -paraview paraview-system \
      -scotch scotch-system \
      ;
    '';

  buildPhase = ''
    export FOAM_CONFIG_MODE="o"
    unset FOAM_SETTINGS
    source ./etc/bashrc || echo "Ignore spurious sourcing error"
    ./Allwmake -j
    wclean all
    wmakeLnIncludeAll
    '';

  installPhase = ''
    install -d $out/opt/OpenFOAM/ThirdParty-v${version} $out/etc/profile.d
    cp -r $(pwd) $out/opt/OpenFOAM/OpenFOAM-v${version}
    chmod -R 755 $out/opt/OpenFOAM/OpenFOAM-v${version}/bin
    chmod 755 $out/opt/OpenFOAM/OpenFOAM-v${version}/etc/*

    install -d $out/bin
    echo 'echo $(readlink -f "$(dirname $0)/../opt/OpenFOAM/OpenFOAM-v${version}")' | \
      install -Dm755 /dev/stdin  $out/bin/openfoam-home.sh
    '';

  meta = with lib; {
    description = "The free, open source CFD software developed primarily by OpenCFD Ltd since 2004";
    homepage = "https://www.openfoam.com/";
    license = licenses.gpl3;
    platforms = platforms.all;
  };
}

然后把这个包加到freecad-cfd.nix里：

# freecad-cfd.nix
let
  ...
  openfoam = pkgs.callPackage (import ./openfoam) { };
  ...
in
pkgs.mkShell {
  buildInputs = [
    ...
    openfoam
    ...
  ];
  ...
}

在中间buildPhase遇到了脚本明明存在却无法执行的问题，提示required file not found，感觉很奇怪，打开对应文件一看：

#！ /bin/sh
...

<(=╯▽╰=)>原来是shebang的问题……要时刻记住nix不遵守FHS，可我该怎么修呢？好消息是nix环境下有提供patch shebang的工具：patchShebangs，它能自动递归地修补所有检测到的shebang。本着最小化修改的原则，我找出了必须修改的脚本，在configurePhase的开头加上这些修改流程：

# openfoam/default.nix
configurePhase = ''
  patchShebangs wmake/w*
  patchShebangs wmake/scripts
  patchShebangs Allwmake
  ...
  ''

编译完后运行CfdOF的依赖检测，告诉我尚不支持OpenFOAM 2312版本。我在此时才注意到了CfdOF还依赖另外两个工具cfmesh和hisa（此前都没察觉到）。

仔细看了看CfdOF的说明文档：

Prerequisites:
- OpenFOAM Foundation versions 9-10 or ESI-OpenCFD versions 2006-2306

顺便看看arch4edu里的openfoam软件包的版本：

arch4edu/openfoam-com v2312-1
    The open source CFD toolbox (www.openfoam.com)
arch4edu/openfoam-org 11.20240116-1
    The open source CFD toolbox (www.openfoam.org)

这也不对！那也就更没必要回去看AUR包的方法了。Arch这点是这样，软件只有最新，有点烦。

我需要降级！还好此时的降级只是把版本号、源码包、源码包的hash调整一下。借机还可以把版本号和hash参数化：

# openfoam/default.nix
{...
, version ? "2306"
, hash ? "1z0sna5jxlyfz8s7vi28m47iwjjjbzg9ycz5maz2gymchg7lw6v7"
}:
stdenv.mkDerivation rec {
  pname = "openfoam";
  inherit version;
  foam_hash = hash;
  src = fetchTarball {
    url = "https://develop.openfoam.com/Development/openfoam/-/archive/OpenFOAM-v${version}/openfoam-OpenFOAM-v${version}.tar.gz";
    sha256 = foam_hash;
  };
  ...
}

OpenFOAM的部分就差不多搞定了。最后在shellHook里加上自动加载OpenFOAM配置的代码：

# freecad-cfd.nix
shellHook = ''
  ...
  source ${openfoam}/opt/OpenFOAM/OpenFOAM-v${openfoam.version}/etc/bashrc || true
  ...
  '';

打包`cfmesh-cfdof`、`hisa`两个插件¶

原本这两个插件都可以由CfdOF工作台自己安装，但本着创建可复现环境的心，尝试把它们也打包成nix的软件包（derivation）。打算先复用OpenFOAM软件包的框架，改改编译指令看看能不能成功。

下载了源码，看了下都用和OpenFOAM一致的wmake系统来构建，那估计编译也是执行根目录的Allwmake脚本。但是没法一下子看懂编译产物究竟放哪里去了。

先直接用装好OpenFOAM的nix-shell环境编译一遍看看（注意要记得加载OpenFOAM环境配置），查查最后的可执行文件（hisa）都去哪里了。结果是/home/user/OpenFOAM/user-v2306/platforms/linux64GccDPInt32Opt/bin，那我猜编译产物会自动丢到/home/user/OpenFOAM/user-v2306/platforms/linux64GccDPInt32Opt。从环境变量的值来看，实际上编译产物会自动安装到$WM_PROJECT_USER_DIR/platforms/$WM_OPTIONS/{bin,lib}中，而$WM_PROJECT_USER_DIR与$HOME有一定关联。考虑到在nix构建derivation过程中的$HOME实际并不存在，则考虑修改$HOME为临时文件夹应该就可以修改安装位置。最后将编译产物复制到$out合适的位置中即可。

脚本改改改……buildInputs里加上openfoam，毕竟这些东西要依赖OpenFOAM的工具编译、绑定对应的版本。运行一下nix-shell试试看。

直接构建提示缺zlib？zlib.h找不到了？看来是编译依赖没写全。把OpenFOAM的复制过来……啊不用，其实有更简洁的方法：

buildInputs = [ openfoam ] ++ openfoam.buildInputs;

把OpenFOAM的依赖一起加进去！

由于所使用的cfmesh-cfdof及hisa的源码来源并没有版本管理，为了让一切可以复现，将源码包一并附上。于是加载源码包的代码就变成了下面这样：

# In both cases, the zip is automatically extracted
src = 
  if (version == "bundled") then
    ./cfmesh-cfdof.zip
  else
    fetchzip {
      url = "https://sourceforge.net/projects/cfmesh-cfdof/files/cfmesh-cfdof.zip/download";
    }
  ;

stdenv.mkDerivation默认会自动解压源码

如果提供一个压缩包给src属性，stdenv.mkDerivation会尝试自动解压，此时需确保nativeBuildInputs提供了解压所需工具。压缩包内单独存在的顶级文件夹会被缩简，默认工作目录会变成源码根目录。我曾因为一些操作和巧合，只编译了一半hisa。

使用stdenv.mkDerivation遇到的默认状况问题

一开始没改动configurePhase，没想到默认的居然会自动用cmake配置，一定记得视情况手动调整，用不到的话可以加一个dontUseCmakeConfigure = true;。同理buildPhase之类也有自己的默认配置，需要注意。

总之到最后搞定了。

不知为何写到这里已经没什么动力继续写环境配置的细节问题了。

一些小修小补¶

除了特殊配置，甚至还要修一些bug，真是没想到。

FreeCAD的数据存储位置最好不要在家目录吧¶

想让整个环境portable的话，肯定不能丢家目录了。经freecad -h指引，我找到了FreeCAD的官方启动配置文档，添加了几个环境变量。

shellHook = ''
    ...
    export FREECAD_USER_HOME=$(pwd)/freecad-state/home
    export FREECAD_USER_DATA=$(pwd)/freecad-state/userdata
    export FREECAD_USER_TEMP=$(pwd)/freecad-state/temp
    ...
    '';

CfdOF检查paraview版本时得到了错误的版本信息¶

CfdOF得到的paraview版本号是"canberra-gtk-module"，没错还包括引号。很奇怪啊。

直接在命令行看看paraview的版本号：

> paraview --version
Gtk-Message: 16:27:34.014: Failed to load module "canberra-gtk-module"
Gtk-Message: 16:27:34.015: Failed to load module "canberra-gtk-module"
paraview version 5.11.2
> paraview --version 2>/dev/null
paraview version 5.11.2

看样子检测版本的时候把标准错误输出流的内容也处理了，通常情况下不需要读stderr才对。

修改了一下代码，正常了。

--- a/CfdOF/CfdTools.py
+++ b/CfdOF/CfdTools.py
@@ -1178,7 +1178,7 @@ def checkCfdDependencies(msgFn):
             proc.setProcessEnvironment(env)
             proc.start()
             if proc.waitForFinished():
-                pvversion = proc.readAllStandardOutput() + proc.readAllStandardError()
+                pvversion = proc.readAllStandardOutput()
                 pvversion = QTextStream(pvversion).readAll().split()
                 # The --version flag doesn't seem to work on Winodws, so quietly ignore if nothing returned
                 if len(pvversion):

把几个软件包丢一个包里¶

nixpkgs能这么做，nixgl能这么做，我也要这么做！

相当于搓了一个库，刚好也可以复用既有代码支持多个版本：

{ pkgs }:
let
  openfoam-2306 = pkgs.callPackage (import ./openfoam) { };
  openfoam-2312 = openfoam-2306.override { version = "2312"; hash = "0wgfyz4q7xr0vlv4znfxpxyp8jb53q5pl17k312dyb3x8gkdx2z4"; };
  cfmesh-cfdof = pkgs.callPackage (import ./cfmesh-cfdof) { openfoam = openfoam-2306; };
  hisa = pkgs.callPackage (import ./hisa) { openfoam = openfoam-2306; };
  cfmesh-cfdof-unstable = cfmesh-cfdof.override { version = "unstable"; };
  hisa-unstable = hisa.override { version = "unstable"; };
in {
  inherit openfoam-2306 openfoam-2312;
  inherit cfmesh-cfdof hisa;
  inherit cfmesh-cfdof-unstable hisa-unstable;
}

不过用overlay的方式好像更合适。暂时不改了，除非之后要加kahip。

FEM工作台检测不到已装的求解器¶

想着流体分析的环境都搞定了，一块把刚体计算的部分补上呗，反正就多装几个求解器。FreeCAD dependencies列出了很有用的信息，我在Nixpkgs搜索站点把FEM的依赖都搜索了一遍，发现还能多装两个有限元分析求解器：calculix和elmerfem。可用求解器数量大于零就不用我像之前给OpenFOAM打包那样了。

把依赖加进去后构建shell，结果发现FreeCAD检测不到我装的求解器。由于nix不遵守FHS，我没法写死求解器路径，所以只好想办法修bug。

FreeCAD有选项开启自动从常见位置找求解器可执行文件，我猜它就是从PATH环境变量里搜索那些东西。calculix的可执行文件是ccx，以此出发，在FreeCAD源码中搜索，最终找到查找可执行文件的代码，其中有一段是这样：

        // first check the environment paths by QFileInfo
        if (QFileInfo::exists(QString::fromLatin1(binaryName.c_str()))) {
            return binaryName;
        }

binaryName是可执行文件的名称，例如ccx。这QT方法看着怪怪的，不像是找可执行文件的方法，倒像加载所给路径的方法（像python的sys.path）。

在自建LLM、搜索引擎、QT官方文档等的联合帮助下（火热的ChatGPT恰好失效了），我搓了一个基本的测试程序验证了我的想法（毕竟直接重新编译FreeCAD并验证太费劲）：

// main.cpp
#include <QFileInfo>
#include <QStandardPaths>
#include <QString>
#include <iostream>

int main(int argc, char* argv[]) {
  if (argc != 2) {
    std::cerr << "Usage: " << argv[0] << " <path to executable>" << std::endl;
    return 1;
  }
  QString executableName(argv[1]);
  QString executablePath = QStandardPaths::findExecutable(executableName);
  QFileInfo fileInfo(executablePath);
  if ( fileInfo.exists() && fileInfo.isExecutable()) {
    std::cout << "The binary exists and is executable." << std::endl;
    std::cout << "Binary location: " << executablePath.toStdString() << std::endl;
    std::cout << "FreeCAD's code test result: ";
    if (QFileInfo::exists(executableName))
      std::cout << "found" << std::endl;
    else
      std::cout << "not found" << std::endl;
  } else {
    std::cout << "The binary does not exist or is not executable." << std::endl;
  }
  return 0;
}

所以后面用QStandardPaths::findExecutable来替代了QFileInfo::exists，修正了相关问题。

但仍然有个问题：如何整合进nix脚本？

结果使用了overrideAttrs这个方法来改写原本包的属性，加上自己的补丁：

# some bug hotfix, only for freecad 0.21.2
freecad-patched = pkgs.freecad.overrideAttrs (finalAttrs: previousAttrs: {
    patches = previousAttrs.patches ++ [ 
        ./patches/0001-Fem-fix-searching-3rd-party-binaries-in-system-path.patch
    ]; 
});

patches属性为什么能生效？

nix的软件包用到了nix标准库中的stdenv.mkDerivation这个工具，可以理解为某种函数或编译脚本，根据参数生成编译成果。

物理仿真实战¶

折腾了那么久软件环境，总该干点实在的对吧！

软件环境声明

以下内容均基于FreeCAD 0.21.2，所有软件环境可用文末提到的nix-shell配置复现。

亚克力弹性按钮仿真¶

亚克力/PMMA是常用外壳板材。通过合适的切割，可以用亚克力实现一些方便的弹性组件。不过这个对切割精度有一定要求，有些亚克力厂可能做不了，或者因为怕损失不接单。

作为示例，我就简单绘制一个弹性按钮3D模型作为示范。如何建模我就不详细写了，完整的示例模型见模型附件。参考材质为3mm厚的PMMA板材。

参考FreeCAD官方的FEM教程，依次操作。

切换到FEM工作台
创建用于存放各种分析配置的分析容器实例
创建所需约束，本案例仅需选择固定面、受力面。由于约束与面相关，按钮中间需要用某种方法单独划块受力面（比如画个草图pad一下）。此处配置受力面受力1N。
添加模型材质。这里选择亚克力。
生成模型网格。官方教程说建议把这步放在准备工作里的最后一步，因为牵扯到模型。这里使用gmsh生成网格。先选中模型，再点击按钮，在新的菜单中先点击Apply，再点击OK，单纯点OK不会更新网格模型。如果提示gmsh报warning了，可以多点几次Apply重试，不然可能影响到后续求解器计算。
创建求解器对象。这里需要选择与你安装的求解器匹配的选项。如果使用了文末提供的nix-shell环境，则可以使用calculix和elmer求解器。此处使用calculix。
双击刚刚创建的求解器对象，选择合适的分析类型后，依次点击Write .inp file、Run CalculiX按钮。计算结果就出来了，但现在什么都看不到，需要进一步处理。
选中结果，点击显示结果（Show Result）按钮，在打开的菜单中，选中Max Sheer Stress可以看到受力情况。在下方Displacement处勾选Show并调整Factor即可观察形变情况。

至此已完成亚克力板受力仿真分析。

示例模型不适合加工

示例模型过于精细，与实物图例有较大差异，加工比较困难，良率应该不高，切勿直接套用。

导风漏斗气流仿真¶

这是我最初想解决的问题，怎么拖到了最后！这也没有现成的教程文档，有点难啊！

CfdOF项目README写道，还没有正式的文档可用，但有几个Demo可以看。考虑到我想做的基本是个风机管道（duct），我就打算参考duct示例来做做看了。点我获取本案例的模型文件。

Demo中提供了几个宏程序，可以快速构建一个示例模型，只需要计算即可。但我肯定要自己手动在我自己的模型上操作一遍啦。基本流程和FEM差不多。

缺失的计算流体动力学知识

笔者并没有流体动力学专业背景，也没有积累相应的知识，因此不能深入理解一些配置选项，选取的数值可能很离谱，总之可能造成一些误解，务必小心。

构建气流管道模型。注意在仿真时用的模型是流体流过的地方。这里我制作了一个参数化的管道，并单独构建了气流区域的模型。
切换到CfdOF工作台，添加分析方案容器。此时会多一个analysis-container，以及其下的四个配置项：物理模型、流体属性、流体初始态、CFD求解器。不过暂时先不改。
将管道模型的面标记为对应类型，设置流体边界。在菜单中点击Add后点击需要添加的面。Inlet面设置的气压是1.28e+02 kPa，数值是我根据手上的管道风机猜的。此处分别添加wall、需注意由于文件中有多个模型，不建议设置默认面属性，以免造成影响。此外建议不要移动目标物体的位置，不然会有奇妙的视觉效果 :)。
回到之前略过的，设置流体初始状态。实话说我不知道怎么讲解，设置了一下初始压强。
设置物理模型。查了下术语后，觉得这里应该选个湍流模型。
设置流体属性。有个空气模板我就直接选了。
添加模型网格。先选中管道模型，再点击添加网格的按钮。在菜单中依次点击Write mesh case和Run mesher。
双击CFD求解器，接下来可以进行计算了。依次点击Write、Run进行计算。最后点击Paraview查看结果。流程基本到此

但是这也不是一帆风顺！我按自己的猜想对模型的面进行划分，结果却导致了求解器的计算错误：

Caught signal 8 (Floating point exception: tkill(2) or tgkill(2))

于是我选择简化并优先完成一个简单模拟。下图是最后的结果（我也看不明白……）。

看起来需要补一些专业知识了，不然仿真计算的意义也不大。

总结与补充说明¶

为了用FreeCAD进行流体仿真计算，尝试了各种方法，后面成功使用nix-shell构建了一个稳定可复现的软件环境，顺带修了CfdOF和FreeCAD的小错误。

在完成FreeCAD可复现环境的构建后，根据现实需求，给出了两个FreeCAD物理仿真案例及其流程。

完整的nix-shell环境项目公开在我的github仓库，使用MIT协议授权分发，欢迎star！

关于项目许可证

虽然项目使用MIT授权分发，但是项目也附带了cfmesh和hisa的源码zip包，它们是按GPL3协议授权的！

后记¶

因为这里的博客都是写给自己看的，所以我经常写得很简略。其中也有自己急躁的因素就是了。此次难得补充一篇，想稍微写细致一点，不过没想到极大量篇幅给了nix。希望读者们能读得开心。

趁此机会，我把这个站点的脚本收拾了一遍，也用nix-shell写了声明式软件环境配置。至少是从NixOS那边汲取了有用的东西。也希望能启发各位读者。

nix和rust还真有几分相似呢

另外之前遇到的FreeCAD玄学小问题好像都消失了٩( ᐛ )و

用 Embassy 开发 Xinput 协议手柄

2023-04-17T00:00:00+08:00

Project repository: GitHub repo

Road Map¶

Important thing:

what about the marketing?

about bluetooth¶

https://en.wikipedia.org/wiki/Xbox_Wireless_Controller#Summary

Classic Bluetooth HID profile
HID over GATT Profile

I wonder if they are mostly the same protocol on a higher level, because there are evidences showing the existence of Bluetooth LE XInput compatible controller.

Embassy——易用的嵌入式Rust异步框架

2023-01-25T00:00:00+08:00

有些「小制作」需要用到USB、蓝牙、WiFi，我又想用 Rust 进行编程，但很多 Crates 提供的方法很有限。目前我粗略接触过的 esp-idf-sys 、 Tock OS 之类，都缺少了一些我计划中需要的关键功能（这么看感觉 C 那边生态优势很明显，瞧瞧 Zephyr RTOS 的成熟度）。最近在搜索 Rust 可用的蓝牙协议栈时，看到了 Embassy 这个框架，第一感觉是帮我简化了很多 MCU 外设管理的冗杂操作，顿时留下不错的印象。下面是一些个人学习记录。

之前觉得是给自己留的坑，写了一半没继续，如今看来还能有点用处，先挂出来吧。写得不咋地，还可能有错，见谅。

Embassy版本更新会带来一些API变更，建议从官方master分支的example开始建立代码工作区。本文不一定适用。

Embassy 点灯¶

废话不多说，先点个灯，好有个直观感受。嘛，还是得先配置好开发环境。先简单列出我的开发资源配置。

笔记本电脑，操作系统为 Arch Linux
开发板：WeAct BluePill Plus（STM32F103CBT6）
调试器：Muse Lab 高速 DAPLink（兼容公版 ATSAM3U2C DAPLink）

首先准备好 Rust 工具链，这个可以参考 https://rustup.rs 提供的信息进行安装，此处不再详叙。

由于我们的目标板 CPU 架构为 ARM Cortex-M，需要额外安装对应的 target 。不过幸运的是，embassy 项目空间内已经写好了工具链配置（rust-toolchain.toml)，待会跑 blinky 的时候 rustup 会自动处理工具链依赖。

这边编程也不用多数人熟悉的 OpenOCD 了（尽管也可以），使用的是基于 Rust Crate probe-rs 的一系列工具。这里主要使用的是 probe-run ¹ （这样可以直接跑官方例程）。使用下面的指令安装 probe-run。

# 安装 probe-run
cargo install probe-run

关于 probe-run 的配置，待进入示例项目再看。

如果 rustup、cargo 下载的速度过慢

可以尝试一下配置使用其它镜像或加速站点 ⁴ ⁵ ⁶。需要额外注意的是，如果自己的 git 配置文件（~/.gitconfig）中配置了代理，建议在操作 rustup 和 cargo 的过程中删除代理相关配置。

开发板选择参考

目前 Embassy 对 STM32、NRF52 的支持情况足够好，资源丰富，所以选相关开发板能省不少力。不过要是有余力，也可以去看看 Xtensa（ESP32）或者 RISC-V（ESP32-C3）架构的支持，截至2023-01-26，Embassy 已经有对它们的初步支持，而相关工具（probe-run）也支持了 ESP32-C3 内置的 JTAG 适配器。

准备运行示例项目，先准备一份源代码，操作如下：

git clone --depth 1 --recursive https://github.com/embassy-rs/embassy

随后进入适用于自己开发板 MCU 的示例项目文件夹。

cd embassy/examples/stm32f1

看一下示例项目内有哪些材料：

> tree -a
.
├── build.rs                # 最早编译并运行的 build script
├── .cargo
│   └── config.toml         # cargo 配置，关于 probe-run 的配置也在这里
├── Cargo.lock              # 锁，锁的是 Crates 版本
├── Cargo.toml              # 项目配置
└── src                     # 这里有 4 个示例程序
    └── bin
        ├── adc.rs
        ├── blinky.rs
        ├── hello.rs
        └── usb_serial.rs

这次就跑个 blinky（blinky.rs），检查下代码适不适合我的板子，一看，就 LED 引脚不一样。那就简单修改一下。

-    let mut led = Output::new(p.PC13, Level::High, Speed::Low);
+    let mut led = Output::new(p.PB2, Level::High, Speed::Low);

再检查一下 probe-run 的配置（在 .cargo/config.toml）和我的 MCU 是否一致。一看，倒也不用改。

[target.'cfg(all(target_arch = "arm", target_os = "none"))']
# replace STM32F103C8 with your chip as listed in `probe-run --list-chips`
- runner = "probe-run --chip STM32F103C8"
+ runner = "probe-run --chip STM32F103CB"

[build]
target = "thumbv7m-none-eabi"

[env]
DEFMT_LOG = "trace"

接下来就连接好开发板，执行下面的指令编译、刷入固件。

cargo run --bin blinky

等编译、刷写完毕，应该就能看到板子上的 LED 在闪烁了。

关于 LED 闪烁时间准确性

你可能会觉得闪烁时间和程序里写的 300 ms 差别有点大，我也不知道为什么。Debug 日志输出使用了RTT，应该影响不大；由此来看很可能是因为 Embassy 的非抢占式调度。谈起调度，可以了解下 RTIC ，Embassy 和 RTIC 的关系可以说是各自的重点不同 ⁷ 。

Embassy 设计初探 ²¶

Embassy 以一个 Executor 为核心。所有的任务用一个宏标记。以 blinky.rs 为例：

#![no_std]
#![no_main]
#![feature(type_alias_impl_trait)]

use defmt::*;
use embassy_executor::Spawner;
use embassy_stm32::gpio::{Level, Output, Speed};
use embassy_time::{Duration, Timer};
use {defmt_rtt as _, panic_probe as _};

#[embassy_executor::main]
async fn main(_spawner: Spawner) {
    let p = embassy_stm32::init(Default::default());
    info!("Hello World!");

    let mut led = Output::new(p.PB2, Level::High, Speed::Low);

    loop {
        info!("high");
        led.set_high();
        Timer::after(Duration::from_millis(300)).await;

        info!("low");
        led.set_low();
        Timer::after(Duration::from_millis(300)).await;
    }
}

在 blinky 的例子中，只是用宏标记了一个 main 入口点（此处已简化许多），Embassy 在完成一定初始化后会从这里开始执行主程序。但是这样好像同时只有一个任务在运行？也确实如此，毕竟还有一个 Task 没有引入。来看官方提供的另一个例子。

#![feature(type_alias_impl_trait)]

use embassy_executor::Spawner;
use embassy_time::{Duration, Timer};
use log::*;

#[embassy_executor::task]
async fn run() {
    loop {
        info!("tick");
        Timer::after(Duration::from_secs(1)).await;
    }
}

#[embassy_executor::main]
async fn main(spawner: Spawner) {
    env_logger::builder()
        .filter_level(log::LevelFilter::Debug)
        .format_timestamp_nanos()
        .init();

    spawner.spawn(run()).unwrap();
}

此处便可以看到，通过 Embassy 提供的宏，创建了一个 Task，而通过调用这个 Task，便可以得到一个 task 实例（实际上和 coroutine 差不多）。有过异步编程经验的人应该很快就能认出这个简单的创建多个任务的模式（个人感觉和 CircuitPython 的使用逻辑很接近）。

回到之前所说的，Embassy 的核心是一个 Executor。根据官方文档 ³ 的介绍：

executor 维护一个存储需要轮询（poll）的任务队列。当一个任务（task）创建时，它就被检视（poll）一次。这个任务会一直执行到它被阻塞。这可能发生在任何等待（await） async 函数返回结果的时候。而当前述事件发生时，对应任务会暂停执行（yield）并返回 Poll:Pending 。随后，executor 将该任务放在任务队列尾部，去检视下一个任务。如果一个任务完成或者取消了，它就不再入队。

当然，这也有个前提：没有哪个任务会一直阻塞、不提供切换任务的机会。 不然 executor 将永远无法切换任务，整个系统也退化成了单道程序处理机。

蓝牙 SBC 双通道高清音频模式

2023-01-22T00:00:00+08:00

本文是原Lineage官网列出的“Bluetooth SBC Dual Channel HD audio mode”¹的个人翻译版本，供各位学习交流使用。译文中的图片均直接转载自原文。原文作者是 Valdikss，发布时间为2019年7月6日，引用时间2023年1月22日。

LineageOS 15.1 和 16.0 为原有的蓝牙 SBC 音频编码带来了一个独特的音质提升。它们引入了带有 eXtreme quality profile (SBC XQ) 的 SBC 双通道模式，将这个老旧编码的音频质量提升到了与高通私有编码——aptX HD——相近的高度。

只要用户的设备运行的是在2019年3月31日或之后编译的 LineageOS 15.1、或是在2019年5月13日或之后编译的 LineageOS 16.0，一个新的“HD Audio: SBC”复选框就会出现在用户的蓝牙音频设备设置界面上。激活这项设定将启用双通道模式（Dual Channel mode），这提供了一个经过提升、比原版 SBC 编码高得多的比特率（bitrate）。新的比特率（452 或 551 kbps）依赖于蓝牙设备的最大增强数据率（Enhanced Data Rate）并且在使用联合立体声模式（Joint Stereo mode）时相比于原版 328 kbps 是一个明显的提升。

这个特性搭载在所有受 LineageOS 支持的设备上，并且可以和现存的绝大多数蓝牙播放设备一同使用。这个特性最适合没有额外编码支持——aptX、aptX HD、AAC 或是 LDAC——的廉价音频设备。

SBC 编码（协议）¶

SBC 有许多在连接过程中协商的不同参数：

音频通道/音轨（类型和数量）：联合立体声，立体声，双通道，单声道；
频带数量：4 或 8；
单个音频数据帧中音频数据块的数量：4，8，12，16；
量化位分配算法：响度，信噪比（SNR）；
量化过程中用到比特池（bit pool）的容量范围：通常为 2 到 53；

解码器（播放设备）应当支持上述参数的任何可能组合，但编码器（智能手机）可以只实现一部分。

现在的蓝牙协议栈通常用下面一组参数进行协商（这一组参数也被称作 profile）：联合立体声（Joint Stereo），8 个频带，16 块，响度，以及一个 2 到 53 位的比特池大小。这个 profile 将用 328 kbps 的比特率为 44.1 kHz 的立体声音频编码。

在所提到的参数中，比特池因其对比特率的直接影响处于格外重要的地位：它的大小越大，比特率就越大，也就提高了音频传输质量。当 profile 中的其他参数不改变时，一个特定的比特池大小将决定一个对应的比特率数值。

比特率同样被其它参数显著影响：音轨类型、频带数量以及音频数据块数量。你可以通过协商非常规的 profiles 来间接提高比特率，而不用调整比特池大小。需要着重注意的是一个更高的比特率并不总是带来更好的音质。例如，将单个音频数据帧中的音频数据块数量从 16 下调到 4，当使用联合立体声模式和 53 位大小的比特池时，将会把比特率从 328 kbps 提升到 441 kbps，但这也将减少很多计算时延，而这样会让动态量化过程变得更糟糕。上述例子不会带来除比特率增长之外的任何好处。

$$ bitrate = \frac{8 \times frame\_length \times sample\_rate}{subbands \times blocks} $$

固定的比特池大小与比特率的值均来自原版编码为高品质音频推荐的 profile。这个推荐值应该不构成我们去限制实际参数值的原因，正如下面所做的那样。

生效自 2007 年至 2015 年的 A2DP 规范 v1.2（译注：节4.3.2.6）要求所有解码设备都能正确处理最高达 512 kbps 的比特率：

The decoder of the SNK shall support all possible bitpool values that do not result in excess of the maximum bit rate. This profile limits the available maximum bit rate to 320kb/s for mono, and 512kb/s for two-channel modes.

输入端（SNK，sink）的解码器必须支持所有不让比特率超过最大限定值的比特池大小。该 profile 将最大比特率限制为单声道模式下的 320kb/s 和双声道模式下的 512kb/s。

而新版本的规范并未声明任何比特率限制。据推测，2015年之后发布的支持 EDR（Enhanced Data Rate）的现代耳机最高能支持 1000 kbps 的比特率。

双通道模式¶

双通道模式分别对左右声道进行编码，每个声道都用单独的比特池大小，这不像立体声或联合立体声那样对两个声道用同一个比特池大小。将设备运行模式从联合立体声模式切换到双通道模式将几乎会让比特率翻倍，达到 617 kbps，这将在不改变比特池大小（也就是53）的情况下带来显著的音质提升。我个人觉得比特池大小应该是一个内部变量。我推测，由于 A2DP 规范自身的设计失误导致了比特池大小并非由其它变量决定，而成了一个独立可协商的参数。

551 和 452 kbps 是哪来的？¶

蓝牙时分技术在设计上是能高效传输固定大小的大数据包的。数据传输以槽（slot）为单位，而每次最多可传输 5 个槽。也有些传输模式使用 1 或 3 个槽，但从来没有用 2 或 4 的。在链接速率为 2 Mbps 的情况下，你可以用 5 个槽传输多达 679 字节数据，而在 3Mbps 的情况下可以传输至多 1021 字节的数据。当使用 3 个槽时，上述情况下的单次传输数据量分别为 367 和 552 字节。

如果我们向传输少于 679 或 1021 字节但多于 367 或 552 字节的数据，单次传输依然要占用 5 个槽，而且传输会占用同样长的时间，也就降低了传输效率。

44100 Hz 的音频经由 SBC 在双通道模式、比特池大小 38、每帧 16 块、8 频带下编码将生成长度为 164 字节的音频数据帧，相应的比特率为 452 kb/s。

一个用尽 5 个槽的传输可以包含至多 4 个音频数据帧：

679 (EDR 2 mbit/s DH5) - 4 (L2CAP) - 12 (AVDTP/RTP) - 1 (SBC header) - (164*4) = 6

单个数据包能至多传输 11.7 毫秒时长的音频数据，而这些数据将在 3.75 毫秒内传输完成，而我们还有 6 字节没用上。如果你稍稍提高一点比特池的大小，4 个音频数据帧将再也不能挤到单次传输之中。你不得不每次发送 3 帧，也就降低了传输效率、单次传输中的音频数据量，还会增加无线环境较差情况下的音频卡顿的概率。

EDR 3 Mbps 情况下的 551 kbps 比特率也是用类似的方法选出的：在比特池大小为 47、每帧 16 块、8 个频带的情况下，帧大小为 200 字节，而比特率为 551 kbps。单词传输也就能用 5 个音频数据帧传输至多 14.6 毫秒的音乐。

计算所有 SBC 可用参数的算法还挺复杂的，增加了出错的可能。如果你想自己全算一遍，建议使用这个交互式计算器。

我们可以做得更好吗？¶

安卓的补丁包有一个额外选项可以增加 EDR 2Mbps 设备的比特率、超过它们既有的限制。你可以把比特率从 452 kbps 增加到 595 kbps，不过代价是当你的设备遇到拥塞的无线网络环境时传输稳定性会下降。

为了启用上述功能，在安卓 root shell 中执行下面的命令：

# setprop persist.bluetooth.sbc_hd_higher_bitrate 1

这个改变真的有什么好处吗？¶

SoundExpert 的 Serge Smirnoff 做了一次蓝牙SBC XQ profile 测试。他的测试表明 SBC XQ 452 kbps 的音频比 aptX 的失真更少，而 551 kbps 的版本甚至可以和 aptX HD 比。

想自己听听差异吗？试试这个实时将音频转码为 SBC 的在线服务（也包括 aptX 和 aptX HD），就运行在浏览器里。你可以比较不同 SBC profile 和其它编码的不同，而不用真的去用蓝牙传输音频，只要用手边的有线耳机、音箱，然后上传你最喜欢的音乐就好。你也可以在播放过程中直接调整那些参数。

结论¶

LineageOS 用户现在可以通过在他们的蓝牙设备设定里为“HD Audio: SBC”复选框打上勾，就能增强他们的蓝牙音频质量。这个特性应该能帮人们改变认为 SBC 低质量、应急用编码的这种偏见。当选择一个新的蓝牙耳机或音箱时，用户不再需要考虑那些私有编码了。

https://www.lineageos.org/engineering/Bluetooth-SBC-XQ/ ↩

HomeAssistant与ESP32

2023-01-12T00:00:00+08:00

前言¶

因为突然对智能家居很感兴趣，稍微折腾了一下

Home Assistant¶

Home Assistant是一个用Python实现的开源智能家居平台，着眼于不依赖于云服务的离线智能家居。有赖于社区动力，主流智能家居供应商的产品大多可接入Home Assistant管理。许多开源家居智能化方案也接入了Home Assistant。就不过多介绍了。

Tasmota¶

简介¶

Tasmota是一个ESP32/ESP8266平台的开源固件，通过MQTT或HTTP API进行数据交互。它将各个平台抽象为一系列模板，用统一的固件+硬件模板配置适配了各种各样的商业产品。比如我手上的小米米家台灯1S，就可以刷成Tasmota固件。

通过其内置的三种脚本系统（rules，scripts，berry scripts）可以实现很多复杂的功能，例如联机自动注册设备、自动上报数据、自动触发某一长时间运行的流程。

想在Home Assistant Core中接入Tasmota，只要自己搭建好MQTT服务器、启用MQTT和Tasmota集成，再配置好Tasmota设备接入即可。

实例：Tasmota+人体传感器+HASS¶

鉴于很多传感器都不需要多少配置就能无缝整合入Home Assistant，这里介绍一个需要一点操作的案例。

人体传感器，简单版，参考下列资料

https://tasmota.github.io/docs/PIR-Motion-Sensors/
https://tasmota.github.io/docs/Rules/
https://www.home-assistant.io/integrations/mqtt

步骤概要：

配置Tasmota中检测信号的GPIO
配置Tasmota中对应的自动化规则
在Home Assistant中配置相关设备集成

首先是人体传感器信号检测。这里使用HLK-LD2410传感器，其支持已加入Tasmota 12.3.1，不过下面做的其实和所谓支持关系不大。 LD2410提供了一个OUT信号脚，在检测到人体时是高电平，一段时间未检测到人体后就变为低电平。将OUT与ESP32的某个GPIO （下称GPIOx）相连，在Tasmota配置页面进入 Configuration → Configure Module ，将对应的GPIOx设置为Switch，并分配一个闲置ID。下面假设这个Switch的ID是1。

Note

Switch的ID无所谓，只要选空闲的就好。后面的指令需要将对应命令、Switch1等字串末尾的1改成对应ID。默认情况下，Switch会控制ID相同的灯。

进入 Consoles → Console ，设置对应Switch模式，关闭其开关相同编号设备的作用，同时关闭开关对应的MQTT消息。

SwitchMode1 1
SwitchTopic 0

给Tasmota配置一个自动化规则，在信号发生变化的时候发送MQTT消息，在连接到MQTT服务时向Home Assistant注册该传感器。

rule1
 on Switch1#state=1 do publish stat/%topic%/PIR1 ON endon
 on Switch1#state=0 do publish stat/%topic%/PIR1 OFF endon
 on mqtt#connected do publish2 homeassistant/binary_sensor/presence_%deviceid%/config { "name": "Presence Sensor", "object_id": "presence_%deviceid%", "device_class": "presence", "state_topic": "stat/%topic%/PIR1"} endon

rule说明

rule有三个存储空间，分别为rule1、rule2、rule3。其中每个空间至少可以存储1000字节的指令，考虑到压缩，可能会更多。 rule1后面的1 不用和对应开关的ID一致！

Note

在终端输入上述指令时注意合并成一行！

下面提供另外一种写法，不过根据配置不同，数据刷新可能不够及时

rule1
 on mqtt#connected do publish2 homeassistant/binary_sensor/presence_%deviceid%/config { "name": "Presence Sensor", "object_id": "presence_%deviceid%", "device_class": "presence", "state_topic": "tele/%topic%/SENSOR", "value_template": "{{ value_json.Switch1 }}"} endon

接下来启用rule1，保存配置并重启

rule1 1
restart 1

最后便可以在Home Assistant的实体注册表找到名为“Presence Sensor”的人体存在检测设备了。通过复杂一点的脚本，还能实现人体动态与静态的检测，当然这就需要启用LD2410传感器对应的支持以利用串口数据了。

ESPHome¶

架构介绍¶

就我目前所知，ESPHome的设计大致如下：

所有ESPHome设备的固件由一组ESPHome程序（Dashboard或CLI）根据给出的设备配置（YAML）生成
- 算是一揽子服务（配合PlatformIO CLI）
- 初见比较难hack
- YAML解析有一些特殊语法
每个ESPHome设备可以独立运行，不依赖面板/Dashboard
- 面板只有UI/UX变了
- CLI有提供指引系统，但是支持的开发板数量较少，如果一开始就要使用不支持的开发板会比较困难
- 固件可以通过USB安装，HTTPS连接dashboard的情况下可以用Web USB给ESP32编程
Home Assistant通过约定的API接口与ESPHome设备交互数据，需要在设备配置YAML中写一行 api: 开启API

（不得不说这个项目的文档很不适合我，很难检索到所需的资料）

也就是说，ESPHome包括编译系统和边缘设备两部分。

使用Python虚拟环境准备ESPHome部署环境¶

鉴于官网已经花费了大量篇幅从一开始就为Home Assistant和Docker用户介绍了对应的使用方法，这里将完整地介绍一遍不使用Docker、Home Assistant插件来使用ESPHome的流程。

前面说过，ESPHome把相关工作都包揽了，这里只需要构建一个虚拟环境作为工作空间就好。构建虚拟环境可以使用下面的指令。

# 创建虚拟环境
python3 -m venv esphome-venv
# 激活虚拟环境
source esphome-venv/bin/activate

虚拟环境的pypi镜像与代理配置

可以直接在虚拟环境文件夹（上例中是 esphome-venv）内新建一个pip.conf，在其中添加对应配置，例如使用阿里云的pypi源：

[global]
index-url = https://mirrors.aliyun.com/pypi/simple/

[install]
trusted-host=mirrors.aliyun.com

接下来随意创建一个保存YAML的文件夹作为工作空间便可以了。

实例：使用LuatOS-CORE-ESP32C3开发板制作低功耗蓝牙（BLE）网关¶

参考了下列资料：

https://digiblur.com/wiki/ha/esphome-bluetooth-proxy-esp32c3/
https://esphome.io/components/display/index.html
https://esphome.io/components/display/st7735.html

激活虚拟环境，在你的配置保存文件夹内编写如下YAML，保存为 ble-gateway.yaml。

substitutions:
  display_name: core-esp32c3-btproxy

esphome:
  name: ${display_name}
  platformio_options:
    board_build.mcu: esp32c3
    board_build.variant: esp32c3  

esp32:
  variant: ESP32C3
  board: esp32dev
  framework:
    type: esp-idf
    sdkconfig_options:
      CONFIG_BT_BLE_50_FEATURES_SUPPORTED: y
      CONFIG_BT_BLE_42_FEATURES_SUPPORTED: y
      CONFIG_ESP_TASK_WDT_TIMEOUT_S: "10"    

logger:
api:
ota:

button:
  - platform: safe_mode
    name: ${display_name} (Safe Mode)

# 记得改WiFi和密码
wifi:
  ssid: "Your SSID"
  password: "Your secret password"
  #manual_ip:
  #  static_ip: !secret ip_esp32c3_btproxy
  #  gateway: !secret ip_gateway
  #  subnet: !secret ip_subnet
  #  dns1: !secret ip_dns1

esp32_ble_tracker:
  scan_parameters:
# 可能需要调参
#    interval: 1100ms
#    window: 1100ms
    active: true

bluetooth_proxy:
  active: true

#### 下面是给显示器模块配置的 ###

# 五个按钮
# 由于 ESPHome 把 GPIO12、GPIO13强制占用了（原本控制Flash的），所以有一个按钮不能用。
binary_sensor:
  - platform: gpio
    name: "Up Button"
    pin:
      number: GPIO9
      inverted: true
      mode:
        input: true
        pullup: true
  - platform: gpio
    name: "Down Button"
    pin:
      number: GPIO5
      inverted: true
      mode:
        input: true
        pullup: true
 - platform: gpio
   name: "Left Button"
   pin:
     number: GPIO8
     inverted: true
     mode:
       input: true
       pullup: true
#  - platform: gpio
#    name: "Right Button"
#    pin:
#      number: GPIO13 # this pin is spared on CORE-ESP32C3
#      inverted: true
#      mode:
#        input: true
#        pullup: true
  - platform: gpio
    name: "Center Button"
    pin:
      number: GPIO4
      inverted: true
      mode:
        input: true
        pullup: true

# 显示器SPI
spi:
  clk_pin: GPIO2
  mosi_pin: GPIO3

# 来点显示的东西
# 可惜写这个的时间貌似还没支持
#time:
#  - platform: sntp
#    id: sntp_time
font: # 字体需要自己拷贝一份哦，下面是相对于该配置文件的位置
  - file: "fonts/iosevka-regular.ttf"
    id: my_font

# display ST7735
display:
  - platform: st7735
    model: "INITR_MINI160X80"
    reset_pin: GPIO10
    cs_pin: GPIO7
    dc_pin: GPIO6
    device_width: 80
    device_height: 160
    col_start: 0
    row_start: 0
    use_bgr: true
    lambda: |-
      it.print(0, 1, id(my_font), "Hello");
      it.print(0, 22, id(my_font), "World!");
      // it.strftime(0, 35, id(my_font), "%Y-%m-%d %H:%M", id(sntp_time).now());

接上设备，执行下面的命令刷机，就可以在Home Assistant里配置了。

esphome run ble-gateway.yaml --device=/dev/ttyACM0

Warning

记得先激活虚拟环境！

为CircuitPython编写专用的C功能模块

2022-12-03T00:00:00+08:00

动机¶

自己的机械键盘需要一个高效、无阻塞的扫键模块，Makerdiary的既有实现不能满足我的需求。

结构¶

通过参考 keypad、digitalio 以及Makerdiary的 matrix 模块，我发现对于CircuitPython 7.x 有如下的代码结构安排：

shared-bindings：存放模块Python接口的定义，和为Python开发C模块很像；
shared-module：实现与平台无关的模块存放其具体实现的地方；
ports/*/common-hal：实现与平台无关的模块存放其具体实现的地方；
ports/*/boards：某类平台的板极定义，可以用来调整特定板子的编译配置；
py/circuitpy_defns.mk：大概是整体编译配置，通过添加内容让编译工具识别到添加的代码；
py/circuitpy_mpconfig.mk：大概是整体编译选项配置，通过添加内容可以添加所需的选项开关；

那么实现某个模块的流程大致如下：

确认Python接口，并将初步定义在 shared-bindings 中创建好；
确认该模块是否与平台强相关：
1. 若只需CircuitPython标准接口或其它模块暴露的接口，可以将实现放在 shared-module 中；
2. 若确认实现与平台相关、用到了部分HAL提供的特殊方法，可以将实现放在对应的 ports/*/common-hal 中；
实现模块具体细节；
修改 py/circuitpy_defns.mk 和 py/circuitpy_mpconfig.mk 以添加对应模块的配置信息；
修改 ports/*/boards 中对应开发板的配置，开启所需模块；
编译、测试与后续工作；

Tinker Board 2S 折腾

2022-11-08T00:00:00+08:00

WIP

TinkerBoard2¶

这是出于某种原因从网友手上收来的一块板子，很漂亮，看着也很强悍。但是吧，官方支持的内核、RootFS什么的都挺老的（opinioned），实在满足不了我折腾的需求。

研究路径¶

rk3399 启动流程 (官方wiki其它地方也能看看)
- http://opensource.rock-chips.com/wiki_Boot_option
- 不能指望 Asus 能做什么, 除了他们那个系统 (TinkerOS) , 不过我是不用的
一个不错的研究笔记
- TN3399_V3
- 好歹都是 RK3399 的板子

原版 TinkerOS 说明¶

U-Boot¶

Arm64 启动时涉及到 ATF (Arm Trusted Firmware), 这里先提一嘴, 也就是要注意下启动流程

Tinker Board 2S 的 U-Boot 改自 Rockchip 维护的版本, 默认调试接口的波特率是 115200

RK3399 优先从 eMMC 启动, 因此为了更方便地测试 uboot, 必须把 eMMC 上的 uboot 破坏掉

所以我在 uboot 里执行了下面的指令, 然后我就能愉快地从 SD 卡启动了。

# 0x40 是 SPL/TPL（idbloader.img）的起址
mmc erase 0x40 2

Kernel¶

版本 4.4 没得说, 毕竟 BSP 给的就是 4.4, ~~晚点给它干上去~~我做不到

自行构建 u-boot、kernel、rootfs¶

ATF(TF-A)¶

一个初始化设备和EL2的程序（大概吧，不太懂）。

git clone https://github.com/ARM-software/arm-trusted-firmware.git
cd arm-trusted-firmware
make realclean
make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399

U-Boot¶

需要适配（写设备树、调整驱动）。看了下 Armbian 最近（2022-11-08）的commit，适配工作正在有序进行（而我只是勉强能明白他们的补丁想干嘛）。 u-boot版本为2022.07。

目前（2022-11-08）看来，HDMI、USB都有点问题。通过修改配置，可以轻松地使用 SPI NOR Flash 存放 u-Boot，这样就不依赖外置存储器了。

如何配置暂时不记录。编译成功后生成适用于 flashrom 的脚本如下：

import subprocess
# gen spi image
subprocess.run(["tools/mkimage", "-n", "rk3399", '-T', 'rkspi', '-d', 'tpl/u-boot-tpl.bin:spl/u-boot-spl.bin', 'idbloader-spi.img'])
# LOAD
## load spi tpl/spl
with open('idbloader-spi.img', 'rb') as f:
    tplspl = f.read()
## load itb
with open('u-boot.itb', 'rb') as f:
    uboot = f.read()
## CONCATENATE
### offset in KB
FIT_OFFSET = 512  # 这里请根据设备树配置项目 `u-boot,spl-payload-offset' 和 `CONFIG_SYS_SPI_FLASH_U_BOOT_OFFS' 等配置进行修改
FLASH_SIZE = 8192  # Flash 大小，只提供rom数据的情况下，flashrom要求rom数据和rom大小一致。
FIT_OFFSET_BYTES = FIT_OFFSET * 1024
FLASH_SIZE_BYTES = FLASH_SIZE * 1024
data = tplspl + bytes([0xff for i in range(FIT_OFFSET_BYTES - len(tplspl))])
data = data + uboot + bytes([0xff for i in range(FLASH_SIZE_BYTES - len(data) - len(uboot))])
## WRITE
with open("spi-nor.bin", 'wb') as f:
    f.write(data)
## FLASH, check your permission
# subprocess.run(['flashrom', '-p', 'ch341a_spi', '-c', "MX25L6406E/MX25L6408E" '-w', 'spi-nor.bin'])

rootfs¶

没啥难度，对于Debian/Ubuntu 有 debootstrap，对于 ArchLinux 有 ArchLinuxARM，不同发行版的RootFS有很多对应制作工具。略。

kernel¶

没搞定，旧的能用继续用旧的，略。

https://tinker-board.asus.com/images/doc/download/E17169_Tinker_Board_2_2S_UM_WEB.pdf ↩
https://tinker-board.asus.com/images/doc/download/Tinker_Board_2_Schematics_20201214.pdf ↩
https://github.com/armbian/build ↩

3D打印机折腾 - XYZPrinting da Vinci 1.0

2022-10-30T00:00:00+08:00

前言¶

因为某种缘分，我上了一个库存3D打印机的车。买到的打印机是 XYZPrinting 出品的 da Vinci 系列，版本1.0，下面简称达芬奇。现在这个系列都加上了前缀“original”。

该打印机用的是私有协议，而我不喜欢被私有上位机控制的感觉（GNU/Linux上操作、配合其它软件时会很麻烦）。于是折腾了“一下下”。

幸运的是我拿到的版本比较老，可以更换电机驱动器。

机器上手¶

这个设备真的比想象的大不少……明明工作空间只有200*200*200的说……占地差不多 500*600，高度 500，单位都是毫米。

比较可惜的是，设备到我手上时已经因运输不当损坏了多个部件，例如柜门转轴、上翻盖转轴、热床支架、热床玻璃、Z轴底座等等。总之先尝试调平、打印了内置测试件，感觉还行。

可惜这个调平不是长久之计，网上搜索后没有找到合适的热床组件，找商家补发了一个备件。在此期间先研究一下通信协议、耗材限制吧。

在此先记录一下我对于3D打印机到手后的操作建议：

检查机械结构
上电检查状况
检查是否校准并视情况调整（例如使用自动校准功能）
装料
打印测试

耗材锁与上位机协议¶

我机器随附光盘的程序没法正常运行……网上找到的官方程序也没法成功地在虚拟机里打印…… ~~可惜了~~ 那正好，必须折腾起来。好在网友留下了大量研究资料¹ ²（相关论坛资料主要发布于2016年前后，很久远，说明这机器年岁也很高）。

“简单”看了一下，就是用特定串口命令上传文件呗，用Py快速实现了一个小工具³。第一次上传gcode时一个不小心让打印头撞了一下平台……这好像也给后面打印立方体测试时埋下了隐患，导致模型某个侧面疯狂突出。

用这个方法打印模型需要用USB连接串口。需要注意的是，没调整好的话床很容易撞喷头，具体我就不详细写了。

刷机 - Repetier 固件¶

工具写到一半发现有个现成的开源固件。刷机也很方便，直接短接、清除原固件后就可以直接用 Arduino IDE 或 PlatformIO IDE 上传。但是在使用过程中会遇到一些小问题。中间虽然尝试了备份原固件，但发现JTAG接口并不能用=_=，算了反正原装固件是枷锁。

我的刷机过程如下，其它设备会略有不同，请参考固件说明。

检查型号兼容性
断电->短接JP1->上电->过几秒断电->断开JP1
Clone并打开项目文件夹，修改 src/ArduinoDUE/Repetier/Configuration.h 中的配置
PlatformIO IDE 编译、上传，随后进行设备校准与检测
根据实际设备情况调整参数
重新编译、上传，校准与检测
终于测试通过了，正常使用

我的挤出头边上的探针（probe）长度与测试点位置的位置好像和程序预定义的有点不同，在使用过程中发现了一些问题。不得不修改了一下代码。

加装WiFi模块¶

ESP3D这个东西还是有点意思的。哦，装了这个玩意儿可能会让USB串口不正常。

以 ESP12F 为例，2.1.x 固件的使用注意点：

~~供电得足……~~
在 esp3d/config.h 中对你需要的功能进行调整
刷机前最好用esptool把模块的存储器擦除一遍，以清除所有会影响到的配置
刷机后上机工作不太正常是正常的，需要简单配置一下
- 连接热点后上传index.html.gz，找不到可以fzf/find一下
- 走一遍tour，配置工作模式
2.x成熟一点，指引直观易用；3.0更先进，但是不知道什么时候才有稳定版，没什么指引不太方便
打印机固件也要开启WiFi功能哦
Repetier for davinci 最大波特率只有 500000，如果你调高了，ESP3D和打印机固件会自动将波特率降下来

硬件连接参考如下（达芬奇1.0 跳线JP1版），可以先看看原项目的示意图⁴。原项目建议串口加一对分压电阻把RX电平降下来。该串口的波特率和 USB 串口的波特率（打印机设置的）一样。

+---------+        +---------------+
|     GND |___  ___|1 to RX        |
|         |   \/   |               |
|     TXD |_  /\  _|2 to VCC(3.3V) |
| ESP     | \/  \/ |               |
|     RXD |_/\  /\_|3 to GND       |
|         |   \/   |               |
|     VCC |___/\___|4 to TX        |
+---------+        +---------------+

测试的时候要同时面对好几个疑问真的头疼死了……总之装上去了！

Warning

后续升级达芬奇固件时，一定把ESP3D取下来！不然会有影响！

关于项目仓库提供的连接示意图

ESP3D项目地址中达芬奇1.0/2.0的连接示意图标注的是连接方法，不是引脚定义。即RX接RX，TX接TX。

达芬奇装WiFi模块供电

不要用LDO（或者说不要用低效率的LDO），原本供电刚好 3.3V 且足够ESP8266开热点，过一个LDO可能就不够用了。如果版型和我的一样，串口可以直接对接，电平都是3.3V不会烧。

换电机驱动¶

想用TMS2209换掉原来的A4988。达芬奇的电机驱动板排针间距大概7个单位距离，比常见的5个单位距离宽一些（1单位距离为2.54mm，排针间距），需要改造。目前想到的办法有魔改双层转接器和自制转接板。结果咧，转接器（双层排母但是两层一样）都做好了，但是怕操作失误把板子弄坏，还是放弃了（网友称其‘fragile’）。 ~~以后有机会用自制转接板改吧，感觉稳妥些。~~ 事实证明 ~~直接直连转接的话需要改一下电机插头线序~~ 只是方向相反而已，另外做的转接板线接错了直接报废。另外说一句，我搞不太懂这些步进电机的1A2B什么的编号，好像有两种标准很坑人（一种字母对应线圈/相、数字对应正负，另一种反过来）。只要知道接对了电机会动，接错了电机会原地抖动，估计就没啥问题了。

~~嘉立创免费打样了一组转接板，配合长排针，把原来的母座改了，同时兼容原版和常见的TMC2209~~ 总之就是直接报废。电机驱动根据soliforum的网友提供的信息⁵来看，驱动电流不应该超过1A，大概在0.8A左右合适。100mΩ的情况下调整电压差不多1V应该就行了。

提前预留了活动空间并测试了一下电机驱动方向，发现恰好相反，那么稍微修改一下固件把它矫正过来～

// 需要修改的内容如下，给出的是使用TMC2209时的值
#define INVERT_X_DIR false
#define INVERT_Y_DIR true
#define INVERT_Z_DIR false

继续用原来的长排针，发现单位移动距离好像对，可能是微步设置出现问题，不管三七二十一先重新做了“可靠的”转换器，又实验了好几次，非常不稳定，中间还不小心插反了一个模块（-11CNY (ಥ_ಥ)），只剩3个可用了…… 一筹莫展之际，想到了板子MS1、MS2、MS3是没有隔离的，而且TMC2209的MS3是个TX（输出模式的IO），说不定影响到了微步设置？嗯，咱把对应的引脚剪掉吧！还好只是剪转接器的引脚。oh，还真的是这样！一切终于正常了。

用TMC2209替换A4988的感受嘛，声音确实小了很多，还是挺明显的。在打印精度上基本没有多少提升=_=。总体上确实有提升就是啦。

关于校准¶

平台平衡校准，配合纸片手动调平比根据自动测量数据调整要靠谱得多（说明自动测量是废物/当然也不完全是）。

我建议的校准流程：

平台校准
1. 清理平台和打印头，这一步在手动校准程序启动时会有个选项；
2. 手动校准（Manual leveling），如果觉得不放心可以多来两次练练手（按照固件提示操作走完流程就行）;
3. 重新检测Zmin（Zmin evaluation）；
4. 打印测试件验证校准状况。
挤出机校准
1. 在耗材上做好长度标记，然后按程序挤出一段耗材（比如100mm），测量实际挤出长度；
2. 然后嘛就是一个比例计算， $S_{new} = S_{old} \frac{E_{program}}{E_{actual}}$；
3. 也可以参考一下网上资料 ¹⁰。

挤出头与热端更换¶

目前看到有网友换了 MK8 或 E3D 的热端⁶ ⁷。以后我得尝试一下。热端拆解得在网上找视频了。看起来以后可以直接换MK8热端。

温度传感器更换¶

参考开源固件讨论区⁸，有两种做法：一是改主板并更换传感器从而能用既有的通用数据，二是自己测对应的温度数据。

其他人的改造¶

发现有人直接把主板换掉魔改了一番⁹。我暂时没这个动力……先好好用用看吧，要换也先换热端和电机驱动了。

芒果派RISCV：麻雀 MQ Pro 上手体验

2022-09-11T00:00:00+08:00

芒果派 MQ Pro 简介¶

这是一块以全志D1（RISCV）CPU为核心的迷你开发板，外观规格同树莓派0（不过USB全改 Type-C了，好评）。特性列出如下：

CPU：Allwinner D1 (RISCV single core)
Form factor: Raspi-0-like
Peripheral ports: GPIO, I2C & SPI, SDIO, Audio port(record, play), Video(touch, HDMI, DVP, DSI and LVDS), USB Host, OTG, etc.
Connectivity: WiFi/BT(RTL8723ds)
Memory: 512MB/1GB respectively for MPi-MQ1PL/MPi-MQ1PH

粉色油墨、过孔盖油、小尺寸、RISCV、开源、该有的接口都有了，除了性能弱一些，其实还不错。

自制“钥匙串”¶

嗯因为板子比较小也好看，不想焊接排针，于是非常具有装饰性，做个钥匙串不过分吧？我用 FreeCAD 按树莓派0的规格绘制了简单的亚克力外壳，用不锈钢齐平螺母和平头螺丝、尼龙隔离柱和垫片等将开发板夹在了两块亚克力板中间，亚克力板则是做成钥匙扣的样子。

简单玩玩，安装 ArchLinux¶

社区力量¶

嗯？好像没有那么简单啊……不过感谢社区的力量¹！我成功安装了 ArchLinux。

进一步折腾¶

~~闲着无聊~~ 将 sehraf 的脚本用 Makefile 重新实现了一遍²，顺便修了一些bug，都自动化了。前前后后花了三四天吧。全当学 Makefile 了。

接着玩？¶

emm，暂时没有想法。不过它确实是我的 tiny-tiny-tiny card computer。

在MSM8916随身WiFi上玩转Linux - part2 新设备

2022-08-07T00:00:00+08:00

动机¶

哎呀，剁手了，又买了一个随身WiFi想刷机。不过这次不再是 UFI001C_MB_V01 而是 UFI_16_V3。刷机流程稍有不同。后面又整了台 UFI003，看过发现和 UFI001C 一样。

刷机流程¶

备份¶

首先是 备份备份备份！

比较友好的是，该款版型的系统原生开启高通调试接口，备份基带QCN无需ROOT。老规矩，上 QPST。

其次是全盘eMMC备份。这里使用 Qualcomm Premium Tool 中备份Block0的功能。

fastboot刷机¶

下面尝试进入fastboot刷机。哎？怎么刷不进去？

% fastboot flash partition gpt_both0.bin 
Sending 'partition' (33 KB)                        OKAY [  0.005s]
Writing 'partition'                                FAILED (remote: 'failed to write partition,please contact vendor')
fastboot: error: Command failed

看样子fastboot做了限制加了锁。经过一番研究，发现在MSM8916平台上fastboot在 aboot（appsboot/lk1st）分区，而刷GNU/Linux正好也要更新这个分区，干脆直接用 Qualcomm Premium Tool 把该写的 aboot 分区通过9008提前写入。看上去不错，fastboot被替换掉了。

然后看情况稍微修改一下 Debian 的刷机脚本，不过好像不改也行。总之就是自己准备好备份，然后相应刷就行。

接下来的步骤和前一篇文章基本一致。

补充¶

LED怎么不亮¶

~~emm这块板子的LED是用 aw2013 控制的，是 i2c6 下面挂的一颗LED控制器。需要相应地修改设备树。~~ 我完完全全地被骗了，这就是三个普通的GPIO LED，只不过其中有一个直接连到了PMIC 上。另外，这板子上的红灯居然是常亮的，只和电源是否接通有关系（看板子估计是因为用一个电阻替换了应有的三脚管）；蓝色LED结果是个绿的，我猜都是为了省经费。

apt-key 的代替方案¶

read https://www.linuxuprising.com/2021/01/apt-key-is-deprecated-how-to-add.html

修改appsboot¶

Clone lk2nd，修改相关配置并编译。原来的aboot是给 UFI001C_MB_V01 用的，这里hack一下给 UFI_16_V3 用。其实也就修改了一下相关LED的引脚定义，顺带改一下product名称，没别的了。

后记¶

经过这次曲折的研究，我意外学习了一些设备树和驱动的概念。感觉设备树这个设计很神奇啊，本来分散的硬件通过设备树的描述就可以当成一个整体了；驱动集成到内核也把硬件细节封装了起来；原本的芯片像是通过外围设备组成了一个更大的芯片。以后看情况再补充学习一下。

WeAct BlackPill 跑 CircuitPython 使用自选外部 Flash

2022-08-05T00:00:00+08:00

动机¶

就是想用便宜的Flash。另外之前在CircuitPython 6.x时代也修改过了，但是之前买的拆机 Flash 质量实在太差，当U盘很不稳，不得已从库存的新Flash中挑了一片 MX25L6406EM2I。 ~~才发现某创商城搞活动时卖的 Flash 是停产/EOL产品。~~

修改¶

这个很容易，关键是要知道修改哪里。在CPY 6.x时代，所有的Flash配置都在一个个结构体中（存疑，可能记错了），驱动大部分是可以通用的。而在CPY 7.x时代，所有的Flash 都有一个自己的 toml 配置文件，定义了其中的各个参数。

准备一份源码。

git clone https://github.com/adafruit/circuitpython.git
cd circuitpython
make fetch-submodule

CPY 7.x的Flash配置文件在 data/nvm.toml 子模块下。以我的Flash为例，依葫芦（MX25L1606，MX25L3206E）画瓢，新建 data/nvm.toml/flash/macronix/MX25L6406E.toml。另外我严重怀疑 MX25L1606 的最大时钟频率配置错了，少了个0。

# Settings for the Macronix MX25L6406E 8MiB SPI flash.
# Datasheet: https://www.macronix.com/Lists/Datasheet/Attachments/8630/MX25L6406E,%203V,%2064Mb,%20v1.9.pdf
total_size = 0x800000 # 8 MiB
start_up_time_us = 5000
manufacturer_id = 0xc2
memory_type = 0x20
capacity = 0x17
max_clock_speed_mhz = 80
quad_enable_bit_mask = 0x40
has_sector_protection = false

然后修改对应板子的配置文件。

diff --git a/ports/stm/boards/stm32f411ce_blackpill_with_flash/mpconfigboard.mk b/ports/stm/boards/stm32f411ce_blackpill_with_flash/mpconfigboard.mk
index 9da716374..bf048775e 100644
--- a/ports/stm/boards/stm32f411ce_blackpill_with_flash/mpconfigboard.mk
+++ b/ports/stm/boards/stm32f411ce_blackpill_with_flash/mpconfigboard.mk
@@ -5,7 +5,7 @@ USB_MANUFACTURER = "WeAct"

 SPI_FLASH_FILESYSTEM = 1
 #See supervisor/shared/external_flash/devices.h for options
-EXTERNAL_FLASH_DEVICES = GD25Q16C,W25Q64FV,W25Q32JVxQ,W25Q64JVxQ
+EXTERNAL_FLASH_DEVICES = GD25Q16C,W25Q64FV,W25Q32JVxQ,W25Q64JVxQ,MX25L6406E
 LONGINT_IMPL = MPZ

 INTERNAL_FLASH_FILESYSTEM = 0

再之后编译。~~不得不提这编译的速度貌似比NRF52快多了。~~

make -C mpy-cross
cd ports/stm
make BOARD=stm32f411ce_blackpill_with_flash -j$(nproc)

最后刷固件。

dfu-util -l  # 列出当前的 DFU 设备
dfu-util -a 0 -D build_stm32f411ce_blackpill_with_flash/firmware.bin -s 0x08000000:leave

Very easy，不是么～

结语¶

好像也没什么好说的。啊对，珍爱开发板，远离拆机Flash。

在高通骁龙410主控的USB网卡上玩 GNU/Linux

2022-07-29T00:00:00+08:00

动机¶

有段时间网上基于物联网卡的USB式移动数据终端（4G网卡）变多了，搞开车活动，设备很便宜，价格10块上下，而且默认可以用 ADB 和 Fastboot。作为骁龙410，内核主线支持也不错。是一个可玩性很高的小设备。我买了某品牌的设备，板号是 UFI001C_MB_V01，目前已经有网友搞定了，可以跑主线内核的 Debian Bullseye。

后面又入了一个 UFI003，结构基本一致。

~~这东西好像可以拿来做下载机、签到、旁路由、渗透工具~~

目前可以公开的信息¶

设备信息（UFI001C_MB_V01）
- CPU：MSM8916，Snapdragon 410，A53@4C，64bit
- RAM/Storage：512M/4G，实际可用约382M/3.3G（因为Modem占用了一些内存）
- 无线：802.11b/g/n，4G LTE，Bluetooth 4.1，其它SoC支持的也不一定能用，因为没有接外设出来
- 有线：USB（可模拟网卡设备，同时用于供电）
- 其它说明
  - 板上有一颗 eSIM，应该是互联网卡注册用的。
  - 有一个 SIM 卡槽位置，但是没有焊接卡座
  - 有一颗按钮，按住它上电会进入 EDL/9008 模式。
操作系统
- 原版系统：安卓（没看版本，盲猜魔改 AOSP
- 修改系统：Debian（融合部分Mobian）、OpenWrt，以及其它发行版
刷机方式
- 原版系统开放 ADB、Fastboot
- 9008工具亦可

刷机流程¶

备份¶

刷机警告

道路千万条，备份第一条。
刷机太心急，锁网废机器。

先使用9008工具做全盘备份，ROOT之后用QPST备份基带（QCN），然后再刷系统。

9008 全盘备份¶

9008刷机用 Windows 方便一些。为了能使用高通测试签名的驱动，需要使用命令行开启测试模式。

# 设置后需重启以应用
bcdedit.exe -set testsigning on
# 刷完后用下面这条改回去
bcdedit.exe -set testsigning off

使用 Qualcomm Premium Tool 做完整的 eMMC 备份。需要使用 Windows。做全盘备份请按图上顺序点击，在出现分区选择时选择最后一个分区（这样备份从0到最后一个分区），后续按提示选择合适的位置存放全盘镜像。只需要保留这一份全盘备份就行，其它分区、分区表等信息可以从中提取。

基带备份¶

基带/QCN 备份，需要在安卓系统下开启高通的调试接口然后用 QPST 提取。基带芯片是一个协处理器，其固件数据存储在一片 NVRAM 中，所以不能直接用 9008 模式读取。

Root有很多方法，在此不详叙，仅提一些操作要点。

如果要用桌面投屏控制这个棒子，请先在投屏成功后再安装桌面应用并将其设置为默认桌面，否则会一直黑；
好像没了

开启测试端口的方法如下：

adb shell
# 接下来是在 adb shell 中操作
su
# 注意留住下面的 adb，不然adb就暂时用不了了
setprop sys.usb.config diag,adb

接下来就可以使用 QPST 的 Software Download 程序，在 Backup 分页中操作并读取当前设备的基带固件了（记得选好自己的设备）。

另外串号什么的最好也备份一下。我这次有点浮躁忍不了 Windows（甩锅）。

~~驱动的事Windows好像并不是全都比GNU/Linux那边方便，感觉 Linux 那边通常更方便。~~

Debian 安装与使用¶

Warning

OpenStick 项目及其主页提供的部分内容有误，且 RootFS 配置上有 Bug，导致会出现 USB 网络和 WiFi 热点不能同时开启的现象。如果有能力，建议自行重建 RootFS。

Note

刷 Debian 可以参考 OpenStick 的文档 ³。此处略过。
不过 Modem 固件（运行时加载的固件）文档并没有写清，在一个 64MB 大小的分区里，所有的固件都在一个 images 文件夹里。部分软件提取出来的分区镜像名是 NON-HLOS.bin。

emm OpenStick小队整的 Debian RootFS 好像缺了不少常用的包，而且配置好像有点点小问题。记录一下操作。

更新时间 timedatectl set-ntp true
安装编辑器：vim
安装 curl/wget/ca-certificates 保证 https 连接
换源到 USTC (网易163源貌似缺包，ftp.cn.debian.org 又是直接重定向到 USTC 会有证书错误)
安装 Bluez 并加载相关模块而启用蓝牙
安装 Zsh/OhMyZsh 方便操作
安装 iproute2/iw 等网络工具
更新到 Debian Bookworm
~~安装 fake-hwclock 保证时间一致性~~ 不用了，可以用 systemd-timesyncd
写了个脚本做网络连接 failsafe，后面有写
改了设备树，让按钮可以用

iperf3 测了一下速度，2.4G WiFi 速度有 33Mbps，USB 则有 112 Mbps。Modem 暂时没条件测试。

编译与修改内核¶

本节内容有参考 OpenStick 文档¹，并加入了自己的更新。

Warning

以下内容仅供参考，不保证准确可用，请灵活应变！

如果你用的是非 Debian 系的 GNU/Linux，建议创建一个 Chroot。BTW 我电脑用的是 Arch Linux，后面自行构建了一个 Debian bookworm RootFS，在 Chroot 内操作。

# Chroot on arch - optional approach
mkdir -p /home/user/CHROOT/bookworm-cache
cd /home/user/CHROOT/
sudo debootstrap --arch=amd64 --cache-dir /home/user/CHROOT/bookworm-cache --foreign bookworm bookworm http://mirrors.ustc.edu.cn/debian/
sudo arch-chroot bookworm
/debootstrap/debootstrap --second-stage

然后准备环境、制作 boot.img。

# Debian bookworm environment
apt update && apt install -y git \
    build-essential \
    gcc-aarch64-linux-gnu \
    bc bison cpio flex rsync kmod libssl-dev

# build kernel
git clone --depth 1 git@github.com:OpenStick/linux.git linux-openstick
cd linux-openstick
export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-
make msm8916_defconfig
make deb-pkg  # packages are generated in the parent directory

## prepare data for boot.img
mkdir ../android-boot
cp arch/arm64/boot/dts/qcom/msm8916-handsome-openstick-ufi001c.dtb ../android-boot
cp arch/arm64/boot/Image.gz ../android-boot

# install kernel packages
scp ../linux-headers-5.15.0-handsomekernel_5.15.0-handsomekernel-1_arm64.deb user@openstick.local:
scp ../linux-image-5.15.0-handsomekernel_5.15.0-handsomekernel-1_arm64.deb user@openstick.local:
ssh user@openstick.local sudo apt remove "linux-image-5.15.0-handsomekernel+"
ssh user@openstick.local sudo apt remove "linux-headers-5.15.0-handsomekernel+"
ssh user@openstick.local sudo dpkg -i linux-image-5.15.0-handsomekernel_5.15.0-handsomekernel-1_arm64.deb linux-headers-5.15.0-handsomekernel_5.15.0-handsomekernel-1_arm64.deb

# get initrd.img
scp user@openstick.local:/boot/initrd.img-5.15.0-handsomekernel ../android-boot

# generate boot.img
cd ../android-boot
cat Image.gz msm8916-handsome-openstick-ufi001c.dtb > kernel-dtb
mkbootimg \
    --base 0x80000000 \
    --kernel_offset 0x00080000 \
    --ramdisk_offset 0x02000000 \
    --tags_offset 0x01e00000 \
    --pagesize 2048 \
    --second_offset 0x00f00000 \
    --ramdisk initrd.img-5.15.0-handsomekernel \
    --cmdline "earlycon root=PARTUUID=a7ab80e8-e9d1-e8cd-f157-93f69b1d141e console=ttyMSM0,115200 no_framebuffer=true rw"\
    --kernel kernel-dtb -o boot.img

# flash boot.img
adb reboot bootloader
fastboot flash boot boot.img

截止文章发布，该内核设备树的按钮电平配置还是反的，我已经改了，不多说了。

按钮修好后，可以配置 systemd-logind 设置 HandleRebootKey 和 HandleRebootKeyLongPress 为 ignore，然后用别的程序监控这个按钮发出别的操作。不过也可以用 systemd-inhibit 去 handle-reboot-key。

其它说明¶

这个设备 sim 卡热插拔不太稳的样子。所以尽量别热插拔了可能 Modem 会出现运行错误；
内核默认配置是激活外部 eSIM，所以自己插卡后需要手动切卡（通过SysFs写点东西），然后可能需要重启 ModemManager，之后大概就能获取到网络信息了。至少我获取到了。
~~我也不知道全网通基带考不靠谱，虽然我刷了，但是没测试（这个测试起来太麻烦了）~~，后面感觉并不靠谱，没必要；
~~想用按钮，或许要自己改 device tree~~；
这东西，Modem 发热严重，可以试试改用低功耗模式；另，使用不匹配的固件同样会造成 Modem 发热严重。

有趣的应用¶

先让自己的设备断网也不怕¶

虽说可以用串口终端，不过也不是什么时候都方便。所以我写了一些脚本²帮我根据情况恢复网络。

其中一个服务会在网络断开时尝试启用所有的候选网络，开启恢复用的接入点；另一个则是监控仅有的 GPIO 按钮，并根据用户配置执行对应操作。

感谢来自下面这些链接中内容的作者们，他们给了我很多启发：

https://github.com/beagleboard/linux/issues/20
https://unix.stackexchange.com/questions/25372/turn-off-buffering-in-pipe
https://unix.stackexchange.com/questions/428399/how-can-i-run-a-shell-script-on-input-device-event

添加 SIM 卡槽¶

网上很多把原来的 eSIM 干掉的做法，emm 实际上没必要。焊接卡槽可以用精密的尖头烙铁。我用 936 就把 SIM 卡槽焊接好了。如图所示。 ~~跳线是测试连通性时发现 GND 居然不通，所以额外跳了一根线到最近的测试点上（CPU 的金属罩子它不沾锡啊TvT）。~~ 实际上不用跳线，因为这个卡槽的GND就是板子设计的使能控制脚，接地可能就只能用卡槽了，会影响esim切卡。后来我把这根线剪掉了。

切换 SIM 卡¶

该设备的 SIM 卡使用 GPIO 作为切换开关，但切换后需要重启 modem 以应用配置。下面列出操作示例。

# 先设置激活你卡对应的led/gpio开关，比如说
echo 0 > /sys/class/leds/esim0_select/brightness  # 禁用 esim0
echo 1 > /sys/class/leds/sim0_select/brightness   # 启用 sim0
# 重新加载内核模块并重启相关服务
modprobe -r qcom-q6v5-mss
modprobe qcom-q6v5-mss
systemctl restart rmtfs
systemctl restart ModemManager
# 注意，有些设备的modem在使用跨运营商卡的时候会主动崩溃一次
# 此时视情况需要重启ModemManager

迷你短信平台¶

咕咕咕

Home Assistant¶

咕咕咕

测试了，太吃内存，就算禁用modem空内存出来还是不够用，还会令WiFi性能急剧下降。

结语¶

emm懒了，这里的内容晚点看情况随缘更新（咕咕咕）

M60 Keyboard - 运行 Python 的机械键盘

2022-07-03T00:00:00+08:00

背景¶

折腾这个主要是因为我自己有用一个固件是 CircuitPython¹ ² 的机械键盘³。然后官方好像咕咕咕了很久没更新，我就忍不了了（也正好有空），直接自己上，把固件大版本提了上来（6.0.0 -> 7.3.1），以便使用更多特性。

定制 CircuitPython¶

为什么不用官方发行并支持的二进制版本呢？emm主要是官方固件不接USB就会停机,也就不能无线使用了，只能定制一下固件。

在 GitHub 上对比了 Makerdiary 和 Adafruit 官方版两个分支的不同 ⁴，从中剥离了 matrix 模块和针对键盘的定制，调整成了一组 Patch，调整后的补丁区分度更高，也方便后面继续升级版本。下面简单说一下遇到的困难。

未声明的函数¶

对于 CircuitPython 7.x 的编译系统，所有用到的函数都需要声明。几乎没写过靠谱的C的我，在面对这个问题的时候竟然非常小心，总认为光声明没有用。

然而事实是，补全声明就行了。

不匹配的类型¶

CircuitPython 7.x 开始，跟上了 MicroPython 内置 C 模块的接口设计，不再用旧的那套了。为此需要将旧的类型转换成新的、函数原型做对应调整。庆幸的是，C实现的 matrix 模块并不需要传入参数，逻辑不用作过多修改。

不过也可以看出这个 matrix 模块不够灵活，是针对 M60 键盘写死的，想迁移到别的设备还得动点脑筋。

安全模式没了¶

为什么我无法手动进入安全模式？安全模式下，不会自动重载代码，不会上电自动启动代码，方便调试板上的 python 程序，同时也可以作为一种更新板上代码的方式。为了避免键盘的虚拟U盘文件系统损坏，我会在 boot.py 中关闭存储设备接口或将存储设置为只读。有时代码没写好，忘了加恢复的快捷键，就需要用安全模式避免代码上电执行。但现在安全模式没了，就又得格式化存储区……

检查了 cherry-pick 的 commit，发现问题可能出在绕过 soft device 崩溃时的安全模式重启上。reset 键盘时， soft device 可能会挂掉，而现在的状况是，手动进入安全模式， soft device 也会挂掉，所以原来的代码顺带把进入安全模式的状态给清了……

解决方法，便是对当前重置条件做额外检查。运气很好，其它模块内有对应实现，搬过来稍微改改就好了。

用 mpy-cross 提前将模块编译成字节码¶

需要用与 CircuitPython 版本对应的 mpy-cross⁵，参数设定好。本来想继续研究看看，但好像没什么用。

还想研究 C 写的模块来着，发现 CircuitPython 还不行……这边 MicroPython 更先进啊。

修 Bug¶

让官方版本 CircuitPython 支持无 USB 连接使用¶

其实很简单，回过头来看，只要把键盘的电源控制IO（P0.28）激活即可。Makerdiary在添加支持时并没有通过board暴露这个引脚，文档里也有点错误。总之搞定了。CPY 8.2.0+应该都能用了。

===

先这样写一点，之后应该不会再补充了。

重新认识 Vim

2022-06-04T00:00:00+08:00

自我接触 GNU/Linux 已有 7 年，用了那么多次 Vim，却还停留在这个水平……感觉不太行，而且确实少了点生产力。

需要重新认识一下 Vim 了！

（本文不定期更新）

一个我认为不错的 Vim primer：Learn Vim For the Last Time: A Tutorial and Primer

有关 Vim 的一些问题¶

Vim 是什么？¶

hmm，简单说就是一个 TUI（Text-based User Interface）环境下的文本编辑器。 ~~和 Emacs 是某种意义上的竞争对手。~~

为什么用 Vim？它有什么优势吗？¶

我选用 Vim 没什么特别的理由。它的界面极其简洁，插件功能非常丰富，适合终端下使用。其它的嘛，其实也不能就这样和别的编辑器比。

相比于现代编辑器，Vim 更依赖键盘快捷键，学习曲线较陡，而且在 GUI 环境下并不一定比其它编辑器更强。不过我现在就基本在命令行环境下开发，学点 Vim 貌似更合适，而且命令行下、围绕键盘的操作方式更适合熟练人员、笔记本电脑用户。

当然这也只是我自己的感受。

学习的思路为何？¶

首先，接受 Vim 的设计特色。Vim、Emacs 等软件并非像常用 GUI 编辑器那样考虑到了很多鼠标操作，而在认识到他们围绕键盘操作的特色后，也能理解为什么需要优先学习快捷键了。

其次，学习 Vim 中等价于其它编辑器的功能。这部分优先学会，才能让使用者实现用 Vim 代替原有的编辑器，将整个环境替换过去。

之后就是喜闻乐见的进阶技巧了。宏、模块/插件之类是非常高效的功能。

我的 Vim 使用记录¶

2022-09-11¶

感觉这样记录不太行……中间都直接不记录了……

2022-07-29¶

到这个时候，我虽然还不能说熟练使用 Vim，但是一些基本功能也已经掌握了，而且通过插件的帮助改善了编程体验。前面好多学习经历都没有记录。

目前学会的部分：

基本的文件浏览
- 上下左右滚屏
- 跳转
基本的编辑
- verbs，noun，adverbs
- 重复
- 查找
- 替换
- 快速改写/删除

MicroPython 上手

2022-05-11T00:00:00+08:00

虽说是上手，但实际我有玩过一阵子了，而且这篇文更接近介绍。本系列博客(?)将尝试给有基础单片机概念的人快速了解 MicroPython。

介绍¶

MicroPython 是一款面向嵌入式设备的 Python 环境，运行于各种单片机上， Adafruit fork 出的 CircuitPython 是一个对新手更友好的分支，并且是CPython的严格子集，不过也缺少了一部分高级特性，这个参考官方仓库说明。

MicroPython 主要通过串口实现 REPL（Read Eval Print Loop）的交互，也就是 Python Console。此外在支持的设备上还能使用网络，从网页或者 Telnet 客户端进行操作。

MicroPython 的语法接近 CPython，许多常用标准库能代换，但相比之下精简了很多，并且添加了一部分独有的库，这些独有库通常以字母 u 开头。

使用前言¶

想使用 MicroPython？买一块兼容开发板，刷上固件，然后就能 Happy 啦！主要支持的设备是部分基于 STM32、NRF52、ESP32 的开发板。具体支持哪些板子可以看官方下载页面。我个人比较推荐纯新手且仅打算使用 Py 编程的朋友选用基于 ESP32 系列 MCU 的开发板，比如 Node32、Lolin32、LuatOS Core。

我选择的是来自 LuatOS 团队的开发板，它使用 ESP32-C3 这款 RISCV 架构的芯片，支持蓝牙、802.11 b/g/n/e/i，我选购的时候它价格也不错。就是不在官方支持列表上XD。

官方的下载渠道在这里，根据不同的开发板，点进去后会有不同的安装说明。

给 LuatOS Core 安装 MicroPython¶

这里就写一下这款开发板的安装流程吧。ESP32 系列的其实都差不多，而且一般不需要调试器。

大概分这么几步：

下载工具
下载固件
清空 Flash
写入固件

下载工具¶

这里需要安装 esptool.py 或者乐鑫提供的 Windows 版刷写工具。工具之类我就不再介绍如何安装了，希望读者能自行搞定（尽管这个可能是大多数人最开始搞不定的地方）。

下载固件 & 清空 Flash & 写入固件¶

由于我这块板子没有进入官方支持列表，有两种选择：

使用官方通用固件
自行补充开发板定义，并编译

我实际上选择了第二种，从结果上看第一种也没差。这里按第一种方法。ESP32-C3 的官方固件下载和说明页面点击这里。

Windows 用户请自行解决工具问题。

对于 Linux 用户，打开命令行终端，使用下面的命令进行刷写。注意，清空 Flash 是为了避免残留数据干扰固件第一次建立文件系统，在第一次刷写时不可避免（当然空 Flash 除外）。

另外，我用的开发板只用了两条数据线读写 Flash，务必选用 DIO 模式。 /dev/ttyACM0 是串口的设备路径，请根据实际情况调整。

# 清空 Flash
esptool.py --chip esp32c3 --port /dev/ttyACM0 erase_flash
# 刷写固件，强制 DIO 模式，波特率460800，刷写固件，从0x0地址开始写入，固件名称 esp32c3-20220117-v1.18.bin
esptool.py --chip esp32c3 --port /dev/ttyACM0 --flash_mode dio --baud 460800 write_flash -z 0x0 esp32c3-20220117-v1.18.bin

这样固件就写入完成了。下篇开始正式玩XD。

结语¶

这样应该就算上手完了？不是吧 XP。嗯，实际上应该再写一点第一次使用时使用的 Demo，比如 Hello World、Blinky 什么的。但对于希望小白能全看懂的我来说，或许更适合放在一篇单独的文章中。但实际写出来的好像也不是非常容易看懂啊……

TLog

Android折腾重启报set_policy_failed:/data/adb

起因¶

原理¶

为我的监控摄像头适配Thingino

契机¶

设备分析¶

拆解过程概要¶

固件备份¶

固件拆解¶

修改固件获取shell¶

初步适配Thingino¶

理解Thingino¶

编译并安装¶

适配摄像头组件¶

按钮和指示灯¶

按钮¶

指示灯¶

WiFi¶

摄像头传感器（sensor）¶

云台电机¶

其它组件¶

优化调整¶

云台活动范围¶

夜间模式自动切换¶

结语¶

相关链接¶

家里云网络基础设施

前言¶

操作环境¶

筋骨：网络划分¶

杂音：PPPoE接入ISP¶

配置上游接口¶

配置PPP服务¶

PPP配置¶

让pppd成为一个正经的systemd服务¶

获取IPv6并分配前缀¶

连结：做个路由器吧！¶

开启路由转发¶

用dnsmasq作DHCP/DNS服务器¶

开启NAT¶

我的名字我做主：掌控自己的DNS¶

设立自己的权威DNS之Knot DNS¶

用smartdns做中间件分流域名解析¶

让本机的systemd-resolved也转发internal tld请求到自己的Knot DNS¶

部分保留dnsmasq的主机名查询能力¶

设立自己的DDNS服务¶

后备隐藏能源：用NUT管理UPS¶

结语：懒得写了¶

主要参考资料¶

为Pixel 4a开启DeviceAsWebcam功能

切入点？几乎是无头苍蝇¶

一步步探索¶

linux开启必要的config¶

启用prop、修改init脚本¶

在HAL中加入UVC gadget支持¶

V4L2节点黑名单¶

有预览了，但是不认V4L2节点¶

内存不足？内存怎么会不足？¶

还是不行？没有输出？¶

终于在上位机上看到视频输出了¶

中途拔USB线就panic？¶

怎么没输出了？危机来临！¶

偶尔用一段时间后会panic？¶

感叹：内核折磨人¶

来看看输出～哎不是，红蓝颜色通道怎么反了啊！¶

OBS上的小问题¶

总结¶

podman使用及与systemd集成

开端¶

懒到极致¶

podman-docker¶

podman-compose¶

systemd集成¶

手搓systemd配置用podman compose启动服务发现问题¶

尝试podlet（失败）¶

遵循podman-compose提示¶

systemd user service 简述¶

linger？¶

podman-compose与systemd集成¶

尝试偷懒：希望能直接用`arch4edu`仓库编译好的软件包¶

打包`cfmesh-cfdof`、`hisa`两个插件¶

Embassy 设计初探 ²¶