使用 ascii-xfr 传输 rz 程序

最近继续折腾一些嵌入式设备,需要通过 UART 传输一些文件。一般来说直接使用 rz/sz 即可,但不幸的是 rz applet 并没有编译进这个设备的 busybox。同时由于一些蛋疼的原因,我们也不能重新烧写设备的 rootfs 镜像或者是从网络安装,那么就只能自己想办法解决咯……

基本思路是自己静态编译一份 rz 程序,然后从串口发送给嵌入式设备,然后再利用这个 rz 接收 sz。然后就能双向发送文件了。

设备上至少需要有cat命令和base64 -d。如果没有base64可以试试openssl base64 -d。如果还是没有那这篇文章的方法就不适用于你了。另外在设备上最好还要有一个 gzip 之类的压缩程序,可以显著缩短初次传输时间,以及一个 checksum 程序用于检查。我这里用了xzmd5sum

在主机上你需要有ascii-xfr程序。

编译 rz

你需要有一个能用的工具链,我的设备是 AArch64,直接使用了源里的 gcc。

1
2
3
4
5
6
7
8
# 下载代码
wget 'https://www.ohse.de/uwe/releases/lrzsz-0.12.20.tar.gz'
# 解压
tar xaf lrzsz-0.12.20.tar.gz
cd lrzsz-0.12.20
# 静态编译
CFLAGS='-Oz -static' CC=aarch64-linux-gnu-gcc ./configure --target=arm64-linux
make

如果你有对应设备的工具链也可以动态编译,这样编译出来的文件会更小。

使用 ascii-xfr 发送 rz

我这里使用picocom连接设备,其他程序比如minicomscreen请自行查阅手册寻找使用方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# 接上文
cp src/lrz rz
# 进一步裁剪文件体积
aarch64-linux-gnu-strip --strip-all rz
# 计算 checksum 备用
md5sum rz
ee96d7186db0f5240040c183636a8c9d
# 压缩
xz -9 rz
# 编码成 BASE64
base64 rz.xz > rz.xz.64
# 连接设备,记得使用你自己设备的波特率
picocom -b 1500000 -s 'ascii-xfr -sn -c 1' /dev/ttyUSB0
# 在设备中准备接收
wimpy_board$ cat > rz.xz.64
# 按 Ctrl-A Ctrl-S,然后输入要发送的文件的文件名
*** file: rz.xz.64
# 等待字符滚完,然后按 回车 + Ctrl-D 退出 cat
# 传输速度是 1000Bps,我最终需要传输 420 多 KB,需要 7 分钟。
# 传输完毕后在设备上还原可执行文件
wimpy_board$ base64 -d rz.xz.64 > rz.xz
wimpy_board$ xz -d rz.xz
wimpy_board$ chmod +x rz
# 最后比较一下 md5 值,并确认可以正常运行
wimpy_board$ md5sum rz
ee96d7186db0f5240040c183636a8c9d
wimpy_board$ ./rz
# 连按 5 次 Ctrl-X 退出

使用 rz 接收 sz

有经验的朋友到这里可以直接右上角退出了,不过我还是记录一下做个备忘。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 按 Ctrl-A Ctrl-X 退出 picocom,然后再重新连接。
# 不带 -s 参数时 picocom 默认使用本机的 sz 发送文件。
picocom -b 1500000 /dev/ttyUSB0
wimpy_board$ ./rz
waiting to receive.**
# 按 Ctrl-A Ctrl-S,然后输入要发送的文件的文件名
*** file: src/lsz
$ sz -vv src/lsz
Sending: lsz
Bytes Sent:1173536 BPS:144649

Transfer complete

*** exit status: 0 ***

折腾 RISC-V 单片机 Part1

SparkFun RED-V

大约半年前在 SparkFun 上买了一块 RED-V 开发板。基本算是 HiFive1 Rev B 的克隆,比 Rev B 便宜一些,同样使用 SiFive 的 FE310-G002 处理器。SiFive 的 MCU 自带一套 SDK,不过要搭配指定的 IDE 才好用,作为有洁癖的 Linux 用户这当然是不行的,所以就有了这次的折腾。

准备工作

我一开始是打算用 SDK 的代码,不过看了一圈感觉这样和玩 Arduino 也没区别了,失去了折腾的意义,所以决定放弃 SDK 直接用汇编艹寄存器。
这里是需要准备的文档和工具:

  • SparkFun RED-V Schematic: 这是板子的电路图,用来看板子上的接口都具体连接到 MCU 的哪个针脚。
  • Freedom E310-G002 Datasheet/Manual: 这两份文件可以从 SiFive 的网站上下载到,包含几乎所有重要信息。
  • Clang: 编译器。为啥不用 GCC?因为我不想单独折腾一份 GCC 的工具链。Clang 既可以编译出 x86 程序又可以编译出 RISC-V 程序,从软件源里装好就可以直接用了。
  • LLD: LLVM Linker。这下也不用配置 RISC-V 的 binutils 了
  • OpenOCD: 负责和板子通信,烧录程序,调试等。

