字如其名，PassKey 是一个钥匙，在 base/types/pass_key.h 中定义，存在 base namespace 下面，允许预先声明的类访问某些特定方法，而不必使用类级别的友元声明。

先来看一下它的最简单定义：

template <typename... Args>
class PassKey;

template <typename T>
class PassKey<T> {
  friend T;
  PassKey() = default;
};

就这么简单。神奇吗？

怎么用？

比如我们有 A， B 和 C 三个类，其中只想 B 访问 A 的 foo() 方法，那么可以这样写：

class B;
class A {
  public:
    // bar 方法可以被任意类调用
    void bar(){}

    // foo 方法只能被 B 调用
    void foo(PassKey<B>){}
};

class B {
  public:
    void foo(){
      A a;
      a.foo({}); // OK!
    }
};

class C {
  public:
    void foo(){
      A a;
      // a.foo({}); // Error under C++20 or higher
    }
};

发现了吗？只有 B 是 PassKey<B> 的友元类，也就只有 B 可以实例化 PassKey<B>，从而调用 A::foo()。

不过你可能会发现，这里有一个问题，就是如果 B 实例化 PassKey<B> 之后传给第三方，那么第三方类也可以拿这个实例来调用 A::foo() 了。这就好像 B 拥有 A::foo() 的钥匙，但是钥匙是可以复刻的，那么任何拿到复刻钥匙的实体都可以打开 A::foo() 这把锁。针对这个问题，我们还可以禁用拷贝构造和赋值操作符，这样就得到了 NonCopyablePassKey:

template <typename T>
class NonCopyablePassKey {
  friend T;
  NonCopyablePassKey() = default;
  NonCopyablePassKey(const NonCopyablePassKey&) = delete;
  NonCopyablePassKey& operator=(const NonCopyablePassKey&) = delete;
};

常用的场景就是只允许某个 Factory 来构造某类 Object ，给 Object 的构造函数加一个 Passkey<Factory> 参数即可。在 Chromium 中，也常用来管控一些设计上正在被废弃的类在新场景下的利用。

此外，PassKey 在较新版本也加入了多类的支持，如下：

有点长，而且是偏特化大师和前沿特性大神（需要 requires 和折叠表达式，至少 C++20）...

namespace pass_key_internal {
template <typename T, typename... Args>
concept OneOf = (std::same_as<T, Args> || ...);

// Calculates how many instances of <T> there are among <Args...>.
template <typename T, typename... Args>
constexpr int type_frequency =
    (static_cast<int>(std::is_same_v<T, Args>) + ... + 0);

// All types in <Args...> are unique if each type occurs there exactly once!
template <typename... Args>
concept PairwiseUnique = ((type_frequency<Args, Args...> == 1) && ...);
}  // namespace pass_key_internal

// Specialization for multi-argument PassKey. This allows a PassKey to be
// constructed from another PassKey if all its arguments are present in
// the target PassKey's argument list. This enables flexible access control
// where a function might accept a PassKey that covers a broader set of
// authorized callers, and callers can provide more specific PassKey-s.
template <typename... Args>
  requires(sizeof...(Args) > 1)
class PassKey<Args...> {
  static_assert(pass_key_internal::PairwiseUnique<Args...>,
                "PassKey<> arguments must be pairwise unique.");

 public:
  // Allows constructing a PassKey<A, B> from PassKey<A> or PassKey<B>.
  // Implicit to allow feeding PassKey<A> into a function that expects
  // PassKey<A, B>.
  template <typename T>
    requires pass_key_internal::OneOf<T, Args...>
  // NOLINTNEXTLINE(google-explicit-constructor)
  PassKey(PassKey<T>) {}

  // Allows constructing a PassKey<A, B, ...> from a PassKey<A, B>.
  // The exact order of arguments doesn't matter.
  // Implicit to allow feeding PassKey<A, B> into a function that expects
  // PassKey<A, B, ...>.
  template <typename... SourceArgs>
    requires(sizeof...(SourceArgs) > 1 &&
             (pass_key_internal::OneOf<SourceArgs, Args...> && ...))
  // NOLINTNEXTLINE(google-explicit-constructor)
  PassKey(PassKey<SourceArgs...>) {}
};

1. NameSilo 的所有系统的时间都没有时区标记！
2. UI 显示的解锁时间是按用户本地时间
3. API 侧给出的解锁时间是按 UTC+0
4. 底层域名管理系统使用 NameSilo 所在地时间，也就是美国山地标准时 MST (UTC-7)

结果就是你看面板解锁了，不算！
你看后端接口显示没有锁了，也不算！
必须等到 MST 那个时间到了才是真的解锁，在此之前你提交多少次转移申请都会静默失败。

| 我才不会告诉你我测了半天发现跑个 docker 都费劲呢~

什么是 iSCSI

iSCSI，全称 Internet Small Computer System Interface（互联网小型计算机系统接口），是一种基于 TCP/IP 协议的存储网络标准。

它允许通过标准的 以太网（Ethernet）基础设施来传输传统的 SCSI（小型计算机系统接口）命令，从而实现 块级别（Block-level）的数据传输和访问。简单来说，iSCSI 就是在 IP 网络上运行 SCSI 协议，将远程的存储设备（如磁盘阵列）虚拟成本地的硬盘，供服务器或计算机使用。

在整个 iSCSI 架构中，发起方 (Initiator) 扮演着客户端的角色，它通常是需要存储空间的服务器或计算机，通过发送 SCSI 命令来请求数据。而 目标方 (Target) 则扮演着服务端的角色，它是一个存储设备，负责接收和处理来自发起方的 SCSI 命令，并将底层的存储资源（即 LUN，逻辑单元号）通过网络的方式虚拟成一块本地硬盘供发起方使用。

这次我们搞试验，就把 J1900 作为目标，而 Windows 电脑作为发起方。

Target

我们常使用 tgt 来搭建 target。我在这里跑 OpenWrt，用 opkg 一把梭就可以安装。

不幸的是，由于这个是比较偏门的应用场景，并没有一个 luci 供我们配置。不过我们仍然可以通过 uci 配置文件来统一化配置，对应的文件是 /etc/config/tgt，下面是一个实例：

config options 'tgt'
# iothreads limits number of worker threads per rdwr target, default is 16
# which seems to be too much for an avarage router
	option iothreads '2'
#	option nop_count '3'
#	option nop_interval '1'
#	option logging '0'
#	list portal '[::1]'
#	list portal '127.0.0.1:3261'
#	list portal '0.0.0.0:3262'
#	list portal '[::]:3263'

config target 1
    # 一个名字
	option name 'iqn.2012-06.lan.server:target1'
    # 允许连接的对端名称
	list allow_name 'iqn.1991-05.com.microsoft:xxx-laptop'
#	list allow_address '192.168.2.128/27'

#config target 2
#	option name 'iqn.2012-06.org.openwrt:t2'

# all options are set to default, except for the device
# lun "name" is constructed as TGTID_LUN
config lun 1_1
    # 这里可以指定一个设备名/文件名
	option device '/dev/sda'
# type of scsi device. available options: disk, cd, pt (sg passthrough)
#	option 'type' 'disk'
# backing store access method: rdwr (read-write), aio (async IO), sg (for pt type only, device must be /dev/sgN)
#	option 'bstype' 'aio'
# set sync and/or direct flags when opening device, affect only rdwr
#	option 'sync' '0'
#	option 'direct' '0'
# block size for lun, default is 512
#	option 'blocksize' 4096
# override SCSI mode page, see tgtadm man page for details
#	option 'mode_page' 'string'
# vendor, product, revision, SCSI ID and SCSI Serial number
#	option 'vendor_id' 'string'
#	option 'product_id' 'string'
#	option 'product_rev' 'string'
#	option 'scsi_id' 'string'
#	option 'scsi_sn' 'string'
# refuse write attempts. applies only to disk type
#	option 'readonly' '0'
# Disk devices default to non-removable, cd - to removable
#	option 'removable' '0'
#  0 = Classic sense format, 1 = Support descriptor format.
#	option 'sense_format' '0'
# Rotaion rate: 0: not reported, 1: non-rotational medium (SSD), 2-1024: reserverd, 1025+: "Nominal rotation rate"
#	option 'rotation_rate' '0'
# A thin-provisioned LUN is represented as a sparse file.
# When initiators use the SCSI UNMAP command TGTD will release the affected areas back to the filesystem using FALLOC_FL_PUNCH_HOLE.
# This option applies to the disk type and rdwr bstype
#	option 'thin_provisioning' '1'

# Target 1 上的第二个卷
config lun 1_2
	option device '/dev/sdb'

#config lun 2_2
#	option device /dev/sdc

# CHAP 认证账号相关
config account
	list target 1
#	list target 2
    # 建议设置为你的 Initiator 的名字，以确保只有一个连接
	option user "iqn.1991-05.com.microsoft:xxx-laptop"
    # 密码需要符合规范，我的试验是 12 位，带有大小写和数字就行
	option password "Abcdefgh1234"

#config account
#	option target 2
#	option user "user2"
#	option password "pwd2"
#	option outgoing 1

Initiator

Windows 一直都带有 iSCSI 发起程序，我们打开它。然后按图设置完成后，一路确定即可。

连接完成后，可以看到 已发现的目标 列表中多了一个项，且状态为 已连接。

如果使用的是一块现有的磁盘，那么应该可以在资源管理器里面直接看到原来的卷标了，否则请到磁盘管理里面去初始化磁盘再分区、格式化，就像插入了一块新硬盘一样。

除了 NFC 很弱（我的手机根本用不了，对，是贴上去无论怎么调整都一点反应都没有的那种）以外，CanoKey Canary 的功能基本对标 Yubikey 5c，而且管理上采用了 WebUSB，十分的便利。

主要是支持了 FIDO2 / WebAuthn，OpenPGP 和 PIV，还有 TOTP，基本够用了。配合 Ed25519-SK 来个 SSH 免密登录（是真的只要插上 key 导出来私钥存根就能用的那种，Xshell 都可以），再替代一手 Authenticator 应用。负担嘛无非是要随身带多一个东西，就像真的钥匙一样。

来点有用的命令：

ssh-keygen -t ed25519-sk -O resident -O application=ssh:YourName # -O verify (to enforce entering PIN)
ssh-add -K # This may need admin/root perm to recover handle and public key from SK into your PC
fido2-token -L # List all SK
fido2-token -L -r <device> # See what's in it

顺便，FIDO 也有两个版本，版本一是非驻留式的，密钥在这里当作一个证明函数；FIDO2 允许驻留私钥，也向后兼容。这也是有些网站明明添加了 PassKey 之后也不能在 SK 上面找到凭据的原因。

Open Shortest Path First (OSPF) 是一种好用的动态路由协议，采用 IP proto 89 交换信息，要求两端对等。可以在广播、点对点和点对多点的环境使用。

这几天也是试了下水，发现比静态路由舒服一点，顺便也给我的内网规划了一下，这里稍微记录一下配置的东西。

阅读建议：非常推荐先会基本的计算机网络和路由原理。

安装软件包

在普通的 Linux 设备上，我们可以通过 frr 来构建这些服务。例如，在 OpenWrt 上，我们需要使用如下的包：

frr	
frr-ospf6d
frr-ospfd
frr-staticd
frr-watchfrr
frr-zebra

Frr 基础使用

frr 提供了一个集中的命令行控制台叫做 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。

以下是最终的示意配置文件，供参考：

路由器 A (R-A):

!
frr version 10.2.1
frr defaults traditional
hostname R-A
log syslog
!
password [YOUR_SECURE_PASSWORD]
!
ip route 192.168.0.0/16 reject        # 内部地址防环/黑洞策略
ip router-id 192.168.0.254            # 路由器A的Router ID
!
interface eth0
 ip address 192.168.3.254/24          # 假设eth0的IP
 ip ospf area 2.0.0.0                 # 本地区域 2.0.0.0
exit
!
interface wg4
 ip address 192.168.0.254/32          # 隧道IPv4地址 (简易起见与Router ID一致)
 ip ospf area 0                       # 骨干网区域，area 0 = 0.0.0.0
 ip ospf network point-to-point       # 指定为点对点网络
 no ip ospf passive                   # 在这个接口上取消被动接口，即宣告 OSPF 信息
exit
!
interface wg6
 ipv6 address fd00:f000::1/128        # 隧道IPv6 ULA地址
 ipv6 address fe80::192:168:0:254/64  # 链路本地地址
 ipv6 ospf6 area 0                    
 ipv6 ospf6 network point-to-point
exit
!
router ospf
 passive-interface default            # 默认接口被动，即默认不宣告 OSPF 
 area 2.0.0.0 range 192.168.0.0/22    # 聚合/通告本地网络 (A 的本地块)
 default-information originate        # (可选) 宣告一个默认路由
exit
!
router ospf6
 ospf6 router-id 192.168.0.254        # 这个 router-id 似乎是独立的
 area 2.0.0.0 range fd00:10::/60      # 聚合/通告本地网络 (A的本地块)
exit
!
access-list vty seq 5 permit 127.0.0.0/8
access-list vty seq 10 deny any
!
line vty
 access-class vty
exit
!
end

路由器 B (R-B):

!
frr version 10.2.1
frr defaults traditional
hostname R-B
log syslog
!
password [YOUR_SECURE_PASSWORD]
!
ip route 192.168.0.0/16 reject        # 内部地址防环/黑洞策略
ip router-id 192.168.8.254            # 路由器B的Router ID (与隧道IP一致)
!
interface eth0
 ip address 192.168.11.254/24         # 假设eth0的IP
 ip ospf area 1.0.0.0
 ip ospf network broadcast            # 这个接口是广播接口，可以通过交换机连接子 OSPF 交换机 
 ip ospf priority 255                 # 主路由器给高优先级，DR/BDR 选举时成为 DR
 ipv6 ospf6 area 1.0.0.0
 no ip ospf passive
exit
!
interface wg4
 ip address 192.168.8.254/32          # 隧道IPv4地址 (与Router ID一致)
 ip ospf area 0
 ip ospf network point-to-point
 no ip ospf passive
exit
!
interface wg6
 ipv6 address fd00:f000::2/128        # 隧道IPv6 ULA地址
 ipv6 address fe80::192:168:8:254/64  # 链路本地地址
 ipv6 ospf6 area 0
 ipv6 ospf6 network point-to-point
exit
!
router ospf
 passive-interface default
 area 1.0.0.0 range 192.168.8.0/22    # 聚合/通告本地网络 (B的本地块)
exit
!
router ospf6
 area 1.0.0.0 range fd00:20::/60      # 聚合/通告本地网络 (B的本地块)
exit
!
access-list vty seq 5 permit 127.0.0.0/8
access-list vty seq 10 deny any
!
line vty
 access-class vty
exit
!
end

效果

查看路由表，可以看到对方宣告过来的路由以 O>* 标记，这表明路由是 OSPF 宣告的，已被选中并安装到内核中。
然后 ping 一下，双方都可以 ping 通。

EOF~

免责声明

以下仅为个人观点，实际以 RFC 为准。

GN 是一个可生成 Ninja 构建配置文件的源构建系统。常用 C/C++ 的同志们都知道 CMake，GN 在某种意义上和 CMake 同级，只不过它只能生成 Ninja makefile，但也提供比 CMake 更多更便利的功能。

和 CMake 类似，GN 也是一个 DSL (领域特定语言)，像是 Python 和 C 的混合体。

这并不是一个完整的教程，只是用到了就会来补充用法，权当一个速查手册。

如何：构建一个可执行文件/库

写一个 BUILD.gn（不要改名）：

executable("demo_exe") {
  sources = [ "demo.cc" ]
}

That's All!

这里我们创建了一个名叫 demo_exe 的 target，类型是可执行文件，源文件有 demo.cc。

对于静态库，使用 static_library；动态库是 shared_library。

如何：引入一个组件/静态库

这在 GN 中被描述为“依赖” (deps)。如果我们的 demo_exe 使用了 base 库的内容，则我们需要这样将依赖加入 deps 数组即可：

executable("demo_exe") {
  sources = [ "demo.cc" ]

  deps = [ "//base" ] # here
}

// 是指项目根目录。

如何：预定义一个宏

在 target 内部加入 defines 数组即可：

defines = [
  "HELLO_SHARED_IMPLEMENTATION",
  "ENABLE_DOOM_MELON=0",
]

如何：条件编译

GN 内部存在很多的变量，我们也可以可以定义变量，然后使用条件控制语句控制。

以常见的跨平台场景为例，我们有 demo.h 定义了接口，然后对于 Windows, linux 和 mac 有 demo_win.cc, demo_linux.cc 和 demo_mac.cc 作为实现。则可以这样写：

executable("demo_exe") {
  sources = [ "demo.h" ]

  if(is_win){
    sources += ["demo_win.cc"]
  }

  if(is_linux){
    sources += ["demo_linux.cc"]
  }

  if(is_mac) {
    sources += ["demo_mac.cc"]
  }
}

这里的 is_win，is_linux 和 is_mac 都是 GN 的预定义变量。自定义变量只需要直接写 var_name = value 即可。

如何：生成 Ninja 构建文件

$ gn gen <out_dir>

随后转到 out_dir 执行 ninja 即可。

失败了，姑且看看图吧，拿来照玩家的话有些不好看...

实现方法

如何：混合颜色

由于渲染管线的并行特性限制，我们并不能在一个 Pixel Shader 中读写同一个缓冲区。那么，我们如何将当前的颜色和已经绘制的颜色混合起来呢？答案是通过 Blend 指令。Blend 指令将在渲染管线的特定步骤执行，以将当前 Pixel Shader 的输出缓冲 (Source) 和屏幕缓冲区(Destination) 以指定的方式混合。典型操作表达式为：

其中 OP 代表某种操作，通常是加，也可以是下面这几十种（以 [Enum(UnityEngine.Rendering.BlendOp)] 注明）

而 Blend 指令的基础格式是：

Blend [RT] <Src> <Dst> | <SrcRGB> <DstRGB>, <SrcA> <DstA>

Src 等参数统称为 Blend Mode, 其取值以 [Enum(UnityEngine.Rendering.BlendMode)] 注明，有如下几个：

我们要实现一种朦胧感，考虑让材质输出为一个灰色蒙版，随后配置 Source blend mode 为 One，Destination blend mode 为 OneMinusSrcColor。

如何：选择范围

我们当然不希望所有东西都被我们选中并且做颜色混合。总结起来，

1. 一帧画面有一个渲染队列，每个 Material 可以指定其排序优先级，渲染时从低到高执行渲染
2. 在 PS 输出后，根据模板缓冲 (Stencil Buffer) 做 StencilTest，如果不通过，则该像素丢弃；测试后可以按情况修改 Stencil Buffer
3. 在 StencilTest 后，根据深度缓冲 (Depth Buffer) 做 ZTest，如果不通过，则该像素丢弃；测试后可以按情况修改 Depth Buffer
4. 都通过的像素进行 Blend 后输出

所以实际上，我们可以控制的是 RenderQueue，StencilTest 和 ZTest 的行为。

这部分内容过多，建议查看原视频理解掌握。这里给出几张图和说明，帮助理解：

其中，手是素体的一部分，其 RenderQueue 为 2451，Stencli 为 Always Keep (0)， ZWrite = true；
衣服的 RenderQueue 为 2460，Stencli 和 ZWrite 都和素体保持一样的设定。

在这前面放置一个胶囊，应用我们的材质，然后 Blend Mode 设置和上面混合颜色设置一致。

这种情况下，先绘制了素体，然后绘制我们的胶囊。胶囊绘制完成后，由于其 ZWrite 为 On，且胶囊比衣服离我们更近，所以深度缓冲被写入了更大的值；随后绘制衣服，在 ZTest 时已被胶囊绘制的部分会失败，从而维持胶囊的绘制结果，显示为部分透明。(如果设置 RenderQueue 为 2461 则这种透明消失)

在此基础上，我们再设置素体的 Stencil 为 Always Replace (22)，随后在胶囊材质设置 StencilTest Mode 为 Euqal 22，可以得到：

这是因为 Stencil 测试通过的只有素体在胶囊这个范围内的部分，也只有这些东西被混合了并且写了深度。

当我们关闭深度写入，以上的一切都消失了，又回到了原本的样子。这是因为后续衣服在渲染的时候发现自身的Z小于缓冲区里的（ZTest 默认 LessEqual Pass），进行了覆盖。这就是 ZTest 的意义。

补充一点，正经的半透明物体一般做法是将渲染队列开高，然后将 ZWrite 关闭。这样就可以达到该透过的物品已经绘制了，但是位于半透明物品前（更靠近摄像机）的物体仍然可以进行正确的覆盖，符合预期。

最终代码

Shader "Unlit/ScreenMaskShader"
{
    Properties
    {
        _MainTex ("Texture", 2D) = "white" { }
        
        [Enum(UnityEngine.Rendering.BlendMode)]
        _SrcBlend ("Source blend", Float) = 0

        [Enum(UnityEngine.Rendering.BlendMode)]
        _DstBlend ("Destination blend", Float) = 0

        [Enum(UnityEngine.Rendering.BlendOp)]
        _BlendOp ("Blend Operation", Float) = 0


        _StencilRef ("Stencil Ref Value", Range(0,255)) = 0

        [Enum(UnityEngine.Rendering.CompareFunction)]
        _StencilComp ("Stencil Compare Mode", Float) = 0

        [Enum(UnityEngine.Rendering.StencilOp)]
        _StencilPassOp ("Stencil Pass Operation",Float) = 0

        [Enum(UnityEngine.Rendering.StencilOp)]
        _StencilFailOp ("Stencil Fail Operation",Float) = 0

        [Enum(UnityEngine.Rendering.CompareFunction)]
        _ZTestComp ("ZTest Compare function", Float) = 0

        [Enum(Off, 0, On, 1)]
        _ZWrite ("ZWrite", Float) = 0

    }
    SubShader
    {
        Tags { "RenderType" = "Opaque" }
        LOD 100

        Pass
        {

            Blend [_SrcBlend] [_DstBlend]
            // Blend Zero One, SrcAlpha OneMinusSrcAlpha
            BlendOp [_BlendOp]
            // ColorMask 0

            Stencil 
            { 
                Ref [_StencilRef]
                Comp [_StencilComp]
                Pass [_StencilPassOp]
                Fail [_StencilFailOp]
            }

            ZTest [_ZTestComp]
            ZWrite [_ZWrite]

            HLSLPROGRAM
            #pragma vertex vert
            #pragma fragment frag
            // make fog work
            #pragma multi_compile_fog

            #include "UnityCG.cginc"

            struct appdata
            {
                float4 vertex : POSITION;
                float2 uv : TEXCOORD0;
            };

            struct v2f
            {
                float2 uv : TEXCOORD0;
                UNITY_FOG_COORDS(1)
                float4 vertex : SV_POSITION;
            };

            sampler2D _MainTex;
            float4 _MainTex_ST;

            v2f vert(appdata v)
            {
                v2f o;
                o.vertex = UnityObjectToClipPos(v.vertex);
                o.uv = TRANSFORM_TEX(v.uv, _MainTex);
                UNITY_TRANSFER_FOG(o, o.vertex);
                return o;
            }

            fixed4 frag(v2f i) : SV_Target
            {
                fixed4 col = tex2D(_MainTex, i.uv);
                col *= 0.08;
                
                // apply fog
                UNITY_APPLY_FOG(i.fogCoord, col);
                return col;
            }
            ENDHLSL
        }
    }
}

liltoon 啥都有，但是为了简化模型还是手搓了

附注

关于各种缓冲区的结论，是使用 RenderDoc 抓帧得到的，但是仍然有如下几个点：

1. 抓到的帧上下颠倒：DX11 的 Y 轴倒置。
2. 深度缓冲中，离摄像机越近的 Z 越大，但是 ZTest 时行为又是离摄像机越远越大：DX11 的 Z 轴倒置。
3. Game 中看到的提前写了更大深度的区域为黑色~白色闪动，但是场景中正常

暂未找到原因。

算是一个作业记录？哈哈哈

任务是使用 shader 实现：

1. 线性渐变
2. 径向渐变
3. 进度条

环境预设

搭建一个场景，存在这样的一个 Cube:

一个 Cube 有 6 个面，考虑每个面渲染一个图像，主要工作在顶点着色器上，我们预先写下一个板子：

Shader "Unlit/NewUnlitShader"
{
    Properties
    {
        _MainTex ("Texture", 2D) = "white" { }
    }
    SubShader
    {
        Tags { "RenderType" = "Opaque" }
        LOD 100

        Pass
        {
            HLSLPROGRAM
            #pragma vertex vert
            #pragma fragment frag
            // make fog work
            #pragma multi_compile_fog

            #include "UnityCG.cginc"

            struct v2f
            {
                float2 uv : TEXCOORD0;
                UNITY_FOG_COORDS(1)
                float4 vertex : SV_POSITION;
                float3 worldNormal : NORMAL;
            };

            sampler2D _MainTex;
            float4 _MainTex_ST;

            v2f vert(appdata_base v)
            {
                v2f o;
                o.vertex = UnityObjectToClipPos(v.vertex);
                o.uv = TRANSFORM_TEX(v.texcoord, _MainTex);
                UNITY_TRANSFER_FOG(o, o.vertex);
                o.worldNormal = UnityObjectToWorldNormal(v.normal);
                return o;
            }

            fixed4 linear_gradient(float2 uv, float4 color1, float4 color2)
            {
            }

            fixed4 radial_gradient(float2 uv, float4 color1, float4 color2)
            {
            }

            fixed4 progress_bar(float2 uv, float4 color, float percentage)
            {
            }

            fixed4 frag(v2f i) : SV_Target
            {
                float3 normal = normalize(i.worldNormal);
                float time = abs(sin(_Time.y));
                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))
                + 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))
                + step(0.5, dot(normal, float3(0, 0, -1))) * progress_bar(i.uv, float4(0.0, 1.0, 0.0, 0.0), time);
                // apply fog
                UNITY_APPLY_FOG(i.fogCoord, col);
                return col;
            }
            ENDHLSL
        }
    }
}

工作就变成了实现 linear_gradient 、radial_gradient 和 progress_bar 这三个函数。

线性渐变

考虑最简单的无角度单向渐变，给定两个颜色 color1 和 color2，在一个方形平面内，我们有：

(0,1)     (1,1)
     +

写了那么久，也快一个月了，都是在 QEMU 调试，多没意思。电子人，就是干，火速弄了块 Sipeed 的 LicheeRV Nano，基于 C906 和 A53的 SG2002，不到一够水就有百兆网口和 WiFi。（深圳到广州居然发了两天，真是慢啊，还有这排线还要我自己焊，好傻）

拿到板子，插锭，开机，屏幕没有当然点不亮。电脑上不停的叮咚响，看了下是模拟出了一个串口。那就很简单，直接找到镜像，烧录！再把卡插进去，启动！好了，过了一会，多了一个网卡，ssh一下成功，测试功能正常。那么就开始我们的上板之旅吧！

启动

我们知道，嵌入式 Linux 的启动流程通常是，FSBL -> 固件 -> U-Boot -> 内核，这里的固件就是 OpenSBI。根据 Sipeed 官网的描述，这个片子的启动流程如下：

1. bootrom(bl1) 判断sd卡第一个FAT分区内是否拥有 fip.bin，如果有，则执行2，如果没有，则进入usb烧录模式(提供一个ACM串口从机设备),bl1会初始化uart0，波特率128000
2. 加载fip.bin(bl2)里面的代码到0x0C000000(TPU SRAM)，跳转到bl2,初始化clock,DRAM,执行3
3. 加载opensbi到DRAM，执行，然后加载uboot到DRAM，执行，执行4
4. uboot加载第一个分区内的boot.sd文件到DRAM，如果文件没有问题,跳转到5
5. 跳转到boot.sd内提供的代码(通常是Linux内核)

再看 boot 分区的内容，果然如此：

Mode                 LastWriteTime         Length Name

这是 AbydOS 的第一篇博文。近期在学习操作系统，想着自己搞一个玩玩，结合之前开发嵌入式的经验，以及烂尾了的 RISCV 模拟器工程，选定了带有 OpenSBI 支持的 RISCV64 平台。

本文主要记录工具链和构建系统的选择与调试过程。

开端

既然选定了平台，就开始构建 OpenSBI。根据 OpenSBI 的文档，尝试在 Ubuntu 20.04 (WSL1) 上安装了 gcc-riscv64-unknown-elf 和 qemu-system 等软件包，使用

CROSS_COMPILE=riscv64-unknown-elf- make PLATFORM=generic

编译之，成功了。开跑，

CROSS_COMPILE=riscv64-unknown-elf- make PLATFORM=generic run

，测试 payload 转起来了。

新建文件夹

既然 OpenSBI 编译过了，那就可以新建文件夹了。一开始想，内核的构建比较复杂，OpenSBI 有现成的 Makefile，套娃一个目录结构然后稍微改一下 Makefile，应该可以单独编译 payload，然后再以 payload 为例搭建上层环境。经过一上午的努力，目录结构变成了这样：

AbydOS
  |
  +- kernel
  |     |
  |     +- main
  |          |
  |          +- objects.mk
  |          +- Kconfig
  |          +- test.c
  |          +- test.S
  |          +- test.ldS
  |
  +- platform
  |      |
  |      + qemu-virt
  |            |
  |            +- objects.mk
  |            +- Kconfig
  |            +- platform.c
  |
  +- Kconfig
  +- Makefile

爆改两个小时的 Makefile，终于是成功编译了。

尝试 CMake

改了两个小时的 Makefile，我已经在各种变量和奇怪的命令中晕头转向。这时候，我想到了现代 C++ 工程的神器：CMake。兴奋地写了两句：

cmake_minimum_required(VERSION 3.0.0)
project(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):
[cmake]   The C compiler
[cmake] 
[cmake]     "/usr/bin/riscv64-unknown-elf-gcc"
[cmake] 
[cmake]   is not able to compile a simple test program.
[cmake] 
[cmake]   It fails with the following output:
[cmake] 
[cmake]     Change Dir: /home/wsl/AbydOS/build/CMakeFiles/CMakeTmp
[cmake]     
[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
[cmake]     make[1]: Entering directory '/home/wsl/AbydOS/build/CMakeFiles/CMakeTmp'
[cmake]     Building C object CMakeFiles/cmTC_164d0.dir/testCCompiler.c.o
[cmake]     /usr/bin/riscv64-unknown-elf-gcc    -o CMakeFiles/cmTC_164d0.dir/testCCompiler.c.o   -c /home/wsl/AbydOS/build/CMakeFiles/CMakeTmp/testCCompiler.c
[cmake]     Linking C executable cmTC_164d0
[cmake]     /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_164d0.dir/link.txt --verbose=1
[cmake]     /usr/bin/riscv64-unknown-elf-gcc      -rdynamic CMakeFiles/cmTC_164d0.dir/testCCompiler.c.o  -o cmTC_164d0 
[cmake]     riscv64-unknown-elf-gcc: error: unrecognized command line option '-rdynamic'

于是上网开搜，一看 unknown-elf 工具链没有 crt，肯定不支持 '-rdynamic'，总共有两种解决方案：

1. 加入两个命令行参数：-DCMAKE_C_COMPILER_WORKS:STRING=1 -DCMAKE_CXX_COMPILER_WORKS:STRING=1，绕过检查
2. 换工具链

考虑到绕过 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。（注意这个坑点！）

由于 QEMU 的手册没有明确内存空间分布，所以 kernel 的起始地址我设成了 0 ，然后使用 -fPIC 参数编译。这样一来，理论上，无论内核被加载到哪里，都应该能够正常跑。搞不定，觉得可能是编译参数不对，改了半天的编译参数，试图去掉自动添加的 '-rdynamic'，无果。（后来明确，这个参数并不指示编译器动态链接）。一天就这样过去了。

第二天，继续修改。由于 ELF 中有 .dynamic 和 。rela.* 段，怀疑是需要重定位，从 OpenSBI 里面抄了一段重定位的汇编代码，再次编译，还是不行。实在没辙了，上 gdb-multiarch 调试，才发现固件运行的地址不是 0x0，不能正常调。找了半天，终于在 OpenSBI 的 platform/generic/objects.mk 里面看到：

FW_TEXT_START=0x80000000
FW_DYNAMIC=y
FW_JUMP=y
ifeq ($(PLATFORM_RISCV_XLEN), 32)
  # This needs to be 4MB aligned for 32-bit system
  FW_JUMP_OFFSET=0x400000
else
  # This needs to be 2MB aligned for 64-bit system
  FW_JUMP_OFFSET=0x200000
endif

这样看，最终运行地址就是 0x80000000 + 0x200000，（

实际上这个值在 OpenSBI 的调试信息就有输出：

Domain0 Next Address      : 0x0000000080200000
Domain0 Next Arg1         : 0x0000000082200000
Domain0 Next Mode         : S-mode

)，这样就直接链接脚本改起始地址到 0x80200000，再编译测试，原来跑不通的 fw_jump 固件也正常了。

自此，上 gdb ，就可以正常 debug 了。看了 test_args 的地址，是 0x80203028，和 ELF 中指示的 .data 段范围一致，再 print 一下，就是 0x0 ! 再上 IDA , 这次它的值不是 0x1000 了，而是 0x100401000，一个很怪异的值。看到.rodata段对应地址是 0x80201000，计算器启动，得到 0x100401000 - 0x80201000 = 0x80200000，正好是内核起始地址。于是怀疑全局指针没设对，但是转念想，我都 -fPIC了，寻址应该没有问题，调试出来的 test_args 地址和 IDA 看到的也一致。

这时候想起直接看 ELF 的值了，7z 解压 .data 段， Hex Editor 一看，这TM写的就是0！还是工具链的锅！于是改回 unknown-elf，跳过了 CMake 的编译器检查，终于是 Configure 过了。尝试编译，还是卡在 '-rdynamic' 上，这问题没有根本解决。看报错知道是链接参数的锅，这个链接参数又是 CMake 加上去的，一顿搜索之后找到了 CMake 的一个提交历史，清晰地显示了：

 # We pass this for historical reasons.  Projects may have
  # executables that use dlopen but do not set ENABLE_EXPORTS.
  set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-rdynamic")

这样就知道参数从哪里来了。直接在工程的配置里面重写：

# get rid of '-rdynamic'
set(CMAKE_STATIC_LINKER_FLAGS " ")
set(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS "")
set(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")

这样再配置和编译，就顺利通过了。

善后工作

配置好了构建系统和工具链，就该考虑 C++ 支持了。还是老办法，既然 C 的环境由 ASM 初始化，那么 C++ 环境就可以由 C 来初始化。根据经验，只需使用 extern "C" 修饰函数 k_main，然后就可以在 C 里面调用之，之后在 k_main 里面就可以完全使用 C++ 写了。

实践确实如此，不过写了类测试，发现加上析构函数之后编译不过，爆链接错误，链接到了一个叫做 _UnWind_Resume 的函数，在 libstdc++ 里面。想到C++ 的异常捕获机制，析构时会捕获异常，这里没有捕获异常的环境，于是加入 -fno-exceptions参数，再编译就过了。

经过这样的配置，不到 60 行的 CMakeLists，支持了 C++ 写内核，真是太舒服啦！语法特性完全都是可用的！

后记

这个配置花了两天多的时间才完成，太痛苦啦！

今天在 QEMU 的源码 查到了设备内存布局：

static const MemMapEntry virt_memmap[] = {
    [VIRT_DEBUG] =        {        0x0,         0x100 },
    [VIRT_MROM] =         {     0x1000,        0xf000 },
    [VIRT_TEST] =         {   0x100000,        0x1000 },
    [VIRT_RTC] =          {   0x101000,        0x1000 },
    [VIRT_CLINT] =        {  0x2000000,       0x10000 },
    [VIRT_ACLINT_SSWI] =  {  0x2F00000,        0x4000 },
    [VIRT_PCIE_PIO] =     {  0x3000000,       0x10000 },
    [VIRT_PLATFORM_BUS] = {  0x4000000,     0x2000000 },
    [VIRT_PLIC] =         {  0xc000000, VIRT_PLIC_SIZE(VIRT_CPUS_MAX * 2) },
    [VIRT_APLIC_M] =      {  0xc000000, APLIC_SIZE(VIRT_CPUS_MAX) },
    [VIRT_APLIC_S] =      {  0xd000000, APLIC_SIZE(VIRT_CPUS_MAX) },
    [VIRT_UART0] =        { 0x10000000,         0x100 },
    [VIRT_VIRTIO] =       { 0x10001000,        0x1000 },
    [VIRT_FW_CFG] =       { 0x10100000,          0x18 },
    [VIRT_FLASH] =        { 0x20000000,     0x4000000 },                       
    [VIRT_IMSIC_M] =      { 0x24000000, VIRT_IMSIC_MAX_SIZE },
    [VIRT_IMSIC_S] =      { 0x28000000, VIRT_IMSIC_MAX_SIZE },
    [VIRT_PCIE_ECAM] =    { 0x30000000,    0x10000000 },
    [VIRT_PCIE_MMIO] =    { 0x40000000,    0x40000000 },
    [VIRT_DRAM] =         { 0x80000000,           0x0 },                       
};

就这样吧，接着搞 MMU 去喽！

上回说到，通过一点手段，我们成功启用了 C++ 的支持。但是，这样的支持并不完善，我们的内核到目前为止，还没有一个 C 运行库(libc)，更别提 C++ 标准库(libc++)了。这就意味着，所有需要用的函数和类都要手写一份，非常折磨人。所以，引入 C 和 C++ 基础库是接下来要做的事。

嵌入式里边，最常用的 libc 是 newlib, 而 C++ 的实现则可以使用 libsupc++。

动工

之前的编译里边，为了最小化库的引入，我加入了一个编译参数：-nostdlib。这个参数指示 gcc 不要链接标准库。所以要引入标准库，第一步就是把这个参数去掉，但是又不能引入默认的 crt 初始文件，所以还得加上 -nostartfiles，然后测试编译器的支持。很不幸地，我只写了一句：

#include <stdio.h>

然后编译就报错了。一开始，我怀疑是 Include Path 没有设置正确，但是 gcc -v 提示：

Using built-in specs.
COLLECT_GCC=riscv64-unknown-elf-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/riscv64-unknown-elf/9.3.0/lto-wrapper
Target: riscv64-unknown-elf
Configured with: ../configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir='/usr/include' 
--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 
-mcmodel=medany'
Thread model: single
gcc version 9.3.0 ()

这表明默认的 include 目录是 /usr/include ，内存模型是 medany 。到 /usr/include 一看，啥也没有，证明这个包没有附带头文件，更别说预编译的库了。（不愧是裸机工具链，真是全 naked 啊）。

更换工具链

手动编译运行时太麻烦，最容易的解决方案就是换一个相同架构的、带有预编译库的工具链。很快，我找到了 riscv-collab/riscv-gnu-toolchain 这个官方的工具链仓库，它的 Release 有预编译的。兴致冲冲地下载下来，解压、配置，编译，爆！

...
findfp.c:(.text.global_stdio_init.part.0+0x2): relocation truncated to fit: R_RISCV_HI20 against `stdio_exit_handler'
/opt/riscv/lib/gcc/riscv64-unknown-elf/13.2.0/../../../../riscv64-unknown-elf/lib/libc.a(libc_a-findfp.o): in function `__sfp':
findfp.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)
/opt/riscv/lib/gcc/riscv64-unknown-elf/13.2.0/../../../../riscv64-unknown-elf/lib/libc.a(libc_a-findfp.o): in function `__sinit':
findfp.c:(.text.__sinit+0x6): additional relocation overflows omitted from the output
...

这里注意到关键信息是 R_RISCV_HI20 。到这个仓库搜 issue，果然有很多问题都类似，问题指向了工具链附带的库使用的内存模型不对，看配置信息确认是使用了 medlow。关于这两种内存模型的区别，实际上要牵扯到 RISCV 的寻址方式，这里不展开，可以查看这篇博文，这里只要知道 medlow 在 RISCV64 上不能支持我们所设定的内核启动地址 0x80200000。怎么办呢？同样是两种办法，

1. 更改内核启动地址
2. 重新编译一份 medany 的工具链

第一种方案并不具有可行性，因为在目前的大多数 RISCV SoC 上，DRAM 的起始地址是 0x80000000，低于这个地址能存储内核的空间，只能是不一定存在的 Flash 设备，或者预先被映射过的内存。出于兼容性考虑，选择第二种方案。由于官方仓库采用了 Github Actions 进行构建，我正好可以利用这一点，fork 一份仓库然后改一下构建配置就可以了。

经过两个多小时的睡觉，这套工具链终于编译好了。下载下来测试，编译顺利通过。

添加 C printf 的支持

在之前的代码里，我们的输出函数是直接通过 ecall 调用 SBI 的控制台扩展 (DBCN Extension), 没有任何格式化的支持。要使用 printf 输出到控制台，我们要做的就是重写 printf 调用链最底端的输出函数。这时候 newlib 的方便就体现出来了，它的底层总共也只有二十多个 POSIX 的桩函数，只要实现了它们，移植就算完成了。关系到 printf 的桩函数看起来只有一个，那就是：

int _write(int fd, char *buf, int size)

这里的 fd 是文件描述符。简单起见，这里我们可以这样实现：

// Hook with libc
int _write(int fd, char *buf, int size)
{
    sbi_ecall(SBI_EXT_DBCN, SBI_EXT_DBCN_CONSOLE_WRITE, size, (unsigned long)buf, 0, 0, 0, 0);
    return size;
}

直接不管 fd。这样之后，添加一个 printf 的调用，编译，不出意料地，报错了：

sbrk.c:(.text._sbrk+0x14): undefined reference to `end'

这个 sbrk.c 实际上是堆内存分配相关的。这里爆了符号未定义的错误，原因就是我的链接器种没有定义 .heap 段，自然没有提供堆的结束地址。修改链接脚本，在内核末尾添加如下段：

.heap : {
        __heap_start__ = .;
        end = __heap_start__;
        _end = end;
        __end = end;
        KEEP(*(.heap))
        __heap_end__ = .;
        __HeapLimit = __heap_end__;
    }

注意堆区是向上增长的，所以 end = heap_start。这样再编译就过了，测试也正常输出了。

C++: 基础支持

有了 printf，很容易想到 C++ 的 std::cout。按照依赖关系，不难想到 cout 的最终调用仍然是 _write()，所以输出的底层就不用管了。尝试添加如下代码：

std::cout << "Hello!\n";

编译，又爆了 qwq

[build] system_error.cc:(.text.startup._GLOBAL__sub_I__ZSt20__throw_system_errori+0x2): undefined reference to `__dso_handle'
[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'
[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
[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 的解释和解决办法，照着文档补上几个函数：

void *__dso_handle(); 
int __cxa_atexit(void (*f)(void *), void *objptr, void *dso);
void __cxa_finalize(void *f);
void __cxa_pure_virtual();

• 实际还要去除 -ffreestanding 参数，让标准库起作用

然后再编译，过了。测试，哎，你怎么卡死了？GDB 一调，好家伙，直接干到 _start_hang 里了，看来是触发了异常然后重置了，由于原子量标记不为0，汇编代码就跳到挂起循环了。想到 std::cout 需要动态分配内存，但是全局new 和 delete 的 operator 没有显式重载，于是加入:

void *operator new(size_t size)
{
    return malloc(size);
}

void *operator new[](size_t size)
{
    return malloc(size);
}

void operator delete(void *p)
{
    free(p);
}

void operator delete[](void *p)
{
    free(p);
}

但是并不起作用，还是卡死。

C++：异常与栈帧

既然排除了内存分配问题，该考虑的就是异常处理了。如果它抛出了异常，但是没有被正常 catch，那就会直接调用 _exit()，在 gdb 调试中也能看到：

(gdb) backtrace
#0  0x000000008021caba in _exit ()
#1  0x000000008021190e in abort ()
Backtrace stopped: frame did not save the PC

然后就找到了 OSDev 关于 libsupc++ 的异常捕获的说明：

To make use of exception handling, you also have to tell libsupc++ where the .eh_frame section begins. Before you throw any exception: .
Terminate 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 段)：

    .text :
	{
		PROVIDE(_text_start = .);
		*(.entry)
		*(.text)
		*(.text.*)
		*(.gcc.*)
		*(.gcc_except_table.*)
		. = ALIGN(8);
		PROVIDE(_text_end = .);
	}

    .eh_frame :
	{
		PROVIDE(__eh_frame_start = .);
		*(.eh_frame);
	}

    .srodata :
	{
		PROVIDE(_srodata_start = .);
    	*(.srodata.cst16)
    	*(.srodata.cst8)
    	*(.srodata.cst4)
    	*(.srodata.cst2)
    	*(.srodata .srodata.*)
		. = ALIGN(8);
		PROVIDE(_srodata_end = .);
	}

然后猜一下 __register_frame() 的原型，在调用 k_main() 之前先调用：

// Prepare C++ environment
void k_prep_cxx()
{
    // init C++ exceptions
    extern void *__eh_frame_start;
    extern void __register_frame(void *); // not knowing the prototype of __register_frame, guess and OK!
    __register_frame(&__eh_frame_start);
}

这样再编译测试，成功了！

善后：全局构造函数与析构函数

看文档的时候注意到 Calling Global Constructors，想起来我确实没有给全局构造函数啥的划分段，更别提调用了。再次修改链接脚本，增加：

    .init_array :
	{
	  PROVIDE_HIDDEN (_init_array_start = .);
	  KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*)))
	  KEEP (*(.init_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .ctors))
	  . = ALIGN(8);
	  PROVIDE_HIDDEN (_init_array_end = .);
	} 
	
	. = ALIGN(0x1000);

	.fini_array :
	{
	  PROVIDE_HIDDEN (_fini_array_start = .);
	  KEEP (*(SORT_BY_INIT_PRIORITY(.fini_array.*) SORT_BY_INIT_PRIORITY(.dtors.*)))
	  KEEP (*(.fini_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .dtors))
	  . = ALIGN(8);
	  PROVIDE_HIDDEN (_fini_array_end = .);
	}

之后增加两段代码，分别在 k_main() 前后调用这些构造函数和析构函数即可。

typedef void (*__init_func_ptr)();
extern __init_func_ptr _init_array_start[0], _init_array_end[0];
extern __init_func_ptr _fini_array_start[0], _fini_array_end[0];

// kernel init
void k_before_main(unsigned long *pa0, unsigned long *pa1)
{
    printf("\n===== Entered Test Kernel =====\n");
    printf("a0: 0x%lx \t a1: 0x%lx\n", *pa0, *pa1);

    printf("Calling init_array...\n");
    for (__init_func_ptr *func = _init_array_start; func != _init_array_end; func++)
        (*func)();

    // No args, use default
    if (*pa0 == 0)
        *pa0 = (unsigned long)default_args;
}

// kernel exit
void k_after_main(int main_ret)
{
    printf("\nReached target k_after_main, clearing up...\n");

    for (__init_func_ptr *func = _fini_array_start; func != _fini_array_end; func++)
        (*func)();

    printf("===== Test Kernel exited with %i =====\n", main_ret);
}

至此，基础环境就基本搭建完成，异常、内存分配测试基本通过。总耗时：一天！

所有连接到系统上的部件，都可以视为设备，从而并入设备驱动框架统一管理。

但是在现代操作系统中，如果没有 ACPI，如何发现设备呢？主线 Linux 已经给出了答案，利用设备树 (Device Tree) 描述。

在设备树中，我们可以描述平台的特性、外设的接入情况、CPU 和 Memory 的数量，还可以携带配置参数，如命令行参数。

由于树状结构不好存储，所以 Linux 推出了一个工具 DTC (Device Tree Compiler)，用于将设备树源码 (DTS) 编译成扁平化的设备树 (Flattened Device Tree,FDT)，并且提供了一个 libfdt 库进行操作，可以进行增删改查。

本篇记录设备发现、驱动框架搭建和系统参数配置的设计和过程。关于设备树的详细解释，请参阅 Linux设备树 和 设备树的解析 LibFDT。

驱动框架搭建

用 CS 的思维来考虑，设备都存在共同之处，也就可以抽象成一个基类。这里给出定义：

#define DRV_INSTALL_FUNC(V) __attribute__((constructor(V)))

typedef enum
{
    DEV_TYPE_SYS = 1,
    DEV_TYPE_CHAR = 0x80,
    DEV_TYPE_BLOCK,
} dev_type_t;

class DriverBase
{
  public:
  // Returns 1 if driver can handle this device, or 2 for cover-all driver (will stop probing for sub nodes)
    virtual int probe(const char *name, const char *compatible) = 0;
    virtual long addDevice(const void *fdt) = 0; // returns handler
    virtual void removeDevice(long handler) = 0; // unregister device by handler
    virtual dev_type_t getDeviceType() = 0;

    virtual ~DriverBase() = default;
};

通过这样的基类，我们就可以通过 probe() 函数进行设备驱动程序枚举，并在枚举成功时调用 addDevice() 请求驱动程序添加设备，使用 removeDevice() 删除设备。

比如，考虑一个系统根设备驱动，这个设备驱动继承 DriverBase 并重写其中的虚函数：

static void drv_register();

class SysDev : public DriverBase
{
  public:
    int probe(const char *name, const char *compatible) override
    {
        std::string id = name;
        if (id == "chosen") // Node to storage cmdline arguments
            return 2;
        if (id == "" && std::string(compatible).find("riscv") != std::string::npos)
            return 1;
        return 0;
    }

    long addDevice(const void *fdt) override
    {
        return ++hdl_count;
    }
    void removeDevice(long handler) override
    {
    }
    dev_type_t getDeviceType() override
    {
        return DEV_TYPE_SYS;
    }

  private:
    static int hdl_count;
    friend void drv_register();
};

int SysDev::hdl_count = -1;

static DRV_INSTALL_FUNC(200) void drv_register()
{
    static SysDev drv;
    drv.hdl_count = 0;
    DriverManager::addDriver(drv);
    printf("Driver SysRoot installed\n");
}

这里还有一个 drv_register() 函数，用于注册驱动到系统中。

设备发现

无论是 OpenSBI 还是 UBoot ，都将设备树加载到内存中并进行修补，随后通过一个寄存器传递到下一级。我们的系统目前从 OpenSBI 直接跳到内核的 _start 处开始执行，根据其文档，设备树地址通过寄存器 a1 传递。所以我们可以直接从 C 环境下的第二个参数接收设备树地址，并加以解析：

long k_early_boot(const unsigned long hart_id, const void *dtb_addr, void **sys_stack_base)
{

    int ret = fdt_check_header(dtb_addr);
    if (ret != 0)
    {
        puts("[EBOOT] FDT header check failed\n");
        return -1;
    }

    ...

}

这里要明确一点，由于内存的描述也在设备树中，所以我们需要先于 k_cstart() 将设备树解析并正确设置系统栈。这里我们通过修改汇编代码增加一个对 k_early_boot() 的调用，在该函数中调整系统栈底的地址 (sys_stack_base)，并将设备树数据全部转移到不会冲突的系统内存区域，供后续正常环境使用，随后返回到汇编中调整系统栈。这项工作稍后再讲述。

进入 k_main() 之后，我们就可以开始进行设备发现了。定义这样一个驱动管理类：

class DriverManager
{
  public:
    static void addDriver(DriverBase &drv)
    {
        _drvlist.push_back(&drv);
    }
    static void removeDriver(DriverBase &drv);

  protected:
    static int probe(const void *fdt,int node = 0);
    friend int k_main(int argc, const char *argv[]);

  private:
    static std::vector<DriverBase *> _drvlist;
    static char _depth[32];

    static int _try(const void *fdt, int node);
};

其中的 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()：

	/* Setup boot C stack */
	lla	a3, _kernel_end
	lla	a4, _KERNEL_BOOT_STACK_SIZE /* this is fake a address provided from ld */
	add	sp, a3, a4
	lla a3, _sys_stack_base
	REG_S	sp, 0(a3)

	/* Early boot in C */
	lla	a3, _boot_a0
	REG_L	a0, 0(a3)
	lla	a3, _boot_a1
	REG_L	a1, 0(a3)
	lla a2, _sys_stack_base
	call k_early_boot

	bne a0, zero, _start_hang 

_start_warm:
    ...

随后在 k_early_boot 中解析内存节点：

    // Detect system memory size
    ret = fdt_path_offset(dtb_addr, "/memory");
    if (ret < 0)
    {
        puts("[EBOOT] FDT memory node not found\n");
        return -3;
    }

    int regsize = 0;
    const void *memreg = fdt_getprop(dtb_addr, ret, "reg", &regsize);
    if (!memreg || regsize < 16)
    {
        puts("[EBOOT] FDT memory reg invalid\n");
        return -4;
    }

    unsigned long mem_start = be2le64(((const unsigned long *)memreg)[0]);
    unsigned long mem_len = be2le64(((const unsigned long *)memreg)[1]);

    printf("[EBOOT] Memory Range: base= 0x%lx, len= 0x%lx\n", mem_start, mem_len);

• 通过调试发现设备树的数据是大端序的，通过函数简单转换一下即可。

系统命令行参数也包含在设备树中，通过节点 /chosen 下的 bootargs属性提供。所以我们还可以先在这里解析了命令行参数，允许手动指定系统可用内存：

    // Get the kernel command line
    ret = fdt_path_offset(dtb_addr, "/chosen");
    if (ret < 0)
    {
        puts("[EBOOT] FDT chosen node not found\n");
        return -5;
    }
    const void *kcmdline = fdt_getprop(dtb_addr, ret, "bootargs", &regsize);
    if (!kcmdline || regsize < 1)
    {
        puts("[EBOOT] FDT bootargs invalid\n");
        return -6;
    }
    memcpy(kernel_args, kcmdline, regsize);
    puts("[EBOOT] Kernel command line: ");
    puts(kernel_args);

    // Parse Kerenl command line args for memory size (force override if specified in cmdline, only the first one is
    // used!)
    kernel_cmdargc = split_args((char *)kernel_args, kernel_args_array);
    unsigned long mem_len_cmdarg = 0;
    char mem_suffix = 'M';
    for (int i = 0; i < kernel_cmdargc; ++i)
    {
        if (strncmp(kernel_args_array[i], "-mem", 4) == 0)
        {
            if (i < kernel_cmdargc - 1)
            {
                int res = sscanf(kernel_args_array[i + 1], "%ld %c", &mem_len_cmdarg, &mem_suffix);
                if (res == 0)
                {
                    puts("[EBOOT] Invalid memory size specified, skipping\n");
                    mem_len_cmdarg = 0;
                    break;
                }
                if (res == 1)
                {
                    puts("[EBOOT] Memory size specified without suffix, assuming MB\n");
                    mem_len_cmdarg *= 1024 * 1024;
                    break;
                }
                if (res == 2)
                {
                    switch (mem_suffix)
                    {
                    case 'K':
                    case 'k':
                        mem_len_cmdarg *= 1024;
                        break;
                    case 'M':
                    case 'm':
                        mem_len_cmdarg *= 1024 * 1024;
                        break;
                    case 'G':
                    case 'g':
                        mem_len_cmdarg *= 1024 * 1024 * 1024;
                        break;
                    default:
                        puts("[EBOOT] Invalid memory size suffix, skipping\n");
                        mem_len_cmdarg = 0;
                        break;
                    }
                    break;
                }
            }
            else
            {
                puts("[EBOOT] Memory size not specified, skipping\n");
                mem_len_cmdarg = 0;
                break;
            }
        }
    }

随后计算系统栈底：

    k_mem_size = (mem_len_cmdarg > 0) ? mem_len_cmdarg : mem_len;

    *sys_stack_base = (void *)(mem_start + k_mem_size);
    printf("[EBOOT] Set SYS_SP: 0x%lx\n", (unsigned long)*sys_stack_base);

至此，这一部分宣告结束，来一段 Log：

[EBOOT] Memory Range: base= 0x80000000, len= 0x10000000
[EBOOT] Kernel command line:

[EBOOT] Set SYS_SP: 0x90000000

===== Entered Test Kernel =====
a0: 0x0
Calling init_array...
Driver SysMem installed
Driver SysRoot installed
Driver UART8250 installed
cmd args: ''
Finding driver for #0  [riscv-virtio] ... Found! Installing... OK, handler: 1
Finding driver for #100 reserved-memory [] ... Found! Installing... OK, handler: 1
Finding driver for #164 mmode_resv1@80000000 [] ... Failed
Finding driver for #236 mmode_resv0@80040000 [] ... Failed
Finding driver for #312 flash@20000000 [cfi-flash] ... Failed
Finding driver for #420 chosen [] ... Found! Installing... OK, handler: 2
Driver has cover the node with offset: 420
Finding driver for #480 uart@10000000 [ns16550a] ... Found! Installing... OK, handler: 1
Finding driver for #604 test@100000 [sifive,test1] ... Failed
Finding driver for #692 virtio_mmio@10008000 [virtio,mmio] ... Failed
Finding driver for #808 virtio_mmio@10007000 [virtio,mmio] ... Failed
Finding driver for #924 virtio_mmio@10006000 [virtio,mmio] ... Failed
Finding driver for #1040 virtio_mmio@10005000 [virtio,mmio] ... Failed
Finding driver for #1156 virtio_mmio@10004000 [virtio,mmio] ... Failed
Finding driver for #1272 virtio_mmio@10003000 [virtio,mmio] ... Failed
Finding driver for #1388 virtio_mmio@10002000 [virtio,mmio] ... Failed
Finding driver for #1504 virtio_mmio@10001000 [virtio,mmio] ... Failed
Finding driver for #1620 cpus [] ... Failed
Finding driver for #1680 cpu-map [] ... Failed
Finding driver for #1692 cluster0 [] ... Failed
Finding driver for #1708 core0 [] ... Failed
Finding driver for #1748 cpu@0 [riscv] ... Failed
Finding driver for #1900 interrupt-controller [riscv,cpu-intc] ... Failed
Finding driver for #2012 memory@80000000 [] ... Found! Installing... OK, handler: 2
Finding driver for #2084 soc [simple-bus] ... Failed
Finding driver for #2160 pci@30000000 [pci-host-ecam-generic] ... Failed
Finding driver for #2852 interrupt-controller@c000000 [riscv,plic0] ... Failed
Finding driver for #3048 clint@2000000 [riscv,clint0] ... Failed

Reached k_after_main, clearing up...
===== Test Kernel exited with 0 =====

上一篇我们已经搭建好了驱动框架，现在我们来实现三个基础驱动：根设备、内存、串口。

• 注：上一篇后驱动框架有小修小补，请参见相关提交

根设备驱动

根设备并不是一个具体设备，而是设备树的根节点，包含了模组信息和兼容信息，可以根据它区别平台。为了方便起见，我们让根设备驱动一并处理 /chosen 节点，因为平台相关的一些额外参数可以直接这样传入。

首先定义一个基类 (顺便定义一个属性导出宏)：

#define __K_PROP_EXPORT__(name, pri)                                                                                   \
    const auto &name() const                                                                                           \
    {                                                                                                                  \
        return pri;                                                                                                    \
    }

class SysRoot : public DriverBase
{
  public:
    virtual dev_type_t getDeviceType() override
    {
        return DEV_TYPE_SYS;
    }

    __K_PROP_EXPORT__(compatible, _compatible)
    __K_PROP_EXPORT__(model, _model)
    __K_PROP_EXPORT__(stdout_path, _stdout_path)

  protected:
    std::string _compatible;
    std::string _model;
    std::string _stdout_path;
};

实现上，考虑提供一个通用的 fallback 驱动，在不匹配的时候也不会终止内核：

class GenericRoot : public SysRoot
{
  public:
    int probe(const char *name, const char *compatible) override
    {
        std::string id = name;
        if (id == "")
            return DRV_CAP_THIS;
        return DRV_CAP_NONE;
    }

    long addDevice(const void *fdt, int node) override
    {
        int len;
        if (node == 0) // root node
        {
            auto prop = fdt_get_property(fdt, node, "compatible", &len);
            if (!prop)
                _compatible = "Generic";
            else
                _compatible = std::string(prop->data);
            prop = fdt_get_property(fdt, node, "model", &len);
            if (!prop)
                _model = "Generic";
            else
                _model = std::string(prop->data);

            auto rc = fdt_path_offset(fdt, "/chosen"); // property of chosen node may diff on other platform
            if (rc >= 0)
            {
                auto prop = fdt_get_property(fdt, rc, "stdout-path", &len);
                if (prop)
                    _stdout_path = std::string(prop->data);
                DriverManager::markInstalled(fdt, rc, 0, this,DRV_CAP_THIS); // mark as installed

                return 0; // singleton device
            }
        }

        return K_ENODEV;
    }

    void removeDevice(long handler) override
    {
    }
};

可以看到，这里的 probe() 条件是名称为空，按照定义看，只有根节点没有名称。由于我们要一并接管 /chosen 节点，所以在安装时，利用传入的完整 fdt 查找到节点偏移，提取属性后向 DriverManager 报告额外安装的节点，避免再次安装。

内存驱动

理论上，内存是不需要驱动的，但是为了更好地管理系统上的内存，在当前架构下还是引入一个驱动。

内存驱动主要的工作如下：

1. 获取并管理保留内存区、可用内存范围
2. 提供接口，进行非连续内存分配（_sbrk）的底层调用

由于是系统驱动，还是定义一个基类：

class SysMem : public DriverBase
{
  public:
    dev_type_t getDeviceType() override
    {
        return DEV_TYPE_SYS;
    }

    virtual void addReservedMem(uint64_t addr,uint64_t size) = 0;

    __K_PROP_EXPORT__(reservedMem, _mem_rsv);
    __K_PROP_EXPORT__(availableMem, _mem_avail);

    protected:
        std::vector<std::pair<size_t,size_t>> _mem_rsv;
        std::vector<std::pair<size_t,size_t>> _mem_avail;
};

然后提供一个通用实现：

class GenericMem : public SysMem
{
  public:
    int probe(const char *name, const char *compatible) override
    {
        std::string id = name;
        if (id.find("memory") != 0 && id != "reserved-memory")
            return DRV_CAP_NONE;
        return DRV_CAP_COVER;
    }

    long addDevice(const void *fdt, int node) override
    {

        uint64_t address, size;
        if (!_fdt_rsv_mem_parsed)
        {
            // fdt command reserved memory
            int n = fdt_num_mem_rsv(fdt);
            for (int i = 0; i < n; ++i)
            {
                auto rc = fdt_get_mem_rsv(fdt, i, &address, &size);
                if (rc == 0)
                {
                    _mem_rsv.push_back(std::make_pair(address, size));
                    printf("(0x%lx - 0x%lx) ", address, address + size);
                }
            }
            _fdt_rsv_mem_parsed = true;

            // Some mark should be done?
        }

        auto name = fdt_get_name(fdt, node, NULL);
        if (name == std::string("reserved-memory"))
        {

            /* process reserved-memory node */
            auto nodeoffset = fdt_subnode_offset(fdt, 0, "reserved-memory");
            if (nodeoffset >= 0)
            {
                auto subnode = fdt_first_subnode(fdt, nodeoffset);
                while (subnode >= 0)
                {

                    if (fdt_get_node_addr_size(fdt, subnode, 0, &address, &size) >= 0)
                    { // each subnode should have only one addr and size
                        _mem_rsv.push_back(std::make_pair(address, size));
                        printf("(0x%lx - 0x%lx) ", address, address + size);
                    }
                    else
                    {
                        printf("Failed to get reserved memory in #%d\n", subnode);
                    }
                    subnode = fdt_next_subnode(fdt, subnode);
                }
            }
        }
        else
        { // memory node, could have multiple
            for (int i = 0; fdt_get_node_addr_size(fdt, node, i, &address, &size) >= 0; ++i)
            {
                _mem_avail.push_back(std::make_pair(address, size));
                printf("(0x%lx - 0x%lx) ", address, address + size);
            }
        }
        return 0; // Also singleton
    }

    void removeDevice(long handler) override
    {
    }

    void addReservedMem(uint64_t addr, uint64_t size) override
    {
        _mem_rsv.push_back(std::make_pair(addr, size));
    }

  private:
    bool _fdt_rsv_mem_parsed = false;
};

这里要考虑的问题在于，内存驱动在设备树上有多个设备与之对应，当存在平台特定驱动的时候，如果不作任何处理，那就容易导致不同的内存区可 probe() 到的驱动不一致，导致数据分散在多个驱动中。这时候，系统根设备就出场了，它总是能先于其他设备进行 probe()，并且知道兼容信息，我们只需要在系统根设备驱动 probe() 的时候，顺手将不兼容平台的驱动先行删除，保证其后不被 probe() 到。

串口驱动

接下来就是及其硬件的一个简单驱动了，串口驱动。在我们的系统上，参考 Linux 的设计，外设抽象成两种，即块设备和字符设备。这里首先继承 DriverChar：

class Drv_Uart8250 : public DriverChar
{

  private:
    struct uart8250_t
    {
        char *base;
        uint32_t freq;
        uint32_t baud;
        uint32_t reg_width;
        uint32_t reg_shift;
        // uint32_t reg_offset;

        bool opened = false;
    };

    const uint32_t default_freq = 0;
    const uint32_t default_baud = 115200;
    const uint32_t default_reg_shift = 0;
    const uint32_t default_reg_width = 1;
    const uint32_t default_reg_offset = 0;

    int hdl_count = -1;
    std::map<long, uart8250_t> hdl;
};

这里定义一个结构体存储数据。当然，也可以使用外部类的方法，更符合 C++ 的思想。

然后参照 openSBI 的实现，将几个 fdt_helper 函数以及 riscv_io 部分内容 cv 过来，然后定义两个辅助函数：

    static u32 get_reg(const uart8250_t &u, u32 num)
    {
        u32 offset = num << u.reg_shift;

        if (u.reg_width == 1)
            return readb(u.base + offset);
        else if (u.reg_width == 2)
            return readw(u.base + offset);
        else
            return readl(u.base + offset);
    }

    static void set_reg(const uart8250_t &u, u32 num, u32 val)
    {
        u32 offset = num << u.reg_shift;

        if (u.reg_width == 1)
            writeb(val, u.base + offset);
        else if (u.reg_width == 2)
            writew(val, u.base + offset);
        else
            writel(val, u.base + offset);
    }

这两个函数非常简单，就是进行寄存器的读写。后面的所以步骤都利用这两个函数进行 IO。

接着实现设备实例化功能：

long addDevice(const void *fdt, int node) override
    {
        uart8250_t uart;
        uint64_t regsize;
        int len, rc;
        const fdt32_t *val;
        rc = fdt_get_node_addr_size(fdt, node, 0, (uint64_t *)&uart.base, &regsize);

        if (rc < 0 || !uart.base || !regsize)
            return K_ENODEV;

        val = (fdt32_t *)fdt_getprop(fdt, node, "clock-frequency", &len);
        if (len > 0 && val)
            uart.freq = fdt32_to_cpu(*val);
        else
            uart.freq = default_freq;

        val = (fdt32_t *)fdt_getprop(fdt, node, "current-speed", &len);
        if (len > 0 && val)
            uart.baud = fdt32_to_cpu(*val);
        else
            uart.baud = default_baud;

        val = (fdt32_t *)fdt_getprop(fdt, node, "reg-shift", &len);
        if (len > 0 && val)
            uart.reg_shift = fdt32_to_cpu(*val);
        else
            uart.reg_shift = default_reg_shift;

        val = (fdt32_t *)fdt_getprop(fdt, node, "reg-io-width", &len);
        if (len > 0 && val)
            uart.reg_width = fdt32_to_cpu(*val);
        else
            uart.reg_width = default_reg_width;

        val = (fdt32_t *)fdt_getprop(fdt, node, "reg-offset", &len);
        if (len > 0 && val)
            uart.base += fdt32_to_cpu(*val);
        else
            uart.base += default_reg_offset;

        u16 bdiv = 0;

        if (uart.baud)
            bdiv = (uart.freq + 8 * uart.baud) / (16 * uart.baud);

        /* Disable all interrupts */
        set_reg(uart, UART_IER_OFFSET, 0x00);
        /* Enable DLAB */
        set_reg(uart, UART_LCR_OFFSET, 0x80);

        if (bdiv)
        {
            /* Set divisor low byte */
            set_reg(uart, UART_DLL_OFFSET, bdiv & 0xff);
            /* Set divisor high byte */
            set_reg(uart, UART_DLM_OFFSET, (bdiv >> 8) & 0xff);
        }

        /* 8 bits, no parity, one stop bit */
        set_reg(uart, UART_LCR_OFFSET, 0x03);
        /* Enable FIFO */
        set_reg(uart, UART_FCR_OFFSET, 0x01);
        /* No modem control DTR RTS */
        set_reg(uart, UART_MCR_OFFSET, 0x00);
        /* Clear line status */
        get_reg(uart, UART_LSR_OFFSET);
        /* Read receive buffer */
        get_reg(uart, UART_RBR_OFFSET);
        /* Set scratchpad */
        set_reg(uart, UART_SCR_OFFSET, 0x00);

        hdl.insert(std::pair<long, uart8250_t>(++hdl_count, uart));

        // Test send here
        write(hdl_count, "TEST UART8250\n", 14);

        return hdl_count;
    }

关于各个寄存器操作的解释，可以参阅 UART 16650D Datasheet。

实例化解决，把剩下的虚函数补完：

   int probe(const char *name, const char *compatible) override
    {
        std::string id = name;
        if (id.find("uart") == std::string::npos)
            return DRV_CAP_NONE;
        id = compatible;
        return (id == "ns16550" || id == "ns16550a" || id == "snps,dw-apb-uart") ? DRV_CAP_THIS : DRV_CAP_NONE;
    }

    int open(long handler) override
    {

        auto u = hdl.find(handler);
        if (u == hdl.end())
            return K_ENODEV;

        auto &uart = u->second;
        if (uart.opened)
            return K_EALREADY;

        // lock here?
        uart.opened = true;

        printf("UART8250 opened\n");
        return 0;
    }

    int close(long handler) override
    {
        auto u = hdl.find(handler);
        if (u == hdl.end())
            return K_ENODEV;

        auto &uart = u->second;
        if (!uart.opened)
            return K_EALREADY;

        // lock here?
        uart.opened = false;

        printf("UART8250 closed\n");
        return 0;
    }

    int read(long handler, void *buf, int len) override
    {
        auto u = hdl.find(handler);
        if (u == hdl.end())
            return K_ENODEV;

        auto &uart = u->second;

        for (int i = 0; i < len; ++i)
        {
            if (get_reg(uart, UART_LSR_OFFSET) & UART_LSR_DR)
                ((char *)buf)[i] = get_reg(uart, UART_RBR_OFFSET);
            else
                return i;
        }

        // printf("UART8250 read\n");
        return len;
    }

    int write(long handler, const void *buf, int len) override
    {
        auto u = hdl.find(handler);
        if (u == hdl.end())
            return K_ENODEV;

        auto &uart = u->second;

        for (int i = 0; i < len; ++i)
        {
            while ((get_reg(uart, UART_LSR_OFFSET) & UART_LSR_THRE) == 0)
                ;

            set_reg(uart, UART_THR_OFFSET, ((const char *)buf)[i]);
        }

        // printf("UART8250 write\n");
        return 0;
    }

    int ioctl(long handler, int cmd, void *arg) override
    {
        printf("UART8250 ioctl -- not supported\n");
        return 0;
    }

当然这里的 open() 和 close() 也是雏形，没有实质的意义。

编译运行，设备安装的时候就能打印出 "TEST UART8250" 了！

后记

这个驱动移植花了两个多小时，真是不容易。实现了各个资源的管理，下一步就可以考虑 MMU 相关的操作了。

• 实际上，设备的安装目前还分成了两步，先安装系统设备，再安装外设。这是一点小小的更改，以适应启动流程的需要。

内存，即 Memory，是存储计算机运行过程数据的主要部件。不过在操作系统中，内存并不单单是主存，还有各种外设内存等。本文所说的内存布局，主要是指在可寻址空间中的布局，这关系到系统和后面应用程序的运行，是及其重要的。在有内存管理单元 (MMU) 的处理器上，寻址空间可以分为两种类型，即 物理地址空间 (Physical Memory Area, PMA) 和 虚拟地址空间 (Virtual Memory Area, VMA)。通过 MMU 的控制与转换，可以实现有效的隔离和保护，防止非法的内存访问。

本文仅浅读标准手册，未尽之处，敬请参阅标准手册。

RISC-V 的地址空间

根据 The RISC-V Instruction Set Manual Volume II: Privileged Architecture，目前 RV32 可用的物理地址空间为 32 位（或更多），而 RV64 可用的物理地址空间是 64 位。

而虚拟地址空间上，RV32 只有一种模式，即 SV32，对应了 32 位的虚拟地址空间，并且由于 MMU 配置上用的是 22位 的物理页号 (每页 4K, 即 12 位)，能够支持到 34 位的物理地址空间。

但是，RV64 因为地址空间足够大，普通应用可能不需要完全的虚拟地址空间支持，截止 V20211203，一共定义了三种模式，即 SV39, SV48, SV57，分别对应 39 位、48 位、57 位虚拟地址空间。

RISC-V 的 MMU

在标准文档中，MMU 被设计成一个带有 TLB 的硬件模块，实现可配置的从虚拟地址空间到物理地址空间的映射。由于原理相同，所以标准文档只对 SV32 作了详细描述，这里我们也同样先分析 SV32，然后推广到 SV39 等。

略语一览：

• PPN: Physical Page Number, 物理页号
• VPN: Virtual Page Number, 虚拟页号
• PTE: Page Table Entry，页表项
• TLB: Translation Lookaside Buffer, 页表缓存

控制

设计上，RV 的 MMU 由一个 CSR (控制与状态寄存器) 控制，名为 SATP (Supervisor Address Translation and Protection)，并带有专用指令用于刷新 TLB。寄存器字段如图所示：

• 注：这里的 WARL 指的是 CSR 的访问策略，即 Write Any Read Legal。

据标准描述，ASID 即 Address Space Identifier，用于标识不同的地址空间而无需频繁地进行刷新 TLB 操作。PPN 字段填入根页表的物理页号，而 Mode 字段用于标识 MMU 的工作模式，如表所示：

RV32:

| 值 | 名称 | 描述 |
| :

由于大部分的 RV64 SoC 都将 DRAM 放置在 0x80000000 以上，其下的空间保留给 IO，如 QEMU 的 virt，其布局如下：

static const MemMapEntry virt_memmap[] = {
    [VIRT_DEBUG] =        {        0x0,         0x100 },
    [VIRT_MROM] =         {     0x1000,        0xf000 },
    [VIRT_TEST] =         {   0x100000,        0x1000 },
    [VIRT_RTC] =          {   0x101000,        0x1000 },
    [VIRT_CLINT] =        {  0x2000000,       0x10000 },
    [VIRT_ACLINT_SSWI] =  {  0x2F00000,        0x4000 },
    [VIRT_PCIE_PIO] =     {  0x3000000,       0x10000 },
    [VIRT_PLATFORM_BUS] = {  0x4000000,     0x2000000 },
    [VIRT_PLIC] =         {  0xc000000, VIRT_PLIC_SIZE(VIRT_CPUS_MAX * 2) },
    [VIRT_APLIC_M] =      {  0xc000000, APLIC_SIZE(VIRT_CPUS_MAX) },
    [VIRT_APLIC_S] =      {  0xd000000, APLIC_SIZE(VIRT_CPUS_MAX) },
    [VIRT_UART0] =        { 0x10000000,         0x100 },
    [VIRT_VIRTIO] =       { 0x10001000,        0x1000 },
    [VIRT_FW_CFG] =       { 0x10100000,          0x18 },
    [VIRT_FLASH] =        { 0x20000000,     0x4000000 },
    [VIRT_IMSIC_M] =      { 0x24000000, VIRT_IMSIC_MAX_SIZE },
    [VIRT_IMSIC_S] =      { 0x28000000, VIRT_IMSIC_MAX_SIZE },
    [VIRT_PCIE_ECAM] =    { 0x30000000,    0x10000000 },
    [VIRT_PCIE_MMIO] =    { 0x40000000,    0x40000000 },
    [VIRT_DRAM] =         { 0x80000000,           0x0 }, 
};

由此，我们可以简单地将低 2G 空间直接映射，然后将 (可能不连续的) DRAM 从 0x80000000 开始进行映射，最后把 DRAM 的一小部分重映射到 VMA 的高地址空间。如下表所示：

| VMA Start | VMA End | PMA Start | Usage |
| :

一个 CPU 上可能不止一个核心 (Hart)，这些核心在物理上分开，独立运行，但是共享总线和外设。也就是说，它们的物理内存空间是一致的，只不过有自己单独的寄存器和 Cache、MMU。而多线程非常类似，只不过是通过调度的方式实现，将多个线程的寄存器等资源分时复用。在裸机的角度上看，我们可以把多核看成硬件的多线程，并利用类似的技术实现。

核心的启动

在 RISCV 手册中，并没有规定 Hart 的启动顺序。比较通常的做法是，核心全部（近乎）同时从 M-mode 启动，随后 SBI 会通过原子量确定一个启动核心，并且执行初始化。至于 S-mode 中是否同时启动，我并没有明确看到文档指出，所以应该也是 SBI 实现自定义。通过实验，OpenSBI 只会将启动核心带入到 S-mode，其他核心会留在 M-mode 等待。但是，我们仍然有必要通过一个原子量保证 S-mode 初期只有一个核心运行，具体看，就是下面的汇编代码：

_start:
	/* Pick one hart to run the main boot sequence */
	lla	a3, _hart_lottery
	li	a2, 1
	amoadd.w a3, a2, (a3)
	bnez	a3, _start_hang // in case multi core start at the same time

这些代码在入口点立即执行，如果有多个核心，没有抢到控制权的就会跳到 _start_hang 的死循环里。当然，为了兼容性，后面肯定会设置一下中断再睡觉，不然在其他 SBI 上可能没法用。

那么我们如何通过 SBI 启动核心呢？答案是 SBI 的 HSM 扩展，即 Hart State Management。该扩展提供 4 个 ecall 调用，分别对应核心的 启动、（自）停止、状态查询和暂停。如下：

struct sbiret sbi_hart_start(unsigned long hartid,
  unsigned long start_addr,
  unsigned long opaque);

struct sbiret sbi_hart_stop(void);

struct sbiret sbi_hart_get_status(unsigned long hartid);

struct sbiret sbi_hart_suspend(uint32_t suspend_type,
  unsigned long resume_addr,
  unsigned long opaque);

文档说明，可以通过 sbi_hart_start 从指定的 start_addr 启动核心，并且其 a0 = hartid，a1 = opaque。

核心的初始化

基于之前的布局，确定启动其他核心的时机是设备外设驱动安装完成后。此时内存映射和系统栈已经确定，可以确定下一步的所有数据。启动后，执行环境非常原始，需要一点汇编来做初始化工作。

内存映射

核心启动后，其 SATP = 0 和 sstatus.SIE = 0，即 MMU 和中断是关闭的。我们的系统栈是布置在虚拟地址空间的，所以要先启用 MMU。在之前的启动步骤，我们保存了系统 MMU 配置寄存器 (SATP) 的值，我们将在所有核心上使用同样的映射。所以内存映射非常简单，只需将保存的值写入 satp 后，刷新 TLB 即可：

_start_hart:
    /* a0: hartid a1: reserved */
	lla   a2, _sys_satp
	REG_L a2, 0(a2)
	csrw  CSR_SATP, a2
	sfence.vma zero, zero

核心系统栈的设定

在前面的步骤，我们确定了系统栈的空间，这里要根据 hart id，通过简单的乘法得到核心系统栈基址。如下：

	/* Setup system stack base according to hart_id as offset */
	lla a3, _sys_stack_base
	REG_L sp, 0(a3)
	li  a2, K_CONFIG_STACK_SIZE
	mul a3, a0, a2
	sub sp, sp, a3

理论上，这里开始就可以进入 C++ 了，但是不要忘记一件事，就是 libc 的上下文还没解决。

多核下 Newlib 的上下文

可重入函数

在 newlib 中，几乎所有函数都提供了两个版本，即不可重入的普通版本（ANSI），以及可重入的版本。不可重入的版本，其最终还是调用了可重入版本的函数，不过传入了一个全局重入结构。例如，printf:

不可重入版：

int	printf (const char *__restrict, ...)
               _ATTRIBUTE ((__format__ (__printf__, 1, 2)));

可重入版：

int	_printf_r (struct _reent *, const char *__restrict, ...)
               _ATTRIBUTE ((__format__ (__printf__, 2, 3)));

可以注意到，可重入版本多了一个 _reent 结构体，其在 <sys/reent.h> 定义，一并定义了全局的：

/*
 * All references to struct _reent are via this pointer.
 * Internally, newlib routines that need to reference it should use _REENT.
 */

#ifndef __ATTRIBUTE_IMPURE_PTR__
#define __ATTRIBUTE_IMPURE_PTR__
#endif

extern struct _reent *_impure_ptr __ATTRIBUTE_IMPURE_PTR__;

#ifndef __ATTRIBUTE_IMPURE_DATA__
#define __ATTRIBUTE_IMPURE_DATA__
#endif

extern struct _reent _impure_data __ATTRIBUTE_IMPURE_DATA__;

/* #define _REENT_ONLY define this to get only reentrant routines */

#if defined(__DYNAMIC_REENT__) && !defined(__SINGLE_THREAD__)
#ifndef __getreent
  struct _reent * __getreent (void);
#endif
# define _REENT (__getreent())
#else /* __SINGLE_THREAD__ || !__DYNAMIC_REENT__ */
# define _REENT _impure_ptr
#endif /* __SINGLE_THREAD__ || !__DYNAMIC_REENT__ */

#define _REENT_IS_NULL(_ptr) ((_ptr) == NULL)

#define _GLOBAL_REENT (&_impure_data)