![\"发起一个](\"https://imgcdn0.octz.net/blog/2025/iscsi-image.png\")
字如其名，PassKey 是一个钥匙，在 base/types/pass_key.h 中定义，存在 base namespace 下面，允许预先声明的类访问某些特定方法，而不必使用类级别的友元声明。
先来看一下它的最简单定义：
\ntemplate <typename... Args>\nclass PassKey;\n\ntemplate <typename T>\nclass PassKey<T> {\n friend T;\n PassKey() = default;\n};就这么简单。神奇吗？
\n比如我们有 A， B 和 C 三个类，其中只想 B 访问 A 的 foo() 方法，那么可以这样写：
class B;\nclass A {\n public:\n // bar 方法可以被任意类调用\n void bar(){}\n\n // foo 方法只能被 B 调用\n void foo(PassKey<B>){}\n};\n\nclass B {\n public:\n void foo(){\n A a;\n a.foo({}); // OK!\n }\n};\n\nclass C {\n public:\n void foo(){\n A a;\n // a.foo({}); // Error under C++20 or higher\n }\n};发现了吗？只有 B 是 PassKey<B> 的友元类，也就只有 B 可以实例化 PassKey<B>，从而调用 A::foo()。
警告
\n这个约束只在 C++20 以上生效，因为在以前 PassKey<B> 这种没有用户定义的构造函数的类是允许聚合初始化从而绕过检查的，但是 C++ 20 认为只要用户显式写了 = default 或者 = delete，那么就不能认为源类是一个聚合体了，必须调用构造函数，从而触发访问检查。
不过你可能会发现，这里有一个问题，就是如果 B 实例化 PassKey<B> 之后传给第三方，那么第三方类也可以拿这个实例来调用 A::foo() 了。这就好像 B 拥有 A::foo() 的钥匙，但是钥匙是可以复刻的，那么任何拿到复刻钥匙的实体都可以打开 A::foo() 这把锁。针对这个问题，我们还可以禁用拷贝构造和赋值操作符，这样就得到了 NonCopyablePassKey:
template <typename T>\nclass NonCopyablePassKey {\n friend T;\n NonCopyablePassKey() = default;\n NonCopyablePassKey(const NonCopyablePassKey&) = delete;\n NonCopyablePassKey& operator=(const NonCopyablePassKey&) = delete;\n};常用的场景就是只允许某个 Factory 来构造某类 Object ，给 Object 的构造函数加一个 Passkey<Factory> 参数即可。在 Chromium 中，也常用来管控一些设计上正在被废弃的类在新场景下的利用。
此外，PassKey 在较新版本也加入了多类的支持，如下：
\n\n\n有点长，而且是偏特化大师和前沿特性大神（需要 requires 和折叠表达式，至少 C++20）...
\n
namespace pass_key_internal {\ntemplate <typename T, typename... Args>\nconcept OneOf = (std::same_as<T, Args> || ...);\n\n// Calculates how many instances of <T> there are among <Args...>.\ntemplate <typename T, typename... Args>\nconstexpr int type_frequency =\n (static_cast<int>(std::is_same_v<T, Args>) + ... + 0);\n\n// All types in <Args...> are unique if each type occurs there exactly once!\ntemplate <typename... Args>\nconcept PairwiseUnique = ((type_frequency<Args, Args...> == 1) && ...);\n} // namespace pass_key_internal\n\n// Specialization for multi-argument PassKey. This allows a PassKey to be\n// constructed from another PassKey if all its arguments are present in\n// the target PassKey's argument list. This enables flexible access control\n// where a function might accept a PassKey that covers a broader set of\n// authorized callers, and callers can provide more specific PassKey-s.\ntemplate <typename... Args>\n requires(sizeof...(Args) > 1)\nclass PassKey<Args...> {\n static_assert(pass_key_internal::PairwiseUnique<Args...>,\n \"PassKey<> arguments must be pairwise unique.\");\n\n public:\n // Allows constructing a PassKey<A, B> from PassKey<A> or PassKey<B>.\n // Implicit to allow feeding PassKey<A> into a function that expects\n // PassKey<A, B>.\n template <typename T>\n requires pass_key_internal::OneOf<T, Args...>\n // NOLINTNEXTLINE(google-explicit-constructor)\n PassKey(PassKey<T>) {}\n\n // Allows constructing a PassKey<A, B, ...> from a PassKey<A, B>.\n // The exact order of arguments doesn't matter.\n // Implicit to allow feeding PassKey<A, B> into a function that expects\n // PassKey<A, B, ...>.\n template <typename... SourceArgs>\n requires(sizeof...(SourceArgs) > 1 &&\n (pass_key_internal::OneOf<SourceArgs, Args...> && ...))\n // NOLINTNEXTLINE(google-explicit-constructor)\n PassKey(PassKey<SourceArgs...>) {}\n};最近从 NameSilo 转出域名，贴着 60 天的 ICANN 域名转移锁时限卡点转移，结果被坑了一把：
\n结果就是你看面板解锁了，不算！
\n你看后端接口显示没有锁了，也不算！
\n必须等到 MST 那个时间到了才是真的解锁，在此之前你提交多少次转移申请都会静默失败。
前一周整了个 J1900，也算是从 ARM 转入 x86 的怀抱了。众所周知，这玩意由两个 SATA 接口，但是 CPU 性能比较差（也比 树莓派3 强多了），比较适合用来做存储和网关。
\n| 我才不会告诉你我测了半天发现跑个 docker 都费劲呢~
\niSCSI，全称 Internet Small Computer System Interface（互联网小型计算机系统接口），是一种基于 TCP/IP 协议的存储网络标准。
\n它允许通过标准的 以太网（Ethernet）基础设施来传输传统的 SCSI（小型计算机系统接口）命令，从而实现 块级别（Block-level）的数据传输和访问。简单来说，iSCSI 就是在 IP 网络上运行 SCSI 协议，将远程的存储设备（如磁盘阵列）虚拟成本地的硬盘，供服务器或计算机使用。
\n在整个 iSCSI 架构中，发起方 (Initiator) 扮演着客户端的角色，它通常是需要存储空间的服务器或计算机，通过发送 SCSI 命令来请求数据。而 目标方 (Target) 则扮演着服务端的角色，它是一个存储设备，负责接收和处理来自发起方的 SCSI 命令，并将底层的存储资源（即 LUN，逻辑单元号）通过网络的方式虚拟成一块本地硬盘供发起方使用。
\n这次我们搞试验，就把 J1900 作为目标，而 Windows 电脑作为发起方。
\n我们常使用 tgt 来搭建 target。我在这里跑 OpenWrt，用 opkg 一把梭就可以安装。
不幸的是，由于这个是比较偏门的应用场景，并没有一个 luci 供我们配置。不过我们仍然可以通过 uci 配置文件来统一化配置，对应的文件是 /etc/config/tgt，下面是一个实例：
config options 'tgt'\n# iothreads limits number of worker threads per rdwr target, default is 16\n# which seems to be too much for an avarage router\n\toption iothreads '2'\n#\toption nop_count '3'\n#\toption nop_interval '1'\n#\toption logging '0'\n#\tlist portal '[::1]'\n#\tlist portal '127.0.0.1:3261'\n#\tlist portal '0.0.0.0:3262'\n#\tlist portal '[::]:3263'\n\nconfig target 1\n # 一个名字\n\toption name 'iqn.2012-06.lan.server:target1'\n # 允许连接的对端名称\n\tlist allow_name 'iqn.1991-05.com.microsoft:xxx-laptop'\n#\tlist allow_address '192.168.2.128/27'\n\n#config target 2\n#\toption name 'iqn.2012-06.org.openwrt:t2'\n\n# all options are set to default, except for the device\n# lun \"name\" is constructed as TGTID_LUN\nconfig lun 1_1\n # 这里可以指定一个设备名/文件名\n\toption device '/dev/sda'\n# type of scsi device. available options: disk, cd, pt (sg passthrough)\n#\toption 'type' 'disk'\n# backing store access method: rdwr (read-write), aio (async IO), sg (for pt type only, device must be /dev/sgN)\n#\toption 'bstype' 'aio'\n# set sync and/or direct flags when opening device, affect only rdwr\n#\toption 'sync' '0'\n#\toption 'direct' '0'\n# block size for lun, default is 512\n#\toption 'blocksize' 4096\n# override SCSI mode page, see tgtadm man page for details\n#\toption 'mode_page' 'string'\n# vendor, product, revision, SCSI ID and SCSI Serial number\n#\toption 'vendor_id' 'string'\n#\toption 'product_id' 'string'\n#\toption 'product_rev' 'string'\n#\toption 'scsi_id' 'string'\n#\toption 'scsi_sn' 'string'\n# refuse write attempts. applies only to disk type\n#\toption 'readonly' '0'\n# Disk devices default to non-removable, cd - to removable\n#\toption 'removable' '0'\n# 0 = Classic sense format, 1 = Support descriptor format.\n#\toption 'sense_format' '0'\n# Rotaion rate: 0: not reported, 1: non-rotational medium (SSD), 2-1024: reserverd, 1025+: \"Nominal rotation rate\"\n#\toption 'rotation_rate' '0'\n# A thin-provisioned LUN is represented as a sparse file.\n# When initiators use the SCSI UNMAP command TGTD will release the affected areas back to the filesystem using FALLOC_FL_PUNCH_HOLE.\n# This option applies to the disk type and rdwr bstype\n#\toption 'thin_provisioning' '1'\n\n# Target 1 上的第二个卷\nconfig lun 1_2\n\toption device '/dev/sdb'\n\n#config lun 2_2\n#\toption device /dev/sdc\n\n# CHAP 认证账号相关\nconfig account\n\tlist target 1\n#\tlist target 2\n # 建议设置为你的 Initiator 的名字，以确保只有一个连接\n\toption user \"iqn.1991-05.com.microsoft:xxx-laptop\"\n # 密码需要符合规范，我的试验是 12 位，带有大小写和数字就行\n\toption password \"Abcdefgh1234\"\n\n#config account\n#\toption target 2\n#\toption user \"user2\"\n#\toption password \"pwd2\"\n#\toption outgoing 1Windows 一直都带有 iSCSI 发起程序，我们打开它。然后按图设置完成后，一路确定即可。
连接完成后，可以看到 已发现的目标 列表中多了一个项，且状态为 已连接。
如果使用的是一块现有的磁盘，那么应该可以在资源管理器里面直接看到原来的卷标了，否则请到磁盘管理里面去初始化磁盘再分区、格式化，就像插入了一块新硬盘一样。
又是一个心血来潮，了解了一下硬件安全密钥，最常见的就是 Yubikey 了（好贵呜呜呜），看到国产替代产品 Canokey 两颗的价格还顶不到一块 Yubikey，果断下手来看看怎么个事。
\n除了 NFC 很弱（我的手机根本用不了，对，是贴上去无论怎么调整都一点反应都没有的那种）以外，CanoKey Canary 的功能基本对标 Yubikey 5c，而且管理上采用了 WebUSB，十分的便利。
\n主要是支持了 FIDO2 / WebAuthn，OpenPGP 和 PIV，还有 TOTP，基本够用了。配合 Ed25519-SK 来个 SSH 免密登录（是真的只要插上 key 导出来私钥存根就能用的那种，Xshell 都可以），再替代一手 Authenticator 应用。负担嘛无非是要随身带多一个东西，就像真的钥匙一样。
\n来点有用的命令：
\nssh-keygen -t ed25519-sk -O resident -O application=ssh:YourName # -O verify (to enforce entering PIN)\nssh-add -K # This may need admin/root perm to recover handle and public key from SK into your PC\nfido2-token -L # List all SK\nfido2-token -L -r <device> # See what's in it顺便，FIDO 也有两个版本，版本一是非驻留式的，密钥在这里当作一个证明函数；FIDO2 允许驻留私钥，也向后兼容。这也是有些网站明明添加了 PassKey 之后也不能在 SK 上面找到凭据的原因。
\n", "date_published": "2026-01-02T00:00:00.000Z", "date_modified": "2026-02-04T04:52:50.000Z", "authors": [ { "name": "DynamicLoader", "url": "https://octz.net/" } ], "tags": [ "Note" ] }, { "title": "构建你的动态路由内网 - OSPF 入门小记", "url": "https://octz.net/blog/Maintaince/OSPF0.html", "id": "https://octz.net/blog/Maintaince/OSPF0.html", "summary": "前言 Open Shortest Path First (OSPF) 是一种好用的动态路由协议，采用 IP proto 89 交换信息，要求两端对等。可以在广播、点对点和点对多点的环境使用。 这几天也是试了下水，发现比静态路由舒服一点，顺便也给我的内网规划了一下，这里稍微记录一下配置的东西。 阅读建议：非常推荐先会基本的计算机网络和路由原理。 安装软件...", "content_html": "Open Shortest Path First (OSPF) 是一种好用的动态路由协议，采用 IP proto 89 交换信息，要求两端对等。可以在广播、点对点和点对多点的环境使用。
\n这几天也是试了下水，发现比静态路由舒服一点，顺便也给我的内网规划了一下，这里稍微记录一下配置的东西。
\n阅读建议：非常推荐先会基本的计算机网络和路由原理。
\n在普通的 Linux 设备上，我们可以通过 frr 来构建这些服务。例如，在 OpenWrt 上，我们需要使用如下的包：
frr\t\nfrr-ospf6d\nfrr-ospfd\nfrr-staticd\nfrr-watchfrr\nfrr-zebra本文使用 10.2.1-2 版本
\n不同的版本可能命令略有差异，具体以实际为准。
\nfrr 提供了一个集中的命令行控制台叫做 vtysh，需要使用 root 权限运行。它的命令和 Cisco 的 IOS 长得很像，玩过 Packet Tracer 的应该知道怎么个事。
命令也是分作用域的，比如刚开始 # 下面我们只能做一些信息查询的工作，比如
show ip route: 查询 IPv4 路由信息show ipv6 route: 查询 IPv6 路由信息show ip ospf neigh: 查询 IPv4 OSPF 邻居show ipv6 ospf6 neigh: 查询 IPv6 OSPF 邻居show running-conf: 查询正在运行的配置，其实就是按照层级记录采用了的配置命令，可以手动重现write: 将当前配置写入配置文件，重启后也有效而在基础模式下输入 conf 我们就进入了配置模式。这个模式我们可以配置全局的一些东西，比如
router-id <A.B.C.D> 可以配置路由器 ID在配置模式下，我们还可以使用 router <xxx> 来配置某一个路由协议，使用 interface <xxx> 来配置一个接口。
此外，如果想要删除某个配置，在原来配置命令的前面加 no 就可以了。
场景如下，两台路由器 A 和 B 通过两个 WireGuard 隧道连接（IPv4 和 IPv6 分离），隧道内允许的 IP 都是 0.0.0.0/0 和 ::/0。
| 路由器 | \nRouter ID | \nIPv4 隧道地址 | \nIPv6 隧道地址 (ULA) | \n宣告的 IPv4 块 | \n宣告的 IPv6 块 | \n
|---|---|---|---|---|---|
| A | \n192.168.0.254 | \n192.168.0.254/32 | \nfd00:f000::1/128, fe80::192:168:0:254/64 | \n192.168.0.0/22 | \nfd00:10::/60 | \n
| B | \n192.168.8.254 | \n192.168.8.254/32 | \nfd00:f000::2/128, fe80::192:168:8:254/64 | \n192.168.8.0/22 | \nfd00:20::/60 | \n
注意
\nRouter A 的隧道地址 (192.168.0.254) 包含在其本地宣告块 (192.168.0.0/22) 内。这不是一个好的分离实践，但是我本地为了方便管理就这么干了，而由于我们使用了 /32 和 point-to-point 网络类型，有一个更长的前缀路由，OSPF 可以正常工作。
相关信息
\nrouter ospf 下面的 network 指令不能和使用了 ip ospf area x.y.z.w 的 interface 同时存在。
以下还聚合宣告了块，这要求要么 area 中有至少一个活动路由，要么配置一个静态路由然后在 router ospf 下做 redistribute static。后者可能还需要挂 filter，不然会把所有静态路由都宣布出去。
以下是最终的示意配置文件，供参考：
\n!\nfrr version 10.2.1\nfrr defaults traditional\nhostname R-A\nlog syslog\n!\npassword [YOUR_SECURE_PASSWORD]\n!\nip route 192.168.0.0/16 reject # 内部地址防环/黑洞策略\nip router-id 192.168.0.254 # 路由器A的Router ID\n!\ninterface eth0\n ip address 192.168.3.254/24 # 假设eth0的IP\n ip ospf area 2.0.0.0 # 本地区域 2.0.0.0\nexit\n!\ninterface wg4\n ip address 192.168.0.254/32 # 隧道IPv4地址 (简易起见与Router ID一致)\n ip ospf area 0 # 骨干网区域，area 0 = 0.0.0.0\n ip ospf network point-to-point # 指定为点对点网络\n no ip ospf passive # 在这个接口上取消被动接口，即宣告 OSPF 信息\nexit\n!\ninterface wg6\n ipv6 address fd00:f000::1/128 # 隧道IPv6 ULA地址\n ipv6 address fe80::192:168:0:254/64 # 链路本地地址\n ipv6 ospf6 area 0 \n ipv6 ospf6 network point-to-point\nexit\n!\nrouter ospf\n passive-interface default # 默认接口被动，即默认不宣告 OSPF \n area 2.0.0.0 range 192.168.0.0/22 # 聚合/通告本地网络 (A 的本地块)\n default-information originate # (可选) 宣告一个默认路由\nexit\n!\nrouter ospf6\n ospf6 router-id 192.168.0.254 # 这个 router-id 似乎是独立的\n area 2.0.0.0 range fd00:10::/60 # 聚合/通告本地网络 (A的本地块)\nexit\n!\naccess-list vty seq 5 permit 127.0.0.0/8\naccess-list vty seq 10 deny any\n!\nline vty\n access-class vty\nexit\n!\nend!\nfrr version 10.2.1\nfrr defaults traditional\nhostname R-B\nlog syslog\n!\npassword [YOUR_SECURE_PASSWORD]\n!\nip route 192.168.0.0/16 reject # 内部地址防环/黑洞策略\nip router-id 192.168.8.254 # 路由器B的Router ID (与隧道IP一致)\n!\ninterface eth0\n ip address 192.168.11.254/24 # 假设eth0的IP\n ip ospf area 1.0.0.0\n ip ospf network broadcast # 这个接口是广播接口，可以通过交换机连接子 OSPF 交换机 \n ip ospf priority 255 # 主路由器给高优先级，DR/BDR 选举时成为 DR\n ipv6 ospf6 area 1.0.0.0\n no ip ospf passive\nexit\n!\ninterface wg4\n ip address 192.168.8.254/32 # 隧道IPv4地址 (与Router ID一致)\n ip ospf area 0\n ip ospf network point-to-point\n no ip ospf passive\nexit\n!\ninterface wg6\n ipv6 address fd00:f000::2/128 # 隧道IPv6 ULA地址\n ipv6 address fe80::192:168:8:254/64 # 链路本地地址\n ipv6 ospf6 area 0\n ipv6 ospf6 network point-to-point\nexit\n!\nrouter ospf\n passive-interface default\n area 1.0.0.0 range 192.168.8.0/22 # 聚合/通告本地网络 (B的本地块)\nexit\n!\nrouter ospf6\n area 1.0.0.0 range fd00:20::/60 # 聚合/通告本地网络 (B的本地块)\nexit\n!\naccess-list vty seq 5 permit 127.0.0.0/8\naccess-list vty seq 10 deny any\n!\nline vty\n access-class vty\nexit\n!\nend查看路由表，可以看到对方宣告过来的路由以 O>* 标记，这表明路由是 OSPF 宣告的，已被选中并安装到内核中。
\n然后 ping 一下，双方都可以 ping 通。
EOF~
\n", "date_published": "2025-11-25T00:00:00.000Z", "date_modified": "2025-11-25T18:22:56.000Z", "authors": [ { "name": "DynamicLoader", "url": "https://octz.net/" } ], "tags": [ "Maintaince" ] }, { "title": "浅谈 IPv6 地址设计与分配", "url": "https://octz.net/blog/Note/thoughts-about-ipv6.html", "id": "https://octz.net/blog/Note/thoughts-about-ipv6.html", "summary": "免责声明 以下仅为个人观点，实际以 RFC 为准。 关于 IPv6 地址设计思想？ 地址总长度的选择 我们都知道，传统的 IP 地址（也就是 IPv4 地址）只有 32 位，其中的公网可用部分已经在前些年完全分配完毕。 IPv6 的提出，一方面要尽可能的缓解地址短缺的问题，另一方面也要尽力的缓解路由碎片化的问题，减少广域网骨干路由表的大小。 如果回到 ...", "content_html": "免责声明
\n以下仅为个人观点，实际以 RFC 为准。
\nGN 是一个可生成 Ninja 构建配置文件的源构建系统。常用 C/C++ 的同志们都知道 CMake，GN 在某种意义上和 CMake 同级，只不过它只能生成 Ninja makefile，但也提供比 CMake 更多更便利的功能。
\n和 CMake 类似，GN 也是一个 DSL (领域特定语言)，像是 Python 和 C 的混合体。
\n这并不是一个完整的教程，只是用到了就会来补充用法，权当一个速查手册。
\n写一个 BUILD.gn（不要改名）：
executable(\"demo_exe\") {\n sources = [ \"demo.cc\" ]\n}That's All!
\n这里我们创建了一个名叫 demo_exe 的 target，类型是可执行文件，源文件有 demo.cc。
对于静态库，使用 static_library；动态库是 shared_library。
这在 GN 中被描述为“依赖” (deps)。如果我们的 demo_exe 使用了 base 库的内容，则我们需要这样将依赖加入 deps 数组即可：
executable(\"demo_exe\") {\n sources = [ \"demo.cc\" ]\n\n deps = [ \"//base\" ] # here\n}// 是指项目根目录。
在 target 内部加入 defines 数组即可：
\ndefines = [\n \"HELLO_SHARED_IMPLEMENTATION\",\n \"ENABLE_DOOM_MELON=0\",\n]GN 内部存在很多的变量，我们也可以可以定义变量，然后使用条件控制语句控制。
\n以常见的跨平台场景为例，我们有 demo.h 定义了接口，然后对于 Windows, linux 和 mac 有 demo_win.cc, demo_linux.cc 和 demo_mac.cc 作为实现。则可以这样写：
executable(\"demo_exe\") {\n sources = [ \"demo.h\" ]\n\n if(is_win){\n sources += [\"demo_win.cc\"]\n }\n\n if(is_linux){\n sources += [\"demo_linux.cc\"]\n }\n\n if(is_mac) {\n sources += [\"demo_mac.cc\"]\n }\n}这里的 is_win，is_linux 和 is_mac 都是 GN 的预定义变量。自定义变量只需要直接写 var_name = value 即可。
$ gn gen <out_dir>随后转到 out_dir 执行 ninja 即可。
失败了，姑且看看图吧，拿来照玩家的话有些不好看...
\n![\"emmm...\"](\"https://imgcdn0.octz.net/vrchat/tech/image-5.png\")
由于渲染管线的并行特性限制，我们并不能在一个 Pixel Shader 中读写同一个缓冲区。那么，我们如何将当前的颜色和已经绘制的颜色混合起来呢？答案是通过 Blend 指令。Blend 指令将在渲染管线的特定步骤执行，以将当前 Pixel Shader 的输出缓冲 (Source) 和屏幕缓冲区(Destination) 以指定的方式混合。典型操作表达式为：
\n其中 OP 代表某种操作，通常是加，也可以是下面这几十种（以 [Enum(UnityEngine.Rendering.BlendOp)] 注明）
![\"Blend](\"https://imgcdn0.octz.net/vrchat/tech/image-6.png\")
而 Blend 指令的基础格式是：
\nBlend [RT] <Src> <Dst> | <SrcRGB> <DstRGB>, <SrcA> <DstA>Src 等参数统称为 Blend Mode, 其取值以 [Enum(UnityEngine.Rendering.BlendMode)] 注明，有如下几个：
![\"Blend](\"https://imgcdn0.octz.net/vrchat/tech/image-7.png\")
我们要实现一种朦胧感，考虑让材质输出为一个灰色蒙版，随后配置 Source blend mode 为 One，Destination blend mode 为 OneMinusSrcColor。
我们当然不希望所有东西都被我们选中并且做颜色混合。总结起来，
\n所以实际上，我们可以控制的是 RenderQueue，StencilTest 和 ZTest 的行为。
\n这部分内容过多，建议查看原视频理解掌握。这里给出几张图和说明，帮助理解：
\n![\"可爱的](\"https://imgcdn0.octz.net/vrchat/tech/image-9.png\")
其中，手是素体的一部分，其 RenderQueue 为 2451，Stencli 为 Always Keep (0)， ZWrite = true；
\n衣服的 RenderQueue 为 2460，Stencli 和 ZWrite 都和素体保持一样的设定。
在这前面放置一个胶囊，应用我们的材质，然后 Blend Mode 设置和上面混合颜色设置一致。
\n![\"仅设定](\"https://imgcdn0.octz.net/vrchat/tech/image-10.png\")
这种情况下，先绘制了素体，然后绘制我们的胶囊。胶囊绘制完成后，由于其 ZWrite 为 On，且胶囊比衣服离我们更近，所以深度缓冲被写入了更大的值；随后绘制衣服，在 ZTest 时已被胶囊绘制的部分会失败，从而维持胶囊的绘制结果，显示为部分透明。(如果设置 RenderQueue 为 2461 则这种透明消失)
\n在此基础上，我们再设置素体的 Stencil 为 Always Replace (22)，随后在胶囊材质设置 StencilTest Mode 为 Euqal 22，可以得到：
\n![\"部分可见的手臂\"](\"https://imgcdn0.octz.net/vrchat/tech/image-11.png\")
这是因为 Stencil 测试通过的只有素体在胶囊这个范围内的部分，也只有这些东西被混合了并且写了深度。
\n当我们关闭深度写入，以上的一切都消失了，又回到了原本的样子。这是因为后续衣服在渲染的时候发现自身的Z小于缓冲区里的（ZTest 默认 LessEqual Pass），进行了覆盖。这就是 ZTest 的意义。
\n补充一点，正经的半透明物体一般做法是将渲染队列开高，然后将 ZWrite 关闭。这样就可以达到该透过的物品已经绘制了，但是位于半透明物品前（更靠近摄像机）的物体仍然可以进行正确的覆盖，符合预期。
\nShader \"Unlit/ScreenMaskShader\"\n{\n Properties\n {\n _MainTex (\"Texture\", 2D) = \"white\" { }\n \n [Enum(UnityEngine.Rendering.BlendMode)]\n _SrcBlend (\"Source blend\", Float) = 0\n\n [Enum(UnityEngine.Rendering.BlendMode)]\n _DstBlend (\"Destination blend\", Float) = 0\n\n [Enum(UnityEngine.Rendering.BlendOp)]\n _BlendOp (\"Blend Operation\", Float) = 0\n\n\n _StencilRef (\"Stencil Ref Value\", Range(0,255)) = 0\n\n [Enum(UnityEngine.Rendering.CompareFunction)]\n _StencilComp (\"Stencil Compare Mode\", Float) = 0\n\n [Enum(UnityEngine.Rendering.StencilOp)]\n _StencilPassOp (\"Stencil Pass Operation\",Float) = 0\n\n [Enum(UnityEngine.Rendering.StencilOp)]\n _StencilFailOp (\"Stencil Fail Operation\",Float) = 0\n\n [Enum(UnityEngine.Rendering.CompareFunction)]\n _ZTestComp (\"ZTest Compare function\", Float) = 0\n\n [Enum(Off, 0, On, 1)]\n _ZWrite (\"ZWrite\", Float) = 0\n\n }\n SubShader\n {\n Tags { \"RenderType\" = \"Opaque\" }\n LOD 100\n\n Pass\n {\n\n Blend [_SrcBlend] [_DstBlend]\n // Blend Zero One, SrcAlpha OneMinusSrcAlpha\n BlendOp [_BlendOp]\n // ColorMask 0\n\n Stencil \n { \n Ref [_StencilRef]\n Comp [_StencilComp]\n Pass [_StencilPassOp]\n Fail [_StencilFailOp]\n }\n\n ZTest [_ZTestComp]\n ZWrite [_ZWrite]\n\n HLSLPROGRAM\n #pragma vertex vert\n #pragma fragment frag\n // make fog work\n #pragma multi_compile_fog\n\n #include \"UnityCG.cginc\"\n\n struct appdata\n {\n float4 vertex : POSITION;\n float2 uv : TEXCOORD0;\n };\n\n struct v2f\n {\n float2 uv : TEXCOORD0;\n UNITY_FOG_COORDS(1)\n float4 vertex : SV_POSITION;\n };\n\n sampler2D _MainTex;\n float4 _MainTex_ST;\n\n v2f vert(appdata v)\n {\n v2f o;\n o.vertex = UnityObjectToClipPos(v.vertex);\n o.uv = TRANSFORM_TEX(v.uv, _MainTex);\n UNITY_TRANSFER_FOG(o, o.vertex);\n return o;\n }\n\n fixed4 frag(v2f i) : SV_Target\n {\n fixed4 col = tex2D(_MainTex, i.uv);\n col *= 0.08;\n \n // apply fog\n UNITY_APPLY_FOG(i.fogCoord, col);\n return col;\n }\n ENDHLSL\n }\n }\n}liltoon 啥都有，但是为了简化模型还是手搓了
\n关于各种缓冲区的结论，是使用 RenderDoc 抓帧得到的，但是仍然有如下几个点：
\n![\"例子\"](\"https://imgcdn0.octz.net/vrchat/tech/image-12.png\")
暂未找到原因。
\n", "image": "https://imgcdn0.octz.net/vrchat/tech/image-5.png", "date_published": "2025-10-29T00:00:00.000Z", "date_modified": "2025-10-29T14:19:41.000Z", "authors": [ { "name": "DynamicLoader", "url": "https://octz.net/" } ], "tags": [ "Game" ] }, { "title": "面向 VRChat 的渲染入门 (1) Shader 基础笔记", "url": "https://octz.net/games/vrchat/tech/shader0.html", "id": "https://octz.net/games/vrchat/tech/shader0.html", "summary": "前言 算是一个作业记录？哈哈哈 任务是使用 shader 实现： 线性渐变 径向渐变 进度条 什么是线性渐变和径向渐变 不知道喵，看 MDN linear-gradient() 和 radial-gradient() 体会一下。 效果图效果图 环境预设 搭建一个场景，存在这样的一个 Cube: Cube InspectorCube Inspector ...", "content_html": "\n\n算是一个作业记录？哈哈哈
\n
任务是使用 shader 实现：
\n什么是线性渐变和径向渐变
\n不知道喵，看 MDN linear-gradient() 和 radial-gradient() 体会一下。
\n![\"效果图\"](\"https://imgcdn0.octz.net/vrchat/tech/image-2.png\")
搭建一个场景，存在这样的一个 Cube:
\n![\"Cube](\"https://imgcdn0.octz.net/vrchat/tech/image-1.png\")
一个 Cube 有 6 个面，考虑每个面渲染一个图像，主要工作在顶点着色器上，我们预先写下一个板子：
\nShader \"Unlit/NewUnlitShader\"\n{\n Properties\n {\n _MainTex (\"Texture\", 2D) = \"white\" { }\n }\n SubShader\n {\n Tags { \"RenderType\" = \"Opaque\" }\n LOD 100\n\n Pass\n {\n HLSLPROGRAM\n #pragma vertex vert\n #pragma fragment frag\n // make fog work\n #pragma multi_compile_fog\n\n #include \"UnityCG.cginc\"\n\n struct v2f\n {\n float2 uv : TEXCOORD0;\n UNITY_FOG_COORDS(1)\n float4 vertex : SV_POSITION;\n float3 worldNormal : NORMAL;\n };\n\n sampler2D _MainTex;\n float4 _MainTex_ST;\n\n v2f vert(appdata_base v)\n {\n v2f o;\n o.vertex = UnityObjectToClipPos(v.vertex);\n o.uv = TRANSFORM_TEX(v.texcoord, _MainTex);\n UNITY_TRANSFER_FOG(o, o.vertex);\n o.worldNormal = UnityObjectToWorldNormal(v.normal);\n return o;\n }\n\n fixed4 linear_gradient(float2 uv, float4 color1, float4 color2)\n {\n }\n\n fixed4 radial_gradient(float2 uv, float4 color1, float4 color2)\n {\n }\n\n fixed4 progress_bar(float2 uv, float4 color, float percentage)\n {\n }\n\n fixed4 frag(v2f i) : SV_Target\n {\n float3 normal = normalize(i.worldNormal);\n float time = abs(sin(_Time.y));\n float4 col = step(0.5, dot(normal, float3(-1, 0, 0))) * linear_gradient(i.uv, float4(1.0, 0.0, 0.0, 0.0), float4(0.0, 1.0, 0.0, 0.0))\n + step(0.5, dot(normal, float3(0, 1, 0))) * radial_gradient(i.uv, float4(1.0, 0.0, 0.0, 0.0), float4(0.0, 1.0, 0.0, 0.0))\n + step(0.5, dot(normal, float3(0, 0, -1))) * progress_bar(i.uv, float4(0.0, 1.0, 0.0, 0.0), time);\n // apply fog\n UNITY_APPLY_FOG(i.fogCoord, col);\n return col;\n }\n ENDHLSL\n }\n }\n}工作就变成了实现 linear_gradient 、radial_gradient 和 progress_bar 这三个函数。
考虑最简单的无角度单向渐变，给定两个颜色 color1 和 color2，在一个方形平面内，我们有：
(0,1) (1,1)\n +写了那么久，也快一个月了，都是在 QEMU 调试，多没意思。电子人，就是干，火速弄了块 Sipeed 的 LicheeRV Nano，基于 C906 和 A53的 SG2002，不到一够水就有百兆网口和 WiFi。（深圳到广州居然发了两天，真是慢啊，还有这排线还要我自己焊，好傻）
\n拿到板子，插锭，开机，屏幕没有当然点不亮。电脑上不停的叮咚响，看了下是模拟出了一个串口。那就很简单，直接找到镜像，烧录！再把卡插进去，启动！好了，过了一会，多了一个网卡，ssh一下成功，测试功能正常。那么就开始我们的上板之旅吧！
\n我们知道，嵌入式 Linux 的启动流程通常是，FSBL -> 固件 -> U-Boot -> 内核，这里的固件就是 OpenSBI。根据 Sipeed 官网的描述，这个片子的启动流程如下：
\n再看 boot 分区的内容，果然如此：
\nMode LastWriteTime Length Name这是 AbydOS 的第一篇博文。近期在学习操作系统，想着自己搞一个玩玩，结合之前开发嵌入式的经验，以及烂尾了的 RISCV 模拟器工程，选定了带有 OpenSBI 支持的 RISCV64 平台。
\n本文主要记录工具链和构建系统的选择与调试过程。
\n既然选定了平台，就开始构建 OpenSBI。根据 OpenSBI 的文档，尝试在 Ubuntu 20.04 (WSL1) 上安装了 gcc-riscv64-unknown-elf 和 qemu-system 等软件包，使用
CROSS_COMPILE=riscv64-unknown-elf- make PLATFORM=generic编译之，成功了。开跑，
\nCROSS_COMPILE=riscv64-unknown-elf- make PLATFORM=generic run，测试 payload 转起来了。
\n既然 OpenSBI 编译过了，那就可以新建文件夹了。一开始想，内核的构建比较复杂，OpenSBI 有现成的 Makefile，套娃一个目录结构然后稍微改一下 Makefile，应该可以单独编译 payload，然后再以 payload 为例搭建上层环境。经过一上午的努力，目录结构变成了这样：
\nAbydOS\n |\n +- kernel\n | |\n | +- main\n | |\n | +- objects.mk\n | +- Kconfig\n | +- test.c\n | +- test.S\n | +- test.ldS\n |\n +- platform\n | |\n | + qemu-virt\n | |\n | +- objects.mk\n | +- Kconfig\n | +- platform.c\n |\n +- Kconfig\n +- Makefile爆改两个小时的 Makefile，终于是成功编译了。
\n改了两个小时的 Makefile，我已经在各种变量和奇怪的命令中晕头转向。这时候，我想到了现代 C++ 工程的神器：CMake。兴奋地写了两句：
\ncmake_minimum_required(VERSION 3.0.0)\nproject(AbydOS_Kernel VERSION 0.1.0 LANGUAGES C ASM)VSCODE 选择工具链：GCC 9.3.0 riscv64-unknown-elf，Configure, 爆！
[cmake] CMake Error at /usr/share/cmake-3.16/Modules/CMakeTestCCompiler.cmake:60 (message):\n[cmake] The C compiler\n[cmake] \n[cmake] \"/usr/bin/riscv64-unknown-elf-gcc\"\n[cmake] \n[cmake] is not able to compile a simple test program.\n[cmake] \n[cmake] It fails with the following output:\n[cmake] \n[cmake] Change Dir: /home/wsl/AbydOS/build/CMakeFiles/CMakeTmp\n[cmake] \n[cmake] Run Build Command(s):/usr/bin/make cmTC_164d0/fast && /usr/bin/make -f CMakeFiles/cmTC_164d0.dir/build.make CMakeFiles/cmTC_164d0.dir/build\n[cmake] make[1]: Entering directory '/home/wsl/AbydOS/build/CMakeFiles/CMakeTmp'\n[cmake] Building C object CMakeFiles/cmTC_164d0.dir/testCCompiler.c.o\n[cmake] /usr/bin/riscv64-unknown-elf-gcc -o CMakeFiles/cmTC_164d0.dir/testCCompiler.c.o -c /home/wsl/AbydOS/build/CMakeFiles/CMakeTmp/testCCompiler.c\n[cmake] Linking C executable cmTC_164d0\n[cmake] /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_164d0.dir/link.txt --verbose=1\n[cmake] /usr/bin/riscv64-unknown-elf-gcc -rdynamic CMakeFiles/cmTC_164d0.dir/testCCompiler.c.o -o cmTC_164d0 \n[cmake] riscv64-unknown-elf-gcc: error: unrecognized command line option '-rdynamic'于是上网开搜，一看 unknown-elf 工具链没有 crt，肯定不支持 '-rdynamic'，总共有两种解决方案：
\n考虑到绕过 CMake 的编译器检查可能不太好，选2，安装 gcc-riscv64-linux-gnu。再次尝试 Configure，过了！
于是从原始的 Makefile 抽一点编译参数出来，把 CMakeLists.txt 补全，尝试编译，过了！运行，哎，结果和原来不一样，一个全局const char* 变量 test_args 没有正常初始化，期望是指向 .rodata 段的，可是运行起来是0。
出现全局变量不初始化的问题，根据嵌入式裸机开发的经验，我第一时间想到的原因是 .data 段没有正常初始化。但是链接脚本没有划分 Memory Region，也没有做 LMA 和 VMA 的指定，.data 段的数据就应该完好地写在 ELF 文件里面。于是上 IDA 分析，一看，这不是初始化得好好的嘛，指向了0x1000。（注意这个坑点！）
\n由于 QEMU 的手册没有明确内存空间分布，所以 kernel 的起始地址我设成了 0 ，然后使用 -fPIC 参数编译。这样一来，理论上，无论内核被加载到哪里，都应该能够正常跑。搞不定，觉得可能是编译参数不对，改了半天的编译参数，试图去掉自动添加的 '-rdynamic'，无果。（后来明确，这个参数并不指示编译器动态链接）。一天就这样过去了。
\n第二天，继续修改。由于 ELF 中有 .dynamic 和 。rela.* 段，怀疑是需要重定位，从 OpenSBI 里面抄了一段重定位的汇编代码，再次编译，还是不行。实在没辙了，上 gdb-multiarch 调试，才发现固件运行的地址不是 0x0，不能正常调。找了半天，终于在 OpenSBI 的 platform/generic/objects.mk 里面看到：
\nFW_TEXT_START=0x80000000\nFW_DYNAMIC=y\nFW_JUMP=y\nifeq ($(PLATFORM_RISCV_XLEN), 32)\n # This needs to be 4MB aligned for 32-bit system\n FW_JUMP_OFFSET=0x400000\nelse\n # This needs to be 2MB aligned for 64-bit system\n FW_JUMP_OFFSET=0x200000\nendif这样看，最终运行地址就是 0x80000000 + 0x200000，（
\n实际上这个值在 OpenSBI 的调试信息就有输出：
\nDomain0 Next Address : 0x0000000080200000\nDomain0 Next Arg1 : 0x0000000082200000\nDomain0 Next Mode : S-mode)，这样就直接链接脚本改起始地址到 0x80200000，再编译测试，原来跑不通的 fw_jump 固件也正常了。
\n自此，上 gdb ，就可以正常 debug 了。看了 test_args 的地址，是 0x80203028，和 ELF 中指示的 .data 段范围一致，再 print 一下，就是 0x0 ! 再上 IDA , 这次它的值不是 0x1000 了，而是 0x100401000，一个很怪异的值。看到.rodata段对应地址是 0x80201000，计算器启动，得到 0x100401000 - 0x80201000 = 0x80200000，正好是内核起始地址。于是怀疑全局指针没设对，但是转念想，我都 -fPIC了，寻址应该没有问题，调试出来的 test_args 地址和 IDA 看到的也一致。
\n这时候想起直接看 ELF 的值了，7z 解压 .data 段， Hex Editor 一看，这TM写的就是0！还是工具链的锅！于是改回 unknown-elf，跳过了 CMake 的编译器检查，终于是 Configure 过了。尝试编译，还是卡在 '-rdynamic' 上，这问题没有根本解决。看报错知道是链接参数的锅，这个链接参数又是 CMake 加上去的，一顿搜索之后找到了 CMake 的一个提交历史，清晰地显示了：
\n # We pass this for historical reasons. Projects may have\n # executables that use dlopen but do not set ENABLE_EXPORTS.\n set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS \"-rdynamic\")这样就知道参数从哪里来了。直接在工程的配置里面重写：
\n# get rid of '-rdynamic'\nset(CMAKE_STATIC_LINKER_FLAGS \" \")\nset(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS \"\")\nset(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS \"\")这样再配置和编译，就顺利通过了。
\n配置好了构建系统和工具链，就该考虑 C++ 支持了。还是老办法，既然 C 的环境由 ASM 初始化，那么 C++ 环境就可以由 C 来初始化。根据经验，只需使用 extern "C" 修饰函数 k_main，然后就可以在 C 里面调用之，之后在 k_main 里面就可以完全使用 C++ 写了。
\n实践确实如此，不过写了类测试，发现加上析构函数之后编译不过，爆链接错误，链接到了一个叫做 _UnWind_Resume 的函数，在 libstdc++ 里面。想到C++ 的异常捕获机制，析构时会捕获异常，这里没有捕获异常的环境，于是加入 -fno-exceptions参数，再编译就过了。
经过这样的配置，不到 60 行的 CMakeLists，支持了 C++ 写内核，真是太舒服啦！语法特性完全都是可用的！
\n这个配置花了两天多的时间才完成，太痛苦啦！
\n今天在 QEMU 的源码 查到了设备内存布局：
\nstatic const MemMapEntry virt_memmap[] = {\n [VIRT_DEBUG] = { 0x0, 0x100 },\n [VIRT_MROM] = { 0x1000, 0xf000 },\n [VIRT_TEST] = { 0x100000, 0x1000 },\n [VIRT_RTC] = { 0x101000, 0x1000 },\n [VIRT_CLINT] = { 0x2000000, 0x10000 },\n [VIRT_ACLINT_SSWI] = { 0x2F00000, 0x4000 },\n [VIRT_PCIE_PIO] = { 0x3000000, 0x10000 },\n [VIRT_PLATFORM_BUS] = { 0x4000000, 0x2000000 },\n [VIRT_PLIC] = { 0xc000000, VIRT_PLIC_SIZE(VIRT_CPUS_MAX * 2) },\n [VIRT_APLIC_M] = { 0xc000000, APLIC_SIZE(VIRT_CPUS_MAX) },\n [VIRT_APLIC_S] = { 0xd000000, APLIC_SIZE(VIRT_CPUS_MAX) },\n [VIRT_UART0] = { 0x10000000, 0x100 },\n [VIRT_VIRTIO] = { 0x10001000, 0x1000 },\n [VIRT_FW_CFG] = { 0x10100000, 0x18 },\n [VIRT_FLASH] = { 0x20000000, 0x4000000 }, \n [VIRT_IMSIC_M] = { 0x24000000, VIRT_IMSIC_MAX_SIZE },\n [VIRT_IMSIC_S] = { 0x28000000, VIRT_IMSIC_MAX_SIZE },\n [VIRT_PCIE_ECAM] = { 0x30000000, 0x10000000 },\n [VIRT_PCIE_MMIO] = { 0x40000000, 0x40000000 },\n [VIRT_DRAM] = { 0x80000000, 0x0 }, \n};就这样吧，接着搞 MMU 去喽！
\n", "date_published": "2024-03-08T00:00:00.000Z", "date_modified": "2025-10-18T03:18:49.000Z", "authors": [ { "name": "DynamicLoader", "url": "https://octz.net/" } ], "tags": [ "ABYDOS" ] }, { "title": "AbydOS开发日记 (1) - 基础运行环境构建", "url": "https://octz.net/blog/AbydOS/1-cxx-and-envs.html", "id": "https://octz.net/blog/AbydOS/1-cxx-and-envs.html", "summary": "基础环境是什么？ 上回说到，通过一点手段，我们成功启用了 C++ 的支持。但是，这样的支持并不完善，我们的内核到目前为止，还没有一个 C 运行库(libc)，更别提 C++ 标准库(libc++)了。这就意味着，所有需要用的函数和类都要手写一份，非常折磨人。所以，引入 C 和 C++ 基础库是接下来要做的事。 嵌入式里边，最常用的 libc 是 new...", "content_html": "上回说到，通过一点手段，我们成功启用了 C++ 的支持。但是，这样的支持并不完善，我们的内核到目前为止，还没有一个 C 运行库(libc)，更别提 C++ 标准库(libc++)了。这就意味着，所有需要用的函数和类都要手写一份，非常折磨人。所以，引入 C 和 C++ 基础库是接下来要做的事。
\n嵌入式里边，最常用的 libc 是 newlib, 而 C++ 的实现则可以使用 libsupc++。
\n之前的编译里边，为了最小化库的引入，我加入了一个编译参数：-nostdlib。这个参数指示 gcc 不要链接标准库。所以要引入标准库，第一步就是把这个参数去掉，但是又不能引入默认的 crt 初始文件，所以还得加上 -nostartfiles，然后测试编译器的支持。很不幸地，我只写了一句：
#include <stdio.h>然后编译就报错了。一开始，我怀疑是 Include Path 没有设置正确，但是 gcc -v 提示：
Using built-in specs.\nCOLLECT_GCC=riscv64-unknown-elf-gcc\nCOLLECT_LTO_WRAPPER=/usr/lib/gcc/riscv64-unknown-elf/9.3.0/lto-wrapper\nTarget: riscv64-unknown-elf\nConfigured with: ../configure --build=x86_64-linux-gnu --prefix=/usr \n--includedir='/usr/include' \n--mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir='/usr/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/x86_64-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --target=riscv64-unknown-elf --prefix=/usr --infodir=/usr/share/doc/gcc-riscv64-unknown-elf/info --mandir=/usr/share/man --htmldir=/usr/share/doc/gcc-riscv64-unknown-elf/html --pdfdir=/usr/share/doc/gcc-riscv64-unknown-elf/pdf --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --with-pkgversion= --disable-shared --disable-threads --enable-languages=c,c++ --enable-tls --with-newlib --with-native-system-header-dir=/include --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libgomp --disable-nls --with-system-zlib --enable-checking=yes --enable-multilib --with-abi=lp64d --disable-libstdcxx-pch --disable-libstdcxx --disable-fixinc --with-arch=rv64imafdc --with-gnu-as --with-gnu-ld --with-as=/usr/lib/riscv64-unknown-elf/bin/as --with-ld=/usr/lib/riscv64-unknown-elf/bin/ld AR_FOR_TARGET=/usr/lib/riscv64-unknown-elf/bin/ar AS_FOR_TARGET=/usr/lib/riscv64-unknown-elf/bin/as NM_FOR_TARGET=/usr/lib/riscv64-unknown-elf/bin/nm LD_FOR_TARGET=/usr/lib/riscv64-unknown-elf/bin/ld OBJDUMP_FOR_TARGET=/usr/lib/riscv64-unknown-elf/bin/objdump RANLIB_FOR_TARGET=/usr/lib/riscv64-unknown-elf/bin/ranlib READELF_FOR_TARGET=/usr/lib/riscv64-unknown-elf/bin/readelf STRIP_FOR_TARGET=/usr/lib/riscv64-unknown-elf/bin/strip CFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-riscv64-unknown-elf-3seJsn/gcc-riscv64-unknown-elf-9.3.0=. -fstack-protector-strong' CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=2' CXXFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-riscv64-unknown-elf-3seJsn/gcc-riscv64-unknown-elf-9.3.0=. -fstack-protector-strong' FCFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-riscv64-unknown-elf-3seJsn/gcc-riscv64-unknown-elf-9.3.0=. -fstack-protector-strong' FFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-riscv64-unknown-elf-3seJsn/gcc-riscv64-unknown-elf-9.3.0=. -fstack-protector-strong' GCJFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-riscv64-unknown-elf-3seJsn/gcc-riscv64-unknown-elf-9.3.0=. -fstack-protector-strong' LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' OBJCFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-riscv64-unknown-elf-3seJsn/gcc-riscv64-unknown-elf-9.3.0=. -fstack-protector-strong' OBJCXXFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-riscv64-unknown-elf-3seJsn/gcc-riscv64-unknown-elf-9.3.0=. -fstack-protector-strong' 'CFLAGS_FOR_TARGET=-Os -mcmodel=medany' 'CXXFLAGS_FOR_TARGET=-Os \n-mcmodel=medany'\nThread model: single\ngcc version 9.3.0 ()这表明默认的 include 目录是 /usr/include ，内存模型是 medany 。到 /usr/include 一看，啥也没有，证明这个包没有附带头文件，更别说预编译的库了。（不愧是裸机工具链，真是全 naked 啊）。
\n手动编译运行时太麻烦，最容易的解决方案就是换一个相同架构的、带有预编译库的工具链。很快，我找到了 riscv-collab/riscv-gnu-toolchain 这个官方的工具链仓库，它的 Release 有预编译的。兴致冲冲地下载下来，解压、配置，编译，爆！
\n...\nfindfp.c:(.text.global_stdio_init.part.0+0x2): relocation truncated to fit: R_RISCV_HI20 against `stdio_exit_handler'\n/opt/riscv/lib/gcc/riscv64-unknown-elf/13.2.0/../../../../riscv64-unknown-elf/lib/libc.a(libc_a-findfp.o): in function `__sfp':\nfindfp.c:(.text.__sfp+0x0): relocation truncated to fit: R_RISCV_HI20 against symbol `__stdio_exit_handler' defined in .sbss.__stdio_exit_handler section in /opt/riscv/lib/gcc/riscv64-unknown-elf/13.2.0/../../../../riscv64-unknown-elf/lib/libc.a(libc_a-findfp.o)\n/opt/riscv/lib/gcc/riscv64-unknown-elf/13.2.0/../../../../riscv64-unknown-elf/lib/libc.a(libc_a-findfp.o): in function `__sinit':\nfindfp.c:(.text.__sinit+0x6): additional relocation overflows omitted from the output\n...这里注意到关键信息是 R_RISCV_HI20 。到这个仓库搜 issue，果然有很多问题都类似，问题指向了工具链附带的库使用的内存模型不对，看配置信息确认是使用了 medlow。关于这两种内存模型的区别，实际上要牵扯到 RISCV 的寻址方式，这里不展开，可以查看这篇博文，这里只要知道 medlow 在 RISCV64 上不能支持我们所设定的内核启动地址 0x80200000。怎么办呢？同样是两种办法，
\n第一种方案并不具有可行性，因为在目前的大多数 RISCV SoC 上，DRAM 的起始地址是 0x80000000，低于这个地址能存储内核的空间，只能是不一定存在的 Flash 设备，或者预先被映射过的内存。出于兼容性考虑，选择第二种方案。由于官方仓库采用了 Github Actions 进行构建，我正好可以利用这一点，fork 一份仓库然后改一下构建配置就可以了。
\n经过两个多小时的睡觉，这套工具链终于编译好了。下载下来测试，编译顺利通过。
\n在之前的代码里，我们的输出函数是直接通过 ecall 调用 SBI 的控制台扩展 (DBCN Extension), 没有任何格式化的支持。要使用 printf 输出到控制台，我们要做的就是重写 printf 调用链最底端的输出函数。这时候 newlib 的方便就体现出来了，它的底层总共也只有二十多个 POSIX 的桩函数，只要实现了它们，移植就算完成了。关系到 printf 的桩函数看起来只有一个，那就是：
\nint _write(int fd, char *buf, int size)这里的 fd 是文件描述符。简单起见，这里我们可以这样实现：
\n// Hook with libc\nint _write(int fd, char *buf, int size)\n{\n sbi_ecall(SBI_EXT_DBCN, SBI_EXT_DBCN_CONSOLE_WRITE, size, (unsigned long)buf, 0, 0, 0, 0);\n return size;\n}直接不管 fd。这样之后，添加一个 printf 的调用，编译，不出意料地，报错了：
\nsbrk.c:(.text._sbrk+0x14): undefined reference to `end'这个 sbrk.c 实际上是堆内存分配相关的。这里爆了符号未定义的错误，原因就是我的链接器种没有定义 .heap 段，自然没有提供堆的结束地址。修改链接脚本，在内核末尾添加如下段：
\n.heap : {\n __heap_start__ = .;\n end = __heap_start__;\n _end = end;\n __end = end;\n KEEP(*(.heap))\n __heap_end__ = .;\n __HeapLimit = __heap_end__;\n }注意堆区是向上增长的，所以 end = heap_start。这样再编译就过了，测试也正常输出了。
\n有了 printf，很容易想到 C++ 的 std::cout。按照依赖关系，不难想到 cout 的最终调用仍然是 _write()，所以输出的底层就不用管了。尝试添加如下代码：
\nstd::cout << \"Hello!\\n\";编译，又爆了 qwq
\n[build] system_error.cc:(.text.startup._GLOBAL__sub_I__ZSt20__throw_system_errori+0x2): undefined reference to `__dso_handle'\n[build] /opt/riscv/lib/gcc/riscv64-unknown-elf/13.2.0/../../../../riscv64-unknown-elf/bin/ld: system_error.cc:(.text.startup._GLOBAL__sub_I__ZSt20__throw_system_errori+0x26): undefined reference to `__dso_handle'\n[build] /opt/riscv/lib/gcc/riscv64-unknown-elf/13.2.0/../../../../riscv64-unknown-elf/bin/ld: AbydOS_KNL: hidden symbol `__dso_handle' isn't defined\n[build] /opt/riscv/lib/gcc/riscv64-unknown-elf/13.2.0/../../../../riscv64-unknown-elf/bin/ld: final link failed: bad value这里提示 __dso_handle 符号找不到，搜索之后知道 DSO 就是 Dynamic Shared Object, 和虚函数那套东西有关系。而 std::cout 又恰好是虚基类派生的，出问题很正常。这里找到了 OSDev Wiki 的解释和解决办法，照着文档补上几个函数：
\nvoid *__dso_handle(); \nint __cxa_atexit(void (*f)(void *), void *objptr, void *dso);\nvoid __cxa_finalize(void *f);\nvoid __cxa_pure_virtual();然后再编译，过了。测试，哎，你怎么卡死了？GDB 一调，好家伙，直接干到 _start_hang 里了，看来是触发了异常然后重置了，由于原子量标记不为0，汇编代码就跳到挂起循环了。想到 std::cout 需要动态分配内存，但是全局new 和 delete 的 operator 没有显式重载，于是加入:
\nvoid *operator new(size_t size)\n{\n return malloc(size);\n}\n\nvoid *operator new[](size_t size)\n{\n return malloc(size);\n}\n\nvoid operator delete(void *p)\n{\n free(p);\n}\n\nvoid operator delete[](void *p)\n{\n free(p);\n}但是并不起作用，还是卡死。
\n既然排除了内存分配问题，该考虑的就是异常处理了。如果它抛出了异常，但是没有被正常 catch，那就会直接调用 _exit()，在 gdb 调试中也能看到：
\n(gdb) backtrace\n#0 0x000000008021caba in _exit ()\n#1 0x000000008021190e in abort ()\nBacktrace stopped: frame did not save the PC然后就找到了 OSDev 关于 libsupc++ 的异常捕获的说明：
\n\n\nTo make use of exception handling, you also have to tell libsupc++ where the .eh_frame section begins. Before you throw any exception: .
\n
\nTerminate the .eh_frame section with 4 bytes of zeros (somehow). If you forget this, libsupc++ will never find the end of .eh_frame and generate stupid page faults.
打开 ELF 文件，确实有 .eh_frame 段产生，还有一堆 .gcc_except_table.* 以及 .srodata.*。这样就先修改链接脚本，把段的起始地址导出来(顺手把没归类的节都归入 .text 和 .srodata 段)：
\n .text :\n\t{\n\t\tPROVIDE(_text_start = .);\n\t\t*(.entry)\n\t\t*(.text)\n\t\t*(.text.*)\n\t\t*(.gcc.*)\n\t\t*(.gcc_except_table.*)\n\t\t. = ALIGN(8);\n\t\tPROVIDE(_text_end = .);\n\t}\n\n .eh_frame :\n\t{\n\t\tPROVIDE(__eh_frame_start = .);\n\t\t*(.eh_frame);\n\t}\n\n .srodata :\n\t{\n\t\tPROVIDE(_srodata_start = .);\n \t*(.srodata.cst16)\n \t*(.srodata.cst8)\n \t*(.srodata.cst4)\n \t*(.srodata.cst2)\n \t*(.srodata .srodata.*)\n\t\t. = ALIGN(8);\n\t\tPROVIDE(_srodata_end = .);\n\t}然后猜一下 __register_frame() 的原型，在调用 k_main() 之前先调用：
// Prepare C++ environment\nvoid k_prep_cxx()\n{\n // init C++ exceptions\n extern void *__eh_frame_start;\n extern void __register_frame(void *); // not knowing the prototype of __register_frame, guess and OK!\n __register_frame(&__eh_frame_start);\n}这样再编译测试，成功了！
\n看文档的时候注意到 Calling Global Constructors，想起来我确实没有给全局构造函数啥的划分段，更别提调用了。再次修改链接脚本，增加：
\n .init_array :\n\t{\n\t PROVIDE_HIDDEN (_init_array_start = .);\n\t KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*)))\n\t KEEP (*(.init_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .ctors))\n\t . = ALIGN(8);\n\t PROVIDE_HIDDEN (_init_array_end = .);\n\t} \n\t\n\t. = ALIGN(0x1000);\n\n\t.fini_array :\n\t{\n\t PROVIDE_HIDDEN (_fini_array_start = .);\n\t KEEP (*(SORT_BY_INIT_PRIORITY(.fini_array.*) SORT_BY_INIT_PRIORITY(.dtors.*)))\n\t KEEP (*(.fini_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .dtors))\n\t . = ALIGN(8);\n\t PROVIDE_HIDDEN (_fini_array_end = .);\n\t}之后增加两段代码，分别在 k_main() 前后调用这些构造函数和析构函数即可。
\ntypedef void (*__init_func_ptr)();\nextern __init_func_ptr _init_array_start[0], _init_array_end[0];\nextern __init_func_ptr _fini_array_start[0], _fini_array_end[0];\n\n// kernel init\nvoid k_before_main(unsigned long *pa0, unsigned long *pa1)\n{\n printf(\"\\n===== Entered Test Kernel =====\\n\");\n printf(\"a0: 0x%lx \\t a1: 0x%lx\\n\", *pa0, *pa1);\n\n printf(\"Calling init_array...\\n\");\n for (__init_func_ptr *func = _init_array_start; func != _init_array_end; func++)\n (*func)();\n\n // No args, use default\n if (*pa0 == 0)\n *pa0 = (unsigned long)default_args;\n}\n\n// kernel exit\nvoid k_after_main(int main_ret)\n{\n printf(\"\\nReached target k_after_main, clearing up...\\n\");\n\n for (__init_func_ptr *func = _fini_array_start; func != _fini_array_end; func++)\n (*func)();\n\n printf(\"===== Test Kernel exited with %i =====\\n\", main_ret);\n}至此，基础环境就基本搭建完成，异常、内存分配测试基本通过。总耗时：一天！
\n", "date_published": "2024-03-09T00:00:00.000Z", "date_modified": "2025-10-18T03:18:49.000Z", "authors": [ { "name": "DynamicLoader", "url": "https://octz.net/" } ], "tags": [ "ABYDOS" ] }, { "title": "AbydOS开发日记 (2) - 驱动程序框架和系统参数配置", "url": "https://octz.net/blog/AbydOS/2-device-detect-and-conf.html", "id": "https://octz.net/blog/AbydOS/2-device-detect-and-conf.html", "summary": "设备与系统参数 所有连接到系统上的部件，都可以视为设备，从而并入设备驱动框架统一管理。 但是在现代操作系统中，如果没有 ACPI，如何发现设备呢？主线 Linux 已经给出了答案，利用设备树 (Device Tree) 描述。 在设备树中，我们可以描述平台的特性、外设的接入情况、CPU 和 Memory 的数量，还可以携带配置参数，如命令行参数。 由于...", "content_html": "所有连接到系统上的部件，都可以视为设备，从而并入设备驱动框架统一管理。
\n但是在现代操作系统中，如果没有 ACPI，如何发现设备呢？主线 Linux 已经给出了答案，利用设备树 (Device Tree) 描述。
\n在设备树中，我们可以描述平台的特性、外设的接入情况、CPU 和 Memory 的数量，还可以携带配置参数，如命令行参数。
\n由于树状结构不好存储，所以 Linux 推出了一个工具 DTC (Device Tree Compiler)，用于将设备树源码 (DTS) 编译成扁平化的设备树 (Flattened Device Tree,FDT)，并且提供了一个 libfdt 库进行操作，可以进行增删改查。
\n本篇记录设备发现、驱动框架搭建和系统参数配置的设计和过程。关于设备树的详细解释，请参阅 Linux设备树 和 设备树的解析 LibFDT。
\n用 CS 的思维来考虑，设备都存在共同之处，也就可以抽象成一个基类。这里给出定义：
\n\n#define DRV_INSTALL_FUNC(V) __attribute__((constructor(V)))\n\ntypedef enum\n{\n DEV_TYPE_SYS = 1,\n DEV_TYPE_CHAR = 0x80,\n DEV_TYPE_BLOCK,\n} dev_type_t;\n\nclass DriverBase\n{\n public:\n // Returns 1 if driver can handle this device, or 2 for cover-all driver (will stop probing for sub nodes)\n virtual int probe(const char *name, const char *compatible) = 0;\n virtual long addDevice(const void *fdt) = 0; // returns handler\n virtual void removeDevice(long handler) = 0; // unregister device by handler\n virtual dev_type_t getDeviceType() = 0;\n\n virtual ~DriverBase() = default;\n};通过这样的基类，我们就可以通过 probe() 函数进行设备驱动程序枚举，并在枚举成功时调用 addDevice() 请求驱动程序添加设备，使用 removeDevice() 删除设备。
比如，考虑一个系统根设备驱动，这个设备驱动继承 DriverBase 并重写其中的虚函数：
static void drv_register();\n\nclass SysDev : public DriverBase\n{\n public:\n int probe(const char *name, const char *compatible) override\n {\n std::string id = name;\n if (id == \"chosen\") // Node to storage cmdline arguments\n return 2;\n if (id == \"\" && std::string(compatible).find(\"riscv\") != std::string::npos)\n return 1;\n return 0;\n }\n\n long addDevice(const void *fdt) override\n {\n return ++hdl_count;\n }\n void removeDevice(long handler) override\n {\n }\n dev_type_t getDeviceType() override\n {\n return DEV_TYPE_SYS;\n }\n\n private:\n static int hdl_count;\n friend void drv_register();\n};\n\nint SysDev::hdl_count = -1;\n\nstatic DRV_INSTALL_FUNC(200) void drv_register()\n{\n static SysDev drv;\n drv.hdl_count = 0;\n DriverManager::addDriver(drv);\n printf(\"Driver SysRoot installed\\n\");\n}这里还有一个 drv_register() 函数，用于注册驱动到系统中。
无论是 OpenSBI 还是 UBoot ，都将设备树加载到内存中并进行修补，随后通过一个寄存器传递到下一级。我们的系统目前从 OpenSBI 直接跳到内核的 _start 处开始执行，根据其文档，设备树地址通过寄存器 a1 传递。所以我们可以直接从 C 环境下的第二个参数接收设备树地址，并加以解析：
\nlong k_early_boot(const unsigned long hart_id, const void *dtb_addr, void **sys_stack_base)\n{\n\n int ret = fdt_check_header(dtb_addr);\n if (ret != 0)\n {\n puts(\"[EBOOT] FDT header check failed\\n\");\n return -1;\n }\n\n ...\n\n}这里要明确一点，由于内存的描述也在设备树中，所以我们需要先于 k_cstart() 将设备树解析并正确设置系统栈。这里我们通过修改汇编代码增加一个对 k_early_boot() 的调用，在该函数中调整系统栈底的地址 (sys_stack_base)，并将设备树数据全部转移到不会冲突的系统内存区域，供后续正常环境使用，随后返回到汇编中调整系统栈。这项工作稍后再讲述。
进入 k_main() 之后，我们就可以开始进行设备发现了。定义这样一个驱动管理类：
class DriverManager\n{\n public:\n static void addDriver(DriverBase &drv)\n {\n _drvlist.push_back(&drv);\n }\n static void removeDriver(DriverBase &drv);\n\n protected:\n static int probe(const void *fdt,int node = 0);\n friend int k_main(int argc, const char *argv[]);\n\n private:\n static std::vector<DriverBase *> _drvlist;\n static char _depth[32];\n\n static int _try(const void *fdt, int node);\n};其中的 probe() 函数将递归地解析设备树，然后调用 _try() 依次调用注册的设备驱动的 probe() 函数，根据其返回值决定是否进行安装和跳过子节点解析。
到这里，我们只要在 k_main() 中调用 DriverManager::probe()，就可以完成设备发现了。
不过还有一个问题要解决，就是驱动程序要如何将自己在 k_main() 之前注册到 DriverManager 中，也就是由谁来调用 drv_register()。相信有经验的同志已经注意到上面的一个宏定义：
#define DRV_INSTALL_FUNC(V) __attribute__((constructor(V)))这里的 __attribute__((constructor(V))) 是一个 GCC 支持的函数属性描述宏，指示 GCC 将函数当作全局构造器 (Global Constructor)，其中的 V 是优先级，越小的越早执行。通过这个修饰，函数指针将被放入 .init_array 段中，并在 k_before_main() 被执行。
此外，我们还需保证 _drvlist 能够较早地初始化，使用下面的定义：
__attribute__((init_priority(K_PR_INIT_DRV_LIST))) std::vector<DriverBase *> DriverManager::_drvlist;指示 GCC 将这个全局对象的构造函数优先级提升到 K_PR_INIT_DRV_LIST。
前文提到要检测系统内存并设置栈，这里首先修改汇编启动代码，设置临时堆栈并调用 k_early_boot()：
\t/* Setup boot C stack */\n\tlla\ta3, _kernel_end\n\tlla\ta4, _KERNEL_BOOT_STACK_SIZE /* this is fake a address provided from ld */\n\tadd\tsp, a3, a4\n\tlla a3, _sys_stack_base\n\tREG_S\tsp, 0(a3)\n\n\t/* Early boot in C */\n\tlla\ta3, _boot_a0\n\tREG_L\ta0, 0(a3)\n\tlla\ta3, _boot_a1\n\tREG_L\ta1, 0(a3)\n\tlla a2, _sys_stack_base\n\tcall k_early_boot\n\n\tbne a0, zero, _start_hang \n\n_start_warm:\n ...随后在 k_early_boot 中解析内存节点：
\n // Detect system memory size\n ret = fdt_path_offset(dtb_addr, \"/memory\");\n if (ret < 0)\n {\n puts(\"[EBOOT] FDT memory node not found\\n\");\n return -3;\n }\n\n int regsize = 0;\n const void *memreg = fdt_getprop(dtb_addr, ret, \"reg\", ®size);\n if (!memreg || regsize < 16)\n {\n puts(\"[EBOOT] FDT memory reg invalid\\n\");\n return -4;\n }\n\n unsigned long mem_start = be2le64(((const unsigned long *)memreg)[0]);\n unsigned long mem_len = be2le64(((const unsigned long *)memreg)[1]);\n\n printf(\"[EBOOT] Memory Range: base= 0x%lx, len= 0x%lx\\n\", mem_start, mem_len);系统命令行参数也包含在设备树中，通过节点 /chosen 下的 bootargs属性提供。所以我们还可以先在这里解析了命令行参数，允许手动指定系统可用内存：
// Get the kernel command line\n ret = fdt_path_offset(dtb_addr, \"/chosen\");\n if (ret < 0)\n {\n puts(\"[EBOOT] FDT chosen node not found\\n\");\n return -5;\n }\n const void *kcmdline = fdt_getprop(dtb_addr, ret, \"bootargs\", ®size);\n if (!kcmdline || regsize < 1)\n {\n puts(\"[EBOOT] FDT bootargs invalid\\n\");\n return -6;\n }\n memcpy(kernel_args, kcmdline, regsize);\n puts(\"[EBOOT] Kernel command line: \");\n puts(kernel_args);\n\n // Parse Kerenl command line args for memory size (force override if specified in cmdline, only the first one is\n // used!)\n kernel_cmdargc = split_args((char *)kernel_args, kernel_args_array);\n unsigned long mem_len_cmdarg = 0;\n char mem_suffix = 'M';\n for (int i = 0; i < kernel_cmdargc; ++i)\n {\n if (strncmp(kernel_args_array[i], \"-mem\", 4) == 0)\n {\n if (i < kernel_cmdargc - 1)\n {\n int res = sscanf(kernel_args_array[i + 1], \"%ld %c\", &mem_len_cmdarg, &mem_suffix);\n if (res == 0)\n {\n puts(\"[EBOOT] Invalid memory size specified, skipping\\n\");\n mem_len_cmdarg = 0;\n break;\n }\n if (res == 1)\n {\n puts(\"[EBOOT] Memory size specified without suffix, assuming MB\\n\");\n mem_len_cmdarg *= 1024 * 1024;\n break;\n }\n if (res == 2)\n {\n switch (mem_suffix)\n {\n case 'K':\n case 'k':\n mem_len_cmdarg *= 1024;\n break;\n case 'M':\n case 'm':\n mem_len_cmdarg *= 1024 * 1024;\n break;\n case 'G':\n case 'g':\n mem_len_cmdarg *= 1024 * 1024 * 1024;\n break;\n default:\n puts(\"[EBOOT] Invalid memory size suffix, skipping\\n\");\n mem_len_cmdarg = 0;\n break;\n }\n break;\n }\n }\n else\n {\n puts(\"[EBOOT] Memory size not specified, skipping\\n\");\n mem_len_cmdarg = 0;\n break;\n }\n }\n }随后计算系统栈底：
\n k_mem_size = (mem_len_cmdarg > 0) ? mem_len_cmdarg : mem_len;\n\n *sys_stack_base = (void *)(mem_start + k_mem_size);\n printf(\"[EBOOT] Set SYS_SP: 0x%lx\\n\", (unsigned long)*sys_stack_base);至此，这一部分宣告结束，来一段 Log：
\n[EBOOT] Memory Range: base= 0x80000000, len= 0x10000000\n[EBOOT] Kernel command line:\n\n[EBOOT] Set SYS_SP: 0x90000000\n\n===== Entered Test Kernel =====\na0: 0x0\nCalling init_array...\nDriver SysMem installed\nDriver SysRoot installed\nDriver UART8250 installed\ncmd args: ''\nFinding driver for #0 [riscv-virtio] ... Found! Installing... OK, handler: 1\nFinding driver for #100 reserved-memory [] ... Found! Installing... OK, handler: 1\nFinding driver for #164 mmode_resv1@80000000 [] ... Failed\nFinding driver for #236 mmode_resv0@80040000 [] ... Failed\nFinding driver for #312 flash@20000000 [cfi-flash] ... Failed\nFinding driver for #420 chosen [] ... Found! Installing... OK, handler: 2\nDriver has cover the node with offset: 420\nFinding driver for #480 uart@10000000 [ns16550a] ... Found! Installing... OK, handler: 1\nFinding driver for #604 test@100000 [sifive,test1] ... Failed\nFinding driver for #692 virtio_mmio@10008000 [virtio,mmio] ... Failed\nFinding driver for #808 virtio_mmio@10007000 [virtio,mmio] ... Failed\nFinding driver for #924 virtio_mmio@10006000 [virtio,mmio] ... Failed\nFinding driver for #1040 virtio_mmio@10005000 [virtio,mmio] ... Failed\nFinding driver for #1156 virtio_mmio@10004000 [virtio,mmio] ... Failed\nFinding driver for #1272 virtio_mmio@10003000 [virtio,mmio] ... Failed\nFinding driver for #1388 virtio_mmio@10002000 [virtio,mmio] ... Failed\nFinding driver for #1504 virtio_mmio@10001000 [virtio,mmio] ... Failed\nFinding driver for #1620 cpus [] ... Failed\nFinding driver for #1680 cpu-map [] ... Failed\nFinding driver for #1692 cluster0 [] ... Failed\nFinding driver for #1708 core0 [] ... Failed\nFinding driver for #1748 cpu@0 [riscv] ... Failed\nFinding driver for #1900 interrupt-controller [riscv,cpu-intc] ... Failed\nFinding driver for #2012 memory@80000000 [] ... Found! Installing... OK, handler: 2\nFinding driver for #2084 soc [simple-bus] ... Failed\nFinding driver for #2160 pci@30000000 [pci-host-ecam-generic] ... Failed\nFinding driver for #2852 interrupt-controller@c000000 [riscv,plic0] ... Failed\nFinding driver for #3048 clint@2000000 [riscv,clint0] ... Failed\n\nReached k_after_main, clearing up...\n===== Test Kernel exited with 0 =====上一篇我们已经搭建好了驱动框架，现在我们来实现三个基础驱动：根设备、内存、串口。
\n根设备并不是一个具体设备，而是设备树的根节点，包含了模组信息和兼容信息，可以根据它区别平台。为了方便起见，我们让根设备驱动一并处理 /chosen 节点，因为平台相关的一些额外参数可以直接这样传入。
首先定义一个基类 (顺便定义一个属性导出宏)：
\n#define __K_PROP_EXPORT__(name, pri) \\\n const auto &name() const \\\n { \\\n return pri; \\\n }\n\nclass SysRoot : public DriverBase\n{\n public:\n virtual dev_type_t getDeviceType() override\n {\n return DEV_TYPE_SYS;\n }\n\n __K_PROP_EXPORT__(compatible, _compatible)\n __K_PROP_EXPORT__(model, _model)\n __K_PROP_EXPORT__(stdout_path, _stdout_path)\n\n protected:\n std::string _compatible;\n std::string _model;\n std::string _stdout_path;\n};实现上，考虑提供一个通用的 fallback 驱动，在不匹配的时候也不会终止内核：
\nclass GenericRoot : public SysRoot\n{\n public:\n int probe(const char *name, const char *compatible) override\n {\n std::string id = name;\n if (id == \"\")\n return DRV_CAP_THIS;\n return DRV_CAP_NONE;\n }\n\n long addDevice(const void *fdt, int node) override\n {\n int len;\n if (node == 0) // root node\n {\n auto prop = fdt_get_property(fdt, node, \"compatible\", &len);\n if (!prop)\n _compatible = \"Generic\";\n else\n _compatible = std::string(prop->data);\n prop = fdt_get_property(fdt, node, \"model\", &len);\n if (!prop)\n _model = \"Generic\";\n else\n _model = std::string(prop->data);\n\n auto rc = fdt_path_offset(fdt, \"/chosen\"); // property of chosen node may diff on other platform\n if (rc >= 0)\n {\n auto prop = fdt_get_property(fdt, rc, \"stdout-path\", &len);\n if (prop)\n _stdout_path = std::string(prop->data);\n DriverManager::markInstalled(fdt, rc, 0, this,DRV_CAP_THIS); // mark as installed\n\n return 0; // singleton device\n }\n }\n\n return K_ENODEV;\n }\n\n void removeDevice(long handler) override\n {\n }\n};可以看到，这里的 probe() 条件是名称为空，按照定义看，只有根节点没有名称。由于我们要一并接管 /chosen 节点，所以在安装时，利用传入的完整 fdt 查找到节点偏移，提取属性后向 DriverManager 报告额外安装的节点，避免再次安装。
理论上，内存是不需要驱动的，但是为了更好地管理系统上的内存，在当前架构下还是引入一个驱动。
\n内存驱动主要的工作如下：
\n由于是系统驱动，还是定义一个基类：
\nclass SysMem : public DriverBase\n{\n public:\n dev_type_t getDeviceType() override\n {\n return DEV_TYPE_SYS;\n }\n\n virtual void addReservedMem(uint64_t addr,uint64_t size) = 0;\n\n __K_PROP_EXPORT__(reservedMem, _mem_rsv);\n __K_PROP_EXPORT__(availableMem, _mem_avail);\n\n protected:\n std::vector<std::pair<size_t,size_t>> _mem_rsv;\n std::vector<std::pair<size_t,size_t>> _mem_avail;\n};然后提供一个通用实现：
\nclass GenericMem : public SysMem\n{\n public:\n int probe(const char *name, const char *compatible) override\n {\n std::string id = name;\n if (id.find(\"memory\") != 0 && id != \"reserved-memory\")\n return DRV_CAP_NONE;\n return DRV_CAP_COVER;\n }\n\n long addDevice(const void *fdt, int node) override\n {\n\n uint64_t address, size;\n if (!_fdt_rsv_mem_parsed)\n {\n // fdt command reserved memory\n int n = fdt_num_mem_rsv(fdt);\n for (int i = 0; i < n; ++i)\n {\n auto rc = fdt_get_mem_rsv(fdt, i, &address, &size);\n if (rc == 0)\n {\n _mem_rsv.push_back(std::make_pair(address, size));\n printf(\"(0x%lx - 0x%lx) \", address, address + size);\n }\n }\n _fdt_rsv_mem_parsed = true;\n\n // Some mark should be done?\n }\n\n auto name = fdt_get_name(fdt, node, NULL);\n if (name == std::string(\"reserved-memory\"))\n {\n\n /* process reserved-memory node */\n auto nodeoffset = fdt_subnode_offset(fdt, 0, \"reserved-memory\");\n if (nodeoffset >= 0)\n {\n auto subnode = fdt_first_subnode(fdt, nodeoffset);\n while (subnode >= 0)\n {\n\n if (fdt_get_node_addr_size(fdt, subnode, 0, &address, &size) >= 0)\n { // each subnode should have only one addr and size\n _mem_rsv.push_back(std::make_pair(address, size));\n printf(\"(0x%lx - 0x%lx) \", address, address + size);\n }\n else\n {\n printf(\"Failed to get reserved memory in #%d\\n\", subnode);\n }\n subnode = fdt_next_subnode(fdt, subnode);\n }\n }\n }\n else\n { // memory node, could have multiple\n for (int i = 0; fdt_get_node_addr_size(fdt, node, i, &address, &size) >= 0; ++i)\n {\n _mem_avail.push_back(std::make_pair(address, size));\n printf(\"(0x%lx - 0x%lx) \", address, address + size);\n }\n }\n return 0; // Also singleton\n }\n\n void removeDevice(long handler) override\n {\n }\n\n void addReservedMem(uint64_t addr, uint64_t size) override\n {\n _mem_rsv.push_back(std::make_pair(addr, size));\n }\n\n private:\n bool _fdt_rsv_mem_parsed = false;\n};这里要考虑的问题在于，内存驱动在设备树上有多个设备与之对应，当存在平台特定驱动的时候，如果不作任何处理，那就容易导致不同的内存区可 probe() 到的驱动不一致，导致数据分散在多个驱动中。这时候，系统根设备就出场了，它总是能先于其他设备进行 probe()，并且知道兼容信息，我们只需要在系统根设备驱动 probe() 的时候，顺手将不兼容平台的驱动先行删除，保证其后不被 probe() 到。
接下来就是及其硬件的一个简单驱动了，串口驱动。在我们的系统上，参考 Linux 的设计，外设抽象成两种，即块设备和字符设备。这里首先继承 DriverChar：
\nclass Drv_Uart8250 : public DriverChar\n{\n\n private:\n struct uart8250_t\n {\n char *base;\n uint32_t freq;\n uint32_t baud;\n uint32_t reg_width;\n uint32_t reg_shift;\n // uint32_t reg_offset;\n\n bool opened = false;\n };\n\n const uint32_t default_freq = 0;\n const uint32_t default_baud = 115200;\n const uint32_t default_reg_shift = 0;\n const uint32_t default_reg_width = 1;\n const uint32_t default_reg_offset = 0;\n\n int hdl_count = -1;\n std::map<long, uart8250_t> hdl;\n};这里定义一个结构体存储数据。当然，也可以使用外部类的方法，更符合 C++ 的思想。
\n然后参照 openSBI 的实现，将几个 fdt_helper 函数以及 riscv_io 部分内容 cv 过来，然后定义两个辅助函数：
\n static u32 get_reg(const uart8250_t &u, u32 num)\n {\n u32 offset = num << u.reg_shift;\n\n if (u.reg_width == 1)\n return readb(u.base + offset);\n else if (u.reg_width == 2)\n return readw(u.base + offset);\n else\n return readl(u.base + offset);\n }\n\n static void set_reg(const uart8250_t &u, u32 num, u32 val)\n {\n u32 offset = num << u.reg_shift;\n\n if (u.reg_width == 1)\n writeb(val, u.base + offset);\n else if (u.reg_width == 2)\n writew(val, u.base + offset);\n else\n writel(val, u.base + offset);\n }这两个函数非常简单，就是进行寄存器的读写。后面的所以步骤都利用这两个函数进行 IO。
\n接着实现设备实例化功能：
\nlong addDevice(const void *fdt, int node) override\n {\n uart8250_t uart;\n uint64_t regsize;\n int len, rc;\n const fdt32_t *val;\n rc = fdt_get_node_addr_size(fdt, node, 0, (uint64_t *)&uart.base, ®size);\n\n if (rc < 0 || !uart.base || !regsize)\n return K_ENODEV;\n\n val = (fdt32_t *)fdt_getprop(fdt, node, \"clock-frequency\", &len);\n if (len > 0 && val)\n uart.freq = fdt32_to_cpu(*val);\n else\n uart.freq = default_freq;\n\n val = (fdt32_t *)fdt_getprop(fdt, node, \"current-speed\", &len);\n if (len > 0 && val)\n uart.baud = fdt32_to_cpu(*val);\n else\n uart.baud = default_baud;\n\n val = (fdt32_t *)fdt_getprop(fdt, node, \"reg-shift\", &len);\n if (len > 0 && val)\n uart.reg_shift = fdt32_to_cpu(*val);\n else\n uart.reg_shift = default_reg_shift;\n\n val = (fdt32_t *)fdt_getprop(fdt, node, \"reg-io-width\", &len);\n if (len > 0 && val)\n uart.reg_width = fdt32_to_cpu(*val);\n else\n uart.reg_width = default_reg_width;\n\n val = (fdt32_t *)fdt_getprop(fdt, node, \"reg-offset\", &len);\n if (len > 0 && val)\n uart.base += fdt32_to_cpu(*val);\n else\n uart.base += default_reg_offset;\n\n u16 bdiv = 0;\n\n if (uart.baud)\n bdiv = (uart.freq + 8 * uart.baud) / (16 * uart.baud);\n\n /* Disable all interrupts */\n set_reg(uart, UART_IER_OFFSET, 0x00);\n /* Enable DLAB */\n set_reg(uart, UART_LCR_OFFSET, 0x80);\n\n if (bdiv)\n {\n /* Set divisor low byte */\n set_reg(uart, UART_DLL_OFFSET, bdiv & 0xff);\n /* Set divisor high byte */\n set_reg(uart, UART_DLM_OFFSET, (bdiv >> 8) & 0xff);\n }\n\n /* 8 bits, no parity, one stop bit */\n set_reg(uart, UART_LCR_OFFSET, 0x03);\n /* Enable FIFO */\n set_reg(uart, UART_FCR_OFFSET, 0x01);\n /* No modem control DTR RTS */\n set_reg(uart, UART_MCR_OFFSET, 0x00);\n /* Clear line status */\n get_reg(uart, UART_LSR_OFFSET);\n /* Read receive buffer */\n get_reg(uart, UART_RBR_OFFSET);\n /* Set scratchpad */\n set_reg(uart, UART_SCR_OFFSET, 0x00);\n\n hdl.insert(std::pair<long, uart8250_t>(++hdl_count, uart));\n\n // Test send here\n write(hdl_count, \"TEST UART8250\\n\", 14);\n\n return hdl_count;\n }关于各个寄存器操作的解释，可以参阅 UART 16650D Datasheet。
\n实例化解决，把剩下的虚函数补完：
\n int probe(const char *name, const char *compatible) override\n {\n std::string id = name;\n if (id.find(\"uart\") == std::string::npos)\n return DRV_CAP_NONE;\n id = compatible;\n return (id == \"ns16550\" || id == \"ns16550a\" || id == \"snps,dw-apb-uart\") ? DRV_CAP_THIS : DRV_CAP_NONE;\n }\n\n int open(long handler) override\n {\n\n auto u = hdl.find(handler);\n if (u == hdl.end())\n return K_ENODEV;\n\n auto &uart = u->second;\n if (uart.opened)\n return K_EALREADY;\n\n // lock here?\n uart.opened = true;\n\n printf(\"UART8250 opened\\n\");\n return 0;\n }\n\n int close(long handler) override\n {\n auto u = hdl.find(handler);\n if (u == hdl.end())\n return K_ENODEV;\n\n auto &uart = u->second;\n if (!uart.opened)\n return K_EALREADY;\n\n // lock here?\n uart.opened = false;\n\n printf(\"UART8250 closed\\n\");\n return 0;\n }\n\n int read(long handler, void *buf, int len) override\n {\n auto u = hdl.find(handler);\n if (u == hdl.end())\n return K_ENODEV;\n\n auto &uart = u->second;\n\n for (int i = 0; i < len; ++i)\n {\n if (get_reg(uart, UART_LSR_OFFSET) & UART_LSR_DR)\n ((char *)buf)[i] = get_reg(uart, UART_RBR_OFFSET);\n else\n return i;\n }\n\n // printf(\"UART8250 read\\n\");\n return len;\n }\n\n int write(long handler, const void *buf, int len) override\n {\n auto u = hdl.find(handler);\n if (u == hdl.end())\n return K_ENODEV;\n\n auto &uart = u->second;\n\n for (int i = 0; i < len; ++i)\n {\n while ((get_reg(uart, UART_LSR_OFFSET) & UART_LSR_THRE) == 0)\n ;\n\n set_reg(uart, UART_THR_OFFSET, ((const char *)buf)[i]);\n }\n\n // printf(\"UART8250 write\\n\");\n return 0;\n }\n\n int ioctl(long handler, int cmd, void *arg) override\n {\n printf(\"UART8250 ioctl -- not supported\\n\");\n return 0;\n }当然这里的 open() 和 close() 也是雏形，没有实质的意义。
\n编译运行，设备安装的时候就能打印出 "TEST UART8250" 了！
\n这个驱动移植花了两个多小时，真是不容易。实现了各个资源的管理，下一步就可以考虑 MMU 相关的操作了。
\n内存，即 Memory，是存储计算机运行过程数据的主要部件。不过在操作系统中，内存并不单单是主存，还有各种外设内存等。本文所说的内存布局，主要是指在可寻址空间中的布局，这关系到系统和后面应用程序的运行，是及其重要的。在有内存管理单元 (MMU) 的处理器上，寻址空间可以分为两种类型，即 物理地址空间 (Physical Memory Area, PMA) 和 虚拟地址空间 (Virtual Memory Area, VMA)。通过 MMU 的控制与转换，可以实现有效的隔离和保护，防止非法的内存访问。
\n本文仅浅读标准手册，未尽之处，敬请参阅标准手册。
\n根据 The RISC-V Instruction Set Manual Volume II: Privileged Architecture，目前 RV32 可用的物理地址空间为 32 位（或更多），而 RV64 可用的物理地址空间是 64 位。
\n而虚拟地址空间上，RV32 只有一种模式，即 SV32，对应了 32 位的虚拟地址空间，并且由于 MMU 配置上用的是 22位 的物理页号 (每页 4K, 即 12 位)，能够支持到 34 位的物理地址空间。
\n但是，RV64 因为地址空间足够大，普通应用可能不需要完全的虚拟地址空间支持，截止 V20211203，一共定义了三种模式，即 SV39, SV48, SV57，分别对应 39 位、48 位、57 位虚拟地址空间。
\n在标准文档中，MMU 被设计成一个带有 TLB 的硬件模块，实现可配置的从虚拟地址空间到物理地址空间的映射。由于原理相同，所以标准文档只对 SV32 作了详细描述，这里我们也同样先分析 SV32，然后推广到 SV39 等。
\n略语一览：
\n设计上，RV 的 MMU 由一个 CSR (控制与状态寄存器) 控制，名为 SATP (Supervisor Address Translation and Protection)，并带有专用指令用于刷新 TLB。寄存器字段如图所示：
\n![\"RV32](\"https://imgcdn0.octz.net/blog/2024/rv32satp.png\")
![\"RV64](\"https://imgcdn0.octz.net/blog/2024/rv64satp.png\")
据标准描述，ASID 即 Address Space Identifier，用于标识不同的地址空间而无需频繁地进行刷新 TLB 操作。PPN 字段填入根页表的物理页号，而 Mode 字段用于标识 MMU 的工作模式，如表所示：
\nRV32:
\n| 值 | 名称 | 描述 |
\n| :
由于大部分的 RV64 SoC 都将 DRAM 放置在 0x80000000 以上，其下的空间保留给 IO，如 QEMU 的 virt，其布局如下：
\nstatic const MemMapEntry virt_memmap[] = {\n [VIRT_DEBUG] = { 0x0, 0x100 },\n [VIRT_MROM] = { 0x1000, 0xf000 },\n [VIRT_TEST] = { 0x100000, 0x1000 },\n [VIRT_RTC] = { 0x101000, 0x1000 },\n [VIRT_CLINT] = { 0x2000000, 0x10000 },\n [VIRT_ACLINT_SSWI] = { 0x2F00000, 0x4000 },\n [VIRT_PCIE_PIO] = { 0x3000000, 0x10000 },\n [VIRT_PLATFORM_BUS] = { 0x4000000, 0x2000000 },\n [VIRT_PLIC] = { 0xc000000, VIRT_PLIC_SIZE(VIRT_CPUS_MAX * 2) },\n [VIRT_APLIC_M] = { 0xc000000, APLIC_SIZE(VIRT_CPUS_MAX) },\n [VIRT_APLIC_S] = { 0xd000000, APLIC_SIZE(VIRT_CPUS_MAX) },\n [VIRT_UART0] = { 0x10000000, 0x100 },\n [VIRT_VIRTIO] = { 0x10001000, 0x1000 },\n [VIRT_FW_CFG] = { 0x10100000, 0x18 },\n [VIRT_FLASH] = { 0x20000000, 0x4000000 },\n [VIRT_IMSIC_M] = { 0x24000000, VIRT_IMSIC_MAX_SIZE },\n [VIRT_IMSIC_S] = { 0x28000000, VIRT_IMSIC_MAX_SIZE },\n [VIRT_PCIE_ECAM] = { 0x30000000, 0x10000000 },\n [VIRT_PCIE_MMIO] = { 0x40000000, 0x40000000 },\n [VIRT_DRAM] = { 0x80000000, 0x0 }, \n};由此，我们可以简单地将低 2G 空间直接映射，然后将 (可能不连续的) DRAM 从 0x80000000 开始进行映射，最后把 DRAM 的一小部分重映射到 VMA 的高地址空间。如下表所示：
\n| VMA Start | VMA End | PMA Start | Usage |
\n| :
一个 CPU 上可能不止一个核心 (Hart)，这些核心在物理上分开，独立运行，但是共享总线和外设。也就是说，它们的物理内存空间是一致的，只不过有自己单独的寄存器和 Cache、MMU。而多线程非常类似，只不过是通过调度的方式实现，将多个线程的寄存器等资源分时复用。在裸机的角度上看，我们可以把多核看成硬件的多线程，并利用类似的技术实现。
\n在 RISCV 手册中，并没有规定 Hart 的启动顺序。比较通常的做法是，核心全部（近乎）同时从 M-mode 启动，随后 SBI 会通过原子量确定一个启动核心，并且执行初始化。至于 S-mode 中是否同时启动，我并没有明确看到文档指出，所以应该也是 SBI 实现自定义。通过实验，OpenSBI 只会将启动核心带入到 S-mode，其他核心会留在 M-mode 等待。但是，我们仍然有必要通过一个原子量保证 S-mode 初期只有一个核心运行，具体看，就是下面的汇编代码：
\n_start:\n\t/* Pick one hart to run the main boot sequence */\n\tlla\ta3, _hart_lottery\n\tli\ta2, 1\n\tamoadd.w a3, a2, (a3)\n\tbnez\ta3, _start_hang // in case multi core start at the same time这些代码在入口点立即执行，如果有多个核心，没有抢到控制权的就会跳到 _start_hang 的死循环里。当然，为了兼容性，后面肯定会设置一下中断再睡觉，不然在其他 SBI 上可能没法用。
\n那么我们如何通过 SBI 启动核心呢？答案是 SBI 的 HSM 扩展，即 Hart State Management。该扩展提供 4 个 ecall 调用，分别对应核心的 启动、（自）停止、状态查询和暂停。如下：
\nstruct sbiret sbi_hart_start(unsigned long hartid,\n unsigned long start_addr,\n unsigned long opaque);\n\nstruct sbiret sbi_hart_stop(void);\n\nstruct sbiret sbi_hart_get_status(unsigned long hartid);\n\nstruct sbiret sbi_hart_suspend(uint32_t suspend_type,\n unsigned long resume_addr,\n unsigned long opaque);文档说明，可以通过 sbi_hart_start 从指定的 start_addr 启动核心，并且其 a0 = hartid，a1 = opaque。
基于之前的布局，确定启动其他核心的时机是设备外设驱动安装完成后。此时内存映射和系统栈已经确定，可以确定下一步的所有数据。启动后，执行环境非常原始，需要一点汇编来做初始化工作。
\n启动流程
\n核心启动后，其 SATP = 0 和 sstatus.SIE = 0，即 MMU 和中断是关闭的。我们的系统栈是布置在虚拟地址空间的，所以要先启用 MMU。在之前的启动步骤，我们保存了系统 MMU 配置寄存器 (SATP) 的值，我们将在所有核心上使用同样的映射。所以内存映射非常简单，只需将保存的值写入 satp 后，刷新 TLB 即可：
\n_start_hart:\n /* a0: hartid a1: reserved */\n\tlla a2, _sys_satp\n\tREG_L a2, 0(a2)\n\tcsrw CSR_SATP, a2\n\tsfence.vma zero, zero在前面的步骤，我们确定了系统栈的空间，这里要根据 hart id，通过简单的乘法得到核心系统栈基址。如下：
\n\t/* Setup system stack base according to hart_id as offset */\n\tlla a3, _sys_stack_base\n\tREG_L sp, 0(a3)\n\tli a2, K_CONFIG_STACK_SIZE\n\tmul a3, a0, a2\n\tsub sp, sp, a3理论上，这里开始就可以进入 C++ 了，但是不要忘记一件事，就是 libc 的上下文还没解决。
\n在 newlib 中，几乎所有函数都提供了两个版本，即不可重入的普通版本（ANSI），以及可重入的版本。不可重入的版本，其最终还是调用了可重入版本的函数，不过传入了一个全局重入结构。例如，printf:
\n不可重入版：
\nint\tprintf (const char *__restrict, ...)\n _ATTRIBUTE ((__format__ (__printf__, 1, 2)));可重入版：
\nint\t_printf_r (struct _reent *, const char *__restrict, ...)\n _ATTRIBUTE ((__format__ (__printf__, 2, 3)));可以注意到，可重入版本多了一个 _reent 结构体，其在 <sys/reent.h> 定义，一并定义了全局的：
/*\n * All references to struct _reent are via this pointer.\n * Internally, newlib routines that need to reference it should use _REENT.\n */\n\n#ifndef __ATTRIBUTE_IMPURE_PTR__\n#define __ATTRIBUTE_IMPURE_PTR__\n#endif\n\nextern struct _reent *_impure_ptr __ATTRIBUTE_IMPURE_PTR__;\n\n#ifndef __ATTRIBUTE_IMPURE_DATA__\n#define __ATTRIBUTE_IMPURE_DATA__\n#endif\n\nextern struct _reent _impure_data __ATTRIBUTE_IMPURE_DATA__;\n\n/* #define _REENT_ONLY define this to get only reentrant routines */\n\n#if defined(__DYNAMIC_REENT__) && !defined(__SINGLE_THREAD__)\n#ifndef __getreent\n struct _reent * __getreent (void);\n#endif\n# define _REENT (__getreent())\n#else /* __SINGLE_THREAD__ || !__DYNAMIC_REENT__ */\n# define _REENT _impure_ptr\n#endif /* __SINGLE_THREAD__ || !__DYNAMIC_REENT__ */\n\n#define _REENT_IS_NULL(_ptr) ((_ptr) == NULL)\n\n#define _GLOBAL_REENT (&_impure_data)在 newlib 内部，不可重入函数通过 _REENT 宏获取全局重入对象指针后传入可重入版本，完成后续操作。
从上面的定义可以看出，我们如果以 __DYNAMIC_REENT__ 定义的情况编译 newlib，那么就可以通过 __getreent() 函数，提供核心本地的 _reent 结构。稍微修改编译脚本，重新编译工具链（参见此处），然后添加一个实现：
struct _reent *__getreent(void)\n {\n if (k_stage == K_MULTICORE)\n return &hl_reent;\n return _GLOBAL_REENT;\n }这里 hl_reent 是线程本地 (Hart Local) 的 _reent。
读到这里，很容易想到一个问题，那就是我的 hl_reent 如何存储呢？
\n核心本地存储，就是每个核心所单独享有的存储空间。在不同核心上运行的系统程序，应该具有同样的需求，（代码都一样啊），即我们需要通过一些手段来区分核心并从不同的地方提供存储。
\n一个简单而容易想到的方法是，不使用统一的 MMU 映射，而是通过差别映射，将核心系统栈固定在一个地址，然后在核心栈以上预留一段空间，作为核心本地存储。具体实现，可以参考此提交时的仓库。
\n获取地址的函数示例：
\nvoid *k_getHartLocal()\n{\n extern uintptr_t _sys_stack_base;\n extern char _KERNEL_HART_LOCAL_DATA_SIZE;\n return (void *)(_sys_stack_base - (uintptr_t)&_KERNEL_HART_LOCAL_DATA_SIZE);\n}前面说过，多核可以看成硬件实现的多线程，那就可以利用一下多线程的技术。这里的 TLS 不是 计网的 TLS，而是 Thread Local Storage。其具体定义可以参考 ELF Handling For Thread-Local Storage。
\n简单来说，通过 C++ 的 thread_local 关键字，或者 C 中的 _Thread_local 定义的变量，会被编译器放入特别的段：.tbss 和 .tdata。这些段并不是直接拿来用的，而是作为一个副本，由实现自行加载内存区域并初始化。那么，如何寻址呢？在 RISCV 上，静态链接的情况下，是通过 tp 寄存器。该寄存器持有一个基址，即 TLS 本地存储的最低地址。我们要做的，首先是创建这两个段，拿到其原始数据的地址：
.tdata :\n\t{\n\n\t\tPROVIDE(_tdata_start = .);\n\n\t\t*(.tdata)\n\t\t*(.tdata.*)\n\t\t. = ALIGN(8);\n\t\tPROVIDE(_tdata_end = .);\n\t} \n\n\t/* In TLS, do not add align 4K, otherwise addressing to tbss will need to add a 4k from $tp which cost much space */\n\n\t.tbss : {\n\t\tPROVIDE(_tbss_start = .);\n\t\t*(.tbss)\n\t\t*(.tbss.*)\n\t\t. = ALIGN(8);\n\t\tPROVIDE(_tbss_end = .);\n\t\t\n\t}要注意的是，由于依赖 tp 寻址，所以两个段中间的空闲区域也会算进去，应该不加对齐，否则会浪费内存，搞不好就非法访问了。（我才不会告诉你我调了一上午才发现 qwq）。
然后，在核心初始化时基于核心栈底，保留一段空间作为 TLS ，设置好 tp 寄存器通过汇编实现：
\t/* Reserve Exception stack */\n\tli a3, K_CONFIG_EXCEPTION_BACKUP_SIZE\n\tcsrw CSR_SSCRATCH, sp\n\tsub sp, sp, a3\n\n_process_tbss:\n\t/* Setup tbss */\n\tlla a4, _tbss_start\n\tlla a5, _tbss_end\n\tbeq a4, a5, _process_tdata\n\n\tsub a2, a5, a4\n\tsub sp, sp, a2\n\tmv tp, sp\n\tmv\ta3, tp\n\n\t/* Zero-out tbss */\n_tbss_zero:\n\tREG_S\tzero, (a3)\n\tadd a3, a3, __SIZEOF_POINTER__\n\tadd\ta4, a4, __SIZEOF_POINTER__\n\tblt\ta4, a5, _tbss_zero\n\n_process_tdata:\n\t/* Setup tdata */\n\tlla a3, _tdata_start\n\tlla a2, _tdata_end\n\tbeq a3, a2, _fini_setup_hart\n\n\tsub a2, a2, a3\n\tsub sp, sp, a2\n\tmv tp, sp\n\n\t/* Copy tdata */\n\tlla a4, _tdata_end\n\tmv a5, tp\n_tdata_copy:\n\tREG_L a2, (a3)\n\tREG_S a2, (a5)\n\tadd a3, a3, __SIZEOF_POINTER__\n\tadd a5, a5, __SIZEOF_POINTER__\n\tblt a3, a4, _tdata_copy\n_fini_setup_hart:\n\tret这里顺便预留一下异常处理空间。处理完成后，整个布局如下：
\n![\"核心存储布局\"](\"https://imgcdn0.octz.net/blog/2024/mcores_stackmap.png\")
NewLib 本身可以使用 TLS 来替代 _reent，但是我目前没有采用这种方案，原因是，
由于核心启动需要时间，而我们不希望在所有核心都启动之前就开跑，就需要使用一个变量构造锁。
\n enum k_stage_t\n {\n K_BEFORE_BOOT = 0,\n K_BOOT = 1,\n K_BOOT_PERIP = 2,\n K_BOOT_HARTS = 3,\n K_MULTICORE = 4,\n K_CLEARUP = 5\n };\n\n extern k_stage_t k_stage;然后在核心启动到 k_premain() 中增加：
while (k_stage != K_MULTICORE)\n ; // wait for the boot core to finish这将导致所有后启动的核心等待启动核心完成。
\n退出多核模式之前，需要保证后启动核心正常停止，然后由启动核心清理现场。通过 k_after_main() 函数实现：
int k_after_main(int hartid, int main_ret)\n{\n if (hartid < 0) // Non boot hart\n {\n\n printf(\"Hart %i has returned with %d\\n\", ::hartid, main_ret);\n k_hart_state[::hartid] = 3;\n // printf(\"Failed to stop hart: %ld\\n\", SBIF::HSM::stopHart());\n }\n else\n {\n printf(\"\\n> Waiting for other harts to return...\\n\");\n int flag = 0;\n do // a timeout can be added here\n {\n flag = 0;\n for (int i = 0; i < 8; ++i)\n {\n if (i == hartid)\n continue;\n if (k_hart_state[i] == 1 || k_hart_state[i] == 2)\n {\n flag = 1;\n break;\n }\n if (k_hart_state[i] == 3 || k_hart_state[i] == 0)\n continue;\n }\n } while (flag);\n k_stdout_switched = false;\n k_stage = K_CLEARUP;\n }\n return main_ret; // pass to the lower\n}虽然我们使用 TLS 提供了核心专用的 _reent，但是 IO 方面仍然不支持多核，需要加锁。这里要利用 newlib 的 retargetable locking，提供自己的实现。首先看 <sys/lock.h> 定义：
#if !defined(_RETARGETABLE_LOCKING)\n\ntypedef int _LOCK_T;\ntypedef int _LOCK_RECURSIVE_T;\n\n#define __LOCK_INIT(class,lock) static int lock = 0;\n#define __LOCK_INIT_RECURSIVE(class,lock) static int lock = 0;\n#define __lock_init(lock) ((void) 0)\n#define __lock_init_recursive(lock) ((void) 0)\n#define __lock_close(lock) ((void) 0)\n#define __lock_close_recursive(lock) ((void) 0)\n#define __lock_acquire(lock) ((void) 0)\n#define __lock_acquire_recursive(lock) ((void) 0)\n#define __lock_try_acquire(lock) ((void) 0)\n#define __lock_try_acquire_recursive(lock) ((void) 0)\n#define __lock_release(lock) ((void) 0)\n#define __lock_release_recursive(lock) ((void) 0)\n\n#else\n\n#ifdef __cplusplus\nextern \"C\" {\n#endif\n\nstruct __lock;\ntypedef struct __lock * _LOCK_T;\n#define _LOCK_RECURSIVE_T _LOCK_T\n\n#define __LOCK_INIT(class,lock) extern struct __lock __lock_ ## lock; \\\n\tclass _LOCK_T lock = &__lock_ ## lock\n#define __LOCK_INIT_RECURSIVE(class,lock) __LOCK_INIT(class,lock)\n\nextern void __retarget_lock_init(_LOCK_T *lock);\n#define __lock_init(lock) __retarget_lock_init(&lock)\nextern void __retarget_lock_init_recursive(_LOCK_T *lock);\n#define __lock_init_recursive(lock) __retarget_lock_init_recursive(&lock)\nextern void __retarget_lock_close(_LOCK_T lock);\n#define __lock_close(lock) __retarget_lock_close(lock)\nextern void __retarget_lock_close_recursive(_LOCK_T lock);\n#define __lock_close_recursive(lock) __retarget_lock_close_recursive(lock)\nextern void __retarget_lock_acquire(_LOCK_T lock);\n#define __lock_acquire(lock) __retarget_lock_acquire(lock)\nextern void __retarget_lock_acquire_recursive(_LOCK_T lock);\n#define __lock_acquire_recursive(lock) __retarget_lock_acquire_recursive(lock)\nextern int __retarget_lock_try_acquire(_LOCK_T lock);\n#define __lock_try_acquire(lock) __retarget_lock_try_acquire(lock)\nextern int __retarget_lock_try_acquire_recursive(_LOCK_T lock);\n#define __lock_try_acquire_recursive(lock) \\\n __retarget_lock_try_acquire_recursive(lock)\nextern void __retarget_lock_release(_LOCK_T lock);\n#define __lock_release(lock) __retarget_lock_release(lock)\nextern void __retarget_lock_release_recursive(_LOCK_T lock);\n#define __lock_release_recursive(lock) __retarget_lock_release_recursive(lock)\n\n#ifdef __cplusplus\n}\n#endif\n\n#endif /* !defined(_RETARGETABLE_LOCKING) */好了，你已经猜到要干嘛了，重新编译工具链，打开这个选项。
\n之后，利用 std:atomic 造一个锁结构：
\n struct __lock\n {\n std::atomic<int> owner = -1;\n std::atomic<int> recursive_count = 0;\n\n void lock(bool recursive = false)\n {\n\n if (k_stage != K_MULTICORE)\n return;\n // _write(0, (char*)\"PLOCK\\n\",6);\n if (recursive)\n {\n if (owner == hartid)\n {\n recursive_count++;\n return;\n }\n }\n int null_owner = -1; // helper for compare_exchange_weak\n while (!owner.compare_exchange_weak(null_owner, hartid))\n null_owner = -1;\n\n recursive_count = 1;\n // _write(0, (char *)\"LOCK\\n\", 5);\n }\n\n void unlock(bool recursive = false)\n {\n if (k_stage != K_MULTICORE)\n return;\n if (recursive)\n {\n if (owner == hartid)\n {\n if (--recursive_count == 0)\n owner = -1;\n }\n return;\n }\n\n if (owner == hartid)\n owner = -1;\n }\n };由于声明中没有使用 __weak，所以我们要将整个编译单元的所有函数和变量全部覆盖，以通过编译，详情可以参见libc_hooks.cpp。
\n通过这样的操作，多核环境就搭建好了，输出也没有冲突。当然，博客所示的代码还是比较少，详细实现还请参看仓库代码。
\n这一波用了 3 天，属实给我调试到麻了，各种冲突、异常，整个都是比较抽象的。不过，结果是好的，下一步，就可以折腾 CPU 的中断了。亲爱的读者，我们下期再会！
\n", "image": "https://imgcdn0.octz.net/blog/2024/mcores_stackmap.png", "date_published": "2024-03-22T00:00:00.000Z", "date_modified": "2025-11-25T18:22:56.000Z", "authors": [ { "name": "DynamicLoader", "url": "https://octz.net/" } ], "tags": [ "ABYDOS" ] }, { "title": "AbydOS开发日记 (7) - 内部中断", "url": "https://octz.net/blog/AbydOS/7-internal-int.html", "id": "https://octz.net/blog/AbydOS/7-internal-int.html", "summary": "RV64 的中断 搞了这么多基础设施，终于到中断的实现了。首先看下 RV 的中断和异常， 这里的 Interrupt 是 scause 这个 CSR 之中的最高位。 注：中断也叫异步异常，异常通常指同步异常，两者合并可以叫陷阱(Trap)。 控制 涉及到中断控制，一共有几个 CSR 需要考虑，如下: 中断控制寄存器中断控制寄存器 首先是 sstatus...", "content_html": "搞了这么多基础设施，终于到中断的实现了。首先看下 RV 的中断和异常，
\n| Interrupt | Exception Code | Description |
\n| :
\n\n好久不见！自从上一篇博客，上板成功，到现在已经过去了 3 个月。这几个月，主要是忙活一些学业上的东西，4月跟着老师探索了一点 IC design with LLM 的内容，5月忙活各种大作业、小组作业，6月忙活备考。终于考完试了，开完香槟就开始填坑啦！
\n
由于 Unix 的 “文件即一切” 思想实在很好，所以我们采用这样的思路。
\n虚拟文件系统，即 Virtual FileSystem, VFS, 是整个文件系统的抽象，向上层提供统一的访问接口。考虑简单的设计，VFS 只需实现真实文件系统的挂载、卸载，以及各种操作的代理即可。
我们定义一个基类，作为基础文件系统，所有真实的文件系统都需要遵守之：
\nclass BasicFS\n{\n public:\n virtual int open(const char *path, int flags, int mode) = 0;\n virtual int close(int fd) = 0;\n virtual int read(int fd, void *buf, size_t count) = 0;\n virtual int write(int fd, const void *buf, size_t count) = 0;\n virtual int lseek(int fd, off_t offset, int whence) = 0;\n virtual int fstat(int fd, struct stat *buf) = 0;\n // virtual int stat(const char *path, struct stat *buf) = 0;\n\n // virtual int opendir(const char *path) = 0;\n // virtual int readdir(int fd, struct dirent *dirp) = 0;\n // virtual int closedir(int fd) = 0;\n\n // virtual int mkdir(const char *path, mode_t mode) = 0;\n // virtual int rmdir(const char *path) = 0;\n\n virtual ~BasicFS() = default;\n};针对 VFS 的初步功能，我们需要维护三张表，如下：
\n这里的设计类似于 DriverManager，但是不同的是，一个文件系统驱动可以拥有多个对象（在不同的挂载点上），而一个对象可以持有多个fd，是一个 1Ⓜ️n 的关系，而 DriverManager 是一个 1:m 的关系，即一个驱动对应多个设备。故而，引入工厂模式，通过专用函数进行构造和销毁，减轻 FS 内部管理的负担。同样的，我们本来可以委派一个 fd 给真实的 FS，但是这样并没有多大用处，只是转换的层级下放到了真实的 FS 中。
\n我们定义这样的类：
\nconstexpr int FILE_STDIN = 0;\nconstexpr int FILE_STDOUT = 1;\nconstexpr int FILE_STDERR = 2;\n\nclass VirtualFS\n{\n public:\n using newInstanceFunc_t = std::function<std::pair<int, BasicFS *>(const char *devicePath)>;\n using deleteInstanceFunc_t = std::function<int(BasicFS *)>;\n\n VirtualFS();\n ~VirtualFS();\n\n static int registerFS(const std::string &fs_name, newInstanceFunc_t nf, deleteInstanceFunc_t df);\n static int unregisterFS(const std::string &fs_name);\n\n static int open(const char *path, int flags, int mode);\n static int close(int fd);\n static int read(int fd, void *buf, int count);\n static int write(int fd, const void *buf, int count);\n static int lseek(int fd, off_t offset, int whence);\n static int fstat(int fd, struct stat *buf);\n\n static int mount(const char *path, const char *devicePath, int flags, int mode, const char *fs_name = nullptr);\n static int umount(const char *path);\n\n private:\n static std::map<std::string, std::pair<BasicFS *, deleteInstanceFunc_t>> _fs_map;\n static std::vector<std::tuple<std::string, newInstanceFunc_t, deleteInstanceFunc_t>>\n _fs_factories; // fs-name, new-instance-func, delete-instance-func\n static lock_t _fs_lock;\n static std::map<int, std::pair<BasicFS *, int>> _global_fd_map;\n static int _global_fd_counter;\n\n};Note
\n遵守 POSIX 的规范，我们预留头三个文件号给 STDIO。
\n所有操作都需要加锁，未来可以考虑细化锁的粒度。
类似于设备驱动的，利用 global constructor 进行注册，要求我们的列表先于文件系统驱动初始化，详细请参阅设备驱动框架的描述。
\n在 registerFS() 中，我们只需做参数校验并加入 _fs_factories；而反注册，只需找出来名称对应的项删除即可。
\n需要注意的是，反注册一个 FS 并不会将其对应的对象销毁，而只能避免安装新的对象，虽然不符合一些原则，但是我们的系统目前没有动态加载和卸载内核模块的办法，先做到这里也无可厚非。
对于挂载，我们遍历所有的安装函数，传入一个挂载设备字符串，驱动程序根据字符串寻找设备对象并进行操作。随后，如果挂载成功，返回一个 0 错误码；若不是支持的文件系统，则返回不支持；若挂载过程出现了错误，则返回错误码。当不支持时，遍历继续，否则终止。
\n static int mount(const char *path, const char *devicePath, int flags, int mode, const char *fs_name = nullptr)\n {\n _fs_lock.lock();\n for (auto &fs : _fs_factories)\n {\n if ((fs_name && std::get<0>(fs) == fs_name) || !fs_name)\n {\n auto [ret, fs_instance] = std::get<1>(fs)(devicePath);\n if (ret == K_OK)\n {\n _fs_map.insert(std::make_pair(path, std::make_pair(fs_instance, std::get<2>(fs))));\n _fs_lock.unlock();\n return 0;\n }\n if (ret != K_ENOTSUPP) // Something other than not supported happened\n {\n _fs_lock.unlock();\n return ret;\n }\n }\n }\n _fs_lock.unlock();\n return K_ENOTSUPP; // No FS could be mounted\n }对于卸载，简单的就是找到挂载点对应的对象，进行解除安装。已打开的文件暂时不受影响，以后完善。
\n static int umount(const char *path) // After unmounting, the FS instance is deleted\n {\n _fs_lock.lock();\n auto it = _fs_map.find(path);\n if (it != _fs_map.end())\n {\n it->second.second(it->second.first);\n _fs_map.erase(it);\n _fs_lock.unlock();\n return 0;\n }\n _fs_lock.unlock();\n return K_ENOTSUPP;\n }主要涉及 open() close() read() write() lseek() 等。
只要维护全局文件描述符表并对应调用真实文件系统服务程序即可。此处以 open() 为例：
static int open(const char *path, int flags, int mode)\n {\n // printf(\"Open %s\", path);\n _fs_lock.lock();\n BasicFS *fs = nullptr;\n size_t max_len = 0;\n for (auto x : _fs_map)\n {\n if (std::string_view(path).find(x.first) == 0)\n {\n if (max_len < x.first.size())\n {\n max_len = x.first.size();\n fs = x.second.first;\n }\n }\n }\n if (fs)\n {\n int ret = fs->open(path+max_len, flags, mode);\n if (ret >= 0)\n {\n auto fd = _global_fd_counter++;\n _global_fd_map.insert(std::make_pair(fd, std::make_pair(fs, ret)));\n _fs_lock.unlock();\n return fd;\n }\n\n _fs_lock.unlock();\n return ret;\n }\n // printf(\"Failed!\\n\");\n _fs_lock.unlock();\n return K_ENOENT;\n }各文件的锁以及权限等在真实文件系统驱动中维护，因其多样性。
\nCPIO 是 Linux 上用于同步文件的一种格式，完整地记录了文件在文件系统中的各个状态。其归档被用于 initrd，读取的代码总共也没有 500 行，也是只读的。要实现它，我们先引入 libcpio，然后适配我们的文件系统框架即可。
\n#include <cstdint>\n#include <cstring>\n#include <stdexcept>\n\n#include \"libcpio/libcpio.h\"\n#include \"k_vfs.h\"\n#include \"k_defs.h\"\n\nclass CPIOFS : public BasicFS\n{\n public:\n CPIOFS(void *archive, unsigned long len) : _archive_len(len)\n {\n printf(\"%p, %lu\\n\", archive, len);\n if (cpio_info(archive, len, &_info))\n {\n throw std::runtime_error(\"cpio_info failed\");\n }\n else\n {\n printf(\"[CPIOFS] cpio_info: %d files, %d max_path_size\\n\", _info.file_count, _info.max_path_sz);\n }\n\n _archive = new uint8_t[len];\n memcpy(_archive, archive, len);\n }\n ~CPIOFS()\n {\n if (_archive)\n delete[] _archive;\n _archive = nullptr;\n }\n\n int open(const char *path, int flags, int mode) override\n {\n unsigned long size = 0;\n const void *file = cpio_get_file(_archive, _archive_len, path, &size);\n if (!file)\n {\n return K_ENOENT;\n }\n for (int i = 0; i < MAX_FILES; i++)\n {\n if (!_fcb[i].used)\n {\n _fcb[i].used = true;\n _fcb[i].file = (void *)file;\n _fcb[i].size = size;\n _fcb[i].lpos = 0;\n return i;\n }\n }\n return K_ENOMEM;\n }\n int close(int fd) override\n {\n if (fd >= MAX_FILES || fd < 0)\n return K_ENOENT;\n if (!_fcb[fd].used)\n return K_ENOENT;\n _fcb[fd].used = false;\n _fcb[fd].file = nullptr;\n _fcb[fd].size = 0;\n _fcb[fd].lpos = 0;\n return K_OK;\n }\n\n int read(int fd, void *buf, size_t count) override\n {\n if (fd >= MAX_FILES || fd < 0)\n return K_ENOENT;\n if (!_fcb[fd].used)\n return K_ENOENT;\n if (_fcb[fd].lpos + count > _fcb[fd].size)\n count = _fcb[fd].size - _fcb[fd].lpos;\n memcpy(buf, (uint8_t *)_fcb[fd].file + _fcb[fd].lpos, count);\n _fcb[fd].lpos += count;\n return count;\n }\n\n int write(int fd, const void *buf, size_t count) override\n {\n return -1; // No write should be made to a CPIO archive\n }\n int lseek(int fd, off_t offset, int whence) override\n {\n if (fd >= MAX_FILES || fd < 0)\n return K_ENOENT;\n if (!_fcb[fd].used)\n return K_ENOENT;\n if (whence == SEEK_SET)\n {\n if (offset < 0)\n return K_EINVAL;\n if (offset > (long long)_fcb[fd].size)\n return K_EINVAL;\n _fcb[fd].lpos = offset;\n }\n else if (whence == SEEK_CUR)\n {\n if (_fcb[fd].lpos + offset < 0)\n return K_EINVAL;\n if (_fcb[fd].lpos + offset > _fcb[fd].size)\n return K_EINVAL;\n _fcb[fd].lpos += offset;\n }\n else if (whence == SEEK_END)\n {\n if (offset > 0)\n return K_EINVAL;\n if (offset < -(long long)_fcb[fd].size)\n return K_EINVAL;\n _fcb[fd].lpos = _fcb[fd].size + offset;\n }\n else\n {\n return K_EINVAL;\n }\n return K_OK;\n }\n int fstat(int fd, struct stat *buf) override\n {\n return -1;\n }\n\n private:\n static constexpr int MAX_FILES = 1024;\n\n uint8_t *_archive = NULL;\n size_t _archive_len = 0;\n struct cpio_info _info;\n\n struct fcb_t\n {\n bool used = false;\n void *file = nullptr;\n unsigned long size = 0;\n unsigned long lpos = 0;\n };\n\n std::array<fcb_t, MAX_FILES> _fcb;\n};\n\n// Register the filesystem\nFS_INSTALL_FUNC(K_PR_FS_BEGIN) static void fs_register()\n{\n VirtualFS::registerFS(\n \"cpiofs\",\n [](const char *devicePath) -> std::pair<int, BasicFS *> {\n try\n {\n size_t addr = 0, len = 0;\n if (sscanf(devicePath, \"%lu,%lu\", &addr, &len) != 2 && sscanf(devicePath, \"%lx,%lx\", &addr, &len) != 2)\n {\n throw std::runtime_error(\"invalid devicePath specified\");\n }\n auto ret = new CPIOFS((void *)addr, len);\n return {0, ret};\n }\n catch (std::exception &e)\n {\n printf(\"[CPIO] Failed to create CPIOFS: %s\\n\", e.what());\n return {-1, nullptr};\n }\n catch (...)\n {\n printf(\"[CPIO] Failed to create CPIOFS: unknown exception\\n\");\n return {-2, nullptr};\n }\n },\n [](BasicFS *fs) -> int {\n delete fs;\n return 0;\n });\n printf(\"FS CPIO installed\\n\");\n}我们限定从内存中读取归档，需要一个起始地址和长度，从安装设备路径字符串获得。
\n我们想要比较容易在 OS 层进行使用文件系统，则需要进行 LibC 的适配。其实只需要将相关函数重写到 VFS 处理即可：
\n // Hook with libc\n int _write(int fd, char *buf, int size)\n {\n return VirtualFS::write(fd, buf, size);\n }\n\n int _read(int fd, char* buf, int size){\n return VirtualFS::read(fd, buf, size);\n }\n\n int _close(int fd)\n {\n return VirtualFS::close(fd);\n }\n\n int _open(const char *path, int flags, int mode)\n {\n return VirtualFS::open(path, flags, mode);\n }\n\n int _lseek(int fd, off_t offset, int whence)\n {\n return VirtualFS::lseek(fd, offset, whence);\n }\n\n int _fstat(int fd, struct stat *buf)\n {\n return VirtualFS::fstat(fd, buf);\n }值得一提的是，之前我们直接重写 _write() 重定向 stdout 到串口，改动之后只需在 VFS 加入一个判断并写在那里即可。
我们首先生成一个 cpio 归档，如下将 2.txt 加入：
echo 2.txt | cpio -o -H newc > 1.cpio\n\n注意cpio 也有多种格式，这里使用 newc 变体。
\n
随后我们修改 sysroot 解析 initrd 参数，
\n prop = fdt_get_property(fdt, rc, \"linux,initrd-start\", &len); // Just compatible with Linux\n if (prop)\n {\n size_t t = 0, e = 0;\n if (len == 4)\n {\n t = fdt32_to_cpu(*((fdt32_t *)(prop->data)));\n }\n if (len == 8)\n {\n t = fdt64_to_cpu(*((fdt64_t *)(prop->data)));\n }\n \n prop = fdt_get_property(fdt, rc, \"linux,initrd-end\", &len); // Just compatible with Linux\n if (prop)\n {\n if (len == 4)\n {\n e = fdt32_to_cpu(*((fdt32_t *)(prop->data)));\n }\n if (len == 8)\n {\n e = fdt64_to_cpu(*((fdt64_t *)(prop->data)));\n }\n \n if (t && e && e > t)\n {\n _initrd_path = std::to_string(t) + \",\" + std::to_string(e - t);\n }\n }\n }然后在 boot 中挂载之:
\n // Mount rootfs\n auto rootfs = sysroot->initrd();\n if (rootfs.empty())\n {\n std::cout << \"[W] Rootfs not specified!\" << std::endl;\n }else{\n std::cout << \"Mounting rootfs: \" << rootfs << std::endl;\n auto rc = VirtualFS::mount (\"/\", rootfs.c_str(), 0, 0);\n if (rc < 0)\n {\n std::cout << \"[E] Failed to mount rootfs: \" << rc << std::endl;\n return rc;\n }\n std::cout << \"[I] Rootfs mounted successfully!\" << std::endl;\n }接着在 k_main 中就可以直接使用 STL 的文件操作了：
\n std::ifstream f(\"/2.txt\");\n if(f.is_open())\n {\n std::string line;\n while(getline(f, line))\n {\n printf(\"!!!Reading from 2.txt: %s\\n\", line.c_str());\n }\n f.close();\n }\n else\n {\n printf(\"Failed to open file\\n\");\n }编译运行，
\nqemu-system-riscv64 -M virt -m 256M -nographic -bios build/opensbi/build/platform/generic/firmware/fw_jump.elf -kernel build/AbydOS_KNL -initrd build/1.cpio得到：
\nMounting rootfs: 2282749952,512\n0x88100000, 512\n[CPIOFS] cpio_info: 1 files, 5 max_path_size\n[I] Rootfs mounted successfully!\n> Booting harts... (Boot hart = 0)\n> Switching to multicore mode\nTimer interrupt for hart 0\nCurrent Time: 2216260\nHello from hart 0!\n!!!Reading from 2.txt: 114514至此，文件系统框架搭建完成，也适配了 initrd，可以用于后续测试而不必急于编写真的文件系统驱动和存储设备驱动，总共耗时：一天。
\n", "date_published": "2024-07-03T00:00:00.000Z", "date_modified": "2025-10-18T03:18:49.000Z", "authors": [ { "name": "DynamicLoader", "url": "https://octz.net/" } ], "tags": [ "ABYDOS" ] }, { "title": "Step into Chromium (0) - 源码编译", "url": "https://octz.net/blog/Chromium/0-Compile.html", "id": "https://octz.net/blog/Chromium/0-Compile.html", "summary": "前言 玩玩 Chromium Native 开发呗？第一步当然是编译一个纯净的 Chromium 啦！ 原始文档 https://chromium.googlesource.com/chromium/src/+/main/docs/windows_build_instructions.md 本文主要记录在我的环境上如何干净的构建它。限制点： 非默认的 ...", "content_html": "玩玩 Chromium Native 开发呗？第一步当然是编译一个纯净的 Chromium 啦！
\n\n本文主要记录在我的环境上如何干净的构建它。限制点：
\n硬件和系统要求并不低，可以参考我的配置：
\n在该笔记本上完整编译一次需要 7 小时以上。
\n重要
\n你还需要一个稳定的可以访问 google source 的网络环境，至少 80GB 的流量开销。
\nChromium 的工程化比较完善，工具链和依赖以 depot_tools 仓库的形式维护。但是在获取这个仓库之前，你还应该安装 Visual Studio 2022，以及下列包：
\n![\"组件\"](\"https://imgcdn0.octz.net/blog/2025/cr0-image.png\")
![\"单个组件\"](\"https://imgcdn0.octz.net/blog/2025/cr0-image-1.png\")
注意
\n随 Chromium 版本升级，源文档中对于 Windows SDK 的小版本号会逐渐变大，如果你发现当前找不到这么新的 Windows SDK，请升级 VS 主版本。
\n安装好以后，到应用中找到 Windows SDK，修改：
\n![\"Windows](\"https://imgcdn0.octz.net/blog/2025/cr0-image-2.png\")
![\"选择](\"https://imgcdn0.octz.net/blog/2025/cr0-image-3.png\")
![\"勾选](\"https://imgcdn0.octz.net/blog/2025/cr0-image-4.png\")
在等待上面步骤完成的过程中，我们还可以安装并配置 git:
\n$ git config --global user.name \"My Name\"\n$ git config --global user.email \"my-name@chromium.org\"\n$ git config --global core.autocrlf false\n$ git config --global core.filemode false\n$ git config --global core.preloadindex true\n$ git config --global core.fscache true\n$ git config --global branch.autosetuprebase always然后在一个至少有 90GB 空间的分区上新建一个文件夹并进入，克隆 depot_tools 仓库：
\n$ mkdir chromium && cd chromium\n$ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git完成后，使用喜欢的编辑器写一个环境设置脚本：
\npushd %~dp0\nset PATH=%cd%\\depot_tools;%PATH%\nset DEPOT_TOOLS_WIN_TOOLCHAIN=0\n\ncall \"D:\\VisualStudio\\IDE\\Common7\\Tools\\VsDevCmd.bat\"\nset vs2022_install=D:\\VisualStudio\\IDE\n\ncmd /k重要
\n为了不污染环境变量，我们使用脚本定义这些环境变量，其仅在当前命令提示符及其子进程中生效。
\n这也要求后面我们的所有操作都在这样的命令提示符上运行。
\n相关信息
\n注意高亮的行，这是非默认 VS 组件安装路径的解法，前一个是调用了 Developer Command Prompt 来设置正确的环境变量，后者是手动指定了 VS 的安装目录，与 VS Installer 中的设置对应：
\n![\"VS-安装位置\"](\"https://imgcdn0.octz.net/blog/2025/cr0-image-5.png\")
读者可参照修改。如果你按照默认的设置安装 VS，应该不太需要这两行。
\n此后，启动这个 env.bat, 运行
$ gclient，这会正确安装 python 和其他工具 在 depot_tools 内。
\n就在刚刚启动的 env.bat 环境中，执行
$ fetch chromium这将一次性下载 chromium 主仓库，以及 200+ 个子仓库和配套工具（runhooks）。
\n好消息是，当主仓库拉取完成后，我们将可以中断这个过程，并通过
\n$ gclient sync恢复。
\n提示
\n如果你中断后再恢复出现了 git conflict， 不要惊慌，进入对应的子仓库中执行
\n$ git reset --hard HEAD此后重试。
\n当你成功完成了源码克隆，将得到一个 src 文件夹包含了所有的源码。
\nChromium 使用 GN 系统构建。 GN，即 Generate Ninja，是一个用于将 GN DSL 转换成 Ninja 构建配置文件的系统，支持灵活的模板配置和依赖管理。
进入 src 目录，执行：
$ gn gen --ide=vs2022 --filters=//chrome --no-deps out\\Default --args=\"is_component_build = true is_debug = true\"这将在 out\\Default 生成构建配置。需要注意的是，由于 Chromium 的构建配置假定输出目录是 out\\<Name>，实际上使用了很多 ..\\..\\ 这样的相对路径来访问到源码，所以务必保证目录结构如预期，否则编译失败。
在其他磁盘上存储构建产物
\n针对我这样的磁盘空间不足的用户打造，或者 CI 环境，我们可以将 out 目录重定向到其他磁盘。
这里的重定向不能够使用软链接/Junction，其在解析上级目录的时候会遇到问题。
\n解法是使用 NTFS 挂载点，如果有条件，可以在磁盘上划分一个足够大的分区并挂载上，或者像我一样使用 VHD。
\nPS: 使用 VHD 还可以后面利用分层特性整点活？
\n此后就可以进行编译了。运行：
\nninja -C out\\Default chrome -j <n>其中 <n> 为你期望的并行进程数。综合你的物理线程数和内存大小考量即可，我选用 12。
加快编译
\n在编译大型项目的时候，Windows Defender 的实时扫描会严重影响速度。建议关闭/加白相应文件夹处理。
\n剩下一个字，等！
\n在经历了漫长的编译后，我们将会得到编译产物。这时候就可以在 out\\Default 里面找到 chrome.exe，蓝色图标的。打开它，看一下 about://version：
![\"庆祝吧！\"](\"https://imgcdn0.octz.net/blog/2025/cr0-image-6.png\")
为了后面能好好编写代码，我们还需要配置好 clangd，并从构建中提取构建命令。
\n$ python3 tools\\clang\\scripts\\generate_compdb.py -p out\\Default -o compile_commands.json chrome此后打开一个源文件，等待 clangd 构建索引（可能需要几天时间）。
\n如果你完全按照上面进行了编译，应该可以在 out\\Default 中找到一个 1 KB 大小的 all.sln 文件，双击打开它。
然后按图中说明操作，转到项目->属性,配置属性->配置，取消勾选“生成”：
\n![\"取消勾选“生成”\"](\"https://imgcdn0.octz.net/blog/2025/cr0-image-8.png\")
强推扩展 Microsoft Child Process Debugging Power Tool 2022
\n![\"扩展管理器搜索到\"](\"https://imgcdn0.octz.net/blog/2025/cr0-image-7.png\")
![\"配置\"](\"https://imgcdn0.octz.net/blog/2025/cr0-image-9.png\")
随后点击“调试”按钮，尝试下断点，应该好了。
\n![\"准备起飞！\"](\"https://imgcdn0.octz.net/blog/2025/cr0-image-10.png\")
提示
\n以下为 PDF 渲染预览版本，没得复制（打印生成的PDF是这样的qwq） 原件戳这里
\n提示
\n以下为 PDF 渲染预览版本，没得复制（打印生成的PDF是这样的qwq） 原件戳这里
\n提示
\n以下为 PDF 渲染预览版本，没得复制（打印生成的PDF是这样的qwq） 原件戳这里
\n提示
\n以下为 PDF 渲染预览版本，没得复制（打印生成的PDF是这样的qwq） 原件戳这里
\n提示
\n以下为 PDF 渲染预览版本，没得复制（打印生成的PDF是这样的qwq） 原件戳这里
\n提示
\n以下为 PDF 渲染预览版本，没得复制（打印生成的PDF是这样的qwq） 原件戳这里
\n首先，Arduino是一种单片机开发板，其MCU大部分基于AVR架构，采用串口下载，板载USB转串口芯片，下载时可自动复位，无需手动重置；开发板大多支持7 ~ 12 V DC 供电以及5V USB供电。
\n要开发它，首先要安装Arduino的IDE (或者安装atmel公司提供的开发环境)，接着安装开发板USB转串口芯片的驱动程序,然后在Arduino IDE中的工具-开发板选择你的开发板型号(我这里用的是基于Atmega328P的Uno)，就可以愉快地coding了！
\nArduino是基于精简的C++的，所以他支持对象，但是对于STL的支持并不完整！
\nArduino的工程文件后缀名为.ino，相当于.cpp（实际上，在编译时预处理器会把工程目录下的所有文件复制到临时文件夹并改名.ino为.cpp），工程目录文件夹名需与主ino文件名相同。
\n当你新建一个工程时，默认有两个函数，如下:
\nvoid setup(){\n \n}\n\nvoid loop(){\n \n}这两个函数没有返回值，也没有入口参数，且不可更改名称。为啥？因为Arduino是在核心文件里包含工程文件来实现编译的，核心文件里就是这样定义这两个函数的，要改了的话会报错（改核心文件另说）。其中setup函数只在板子上电或重置时执行一次，loop则在setup后无限循环。
\n在文件-示例-Basics里找到Blink程序，如下：
\n//LED_BUILTIN 是板载LED的引脚号，是自动定义的，不用管直接用\nvoid setup() {\n // 初始化LED引脚为OUTPUT\n //Arduino的引脚有3种模式，分别为\n // OUTPUT 输出模式，向外输出电流，单个引脚最大40mA\n // INPUT 输入模式，引脚为高阻抗态，对外部电平变化敏感\n // INPUT_PULLUP 与INPUT作用相同，只是多开启了内部的10k上拉电阻\n pinMode(LED_BUILTIN, OUTPUT);\n}\n\nvoid loop() {\n digitalWrite(LED_BUILTIN, HIGH); // 将LED引脚电平配置为高(HIGH=1)\n delay(1000); // 等待1000毫秒\n digitalWrite(LED_BUILTIN, LOW); // LED引脚电平配置为低(LOW=0)\n delay(1000); // 等待1000毫秒\n}插上你的开发板的USB线，等待电脑识别后在工具-端口里选择对应串口，按Ctrl+U进行编译并下载，下载完成后，你就可以看到开发板上的LED亮一秒灭一秒地闪烁了。
\n", "date_published": "2020-02-13T00:00:00.000Z", "date_modified": "2025-10-18T03:18:49.000Z", "authors": [ { "name": "DynamicLoader", "url": "https://octz.net/" } ], "tags": [ "Embedded" ] }, { "title": "C51 单片机开发之开发环境搭建", "url": "https://octz.net/blog/Embed/C51_0.html", "id": "https://octz.net/blog/Embed/C51_0.html", "summary": "C51单片机简介 C51单片机，很老了，其基于 Intel 的 8051 内核，采用 C 语言开发。 下面说一下我将要使用的单片机基本信息: 开发环境搭建--软硬件准备 我开发用的硬件: 注意 我使用的STC8F1k08内置RC振荡器，无需外部晶振！其他51单片机请自行搜索并搭建最小系统电路！ 开发用软件: 下载烧写工具 安装好之后，就已完成环境的搭建...", "content_html": "C51单片机，很老了，其基于 Intel 的 8051 内核，采用 C 语言开发。
\n下面说一下我将要使用的单片机基本信息:
\n\n| 项目 | \n属性 | \n
|---|---|
| 单片机名称 | \nSTC8F1K08(S2) | \n
| 封装 | \nSOP-8 或 SOP-16 | \n
| 内存 | \n128Byte data,128Byte idata,1024Byte xdata | \n
| 代码容量 | \n8KB | \n
| EEPROM | \nFlash模拟,3KB | \n
| 串口,IIC,SPI | \nx1,x1,x1 | \n
| 备注 | \nSOP-8封装版本的SPI少两根线，无法使用 | \n
我开发用的硬件:
\nSTC8F1k08 SOP16封装或SOP8封装的芯片(使用串口下载程序)\nArduino Uno (其上有一个USB转串口的芯片CH340G可以利用，节省成本)(待测试)\nPC (Windows 7 64位)注意
\n我使用的STC8F1k08内置RC振荡器，无需外部晶振！其他51单片机请自行搜索并搭建最小系统电路！
\n开发用软件:
\nKeil uVision4\nSTC-ISP (烧写工具)安装好之后，就已完成环境的搭建，可以写代码了。
\n", "date_published": "2020-02-14T00:00:00.000Z", "date_modified": "2025-10-18T03:18:49.000Z", "authors": [ { "name": "DynamicLoader", "url": "https://octz.net/" } ], "tags": [ "Embedded" ] }, { "title": "NOLOAD 在自定义段的应用 - CH573 HardFault排查日记", "url": "https://octz.net/blog/Embed/custom_ld.html", "id": "https://octz.net/blog/Embed/custom_ld.html", "summary": "介绍在 CH571/CH573 嵌入式开发中，利用 NOLOAD 属性自定义链接脚本段以避免 HardFault 的排查过程。", "content_html": "想做一个低功耗的复合宏键鼠，看上了CH571这款片子，先去弄了个板子开发着。
\n根据数据手册，Data区域分为16K+2K，低电压时可以选择断电。又RV32的栈是向下增长的，原始链接脚本直接将栈底放在RAM最后部，无法满足需求。
\n\nENTRY( _start )\n\nMEMORY\n{\n\tFLASH (rx) : ORIGIN = 0x00000000, LENGTH = 448K\n\tRAM (xrw) : ORIGIN = 0x20003800, LENGTH = 18K\n}\n\nSECTIONS\n{\n\n /* 省略 */\n\n\t.stack ORIGIN(RAM)+LENGTH(RAM) :\n\t{\n\t\t. = ALIGN(4);\n\t\tPROVIDE(_eusrstack = . );\n\t} >RAM \n\n}既然要将指定的数据放到后2K位置，容易想到自定义一个段，这里我叫他(.lram)，将段地址指定一下。
\n修改后的链接脚本：
\n\nENTRY( _start )\n\n__lram_size = 256;\n\nMEMORY\n{\n\tFLASH (rx) : ORIGIN = 0x00000000, LENGTH = 448K\n\tRAM (xrw) : ORIGIN = 0x20003800, LENGTH = 18K\n}\n\nSECTIONS\n{\n\n /* 省略 */\n\n\t.stack ORIGIN(RAM)+LENGTH(RAM) - __lram_size :\n\t{\n\t\t. = ALIGN(4);\n\t\tPROVIDE(_eusrstack = . );\n\t} >RAM \n\t\n\t.lram ORIGIN(RAM)+LENGTH(RAM) - __lram_size :\n\t{\n\t\t. = ALIGN(4);\n\t\t*(.lram);\n\t\t*(.lram.*);\n\t\t. = ALIGN(4);\n\t} > RAM \n\n}定义好以后，在源码中定义一个结构体，并按照 GCC 的规范加上 attribute，如下：
\n\ntypedef struct {\n uint32_t passCode;\n uint8_t rsv[236];\n\n} globalVar_t, *pglobalVar_t; // 256 Bytes max\n\n__attribute__((section(\".lram\")))\nglobalVar_t globalVar;编译通过后，用WCHISPStudio 3.40 烧录到板子上，成功获得一个不断重启且指示原因为 RPOR(真上电复位)的工程。
\n起初怀疑是破坏了栈，将栈地址前移4 Bytes，正常了，但是，还是有那么一点不对劲啊
\n", "date_published": "2023-08-24T00:00:00.000Z", "date_modified": "2026-01-03T08:10:22.000Z", "authors": [ { "name": "DynamicLoader", "url": "https://octz.net/" } ], "tags": [ "Embedded" ] }, { "title": "ESP-IDF 及 VSCode 插件在WSL下的安装及配置", "url": "https://octz.net/blog/Embed/ESPIDF-WSL.html", "id": "https://octz.net/blog/Embed/ESPIDF-WSL.html", "summary": "WSL 下安装 ESP-IDF 及 VSCode 扩展以实现快速编译的指南。", "content_html": "众所周知，ESP-IDF 在 Windows 下的安装十分困难，编译速度巨慢。通常情况下，编译一个 HelloWorld 程序也需要5分钟及以上。
\n实测发现，ESP-IDF 在 Linux (WSL) 下的编译速度极快，一个同样的 HelloWorld 程序仅需 10 秒即可完成编译。
本文主要介绍在 WSL 上安装 ESP-IDF 及其 VSCode 插件的步骤。
\nWindows 上所需软件有：
\n注意
\n打开 WSL 窗口，执行下列指令以安装必须软件包：
\nsudo apt update\nsudo apt-get install git wget flex bison gperf python3-pip python3-venv python3-setuptools cmake ninja-build ccache libffi-dev libssl-dev dfu-util请手动从 VSCode - 扩展 界面安装 Remote - WSL（扩展ID为 ms-vscode-remote.remote-wsl)；
点击 VSCode 左下角的绿色图标，出现类似图中的页面,选择New WSL Window，此时应打开一个新的 VSCode 窗口，左下角绿色图标变为WSL:Ubuntu-22.04;
\n![\"WSL-1\"](\"https://imgcdn0.octz.net/blog/2023/WSL-1.png\")
在新打开的窗口中，找到 扩展 页面，搜索 Espressif IDF，点击如图中所示安装在WSL:Ubuntu-22.04中按钮，等待安装完成；
\n![\"WSL-2\"](\"https://imgcdn0.octz.net/blog/2023/WSL-2.png\")
安装完成后，按图示操作，改好选择下载源，更改安装路径，点 [Install]，然后继续等待；
\n![\"WSL-3\"](\"https://imgcdn0.octz.net/blog/2023/WSL-3.png\")
实测发现，进行到这里，已经可以超快速编译，但是仍不能烧录程序。按照官方文档，需要安装 usbipd 映射串口，然后会遇到权限问题。
\n这里我们利用 IDF 的一个神奇特性（Bug），即烧录的时候调用的是本地的 PowerShell.exe，顺理成章地，调用到的 Python 也是本地的。
\n因此，我们只需在本地安装相应依赖，就可完美解决问题。下列步骤:
提示
\n请将复制出来的 requirements.txt 及 esp-windows-curses 文件夹置于同一个文件夹下。
修改 requirements.txt ,将下列行（通常在末尾）
file://${IDF_PATH}/tools/kconfig_new/esp-windows-curses; sys_platform == 'win32'改为
\n./esp-windows-curses; sys_platform == 'win32'然后打开 Windows 终端（你喜欢就好），导航至保存的文件目录下，执行
\npip install -r requirements.txt静待片刻，即可安装完成。（若不成功请尝试换源）
\n在连接到 WSL 的 VSCode 窗口内打开一个文件夹，
\n按下 Ctrl + E，紧接着按下C，选择Use current directory，即可用模板创建一个 IDF 工程。
\n接着，连接开发板，在下边栏 [/dev/ttyUSB1] 处选择串口；再进行编译、烧录；(点击🔥图标一步到位)
片刻过后，你将可以从串口监视器看到 Log！
\n现在，您可以享受 10s 飞速编译和烧录啦！
\n", "image": "https://imgcdn0.octz.net/blog/2023/WSL-1.png", "date_published": "2022-07-22T00:00:00.000Z", "date_modified": "2026-01-03T08:10:22.000Z", "authors": [ { "name": "DynamicLoader", "url": "https://octz.net/" } ], "tags": [ "Embedded" ] }, { "title": "ESP8266（ESP32）开发之入坑", "url": "https://octz.net/blog/Embed/ESP_0.html", "id": "https://octz.net/blog/Embed/ESP_0.html", "summary": "简介与开发环境 首先，ESP8266/ESP32 是一款WiFi芯片，后者还带有蓝牙功能。有关的更多信息，请到官网查看。 开发它的方式： 通过安装 ESP8266 /ESP32 for Arduino Core从而在Arduino IDE 里进行开发 通过安装 ESP-IDF 开发（难度较大） NOTICE 请务必按照官网的操作说明进行安装！ 关于我所...", "content_html": "首先，ESP8266/ESP32 是一款WiFi芯片，后者还带有蓝牙功能。有关的更多信息，请到官网查看。
\n开发它的方式：
\n\n\nNOTICE
\n请务必按照官网的操作说明进行安装！
\n我使用 Wemos D1 作为ESP8266的开发板，其上的芯片为 ESP8266-12 ，有9个IO口。
\n我使用 ESP32 Dev Kit 作为ESP32的开发板，其上为 ESP32 Dev Module ，无 PSRAM。
\n开发方式选用 Arduino IDE 。
前几天终于是放了假，好好休息一番后，搞了一套 E3 平台玩，想着搞成服务器，又想在闲置时省点电。从开发板库里面找到了吃灰很久的 ESP8266 (WeMos D1 R1)，就它了。
\n要求 1 很容易实现，因为根据 Intel 的前面板 IO 设计文档并结合实际测试，可以知道按键都是 3v3 上拉输入，而电源灯是推挽 5V 输出。而 COM 口按照标准应该是 RS232 电平，但是我的主板(Z270-Dragon)没有引出来，用的是 COM_Debug 口正好是 TTL 电平。串口控制台最容易了，板子上的 CH340 直接接入 USB 就可以得到 ttyUSB 了。
\n至于4，原本打算搞的，但是硬盘灯是推挽 PWM 输出 5V，蜂鸣器更迷不知道是什么，猜测是开漏，ESP8266 的正常可用的 IO 就 5 个（别看引脚多，实际上上电有特殊状态/要求的很多），搞起来还得刮板加分压电路；加上硬盘灯不是刚需（正常用谁看啊），蜂鸣器要是响了那是低级硬件问题，远程也无法解决，不如不管。
\n首先是供电的选择，我们的 IO 全部在机箱内部，所以直接怼 5VSB 就可以了；当然主板上哪里能找到 5VSB，就看具体的了，实在不行就从 ATX 接口那里引一根线好了！当然也必须把 USB 口的电给断开，不然短接 5V 和 5VSB 是有一点不好的。
\n然后是电源灯的电平问题，它是 5V 推挽输出，所以需要进行分压降压；在这块板子上，注意到 A0 接口有分压电路，ESP8266 只接收 1V 的电平，板子上原来设计的是 104 和 224 分压 3.3V 到 1V，我们直接改掉，用 202 和 123 分压 5V 即可。
\n魔改以下：
\n![\"Board](\"https://imgcdn0.octz.net/blog/2025/IMG_20250120_231421.jpg\")
接下来就可以分配下 IO，
\n| ESP8266 | \nFunc | \n
|---|---|
| D0 D1 (3 1) | \nSerial Console | \n
| TX1 (2) | \nDebug Logger | \n
| SCK (14) | \nTo PWR_BTN | \n
| MISO (12) | \nTo RST_BTN | \n
| A0 (17) | \nFrom PWR_LED | \n
| MOSI SS (13 15) | \nTo COM_Debug | \n
另外，部分华硕主板的 COM_Debug 定义是这样的：
\n![\"COM_DEBUG](\"https://imgcdn0.octz.net/blog/2025/COM_DEBUG_ASUS.png\")
当然经过测试我这块主板就正好是了 :smile
\n警告
\n通常主板上的标准 COM 口是 RS232 规范的，这意味着它的电平和 TTL 电平不兼容。在该情况下，您还需要一个转换芯片。
\n选定 23 端口作为串口转发，22 端口作为控制台。
\n电源控制命令前缀 # ，后缀 $ ，中间 R - 短接 RST，P - 长按 PWR_BTN，S - 短按PWR_BTN。
\n然后就是 L 列出所有日志文件，大于 0x80 的码作为日志读取 index。
\nD 开启/关闭 COM 实时转出，M 获取当前状态，V 获取版本信息。
\n直接套用 WiFiToSerial 示例的工程，修改一下套个类封装即可。
\n因为 ESP8266 只有一个可以接收的串口，所以使用 swap 功能切换引脚，当串口端口连接时，切断日志并映射到 USB 串口上，其他时间则映射到 COM 上。
\n基于 LittleFS 实现日志文件分块，3M 大小按 64K 分块，最多有 90 多个文件，为单字符命令读取作一点限制。由于 LittleFS 的掉电安全设计，必须定时进行 sync 才可以保证写入可见，我们也正好连同文件大小检测和删除旧文件一起做了。
\n利用 WiFiManager 库，自动连 WiFi 和在失败时提供 Config Portal。
\n另外注册一个断连事件重启 ESP8266 即可。
安装的时候发现，进入系统以后长按电源开关的时间要长点才可以强制关机。另外，全金属机箱内的信号太差了，需要更换安装位置，比如前面板缝隙。。。
\n源码见 仓库。
\n", "image": "https://imgcdn0.octz.net/blog/2025/IMG_20250120_231421.jpg", "date_published": "2025-01-20T00:00:00.000Z", "date_modified": "2026-02-04T04:52:50.000Z", "authors": [ { "name": "DynamicLoader", "url": "https://octz.net/" } ], "tags": [ "Embedded" ] }, { "title": "基于 CH551/CH552G 的模拟键鼠设计", "url": "https://octz.net/blog/Embed/SoftKeyMouse.html", "id": "https://octz.net/blog/Embed/SoftKeyMouse.html", "summary": "基于 CH552G 单片机和 CH340K USB 转串口芯片的 USB 键盘鼠标模拟器的设计与实现。", "content_html": "本月突发奇想，想制作一个模拟键鼠，于是打开了熟悉的 WCH 官网 ，然后找到了 CH552G 和 CH340K.
\n话不多说，开整。（此时我还没有意识到我踏进了一个大坑，因为有 CH9326 这个现成的片子）
先看原理图：
\n![\"原理图\"](\"https://imgcdn0.octz.net/blog/2023/softKM-1.png\")
总体思路是用 CH340K 转串口与 CH552 连接，CH552 模拟 HID 设备，并根据串口0收到的命令向被控主机发送 HID 包，完成模拟的操作。
\n图中，我将串口 RTS 和 DTR 接到了 CH552 的中断引脚上，以便进行流控。SRV05 是防静电的芯片。（为啥冬天了才考虑到这事...）
至于PCB，随手一画，双层小板，送 JLC 打样即可。（然后我就被 MicroUSB 的焊接坑惨了）
\n最近进行服务器的装维工作，为了节省安装系统的时间，研究了一下网络启动，经过实践成功，记录于此。
\n前置知识：
\n假设你是一名服务器管理员，每天都在进行服务器的装维工作。这一天，你的老板要求你给新购置的服务器装个系统。
\nBoss: 小管，给服务器装个 Ubuntu Server。\nYou : 没问题，等我烧个镜像先。\nBoss: 好的，也不多，就 20 台，一个上午能搞定吧？\nYou : ... (20台？我哪有20个U盘啊啊啊啊，还TM要一上午搞定？？)于是，为了完成老板的压榨性任务，你不得不另辟蹊径。经过一番思考，你猛然想起，所有的服务器都会事先连接到网络（Hardware Setup），而且要安装的系统都是 Ubuntu Server，如果能够通过网络分发安装镜像并启动安装，配合一下云端配置，就能快速解决这个问题了。
\n之后，你打开了浏览器，发现已经有了成熟的解决方案，而这个方案就是 PXE -- Preboot Execution Environment。
\n观察传统 x86 的磁盘引导过程可以发现，引导是由 BIOS 读取活动磁盘的第一扇区(MBR)并载入到内存 0x7c00 处执行，再由 MBR 程序引导真正的启动管理器。不难想到，如果 BIOS 不是载入 MBR，而是从一个固定位置运行一个预置的程序，那只要这个程序能够驱动网卡，并从网络上拿到真正的引导程序，就可以支持网络启动了。这样的程序提供了启动程序的执行环境，我们称之为预启动执行环境，即PXE。
\nPXE 是由 Intel 开发的。PXE 通常由网卡提供，可以被 BIOS 执行。PXE是基于C/S架构的，原始的 PXE 一般只支持最基本的网络启动功能，如 DHCP 和 TFTP。DHCP 就不用多说，多台服务器的 IP 地址分配一定需要依赖 DHCP，而 DHCP 中可以选择带有自定义的节，这样就可以下发启动配置数据。而 TFTP 是 Trivial File Transfer Protocol 的缩写，即简单文件传输协议。与 FTP 最大的不同是“简单”，走 UDP 69 端口通信，且只有上传下载等基本功能，不能列出文件。这使得它易于实现，代码量也小。
\n原始的 PXE 支持的功能实在有限，且支持的速度很低，只有 10 Mbps。这对于通常大于 1G 的安装镜像是灾难性的，下载的速度实在太慢，还没有完整性保证。由此，前人也有高招，即 PXE 不直接载入安装镜像，而是载入一个更强大的 PXE，由新的 PXE 支持更高速率的网络、更多协议，再加载镜像启动。这样的二级 PXE ，也有很多，最常用的是 pxelinux 和 iPXE。pxelinux 是 linux 内核启动的附属工程，专用于支持 linux 的网络启动。而 iPXE 则是 GNU GPL 开源的网络启动固件。其官网为：ipxe.org。描述如下：
\niPXE is the leading open source network boot firmware. It provides a full PXE implementation enhanced with additional features such as:\n\n- boot from a web server via HTTP\n- boot from an iSCSI SAN\n- boot from a Fibre Channel SAN via FCoE\n- boot from an AoE SAN\n- boot from a wireless network\n- boot from a wide-area network\n- boot from an Infiniband network\n- control the boot process with a script通过 iPXE，我们可以轻松地从 HTTP 服务器获得安装文件，还可以使用 sanboot 功能将 HTTP 服务器上得镜像挂载为一个 SAN 设备支持启动（当然也可以走诸如 iPXE + GRUB4DOS 这样弯曲的路）。
\n如上文所述，PXE 的主要依赖是 DHCP 和 TFTP。流程主要如下图所示：
\n![\"PXE流程\"](\"https://imgcdn0.octz.net/blog/2024/pxe_flow.svg\")
需要说明的是，iPXE 的启动配置文件名不是固定的，而是可以写死在启动文件里（需要重新编译），或者通过 DHCP 下发。这样一来，DHCP 服务器就不能一直返回初始的启动文件路径，而要根据条件选择。这个选择，只需利用 DHCP user class。具体而言，PXE请求DHCP时会使用机器的 user class，而 iPXE 在请求 DHCP 时会使用自定义的 user class，即 "iPXE"。官方推荐的配置 DHCP 服务器时 ISC DHCPd 或者 Microsoft DHCP server，方便起见，我使用了 dnsmasq 在 OpenWRT 软路由上搭建，TFTP 服务器也由dnsmasq 一并提供。参考配置文件如下：
\n\ndhcp-name-match=set:dhcp_bogus_hostname,localhost\ndhcp-name-match=set:dhcp_bogus_hostname,wpad\n\ndhcp-match=set:iPXE,175\n\ndhcp-vendorclass=set:flag,PXEClient:Arch:00000\ndhcp-vendorclass=set:flag,PXEClient:Arch:00006\ndhcp-vendorclass=set:flag,PXEClient:Arch:00007\ndhcp-vendorclass=set:flag,PXEClient:Arch:00009\n\ntag-if=set:load,tag:!iPXE,tag:flag\n\npxe-prompt=\"Press F8 or Enter key for PXE menu.\", 5\n\n#BIOS MENU\npxe-service=tag:load,X86PC, \"BIOS IPXE (UNDI)\", legacy/undionly.kpxe\npxe-service=tag:load,X86PC, \"BIOS IPXE\", legacy/ipxe.pxe\n# pxe-service=tag:load,X86PC, \"BIOS Microsoft PXE\", pxeboot.n12\n# pxe-service=tag:load,X86PC, \"Memtest\", memtest.bin\npxe-service=tag:load,X86PC, \"Boot from local\", 0\n\n\n#UEFI MENU\n# pxe-service=tag:load,IA32_EFI, \"Microsoft UEFI (IA32_EFI)\", bootia32.efi\n# pxe-service=tag:load,X86-64_EFI, \"Microsoft UEFI (X86-64_EFI)\", bootx64.efi\n# pxe-service=tag:load,BC_EFI, \"Microsoft UEFI(BC-EFI)\", bootx64.efi\n\n# pxe-service=tag:load,6, \"iPXE snponly UEFI32(6)\", snponly32.efi\npxe-service=tag:load,7, \"iPXE snponly UEFI\", efi/snponly.efi\npxe-service=tag:load,9, \"iPXE snponly UEFI\", efi/snponly.efi\n\n# pxe-service=tag:load,06, \"iPXE UEFI32(06)\", ipxe32.efi\npxe-service=tag:load,07, \"iPXE UEFI\", efi/ipxe.efi\npxe-service=tag:load,09, \"iPXE UEFI\", efi/ipxe.efi\npxe-service=tag:load,X86-64_EFI, \"GRUB4 EFI\", grub/BOOTX64.EFI\n# pxe-service=tag:load,X86-64_EFI, \"Memtest\", memtest.bin\n\ndhcp-boot=tag:iPXE, boot.ipxe这个配置文件支持 BIOS 和 EFI 启动。所需的大部分文件可以从 boot.ipxe.org 获取。
\n如前所述，经过一番配置，我们已经能够启动到 iPXE 中。接下来就是由 iPXE 启动 Ubuntu Server 镜像了。首先就要下载镜像，然后开启一个 HTTP 服务器提这个镜像，这里不再详细描述。在 iPXE 控制台中，使用
\nsanhook --drive 0x81 ${url}加载 url 为一个 SAN 设备 (设备号0x81，即磁盘1，可以为其他值，参考 x86 实模式的 BIOS 磁盘操作)。随后，使用
\nsanboot --no-describe --drive 0x81启动镜像。
\n到这里，应该可以进入 GRUB2 了。但是在真正启动内核之前，我们还需要修改启动参数，指定 url 供内核获取镜像并挂载。由于这里的 SAN 设备是虚拟的，即使用了 x86 的中断 Hook ，也只能在实模式下起效，ubuntu 的内核没有特殊支持，只能重新从 HTTP 服务器获取一份完整镜像并保存在内存中再挂载。
\n要做到这一点，只需按e编辑菜单命令，进入编辑器后，找到 linux 开头的一行，在该行末尾 （如有--，在这之前） 添加
\nip=dhcp url=\"${url}\"此处需将${url}替换为具体值。
修改完成后，按 F10 启动，就可以了。
\n\n\n你已经读到这里了，好厉害~
\n
相信你已经发现，手动搭建整个服务并不容易，即便是使用 dnsmasq 这样的集成了 DHCP 和 TFTP 的服务端也一样。
\n人的本性是偷懒，包括网络启动的初衷，也是偷懒。所以，一懒到底，使用第三方的集成工具快速解决问题。这里推荐一个，iVentoy，可以傻瓜式操作，详细配置什么的看文档就行。
\nsudo -i\napt-get install ntp\napt-get install ufw #防火墙配置程序nano /etc/ntp.conf然后照着下面的中文注释改：
\n /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help\n\ndriftfile /var/lib/ntp/ntp.drift\n\n# Leap seconds definition provided by tzdata\nleapfile /usr/share/zoneinfo/leap-seconds.list\n\n# Enable this if you want statistics to be logged.\n#statsdir /var/log/ntpstats/\n\nstatistics loopstats peerstats clockstats\nfilegen loopstats file loopstats type day enable\nfilegen peerstats file peerstats type day enable\nfilegen clockstats file clockstats type day enable\n\n# You do need to talk to an NTP server or two (or three).\n#server ntp.your-provider.example\nserver ntp.ntsc.ac.cn #这里写要同步的服务器地址\n\n# pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will\n# pick a different set every time it starts up. Please consider joining the\n# pool: <http://www.pool.ntp.org/join.html>\npool 0.debian.pool.ntp.org iburst\npool 1.debian.pool.ntp.org iburst\npool 2.debian.pool.ntp.org iburst\npool 3.debian.pool.ntp.org iburst\n\n# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for\n# details. The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>\n# might also be helpful.\n#\n# Note that \"restrict\" applies to both servers and clients, so a configuration\n# that might be intended to block requests from certain clients could also end\n# up blocking replies from your own upstream servers.\n\n# By default, exchange time with everybody, but don't allow configuration.\nrestrict -4 default kod notrap nomodify nopeer noquery limited\nrestrict -6 default kod notrap nomodify nopeer noquery limited\n\nrestrict 192.168.10.0 mask 255.255.255.0 nomodify \n# 上面的一行是限制访问，格式： \n# restrict <IP地址，请填写本网地址，并把最后一个byte改成0> mask <子网掩码> nomodify\n#\n# nomodify是不允许客户端更改，允许对时\n\n\n# Local users may interrogate the ntp server more closely.\nrestrict 127.0.0.1\nrestrict ::1\n\n# Needed for adding pool entries\nrestrict source notrap nomodify noquery\n\n# Clients from this (example!) subnet have unlimited access, but only if\n# cryptographically authenticated.\n#restrict 192.168.123.0 mask 255.255.255.0 notrust\n\n......省略...........保存退出。
\n然后执行：
\nsudo service ntp restart\nps -ef | grep ntp看到下面的内容，就配置好了NTP服务器：
\nntp 1066 1 0 18:10 ? 00:00:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 104:110\npi 1069 1034 0 18:10 pts/0 00:00:00 grep --color=auto ntpufw enable\nufw deny\nufw allow 123/udp #开启UDP协议123端口\nufw allow 22/tcp #开启ssh端口然后你会看到：
\nStatus: active\n\nTo Action From\n--WireGuard 是由 Jason Donenfeld 等人用 C 语言编写的一个开源3层网络隧道工具，被视为下一代 VPN 协议，旨在解决许多困扰 IPSec/IKEv2、OpenVPN 或 L2TP 等其他 VPN 协议的问题。它与 Tinc 和 MeshBird 等现代 VPN 产品有一些相似之处，即加密技术先进、配置简单。从 2020 年 1 月开始，它已经并入了 Linux 内核的 5.6 版本，这意味着大多数 Linux 发行版的用户将拥有一个开箱即用的 WireGuard。
\n前置知识：
\n本文仅对其原理和使用作技术上的探讨，不对用途担责。
\n如前言所述，WireGuard (下称：WG) 完全工作在内核模式上，这是它和其它 VPN 的很大不同之处。这意味着，WG 在效率上要高于运行在用户空间中的其他 VPN 软件（少了来回切换上下文的开销），同时却也限制了其安装，即在无法获得 root / 修改内核的情况下无法正确配置。
\n所有的 VPN 实现上有两种途径，一是配置系统代理，二是通过虚拟网卡。WG 工作在内核模式下，最方便的就是创建一个虚拟网卡了，在 Linux 中就是一个 TAP 设备。有了虚拟网卡，就可以分配 IP ，然后修正路由表，使得特定的流量通过虚拟网卡发送/接收，从而被 WG 处理。WG 在接收到网卡数据包时，首先进行非对称加密，然后封包通过 UDP 发送。接收到对端 (Peer) 发送的 UDP 数据包则进行解密，然后放到虚拟网卡上。加解密的操作也通过内核模块的 25519 算法完成，开销很低。
\n不同于 SoftEther VPN 、L2TP 等二层 VPN 协议，WG 工作在三层，即 IP 层，这意味着它无法传输二层包，也就从根本上拒绝了 DHCP。不过，静态 IP 配置也基本够用。而这样做，也进一步减少了 WG 实现上的代码量，路由的工作完全无需在 WG 中实现，完全交给系统，保持了很好的系统兼容性。
\n上述，WG 是通过 UDP 进行端点间通信的，（并且明确不支持也不会支持 TCP），这就没有连接状态了，唯一能确定对端是否联通的方法就是可选的握手。这意味着，一旦 WG 接口启动，无论对端是否连接上，在系统中都是活动的连接，这一点在配置 DDNS 等功能的时候需要尤为注意。
\nWG 虽然借鉴了传统的 C/S 架构，但是没有明确端点的角色，默认情况下，由被链接的一方担任 Server，对方则为 Client。默认端口为 51820，作为 Client 时，如果不显式指定，则使用随机端口连接。典型的连接如图：
\n UDP\n Client (Local port) <玩上了 E3，很好奇通道分配情况。使用的主板是 Z270-Dragon, CPU 是 E3 1240v6。
\nPCIE 有很多种规格，为了清晰描述，给出以下方便的定义：
\nPCIE 在实现上可以有两种，即 CPU 直连 和 PCH 提供。CPU 直连的通道速度最快，不受其他限制；而 PCH 提供的通道虽然多，总体速度受 DMI Link 的速度限制。（小水管）
\nPCIE 的通道拆分即指 CPU 直连的 PCIE 通道拆分，涉及到 CPU 相应 CFG 引脚的配置，高端芯片组通过 GPIO 连接到这些引脚来提供动态配置拆分的选项。
PCH 上的 PCIE 信号路径大致如下：
\n +可选：
\n5. Moonlight 远程桌面（没有 RDP qwq）
\n6. 其他厂商的 安全键盘，如华子的 Secure IME，用于屏蔽自带输入法的抽象捕获（点名百度输入法捕获 Tab 键导致无法接受建议）
最近整了一套 Z270 + 1240v6，打算无头启动（连显卡都无的那种！），结果踩坑了，拔了显卡之后网络挂壁，而且CPU风扇慢转。
\n以为是内核模块挂了导致 kernel panic，排查了好几个小时，终于看到这篇博文，是 PCIE 变动导致网卡名称改变的问题，遂修改 netplan 为：
\nnetwork:\n version: 2\n ethernets:\n enp1s0:\n dhcp4: true\n enp2s0:\n dhcp4: true\n enp3s0:\n dhcp4: true\n enp4s0:\n dhcp4: true\n enp5s0:\n dhcp4: true重启解决！后面进去一看，哎，正好是跑到了 enp1s0 的位置！
\nEdit: 其实可以使用 netplan 的 MAC match 功能进行指定，可以有效解决这些问题。
\n", "date_published": "2025-01-13T00:00:00.000Z", "date_modified": "2026-02-04T04:52:50.000Z", "authors": [ { "name": "DynamicLoader", "url": "https://octz.net/" } ], "tags": [ "Note" ] }, { "title": "lvm分层缓存失效恢复", "url": "https://octz.net/blog/Note/lvm-cache-rec.html", "id": "https://octz.net/blog/Note/lvm-cache-rec.html", "summary": "文章描述了如何恢复使用内存盘作为缓存层的lvm设置。", "content_html": "Refer： https://serverfault.com/questions/932247/how-to-recover-a-cached-lvm-with-cache-on-ram-disk
\n插入新盘，或者使用内存创建loop设备（不够大就寄了）
\nlvm 后执行以下 去除缓存
\npvs\npvcreate --norestore --uuid <uuid_of_pv> /dev/loop0\nlvchange -a y vg\nlvconvert --uncache vg/lvlvchange -ay lvrootfsck.ext4 /dev/mapper/vg0-lvroot众所周知，资源文件对程序的运行具有不可或缺的作用。然而，想要实现跨平台的资源文件利用，我们就不得不摒弃 Win32 资源文件。本文介绍了利用 (MinGW) GCC 工具链生成并嵌入资源文件的一种方法。
\n在这一步，我们将利用 链接器(ld) 生成我们所需要的资源对象文件(.o)。
\n资源文件可以是任意的格式，包括但不限于图片，文本；以下用两个文本文档为例：
\n文件：a.txt
\ndawdawwdwkjagcbsfgbcfgfjbkajkaadgad文件：b.txt
\nHello,txt1!在包含该资源文件的文件夹路径下打开 CMD，执行指令：
\nld -r -b binary a.txt b.txt -o res.o提示
\n指令模板为：ld -r -b binary {文件1} {文件2} -o {输出文件路径}；通配符可用。
这样，我们就得到了资源对象文件res.o。
为了确保编译的成功，我们可以先行检查资源文件暴露的符号，得出符号命名规律。
\n在原先的 CMD 中执行指令
\nobjdump -x res.o我们便得到了一大段输出。找到输出的最后，有类似的表格：
\nSYMBOL TABLE:\n[ 0](sec -1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000023 _binary_a_txt_size\n[ 1](sec -1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x000000000000000b _binary_b_txt_size\n[ 2](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x000000000000002e _binary_b_txt_end\n[ 3](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000023 _binary_b_txt_start\n[ 4](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000023 _binary_a_txt_end\n[ 5](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000000 _binary_a_txt_start这表示，我们的文本文档嵌入了资源对象文件之中，并生成了几个符号。可以总结得出：
\n符号的命名规律
\n_binary_文件名_start
\n_binary_文件名_end
\n_binary_文件名_size
注意：文件名中.转为_。
我们的最终目标是将资源文件嵌入可执行文件中并在程序中使用。为了实现这一目标，我们需要在源码文件中引入符号，例如：
\nextern const char _binary_a_txt_start[], _binary_a_txt_end[];\nextern const char _binary_b_txt_start[], _binary_b_txt_end[];使用extern关键字，并复制符号名称，我们就可以将符号引入源码了。
特别注意
\n符号是一个地址，应定义为 const char[] 类型。
\n例如：
\nint main(){\n size_t a_len = _binary_a_txt_end - _binary_a_txt_start;\n size_t b_len = _binary_b_txt_end - _binary_b_txt_start;\n printf(\"a.txt len=%u,content= %.*s\\n\", a_len, a_len, _binary_a_txt_start );\n printf(\"b.txt len=%u,content= %.*s\\n\", b_len, b_len, _binary_b_txt_start );\n return 0;\n}保存为test.cpp，然后编译：
\ng++ res.o test.cpp -o test.exe这样，我们就得到了可执行文件。执行的结果应如下所示：
\na.txt len=35,content= dawdawwdwkjagcbsfgbcfgfjbkajkaadgad\nb.txt len=11,content= Hello,txt1!这里利用 GCC 的宏定义展开特性，编写示例封装代码：
\n文件：customResource.hpp
\n#pragma once\n#include <cstdint>\n\n#define RESDEF(name) extern const char _binary_##name##_start[], _binary_##name##_end[]\n#define RES(name) _binary_##name##_start, _binary_##name##_end\n\nnamespace Utils {\nclass Resource {\npublic:\n Resource(const char* begin, const char* end)\n : _begin(begin)\n , _end(end)\n {\n }\n ~Resource() { }\n const char* begin() { return this->_begin; }\n const char* end() { return this->_end; }\n size_t length() { return this->_end - this->_begin; }\n const uint8_t* data() { return (const uint8_t*)this->_begin; }\n\nprivate:\n const char* _begin = nullptr;\n const char* _end = nullptr;\n};\n\n}文件：main.cpp
\n#include <cstdio>\n#include \"customResource.hpp\"\n\nusing namespace Utils;\n\nRESDEF(a_txt);\nRESDEF(b_txt);\nResource a(RES(a_txt));\nResource b(RES(b_txt));\n\n\nint main()\n{\n printf(\"a.txt len=%u,content= %.*s\\n\", a.length(), a.length() , a.begin());\n printf(\"b.txt len=%u,content= %.*s\\n\", b.length(), b.length() , b.begin());\n return 0;\n}编译运行即可。
\n使用提示
\n先使用RESDEF(文件名)来引入符号，然后使用Utils::Resource(RES(文件名))来实例化对象
本文参考了下列博文：
\n\n\n\n并经 Windows 11 + MinGW-w64 11.2.0 Seh 测试通过再行编写而成。在此对原博文博主们表示感谢！
\n", "date_published": "2022-09-12T00:00:00.000Z", "date_modified": "2026-01-03T08:10:22.000Z", "authors": [ { "name": "DynamicLoader", "url": "https://octz.net/" } ], "tags": [ "Programming" ] }, { "title": "Profile Guided Optimization (PGO) 初探 [GCC 篇]", "url": "https://octz.net/blog/Programming/PGO0.html", "id": "https://octz.net/blog/Programming/PGO0.html", "summary": "前言 编译优化是一个很重要的课题。现代编译器不仅实现了 Link-Time Optimization (LTO)，针对跨编译单元优化；也实现了 PGO ，基于实际运行数据来进行优化。 多说无益，直接实验启动！ 测试程序与编译 在这之前，有必要提一下我们的环境和编译参数： 编译器：GCC 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.0...", "content_html": "编译优化是一个很重要的课题。现代编译器不仅实现了 Link-Time Optimization (LTO)，针对跨编译单元优化；也实现了 PGO ，基于实际运行数据来进行优化。
\n多说无益，直接实验启动！
\n在这之前，有必要提一下我们的环境和编译参数：
\n为了反编译的简单起见，使用 -Og 进行编译，链接器参数默认。
本次采用的测试程序如下：
\n#include <stdio.h>\n#include <stdlib.h>\n\nint main(int argc, char** argv)\n{\n int num0 = atoi(argv[1]);\n int num1 = atoi(argv[1]);\n int branch = atoi(argv[2]);\n if (branch < 1) {\n for (int i = 2; i < num0; i++) {\n if (num0 % i == 0) {\n printf(\"%i\",i);\n break;\n }\n }\n } else {\n for (int i = 2; i < num1; i++) {\n if (num1 % i == 0) {\n printf(\"%i\",i);\n break;\n }\n }\n }\n return 0;\n}即存在两个一样内容的块，由命令行参数控制路径。
\n采用如下命令编译：
\ngcc -Og -fprofile-generate test.c -o test_pgogen\ngcc -Og test.c -o test这样得到两个不一样的程序:
\n-rwxrwxrwx 1 wsl wsl 16744 Apr 4 16:58 test\n-rwxrwxrwx 1 wsl wsl 552 Apr 4 17:15 test.c\n-rwxrwxrwx 1 wsl wsl 28480 Apr 4 17:15 test_pgogen可以初步看到大小就不一样了。
\n要搞清楚发生了什么，还是通过不同的阶段编译器的产物来比较一下。考虑编译的几个步骤(括号内为编译参数)：
\n依次看下就知道了。
\n首先是预处理，加入 -E，除去头文件，是否启用 profile 生成结果均一致，输出如下：
\n# 3 \"test.c\" 2\n\n\n# 4 \"test.c\"\nint main(int argc, char** argv)\n{\n int num0 = atoi(argv[1]);\n int num1 = atoi(argv[1]);\n int branch = atoi(argv[2]);\n if (branch < 1) {\n for (int i = 2; i < num0; i++) {\n if (num0 % i == 0) {\n printf(\"%i\",i);\n break;\n }\n }\n } else {\n for (int i = 2; i < num1; i++) {\n if (num1 % i == 0) {\n printf(\"%i\",i);\n break;\n }\n }\n }\n return 0;\n}这里的编译特指生成汇编代码。有兴趣的读者可以看一下下面的汇编代码，比较下不同：
\n不难发现里面多了一堆 __gcov 开头的符号引用，是 libgcov 提供的，想必这就是追踪代码了。
后面的汇编和链接，我们就先不考虑了，可以预见是有差异的。
\n简单起见，我们还是发挥传统艺能，启动 IDA 看一下：
\n\n稍微翻一下就可以知道，这个库的初始化是由 ctors 调用的，而退出函数是由 dtors 调用的。
\n对比一下，可以看到编译器主要做了两件事：
\n当程序执行时，会根据程序流经过插桩代码，从而在内存中记录下程序的 profile。当程序正常退出时，将会触发保存逻辑，将内存中的 profile dump 到磁盘上，供 PGO 使用。
\n我们测试一下，就运行一次，参数为10201 1，会发现多了一个 test.gcda 文件。
头在这里。hexdump 一下：
\n00000000 61 64 63 67 2a 34 39 41 ec e2 15 00 00 00 00 a1 |adcg*49A........|\n00000010 02 00 00 00 01 00 00 00 63 00 00 00 00 00 00 01 |........c.......|\n00000020 03 00 00 00 eb 72 70 06 68 a7 65 eb 1d 12 f1 50 |.....rp.h.e....P|\n00000030 00 00 a1 01 16 00 00 00 01 00 00 00 00 00 00 00 |................|\n00000040 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 |................|\n00000050 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|\n00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|\n00000070 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 |................|\n00000080 63 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 |c...............|\n00000090 00 00 a7 01 0c 00 00 00 00 00 00 00 00 00 00 00 |................|\n000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|\n000000b0 64 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |d...............|\n000000c0 64 00 00 00 00 00 00 00 00 00 af 01 02 00 00 00 |d...............|\n000000d0 01 00 00 00 00 00 00 00 00 00 00 00 |............|包看不懂的。不过，我们有办法可以看，那就是使用 gcov 工具。不过，这个工具设计用于代码覆盖率的检查，而我们知道，程序流可以表示为一个图。
\n图的组成里面，有节点和边，我们的 .gcda 文件就只包含了边的数据，这对于有源代码的编译器来说已经足够，但是对于 gcov 生成覆盖率报告却不够。
\n要注意的是，PGO 和 覆盖率测试不是一回事，但是其中的数据可以共用，不过是 GCC 正好用了同一套。对此，我们只需生成一下节点数据即可：
gcc -Og --coverage test.c -S这将生成 test.s 和 test.gcno 。gcno 文件一样是二进制格式文件，没有读的必要，我们只要提供给 gcov 解读即可。
gcov -c ./test.gcda显示
\n./test.gcda:stamp mismatch with notes file\nFile 'test.c'\nLines executed:0.00% of 9\nCreating 'test.c.gcov'\n\nFile '/usr/include/stdlib.h'\nLines executed:0.00% of 1\nCreating 'stdlib.h.gcov'\n\nFile '/usr/include/x86_64-linux-gnu/bits/stdio2.h'\nLines executed:0.00% of 1\nCreating 'stdio2.h.gcov'这是因为我们后生成的 gcno 有不一样的时戳，参照头文件描述的格式，从 gcda 里面修正过来再执行即可，之后得到 test.c.gcov：
-: 0:Source:test.c\n -: 0:Graph:./test.gcno\n -: 0:Data:./test.gcda\n -: 0:Runs:1\n -: 1:#include <stdio.h>\n -: 2:#include <stdlib.h>\n -: 3:\n 1: 4:int main(int argc, char** argv)\n -: 5:{\n 1: 6: int num0 = atoi(argv[1]);\n 1: 7: int num1 = atoi(argv[1]);\n 1: 8: int branch = atoi(argv[2]);\n 1: 9: if (branch < 1) {\n #####: 10: for (int i = 2; i < num0; i++) {\n #####: 11: if (num0 % i == 0) {\n -: 12: printf(\"%i\",i);\n -: 13: break;\n -: 14: }\n -: 15: }\n -: 16: } else {\n 100: 17: for (int i = 2; i < num1; i++) {\n 100: 18: if (num1 % i == 0) {\n -: 19: printf(\"%i\",i);\n -: 20: break;\n -: 21: }\n -: 22: }\n -: 23: }\n -: 24: return 0;\n -: 25:}可以看到，随手测试的数据产生了分支情况的不同。分支 < 1 的情况没有执行过，所以其计数值为0，显示为 #####。
\n执行下面命令，生成使用 PGO 的程序：
\ngcc -Og -fprofile-use test.c -o test_use不看汇编了，我们直接启动 IDA:
\nint __cdecl main(int argc, const char **argv, const char **envp)\n{\n int v3; // r12d\n int v4; // ebx\n int v5; // ecx\n int v6; // esi\n int v7; // r8d\n int i; // r9d\n\n v3 = strtol(argv[1], 0LL, 10);\n v4 = strtol(argv[1], 0LL, 10);\n if ( (int)strtol(argv[2], 0LL, 10) > 0 ) // 这里变成大于了\n {\n v5 = 2;\n v6 = ((_BYTE)v4 - 2) & 7;\n if ( (((_BYTE)v4 - 2) & 7) == 0 )\n goto LABEL_23;\n if ( v4 <= 2 )\n return 0;\n if ( v4 % 2 )\n {\n v5 = 3;\n if ( v6 == 1 )\n goto LABEL_23;\n if ( v6 != 2 )\n {\n if ( v6 != 3 )\n {\n if ( v6 != 4 )\n {\n if ( v6 != 5 )\n {\n if ( v6 != 6 )\n {\n if ( !(v4 % 3) )\n goto LABEL_38;\n v5 = 4;\n }\n if ( !(v4 % v5) )\n goto LABEL_38;\n ++v5;\n }\n if ( !(v4 % v5) )\n goto LABEL_38;\n ++v5;\n }\n if ( !(v4 % v5) )\n goto LABEL_38;\n ++v5;\n }\n if ( !(v4 % v5) )\n goto LABEL_38;\n ++v5;\n }\n if ( v4 % v5 )\n {\n ++v5;\nLABEL_23:\n while ( v5 < v4 )\n {\n if ( !(v4 % v5) )\n goto LABEL_38;\n v7 = v5 + 1;\n v5 = v7;\n if ( !(v4 % v7) )\n goto LABEL_38;\n v5 = v7 + 1;\n if ( !(v4 % (v7 + 1)) )\n goto LABEL_38;\n v5 = v7 + 2;\n if ( !(v4 % (v7 + 2)) )\n goto LABEL_38;\n v5 = v7 + 3;\n if ( !(v4 % (v7 + 3)) )\n goto LABEL_38;\n v5 = v7 + 4;\n if ( !(v4 % (v7 + 4)) )\n goto LABEL_38;\n v5 = v7 + 5;\n if ( !(v4 % (v7 + 5)) )\n goto LABEL_38;\n v5 = v7 + 6;\n if ( !(v4 % (v7 + 6)) )\n goto LABEL_38;\n v5 = v7 + 7;\n }\n return 0;\n }\n }\nLABEL_38:\n __printf_chk(1LL, &unk_2004, (unsigned int)v5);\n return 0;\n }\n for ( i = 2; i < v3; ++i )\n {\n if ( !(v3 % i) )\n {\n __printf_chk(1LL, &unk_2004, (unsigned int)i);\n return 0;\n }\n }\n return 0;\n}可以发现分支那里从 < 变成了 >，因为我们的 profile 表明，有极大概率 branch 是 > 0 的，所以将顺序调过来，以便最大化地利用指令 Cache 提速。
\n此外，针对执行多的分支，还进行了展开，对于最常见情况可以少做循环。
\n反观没有执行过的分支，编译器倾向于保持不变。
实验到这里就结束了，我们通过反编译的手段，清晰地看到编译器究竟做了什么，生成了什么代码。接下来，我们还将尝试 clang 编译器！
\n", "date_published": "2025-04-05T00:00:00.000Z", "date_modified": "2025-10-18T03:18:49.000Z", "authors": [ { "name": "DynamicLoader", "url": "https://octz.net/" } ], "tags": [ "Programming" ] }, { "title": "Profile Guided Optimization (PGO) 初探 [Clang 篇]", "url": "https://octz.net/blog/Programming/PGO1.html", "id": "https://octz.net/blog/Programming/PGO1.html", "summary": "前言 上一篇我们看了 GCC 的 PGO，是时候来看看 Clang 啦！ 源程序和编译参数都和 GCC 的一样，clang 的 wrapper 做的还是很好的！ 看一下段 话不多说，我们直接 IDA 启动： 段节选** 可以发现，多了几个段，顾名思义即可。相比之下，GCC 就不会多出来段，全部都混在一起非常难搞。 参考 Clang文档 ，看一下每个段的...", "content_html": "上一篇我们看了 GCC 的 PGO，是时候来看看 Clang 啦！
\n源程序和编译参数都和 GCC 的一样，clang 的 wrapper 做的还是很好的！
clang version 10.0.0-4ubuntu1 \nTarget: x86_64-pc-linux-gnu\nThread model: posix话不多说，我们直接 IDA 启动：
\n![\"段节选\"](\"https://imgcdn0.octz.net/blog/2025/pgo-image.png\")
**
可以发现，多了几个段，顾名思义即可。相比之下，GCC 就不会多出来段，全部都混在一起非常难搞。
\n参考 Clang文档 ，看一下每个段的数据：
\n![\"__llvm_prf_cnts\"](\"https://imgcdn0.octz.net/blog/2025/pgo-image-1.png\")
__llvm_prf_cnts 这个段就全部都是计数器。
![\"__llvm_prf_data\"](\"https://imgcdn0.octz.net/blog/2025/pgo-image-2.png\")
__llvm_prf_data 这个段主要是一些元数据。多编译一个单元，可以得到更多一份，这样就有规律可循：
#include <stdio.h>\n\nvoid mm(){\n puts(\"BBB\");\n}\n\nvoid m(){ puts(\"CC\");}![\"多加一个编译单元后的](\"https://imgcdn0.octz.net/blog/2025/pgo-image-6.png\")
可以知道每个函数对应一个块，每个块具有如下结构：
\nstruct meta_t {\n char header[12];\n uint32_t some_nums; // 和函数行数有关\n void* ptr_to_cnt_start;\n void* func;\n void* reserved;\n uint64_t num_cnts;\n};![\"__llvm_prf_names\"](\"https://imgcdn0.octz.net/blog/2025/pgo-image-3.png\")
__llvm_prf_names这个段主要提供了名称信息，在实际的 profdata 中通常是被复制写入的。
\n根据文档的意思，数据是 zlib 压缩的，我们用 CyberChef 梭一下：
![\"decompress\"](\"https://imgcdn0.octz.net/blog/2025/pgo-image-4.png\")
可以看到是存储了函数名称。
\n另外注意到其后有一个 LOAD 段，这只是个 padding，不需要考虑。
\n然后是 __llvm_prf_vnds 这个段，全部都是 0，长度是 0x6000，即便多编译单元其长度也不变，暂不明确用途。
不难发现 clang 的默认优化都比 GCC 要激进一些。对比起来，Clang 没有生成关于间接调用追踪的代码，函数体内的插桩全部都是简单的加减法；而且插桩倾向于在基本块靠后的位置。插桩后似乎又进行了一次优化才生成的机器码，导致看起来稍显费劲。
\n还是按照 GCC 篇中的办法，使用 10201 1 参数运行一次，得到一个名字很长的文件：
-rwxrwxrwx 1 wsl wsl 192 Apr 6 11:03 default_15822678452419286522_0.profraw这个是原始文件，要用它来调优，我们还需要做格式转换。
\nllvm-profdata-10 merge -o=default.profdata default_15822678452419286522_0.profraw这将从原始数据合并出来一个 default.profdata 供 Clang PGO 优化使用。
随后，
\nclang -Og -fprofile-use test.c -o test_clang_pguse得到优化后的程序。
\n很不幸的是，我们并没有观测到任何的变化，反编译的代码仍然是：
\nint __cdecl main(int argc, const char **argv, const char **envp)\n{\n int v3; // ebx\n __int64 v4; // rsi\n\n v3 = strtol(argv[1], 0LL, 10);\n if ( (int)strtol(argv[2], 0LL, 10) <= 0 )\n {\n if ( v3 >= 3 )\n {\n v4 = 2LL;\n while ( v3 % (int)v4 )\n {\n v4 = (unsigned int)(v4 + 1);\n if ( v3 == (_DWORD)v4 )\n return 0;\n }\n goto LABEL_12;\n }\n }\n else if ( v3 >= 3 )\n {\n v4 = 2LL;\n while ( v3 % (int)v4 )\n {\n v4 = (unsigned int)(v4 + 1);\n if ( v3 == (_DWORD)v4 )\n return 0;\n }\nLABEL_12:\n printf(\"%i\", v4);\n }\n return 0;\n}即使我们重新以 -O3 编译也一样无法起效。看来，Clang 的默认优化就已经做的很好？
\n挺无奈的。。。
\n", "image": "https://imgcdn0.octz.net/blog/2025/pgo-image.png", "date_published": "2025-04-06T00:00:00.000Z", "date_modified": "2025-10-29T14:19:41.000Z", "authors": [ { "name": "DynamicLoader", "url": "https://octz.net/" } ], "tags": [ "Programming" ] }, { "title": "Codeblocks wxWidgets 安装与配置", "url": "https://octz.net/blog/Programming/wxWidgetsInit.html", "id": "https://octz.net/blog/Programming/wxWidgetsInit.html", "summary": "简介 wxWidgets是一个基于C++的GUI库，支持动、静态链接方式，还可以支持OpenGL！ 本篇记录我的配置过程。 下载与编译 用到的软件（Win7下）： Codeblocks 17.12 （附带GCC 5.10） wxWidgets 2.8.12 安装Codeblocks,并把Codeblocks安装目录下的MinGW\\bin添加到path环...", "content_html": "wxWidgets是一个基于C++的GUI库，支持动、静态链接方式，还可以支持OpenGL！
\n本篇记录我的配置过程。
\n\n用到的软件（Win7下）：
\n安装Codeblocks,并把Codeblocks安装目录下的MinGW\\bin添加到path环境变量；
\n到这里下载v2.8.12版的源码（其他版本请到简介中的链接下载）；
\n下载好之后，把它解压到C:\\下，然后新建一个build.bat，命令如下：
\n@echo off \n cd build/msw \n title Compile wxWidgets \n echo Start Compile ... \n echoJQuery是一个开源的前端JS框架，能简化许多操作，比如 ajax 。。。
\n要使用他，只需要引入一个90KB左右的 JS 文档，网上的cdn多的是，本站也在用。
首先，你需要用<script>标签引入他，才能正常使用，像这样：
<script src=\"https://code.jquery.com/jquery-2.2.4.min.js\"></script>如果你在引入之前就使用它的语句，会报错，比如下面的例子：
\n<html>\n <body>\n <script>\n $(\"html\").html(\"<h1>Hello,World<//h1>\");\n </script>\n <script src=\"https://code.jquery.com/jquery-2.2.4.min.js\"></script>\n </body>\n</html>JQuery几乎所有的函数都是以$开头。
\n目前用的最多的就是：
\n$(\"元素选择器\").attr(\"属性\",\"值\");元素选择器可以是：
\n元素名称，如 "html" ,"body" ...
\n元素ID,在ID前加一个"#"表示通过ID选择要操作的元素，如 "#main" 表示选择页面中所有ID="main的元素"；
\n元素的类(Class),在Class之前加一个"."表示通过类选择元素，如".span8"表示选择页面中所有Class="span8"的元素。
\n元素选择器之后有一个"."，表示访问他的成员函数（这和VB有点像）
\n常用的成员函数（方法）有：
\nattr(\"属性\"，\"值\") //将元素的属性设置为值 \ncss(\"属性\"，\"值\") //将元素的CSS的某个属性改为值 \nhtml(\"值\") //将元素内的html改为值如果上述函数括号内的“值”为空，则返回选定元素当前的属性值。
\nNot finished yet!
\n由于域名已经备案，故可以使用 CDN 加速访问速度。上了 CDN 之后一切正常，直到某一天，看了一眼 CDN 日志，发现回源错误率猛增。
\n首先访问自己的网站，发现页面可以显示，但是样式和按钮全部没了。打开F12一看，woc，报了很多的403，怪不得回源错误率高。
\n然后就想到源站是不是寄了。但是，源站也是静态站点，不存在被攻击的可能。直接访问源站，也正常。
\n这时候，已经猜测出来是DNS污染的问题了。也就是说，CDN 服务器拿到的回源地址是被改写过的。为了进一步证实我的猜测，直接与 CDN 提供商沟通。
\n经过他们测试，使用各地的虚拟机访问源站，发现在某些省份的结果不正确（被重定向了）。
至此，DNS污染实锤。
\n既然被污染，那很简单，直接更换源站域名为一个未被污染的域名即可。虽然仍然存在被污染的风险，但是可以启用 DNSSEC，在一定程度上防止 DNS 污染。
\n", "date_published": "2023-06-01T00:00:00.000Z", "date_modified": "2026-01-02T13:13:48.000Z", "authors": [ { "name": "DynamicLoader", "url": "https://octz.net/" } ], "tags": [ "Web" ] } ] }