更新时间：2024/01
一年前，心血来潮买了几块Radxa Zero，觉得很有意思，可惜最近想升级到新的系统之后就出了问题，刷机挣扎了好几天，官方文档也已经各种过时了，于是决定记录一下踩坑的过程。
Radxa Zero有自带eMMC和不带eMMC两个版本，两个版本使用sd卡运行系统都是ok的，但是如果想将系统刷入eMMC并用eMMC进行引导，就很容易遇到u-boot无法引导的问题。网上有很多讨论，但是大多都已经过时了，官方提供的troubleshooting guide也非常的模糊，提供的u-boot更新依然有问题，即便是成功更新了u-boot，也有可能重启之后u-boot的patch就又失效了。在经过了一周的挣扎之后，以下是我找到的能用的方法。
（以下内容已经整合进《SONiC入门指南》的 BGP路由变更下发 一节中。）
在上一篇中，我们介绍了BGP路由变更的工作流中从bgpd到fpmsync的部分，本篇我们将继续介绍剩下的BGP路由变更的下发流程。
当FRR变更内核路由配置后，SONiC便会收到来自Netlink和FPM的通知，然后进行一系列操作将其下发给ASIC，其主要流程如下：
sequenceDiagram
autonumber
participant K as Linux Kernel
box lightyellow bgp容器
participant Z as zebra
participant FPM as fpmsyncd
end
box pink database容器
participant R as Redis
end
box lightblue swss容器
participant OA as orchagent
end
box lightgreen syncd容器
participant SD as syncd
end
participant A as ASIC
K->>FPM: 内核路由变更时通过Netlink发送通知
Z->>FPM: 通过FPM接口和Netlink<br/>消息格式发送路由变更通知
FPM->>R: 通过ProducerStateTable<br/>将路由变更信息写入<br/>APPL_DB
R->>OA: 通过ConsumerStateTable<br/>接收路由变更信息
OA->>OA: 处理路由变更信息<br/>生成SAI路由对象
OA->>SD: 通过ProducerTable<br/>或者ZMQ将SAI路由对象<br/>发给syncd
SD->>R: 接收SAI路由对象，写入ASIC_DB
SD->>A: 通过SAI接口<br/>配置ASIC（以下内容已经整合进《SONiC入门指南》的 BGP工作流 ，BGP命令实现和BGP路由变更下发 三节中。）
BGP可能是交换机里面最常用，最重要，或者线上使用的最多的功能了。这一篇，我们就来深入的看一下BGP相关的工作流。
SONiC使用FRRouting作为BGP的实现，用于负责BGP的协议处理。FRRouting是一个开源的路由软件，支持多种路由协议，包括BGP，OSPF，IS-IS，RIP，PIM，LDP等等。当FRR发布新版本后，SONiC会将其同步到SONiC的FRR实现仓库：sonic-frr中，每一个版本都对应这一个分支，比如frr/8.2。
FRR主要由两个大部分组成，第一个部分是各个协议的实现，这些进程的名字都叫做*d，而当它们收到路由更新的通知的时候，就会告诉第二个部分，也就是zebra进程，然后zebra进程会进行选路，并将最优的路由信息同步到kernel中，其主体结构如下图所示：
1 | +----+ +----+ +-----+ +----+ +----+ +----+ +-----+ |
（以下内容已经整合进《SONiC入门指南》的 SAI介绍 和 Syncd-SAI工作流 两节中。）
Syncd容器是SONiC中专门负责管理ASIC的容器，其中核心进程syncd负责与Redis数据库沟通，加载SAI并与其交互，以完成ASIC的初始化，配置和状态上报的处理等等。
由于SONiC中大量的工作流最后都需要通过Syncd和SAI来和ASIC进行交互，所以这一部分也就成为了这些工作流的公共部分，所以，在展开其他工作流之前，我们先来看一下Syncd和SAI是如何工作的。
在看完事务层和数据链路层之后，我们来继续我们的协议栈之旅吧！这一篇中，我们会来看看PCIe物理层（Physical Layer）是如何工作的，从而帮助我们更加深入的了解PCIe的数据传输。
当数据链路层将上层数据封装好后，就会将其交给物理层进行传输。而物理层的主要目的将数据转换为易于介质传输的电信号，并发送出去，或者将接收到的转换后的信号，转变为上层能处理的数据包。其主要结构如下：
在上一篇中，我们介绍了PCIe设备的配置空间，及其设计的目的，最后我们说到了消息路由的设计。所以，这一篇我们就继续这个话题，来看看PCIe设备之间的通信方式吧。
PCIe是以包（Packet）为单位传输数据的。和计算机网络类似，其协议也是分层的。其协议栈主要分为三层：物理层（Physical Layer），数据链路层（Data Link Layer）和事务层（Transaction Layer），如下图所示：
在上一篇中，我们简单的介绍了PCIe的总体架构，设备树和主要组成部分，并且了解了如何通过lspci命令和Windows下的设备管理器来查看PCIe的系统结构。这一篇，我们来更加深入的看看PCIe中的设备相关的信息，如配置空间，来帮助我们了解PCIe和这些命令的工作原理。
理解PCIe的关键，我个人觉得是理解内存的访问。这里先小小的剧透一下，PCIe中主要定义了4种请求：Memory Transaction，I/O request，Configuration Space Access和Message。除了最后一种以外，其余三种全都是基于内存访问的，甚至连中断发起都是基于内存访问的，所以如果我们能很好的理解内存的访问，我们就能很好的理解PCIe。
PCIe的全称是Peripheral Component Interconnect Express，是一种用于连接外设的总线。它于2003年提出来，作为替代PCI和PCI-X的方案，现在已经成了现代CPU和其他几乎所有外设交互的标准或者基石，比如，我们马上能想到的GPU，网卡，USB控制器，声卡，网卡等等，这些都是通过PCIe总线进行连接的，然后现在非常常见的基于m.2接口的SSD，也是使用NVMe协议，通过PCIe总线进行连接的，除此以外，Thunderbolt 3 [2]，USB4 [3]，甚至最新的CXL互联协议 [4]，都是基于PCIe的！
所以一旦开始往设备相关的开发上面走了之后，PCIe可以算是一个绕不过的坎。这几天看了一些和PCIe相关的资料，这里简单的总结一下，也希望对大家有所帮助。这篇文章主要会聚焦在硬件的部分，和操作系统本身没有什么太大的关系，无论是Windows还是Linux，底层的部分都是非常类似的，文章中也会提到调试的方法，不过会主要以Linux为主。
那我们就开始吧！
Hexo虽然可以通过一些方法来支持MathJax，比如next主题或者Hexo Filter MathJax，但是它们都提到了默认renderer的兼容性问题，并且说最好是换成pandoc，不过我切换成pandoc之后所有的页面渲染却全都失败了……整个博客都瘫痪了，正当我快放弃的时候，突然发现hexo-renderer-markdown-it好像兼容的还不错，所以遇到了类似问题的小伙伴，可以也试一试这个～
以下是一些常用的测试和效果：
_会被hexo-renderer-marked转义导致失败：
$\epsilon_0$：$\epsilon_0$*会被转义导致失败
$\begin{eqnarray*}\nabla\cdot\vec{E}&=&\frac{\rho}{\epsilon_0}\end{eqnarray*}$：$\begin{eqnarray*}\nabla\cdot\vec{E}&=&\frac{\rho}{\epsilon_0}\end{eqnarray*}$$\frac{\partial}{\partial t}$：$\frac{\partial}{\partial t}$这里可以看到，即便是使用"`"包裹的代码，也没有什么问题！挺好～
画数字时序图怎么能没有WaveDrom呢？所以必须整一个！给正在用的Hexo皮肤Next添加了WaveDrom的支持，现在可以在文章中直接使用WaveDrom了！效果如下：