三份 PDF 文档需要自己下载,而其他三个程序应该能直接用包管理装。

Rclone 同步 OneDrive for Business 共享

使用 OneDrive for Business 的 WebDAV 接口访问,无需登录。先去浏览器访问你拿到的分享链接,地址栏应该会变成如下形式:

https://[YOUR-DOMAIN]-my.sharepoint.com/personal/[YOUR-EMAIL]/_layouts/15/onedrive.aspx?[一堆别的东西]

然后打开 F12 找到一个叫 FedAuth 的 Cookie:

FedAuth=77u/......

然后用命令行在 rclone 里添加一个 WebDAV 的远程地址。语法是这样的:

rclone config create <name> <type> <key>=<val> <key>=<val> ...

具体到这里就是:

rclone config create <随便> webdav 'url=https://[YOUR-DOMAIN].sharepoint.com/personal/[YOUR-EMAIL]/Documents' 'headers=Cookie,FedAuth=77u/...'

细节请根据浏览器里的信息自己调节,如果设置无误就可以在 Rclone 里查看文件了:

rclone lsd '<你之前填的>:'

几个注意事项:

  • 暂不清楚这个 Cookie 的有效期是多长,如果 Cookie 失效的话自然就不能访问了。
  • 限速是存在的,如果 sync 的时候进度不动并且网络没流量通过,那大概是被限了。rclone 自己的速度计在速度为 0 的时候不会立即归零,而是 5MB,4MB,3MB… 这样慢慢下去,非常反直觉。限速时间还挺长的,暂时没有发现好办法能绕过。
  • 暂不清楚是不是所有的分享链接都可以用这种方式访问,可能需要组织管理员开启 WebDAV 功能?

LTO-5 磁带机折腾入门

LTO-5 Cartridge
最近在 eBay 上捡了一台 HP 的 LTO-5 磁带机,型号是 BRSLA-0903-DC,这次就把折腾过程简单记录一下。
LTO 磁带机本体一般都是标准的 5.25 寸光驱位大小,接口类型一般是 Fiber Channel 或者是 SAS 加上供电用的 Molex 4Pin。
不管哪种接口你都需要一张对应的 HBA 卡插在 PCI-E 槽里,以及对应的光纤线或者是 SAS 线把磁带机接到卡上。
如果机箱带光驱位,SAS 的磁带机可以直接放在机箱里,FC 的应该就不行了,因为我还没找到接口朝内部的 FC HBA 卡。

USB4 与 Thunderbolt 4 备忘

Summary

最近研究了一些关于 USB4 以及 Thunderbolt 4 的资料,在此做个备忘。目前只考虑 USB Type-C 接口,并且忽略 Type-C 可以正反随意插带来的复杂性。

  1. USB Type-C 接口里有一对(两根)差分信号线,用于 USB 2.0 协议(USB 2.0, 480 Mbps)。
  2. USB Type-C 接口里有四根 GND 以及四根 V_BUS 用于送电,具体电压和电流由两端使用 CC 线协商 (Power delivery)。
  3. 在 Type-C 接口里再取两对差分信号线,用于 USB 3.x 协议(USB 3.2 Gen 1, 5 Gbps)。
  4. 通过改进协议,可以将传输速度翻倍(USB 3.2 Gen 2, 10 Gbps)。
  5. 再把 Type-C 中最后剩下四根信号线也用上,传输一样的协议,可以将速度再次翻倍(USB 3.2 Gen 2x2, 20 Gbps)。
  6. 大家发现这八根高速信号线不止可以用于 USB,也可以用来传输其他信号。比如:电脑可以与显示器透过 CC 线协商,使用两对差分信号线传输 DisplayPort 信号(DP Alt mode)。
  7. Intel 觉得 Type-C 接口不错,于是有了 Thunderbolt Alt mode,使用全部四对差分信号线传输 Thunderbolt 协议(Thunderbolt 3, 40Gbps)。
    Thunderbolt 3 本身是一种隧道协议,在这个隧道中可以传输 PCI-E 数据和 DisplayPort 数据。
    至于 USB 则可以在扩展坞中内置一个 USB 控制器芯片,通过 PCI-E 与电脑连接,这样扩展坞就可以插 USB 设备了。
  8. USB-IF 觉得 Thunderbolt 3 这个协议不错,在 Intel 开放了 Thunderbolt 3 协议后,就把它拿过来“改名”成了 USB4。使用 USB Type-C 中的两对或四对差分信号线传输(USB4, ~40Gbps)。
    与 Thunderbolt 3 相同,USB4 也是一种隧道协议,其中可以传输 USB 3.2,PCI-E,DisplayPort 等协议。
    (吐槽时间:外层协议和内层协议都叫 USB 你是认真的吗?)
    USB4 规范并不要求硬件生产厂家实现所有功能,比如说,一个最高只支持 20Gbps 速度的设备可以合法地被称作“支持 USB4”。因为 USB4 规范并不要求所有设备都支持 40Gbps。(吔屎啦你 USB-IF)
  9. Intel 觉得 USB-IF 的标准混乱,是赚钱的好机会,于是自己列了一套更高的标准(比如要求设备必须支持 40Gbps 速度),并给符合 Intel 的标准的设备贴上 “Thunderbolt 4” 的标签。

