在 Big Sur(M1) 上解决 LaTeX 找不到楷体字体的问题

背景 最近在尝试移植 MiKTeX 到 Apple Silicon 上,添加了一些 patch 以后就可以工作了,但遇到了新的问题,即找不到 KaiTi ~/Library/Application Support/MiKTeX/texmfs/install/tex/latex/ctex/fontset/ctex-fontset-macnew.def:99: Package fontspec Error: The font "Kaiti SC" cannot be found. 用 miktex-fc-list 命令找了一下,确实没有找到: $ /Applications/MiKTeX\ Console.app/Contents/bin/miktex-fc-list | grep Kaiti # Nothing 上网搜了一下,找到了一个解决方案:字体在目录 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Support/FontSubsets/Kaiti.ttc 里,所以手动安装一下,就可以让 LaTeX 找到了。但我觉得,与其安装多一份在文件系统里,不如让 LaTeX 去找它。 解决方法 按照上面的线索,找到了 Kaiti.ttc 所在的路径: $ fd Kaiti.ttc /System/Library/PrivateFrameworks/FontServices.framework/Versions/A/Resources/Fonts/Subsets/Kaiti.ttc 可以看到,和上面的路径又不大一样。研究了一下 fontconfig,发现可以用 miktex-fc-conflist 找到配置文件的目录: $ /Applications/MiKTeX\ Console.app/Contents/bin/miktex-fc-conflist + ~/Library/Application Support/MiKTeX/texmfs/config/fontconfig/config/localfonts2.conf: No description + ~/Library/Application Support/MiKTeX/texmfs/config/fontconfig/config/localfonts.conf: No description ... 看了下第一个文件(localfonts.conf): <?xml version="1.0" encoding="UTF-8"?> <!

Read More

COMMON 符号

背景 在编译一个程序的时候,遇到了 undefined symbol 的问题。具体情况是这样的: 一开始的时候,直接把所有的源代码编译成 .o,再一次性链接,这样不会报错 后来,把一些代码编译成静态库,即把其中一部分源代码编译成 .o 后,用 ar 合并到一个 .a 中,再和其余的 .o 链接在一起,这时候就报错了: Undefined symbols for architecture arm64: "_abcd", referenced from: ... 如果换台机器,编译(使用的是 gcc 10.2.0)就没有问题。 而如果去找这个符号存在的 .o 里,是可以找到的: $ objdump -t /path/to/abcd.o 0000000000000028 *COM* 00000008 _abcd 在合成的静态库 .a 里,也是存在的(一个定义+若干个引用): $ objdump -t /path/to/libabc.a | grep abcd 0000000000000028 *COM* 00000008 _abcd 0000000000000000 *UND* _abcd 0000000000000000 *UND* _abcd 0000000000000000 *UND* _abcd 0000000000000000 *UND* _abcd 0000000000000000 *UND* _abcd 于是觉得很奇怪,就上网搜了一下,找到了一篇 StackOverflow 讲了这个问题。解决方案很简单,就是:

Read More

Skid Buffer

Skid buffer Skid buffer 指的就是,对于 valid + ready 的握手信号,用空间(更多的逻辑)来换取时间(更好的时序)的一个硬件模块。 简单来说,背景就是,为了解决 valid 和 ready 信号在数据流水线上一路经过组合逻辑导致的时序问题,在中途加上一些寄存器来阻隔。当然了,代价就是延迟和面积,不过吞吐量还是需要保持的。 由于需求的不同,Skid buffer 也有不同的实现。目前,找到了四个实现,实现上有所不同,特性也不大一样。 统一约定 由于我在 SpinalHDL 语言中重新实现了下面的这些 Skid buffer,所以按照 SpinalHDL 的 Stream 定义接口: class SkidBufferCommon[T <: Data]( gen: => T ) extends Component { val io = new Bundle { val s = slave(Stream(gen)) val m = master(Stream(gen)) } } 在这里,io.s 表示从上游取的数据,io.m 表示传递给下游的数据。 输出信号共有:io.s.ready、io.m.valid 和 io.m.payload。 ZipCPU 版本 第一个版本来自 ZipCPU: 博客地址:Building a Skid Buffer for AXI processing 代码地址:skidbuffer.

Read More

在 M1 上用 QEMU 运行 Debian 虚拟机

背景 看到 @jsteward 在 M1 的 QEMU 中运行了 Windows on ARM,所以我先来试试 Debian on AArch64,这样会简单一些。 参考:https://gist.github.com/niw/e4313b9c14e968764a52375da41b4278#file-readme-md 大约需要 3G 的硬盘空间。 安装 QEMU w/ M1 patches 目前上游的 QEMU 还不支持 M1 的 Hypervisor framework,需要打 patch: git clone https://mirrors.tuna.tsinghua.edu.cn/git/qemu.git cd qemu git checkout master -b wip/hvf curl 'https://patchwork.kernel.org/series/400619/mbox/'|git am --3way mkdir build cd build ../configure --target-list=aarch64-softmmu --enable-cocoa --disable-gnutls make -j4 编译后,得到 qemu-system-aarch64 的二进制 准备好文件系统 需要下载 EFI 固件 和 Debian 安装镜像,解压前者以后把文件放同一个目录中,并且创建需要的文件: $ ls *.fd QEMU_EFI.fd QEMU_VARS.fd $ dd if=/dev/zero of=pflash0.

Read More

以太网的物理接口

背景 最近逐渐接触到了一些高速的以太网的接口,被一大堆的名字搞得有点懵,所以特意学习了一下并整理成这篇博客。 更新:经 @z4yx 指出,还可以看华为的介绍文档 几几 BASE 杠什么是什么意思 在下文里,经常可以看到类似 100BASE-TX 这种写法,它表示的意思是: BASE 前面的数字表示速率,比如 10,100,1000,10G等等 BASE 之后的第一个字母,常见的 T 表示双绞线,S 表示 850nm 光纤,L 表示 1310nm 光纤,C 表示同轴电缆 之后可能还有别的字母,比如 X 表示 8b/10b 或者 4b/5b(FE) 的编码,R 表示 64b/66b 的编码 之后可能还有别的数字,如果是 LAN PHY 表示的是所使用的 lane 数量;如果是 WAN PHY 表示的是传输的公里数 详见Wikipedia - Ethernet Physical Layer # Naming Conventions。 各个速率对应的英文单词是什么 Fast Ethernet: 100Mbps Gigabit Ethernet: 1Gbps Multi Gigabit Ethernet: 2.5Gbps Ten Gigabit Ethernet: 10Gbps Forty Gigabit Ethernet: 40Gbps Hundred Gigabit Ethernet: 100Gbps 常见的连接器 连接器(connector)一般来说指的就是线缆和网络设备之间的物理接口了。常见的有:

Read More

Rust 在 M1 上的 Code Signing 问题和临时解决方法

不久前,rust 添加了 Tier2 的 aarch64-apple-darwin 的支持,试了一下,确实可以运行,不过当我编译的时候,出现: error: failed to run custom build command for `xxxx v1.0 (/path/to/xxxx)` Caused by: process didn't exit successfully: `/path/to/xxx/target/debug/build/xxx-xxxx/build-script-build` (signal: 9, SIGKILL: kill) 看了一下 Console.app 里面的 crash 日志,发现是 codesigning 问题。解决方法是,用 codesign 命令来签名: # for build.rs codesign -s - target/debug/build/*/build-script-build # for dylib of some crates codesign -s - target/debug/deps/*.dylib # for final executable codesign -s - target/debug/xxx 多次编译并签名后,就可以正常运行最后的二进制了: target/debug/xxxx: Mach-O 64-bit executable arm64 然后就可以了。等待上游添加 code signing 支持吧。

Read More

ARM M1 MacBook Air 开箱

购买 我是 11.12 的时候在 Apple Store 上下单的,选的是 MacBookAir ,带 M1 芯片,8 核 CPU + 8 核 GPU,加了一些内存和硬盘。今天(11.19)的时候顺丰到货,比 Apple Store 上显示的预计到达时间 21-28 号要更早。另外,我也听朋友说现在一些线下的店也有货,也有朋友直接在京东上买到了 Mac mini,总之第一波 M1 的用户最近应该都可以拿到设备了。 现在这篇博客,就是在 ARM MBA 上编写的,使用的是 Intel 的 VSCode,毕竟 VSCode 的 ARM64 版不久后才正式发布。 开箱 从外观来看,一切都和 Intel MBA 一样,包装上也看不出区别,模具也是一样的。 进了系统才能看得出区别。预装的系统是 macOS Big Sur 11.0,之后手动更新到了目前最新的 11.0.1。 顺带 @FactorialN 同学提醒我在这里提一句:包装里有电源适配器,不太环保。 体验 ARM64 首先自然是传统艺能,证明一下确实是 Apple Silicon: $ uname -a Darwin macbookair.lan 20.1.0 Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:10 PDT 2020; root:xnu-7195.

Read More

在 Spack 中用 external 的 Slurm 依赖编译 OpenMPI

最近在一个集群上,需要用一个自己编译的 openmpi,但并没有 root 权限,所以需要自己搞一个 spack,在 spack 里面装 openmpi。但默认的安装选项下,它没有打开 slurm 支持,所以 srun 的话会出问题,只能 sbatch 然后指定 host 去做。于是我研究了一下怎么在 spack 里引入 external 的 slurm,然后用它来编译 openmpi 首先,编译 ~/.spack/packages.yaml: packages: slurm: buildable: False paths: "slurm@15-08-7-1%gcc@8.3.0 arch=linux-ubuntu16.04-haswell": /usr 这里 slurm 版本是 15.08.7,我就按照 spack 里面 slurm 的版本号来写了。可以用 spack spec openmpi schedulers=slurm +pmi 来确认一下外部的 slurm 确实出现在了依赖之中。 这一步配好的话,安装的时候就会直接跳过 spack 里面 slurm 的安装。但又出现了 configure 错误,找不到 pmi 的库。于是,先用 external 的 mpirun 看一下配置: $ module load openmpi-3.0.0 $ ompi_info ... --with-pmi=/usr --with-pmi-libdir=/usr/lib/x86_64-linux-gnu .

Read More

在裸机上部署 ESXi 和 vCSA 7

之前在另一篇文章里提到过 vCSA 的安装,这次又在另一台机器上重新做了一遍,特此记录一下。 首先在官网上下载 ESXi+VCSA 7.0 ,应该得到两个文件: 7.9G VMware-VCSA-all-7.0.1-16860138.iso 358M VMware-VMvisor-Installer-7.0U1-16850804.x86_64.iso 首先安装 ESXi,用 UNetBootin 制作 ESXi 的安装光盘。注意不能用 dd,因为它是 CDFS 格式的,不能直接boot。启动以后,按照界面要求,一路安装即可。 接着,就可以用网页访问 ESXi 进行配置。比如安装一些 Linux 发行版,然后在 Linux 虚拟机里面 mount 上面的 VCSA 的 iso: sudo mount /dev/sr0 /mnt 接着,复制并修改 /mnt/vcsa-cli-installer/templates/install/embedded_vCSA_on_ESi.json,按照代码注释进行修改。需要注意几点: 密码都可以设为空,然后运行 cli 的时候输入 ESXi 的密码和 vCSA 的密码是不一样的 可以把 ceip 关掉,设置 ceip_enabled: false 接着,进行安装: /mnt/vcsa-cli-installer/lin64/vcsa-deploy install --accept-eula /path/to/customized.json -v 慢慢等待它安装成功即可。 安装完成后,进入 vCSA,新建一个 Datacenter,然后选择新建的 Datacenter,选择 Add host,输入 ESXi 的地址和用户密码信息即可。

Read More

IBM Power S822LC(8335-GTB) BMC 升级

背景 最近拿到一台 IBM Power S822LC(8335-GTB) 机器的访问权限,这也是我第一次碰 ppc64le 指令集的服务器。然后发现,它的 BMC 版本比较老,我想连接 Remote Control 失败了,原因是 JViewer 不支持 macOS,我就想着能不能升级一下。 升级过程 首先,在网上找了一下文档,首先用 ipmitool 找一下机器型号: $ sudo ipmitool fru print 3 Chassis Type : Unknown Chassis Part Number : 8335-GTB Chassis Serial : REDACTED 可以看到,这台机器是 8335-GTB 型号,按照这个型号在 Fix Central 上搜索,可以找到若干个版本的 firmware,其中最老的版本是 OP8_v1.11_2.1,对比了一下,和原来的版本一致: $ sudo ipmitool fru print 47 Product Name : OpenPOWER Firmware Product Version : IBM-garrison-ibm-OP8_v1.11_2.1 Product Extra : op-build-da02863 Product Extra : buildroot-81b8d98 Product Extra : skiboot-5.

Read More