最后围观 USB4 混乱的速度要求被鞭尸的现场:https://youtu.be/ly5-QHjs8Gw?t=1845

Allison Sheridan: So a Thunderbolt 4 device is a USB4 device...
Brad Saunders:    (nodding)
Allison Sheridan: ...but a USB4 device is not necessarily a Thunderbolt 4 device?
Brad Saunders:    It can be ...
Allison Sheridan: It can be but it isn't necessarily.
Brad Saunders:    It'll probably have... they may have made a choice to... maybe it's only 20 Gbps.
Allison Sheridan: Right, but it's Thunderbolt 4 it's 40 [Gbps] per second, Okay.

手动硬盘安装 WePE

最近尝试了一些 Windows 下的全盘备份/恢复方案,于是顺便折腾了一下各种 WinPE 系统。WinPE 简单来说就是一个 Windows 的 LiveCD,带有各种用于 Windows 的工具。网友们在微软的 WinPE 基础上加入各种驱动和方便使用的图形化操作界面,作为不同的 WinPE “发行版”发布,微PE(WePE) 是这些“发行版”之一。

WePE 自带的安装程序除了安装必要的启动项以外还会安装一些没啥用的选项。所以记录一下手动安装启动项的方法。环境为 Windows 10 64位 UEFI 启动。你需要先制作 WePE 的 ISO,然后把 ISO 里的WEPE目录复制到随便一个分区里,我假设是D:。用管理员身份执行以下命令:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
bcdedit /create /device
# 你会拿到一串 GUID, 假设是 {A...}
bcdedit /set "{A...}" ramdisksdidevice partition=D:
bcdedit /set "{A...}" ramdisksdipath \WEPE\WEPE.SDI

bcdedit /create /d "WePE" /application osloader
# 你会拿到一串 GUID, 假设是 {B...}
bcdedit /set "{B...}" device "ramdisk=[D:]\WEPE\WEPE64.WIM,{A...}"
bcdedit /set "{B...}" osdevice "ramdisk=[D:]\WEPE\WEPE64.WIM,{A...}"
bcdedit /set "{B...}" path \windows\system32\boot\winload.efi
bcdedit /set "{B...}" systemroot \windows
bcdedit /set "{B...}" nx OptIn
bcdedit /set "{B...}" pae ForceEnable
bcdedit /set "{B...}" detecthal Yes
bcdedit /set "{B...}" winpe yes
bcdedit /displayorder "{B...}" /addlast
bcdedit /timeout 3

设定完启动项以后就可以把盘符删掉了。

Ciphersuite Memo

I'm sorry if you landed in this keywords soup only to find it not helpful.

  • Key Exchange

    • DH (Diffie-Hellman): \(g^{xy} = (g^x)^y = (g^y)^x\)
    • ECDH (Elliptic-Curve DH)
    • ECDHE (ECDH Ephemeral)
    • DHE (DH Ephemeral)
    • RSA (Encryption): Generate a random bitstream and share it with the peer by encrypting using peer's RSA public key.

    A related concept is PFS (Perfect Forward Secrecy). DH offers PFS while RSA cannot.

  • Authentication
    Also known as key-signing. Commonly used together with the PKI(Public Key Infrastructure).

  • Encryption
    Used for data confidentiality.

    A related concept is mode of operation,which turns a block cipher to a stream cipher. CBC is a commonly used one. When it's used with AES, it's expressed as AES-CBC

  • Message authentication
    Used for data integrity. These algorithms are also called MAC(Message authentication code).

  • Authenticated Encryption (AE)
    Combines confidentiality and integrity. Wikipedia: Authenticated Encryption.

    • EtM (Encrypt-then-MAC): A secure way to combine encryption algorithms with MAC algorithms.
    • GCM (Galois/Counter Mode): A mode of operation, when paired with a block cipher, offers AE (actually AEAD) in one step.

    Some commonly used AE methods:

    • AES-CBC with an HMAC e.g.AES128-CBC-HMAC-SHA256.
    • ChaCha20 with Poly1305.
    • AES-GCM
  • Authenticated Encryption with Associated Data (AEAD)
    Similar to AE, but allows extra unencrypted data (associated data) to be authenticated. Roughly speaking:

    ciphertext = Encrypt(plaintext)
    auth_tag = Mac(associated_data + ciphertext)

    A common use case for AEAD is when encrypting a network packet, you want the packet header to stay unencrypted (for network routing purposes) but still authenticated.

  • Note about DH and curves of EC-based algorithms
    DH-based algorithms may have a “Group” option, which specifies a prime field or an elliptic curve. If a prime field is used, such as modp2048, it's normal DH. If an elliptic curve group is used, such as ecp256, it's EC-based DH.
    Some other curves may be used: