实验小项目招新：物理网卡驱动(华山派、荔枝派、U740、星光二代等)

[chyyuu]

支持各种物理网卡，尽量做到与OS无关

如有兴趣一起来探索，请联系我 yuchen AT tsinghua.edu.cn OR 微信 id chyyuu

[shzy2012]

华山派的以太网卡驱动相关的资料
以太网卡驱动型号叫Cvitek DWMAC
Linux的该网卡驱动在：
https://github.com/sophgo/sophpi-huashan/tree/master/cvi_mmf_sdk/linux_5.10/drivers/net/ethernet/stmicro/stmmac

AliOS的该网卡驱动在：
https://github.com/sophgo/cvi_alios_open/blob/master/components/chip_cv181x/src/drivers/net/ethernet/dw/src/dw_gmac_mars.c

AliOS 中 dw_gmac_dma_regs的定义
https://github.com/sophgo/cvi_alios_open/blob/8f87bb58bc4b84aca2d8202342b7adc9bd64f946/components/chip_cv181x/src/drivers/net/ethernet/dw/include/dw_gmac_mars.h#L38

[elliott10]

ArceOS for RISCV硬件驱动开发: 华山派, 星光派2, 荔枝派, sifive fu740
https://github.com/rcore-os/arceos/discussions/120

[shzy2012]

dw 网卡驱动运行后，中断报错接受 buffer 不可用
原因：是 MMU 页表配置问题，收发描述符必须是 no cacheable 属性的，否则就会出现这个错误。此时读写当前主机接受 buffer 地址寄存器（偏移地址：0x1054），会出现一个随机值，而这个随机值就是 cache 中存储的内容。

[shzy2012]

参考陈乐同学之前在ArceOS上的工作把cvitek-nic的框架搭建好了，
代码仓库：https://github.com/zxgsn/arceos/tree/cvitek-nic
DMA定义：https://github.com/zxgsn/arceos/blob/cvitek-nic/crates/cvitek-nic/src/cvitek_defs.rs

[shzy2012]

MAC寄存器组 与 DMA寄存器组：
以太网控制器（Ethernet Controller）通常具有一组寄存器，用于配置、控制和监视以太网通信。这些寄存器用于设置通信参数、启动数据传输、处理中断等。在以太网控制器中，通常会涉及两个重要的寄存器组：MAC寄存器组和DMA寄存器组。

1. MAC寄存器组：
   MAC寄存器组用于配置和控制以太网通信的数据链路层，即MAC层。这些寄存器允许你设置MAC地址、帧过滤、帧生成和解析规则、流控制等参数。一些常见的MAC寄存器包括：

   • MAC地址寄存器：用于配置设备的MAC地址。
   • 控制寄存器：包括启动和停止MAC传输、设置全双工/半双工模式等控制位。
   • 帧过滤寄存器：用于配置哪些帧将被接收或过滤。
   • 帧计数器：用于统计接收和发送的帧数量。
   • 流控制寄存器：用于配置流控制参数，如PAUSE帧。

2. DMA寄存器组：
   DMA寄存器组用于配置和控制直接内存访问（DMA）操作，用于高速数据传输，减轻CPU的负担。DMA负责将数据从内存传输到以太网控制器或反之。一些常见的DMA寄存器包括：

   • 控制寄存器：用于启动和停止DMA传输、配置传输方向、设置传输模式等。
   • 地址寄存器：用于指定源地址和目的地址。
   • 数据计数寄存器：用于指定要传输的数据长度。
   • 状态寄存器：用于监视DMA传输的状态和中断。

这些寄存器组的具体细节和功能可能因不同的以太网控制器而有所不同。在进行以太网控制器编程时，你需要查阅硬件厂商提供的文档，了解具体的寄存器布局和功能，以便正确地配置和操作以太网控制器。

[shzy2012]

网卡驱动技术实现：

[shzy2012]

Dwmac介绍

"DWmac" 是指 "DesignWare MAC"，它是Synopsys公司推出的一种网络接口控制器IP（Intellectual Property），用于在嵌入式系统中实现以太网（Ethernet）功能。DWmac IP是用于集成到SoC（System on Chip）中的一个IP核，帮助系统在物理层和数据链路层实现以太网通信。

DWmac提供了一个高度可配置和可定制的以太网MAC控制器，可以适配不同的以太网标准和速率。它支持多种操作模式和功能，例如全双工和半双工传输、自动重传请求（ARQ）、流控制等，以支持数据在网络中的可靠传输。

DWmac通常用于嵌入式系统中，这些系统可能包括嵌入式处理器、FPGA（Field-Programmable Gate Array）等。它为这些系统提供了可靠的网络连接功能，使得设备能够通过以太网与其他设备或网络进行通信。

总之，DWmac是一种以太网控制器IP，由Synopsys公司提供，用于嵌入式系统中实现以太网通信功能。这是一种常见的解决方案，用于在嵌入式系统中集成网络连接能力。

[shane-ss]

你好老师，我最近正在学习dwmac控制器。请问关于dwmac ip核的数据手册可以从哪里获得呢。目前我使用的是RK3568进行学习，但是Rk3568的数据手册中并没有关于GMAC的dma通道的寄存器相关的说明。

[shzy2012]

PHY芯片 与 DWMAC 的关系？
PHY芯片（Physical Layer Integrated Circuit）和DWMAC（DesignWare MAC）是网络通信中两个不同层次的组件，它们分别负责物理层和数据链路层的功能。它们在网络通信中密切合作以实现完整的通信。

1. PHY芯片：
   PHY芯片位于网络通信的物理层，它负责将数字信号转换为适合在物理媒介上传输的模拟信号（调制），以及将接收到的模拟信号转换回数字信号（解调）。PHY芯片还负责时钟同步、信号增强和抑制噪声等任务。在以太网中，PHY芯片通常与特定的传输媒介（如双绞线、光纤）以及特定的传输速率和标准（如100BASE-TX、1000BASE-T）相关联。

2. DWMAC：
   DWMAC是Synopsys公司提供的一个以太网MAC（Media Access Control）控制器的IP核。MAC层位于数据链路层，负责控制数据在局域网内的传输，实现多台设备之间的数据帧发送和接收。DWMAC提供了适用于不同类型的以太网（如以太网、Fast Ethernet、Gigabit Ethernet）的控制功能，包括数据帧的生成、解析、发送和接收。

关系：
在一个完整的以太网通信链路中，PHY芯片和DWMAC密切合作以实现数据的可靠传输。PHY芯片负责将数字信号转换为物理信号，并通过物理媒介传输，而DWMAC负责在MAC层管理数据的流动和控制数据帧的发送和接收。两者协同工作，使得数据能够从应用层经过各层的处理（包括传输、帧生成、解析等），最终在网络中进行传输和交换。

[shzy2012]

DWMAC与Ethernet MAC的关系？
DWMAC（DesignWare MAC）是Synopsys公司提供的一个以太网MAC（Media Access Control）控制器的IP核，用于在嵌入式系统中实现以太网通信功能。而Ethernet MAC是一般性的术语，指的是实现以太网通信的MAC层功能，是网络通信中的一部分。

具体来说，DWMAC是一种特定的以太网MAC控制器的实现，由Synopsys公司提供。它提供了各种功能，例如帧生成、解析、流控制、自动协商、错误检测等，以支持数据在局域网内的可靠传输。

所以，DWMAC可以被视为Ethernet MAC的一种实现，它在特定的硬件平台上提供了以太网的MAC层功能。Ethernet MAC则是一个更一般的术语，指的是用于在局域网中管理数据链路层通信的一类功能，而不涉及特定的硬件实现。

[shzy2012]

实现网卡驱动的两个关键的步骤：

1. 处理网卡相关的寄存器
2. 找OS申请一块内存给dma用于数据传输

[shzy2012]

DMA映射是什么？

DMA映射（DMA Mapping）是一种将内存区域与外部设备之间建立映射关系的过程，以便直接内存访问（DMA）控制器能够在设备和内存之间高效地传输数据，而无需CPU的干预。这种技术允许数据在设备和内存之间进行快速、无缝的传输，提高了系统性能和数据传输效率。

DMA映射通常涉及以下步骤：

1. 分配内存区域：
   首先，需要分配一块内存区域，用于存储要传输的数据。这个内存区域需要在物理内存中连续，以便DMA控制器能够有效地进行数据传输。

2. 建立映射关系：
   在建立DMA传输之前，需要将外部设备的地址空间与分配的内存区域之间建立映射关系。这可以通过操作系统提供的API函数或硬件相关的方式来实现。

3. 配置DMA控制器：
   接下来，需要配置DMA控制器，指定数据传输的源地址和目的地址，以及要传输的数据长度。DMA控制器将根据这些配置进行数据传输。

4. 启动DMA传输：
   一旦DMA控制器被配置好，可以通过设置控制寄存器或调用相应的函数来启动DMA传输。DMA控制器将自动从外部设备读取数据或将数据发送到外部设备，而不需要CPU的直接干预。

5. 数据传输：
   DMA控制器根据配置进行数据传输，将数据从内存复制到外部设备或从外部设备复制到内存。这样可以实现高速、高效的数据传输，减少了CPU的负担。

6. 传输完成和中断处理：
   DMA传输完成后，DMA控制器通常会触发一个中断信号，通知CPU传输已经完成。CPU可以根据中断来执行后续的操作，如数据处理或其他操作。

总之，DMA映射是一种通过建立内存和外部设备之间的映射关系，实现高速数据传输的技术。这在需要大量数据传输的应用中特别有用，可以显著提高系统性能和数据传输效率。

[shzy2012]

DMA与DMAC的关系？

1. DMA (Direct Memory Access)：
   DMA 是指 "直接内存访问"，是一种计算机系统中的数据传输技术，允许外部设备在不需要CPU干预的情况下与内存进行数据传输。DMA控制器负责管理数据的传输，从而减轻了CPU的负担，提高了数据传输效率。DMA通常涉及配置寄存器，以指定传输参数、源地址、目的地址和数据长度等。

2. DMAC (Direct Memory Access Controller)：
   DMAC 是指 "直接内存访问控制器"，是负责管理DMA操作的硬件组件。DMAC是一个专用的硬件单元，用于配置、启动、控制和监视DMA传输。它可以根据预设的参数自动完成数据传输，而无需CPU的干预。DMAC通常包含一组寄存器，用于配置传输参数、源地址、目的地址、数据长度等。

总结来说，DMA是一种技术，用于实现外部设备与内存之间的数据传输，而DMAC是负责管理和控制DMA操作的硬件组件。DMAC通过配置寄存器来控制DMA传输，从而在数据传输方面提供高效率和低CPU干预。

[shzy2012]

华山派DMAC 特点如下:

• 最大可同时建立 8 个 DMA 通道。
• 传输的数据来源与数据目的， 皆可设置为内存或设备。
• 只允许单向传输配置。
• 供 DMA 传输暂停、恢复、取消。
• 支持 DMA Burst 长度配置。
• 供 DMA 通道优先等级配置。
• 当通道数据是在设备间传输时，流量控制可交由设备控制。
• 支持硬件链表功能。
• 支持通道上锁，在上锁通道未完成前的其他通道请求会被忽略。

DMAC 硬件控制流程示意图：

[shzy2012]

DMA通道（DMA Channel）是在DMA控制器中用于执行数据传输的逻辑通路或路径。每个DMA通道可以独立地配置和管理数据传输，允许同时执行多个数据传输操作，从而提高系统的数据传输效率。

在一个DMA控制器中，通常会有多个DMA通道可供使用，每个通道都具有一组相关的寄存器和控制逻辑，用于配置和控制数据传输。每个DMA通道可以配置为不同的传输方向、源地址、目的地址、数据长度等，以适应不同的数据传输需求。

使用DMA通道的优点包括：

1. 并行数据传输：多个DMA通道可以同时执行数据传输，从而允许系统并行地传输多个数据块，提高了数据传输效率。

2. 降低CPU负担：DMA通道的使用可以减轻CPU在数据传输过程中的干预。CPU只需要配置DMA通道并启动传输，然后可以继续执行其他任务，从而提高系统的并发性。

3. 高效数据流动：通过使用多个DMA通道，数据在内存和外设之间可以高效地流动，从而降低了数据传输的延迟。

4. 支持不同数据流：不同的DMA通道可以用于不同类型的数据传输，例如音频数据、图像数据和控制数据，从而提供更大的灵活性。

当需要在系统中实现多个数据传输任务时，使用DMA通道是非常有用的。通常，每个DMA通道都会有一组寄存器，用于配置通道的传输参数、源地址、目的地址和数据长度，以及其他控制选项。这样，系统可以同时管理多个数据传输操作，而不会牵涉到每个传输的详细设置。

[shzy2012]

网卡工作原理

1、网卡的基本机构

网卡包含7个功能模块分别是：

• CU（Control Unit，控制单元）
• OB（Output Buffer，输出缓存）
• IB（Input Buffer，输入缓存）
• LC（Line Coder，线路编码器）
• LD（Line Decoder，线路解码器）
• TX（Transmitter，发射器）
• RX（Receiver，接收器）

数据发送路径：OB->LC->TX
数据接受路径：RX->LD->IB

参考：《网络知识：网卡的基本组成结构和工作原理》 https://zhuanlan.zhihu.com/p/564901837

[shzy2012]

Ethernet MAC（Media Access Control）是以太网中的数据链路层的一个子层，负责控制和管理数据在局域网内的传输。它定义了数据帧的格式、数据的传输方式、帧的生成和解析规则等，以确保多台设备可以在共享的物理媒介上进行有效的通信。

以太网MAC层的主要功能包括：

1. 帧生成和解析：MAC层负责生成以太网数据帧，将数据从上层封装到帧中，并添加必要的控制信息（如目标MAC地址、源MAC地址、帧类型等）。在接收端，MAC层解析接收到的帧，提取数据并将其传递到上层。

2. 帧的发送和接收控制：MAC层控制何时发送数据帧以及何时接收数据帧。它通过一些机制来避免冲突和碰撞，确保多台设备能够在共享的媒介上进行协调的传输。

3. 帧的地址管理：以太网使用MAC地址（也称为物理地址或硬件地址）来唯一标识网络中的每个设备。MAC层负责管理MAC地址，确保每个设备有唯一的地址，并在帧中正确地标识目标和源设备。

4. 帧的流量控制：MAC层可能会实现一些流量控制机制，以避免网络拥塞和数据丢失。例如，基于CSMA/CD（Carrier Sense Multiple Access with Collision Detection）的机制用于检测碰撞并执行退避。

5. 错误检测和纠错：MAC层可以执行一些错误检测和纠错机制，例如CRC（循环冗余校验），以确保数据的完整性。

Ethernet MAC层通常与PHY（Physical Layer）层紧密合作，PHY层负责将数据帧转换为适合在物理媒介上传输的信号，并将接收到的信号转换回数据帧。这两个层级协同工作，实现了以太网通信的各个方面，从数据生成到传输再到接收。

[shzy2012]

华山派 Ethernet PHY 蕊片供一组内建 Ethernet 10/100 Base-TX compliant PHY 接口。

功能描述：

• 支持 IEEE 802.3 10/100 Base-TX compliant.
• 支持传收送速度与全半双工工作模式自动协商功能.
• 支持以太网路线交叉线或直连线自动移动翻转功能.
• 支持以太网路 WOL(Wake on Lan) 功能.

内建 10/100 Ethernet PHY 框图

10/100Mbps 传送及收发功能在标准 category5(CAT5) 双绞线上, 传送接收讯号经由
transformer 连接于 RJ45 标准接口.

[zxgsn]

华山派 ON ArceOS 网卡驱动框架搭建

本文档记录在华山派( CV1811H )上搭建网卡驱动框架的流程

目前能成功初始化网卡并执行 helloworld app

在 qemu 模拟器上执行的结果如下图（选用aarch64 架构是因为我们为了适配华山派，修改了ArceOS 的页表项, 在Riscv64 架构下暂时不能在 qemu 上运行）。

仓库地址

make A=apps/net/cvitek_nic_test ARCH=aarch64 SMP=1 NET=y LOG=info run

run in CV1811:

​ make A=apps/net/cvitek_nic_test ARCH=riscv64 SMP=1 NET=y LOG=info cv1811

初探框架代码

增添网卡驱动框架代码(与网卡驱动具体实现无关)，需要做出一些改动：

apps层

apps/
|
...
|
├── net
│   ├── cvitek_nic_httpserver_test  // httpserver应用
│   │   ├── Cargo.toml
│   │   └── src
│   │       ├── main.rs
│   │       └── ramfs.rs
│   ├── cvitek_nic_test  // helloworld应用, 主要测试网卡驱动框架是否可以跑通
│   │        ├── Cargo.toml
│   │        └── src
│   │        └── main.rs

ulib层

ulib/
|
...
|
└── libax
    ├── build.rs
    ├── Cargo.toml  // 添加 cviteknic 的 feature
    ├── cbindgen.toml
    ├── ctypes.h
    ├── include
    └── src  // 提供一些上层应用使用的接口
        |
        ...
        |
        ├── net
        │   ├── mod.rs
        │   ├── socket_addr.rs
        │   ├── tcp.rs
        │   └── udp.rs
        |
        ...

modules层

modules/
|
...
|
├── axdriver
│   ├── build.rs  // 启用 cviteknic 的 feature
│   ├── Cargo.toml // 添加 cviteknic 的 feature
│   └── src
│       ├── bus
│       │   ├── mmio.rs
│       │   ├── mod.rs
│       │   └── pci.rs
│       ├── cvitek_traits.rs // impl CvitekNicTraits
│       ├── drivers.rs // 增加cviteknic支持
│       ├── dummy.rs
│       ├── lib.rs     // 增加cviteknic支持
│       ├── macros.rs  // 增加cviteknic支持
│       ├── prelude.rs
│       ├── structs
│       │   ├── dyn.rs
│       │   ├── mod.rs
│       │   └── static.rs
│       └── virtio.rs
|
...
|
├── axnet
│   ├── Cargo.toml
│   └── src
│       ├── lib.rs
│       └── smoltcp_impl
│           ├── dns.rs
│           ├── listen_table.rs
│           ├── mod.rs
│           ├── tcp.rs
│           └── udp.rs
├── axruntime
│   ├── Cargo.toml // 添加 cviteknic 的 feature
│   └── src
│       ├── lang_items.rs
│       ├── lib.rs
│       ├── mp.rs
│       └── trap.rs
|
...

crates层

crates/
|
...
│       
├── cvitek-nic // 网卡驱动主要流程的实现
│   ├── Cargo.toml
│   └── src
│       ├── cvitek_defs.rs
│       ├── cvitek_main.rs
│       └── lib.rs
|
...

│      
├── driver_net
│   ├── Cargo.toml // 增加cviteknic支持
│   └── src
│       ├── cvitek // 网卡驱动  // TODO!
│       │   └── mod.rs
│       ├── lib.rs // 增加cviteknic支持
│       └── net_buf.rs
|
...
|
├── driver_virtio
│   ├── Cargo.toml
│   └── src
│       ├── blk.rs
│       ├── gpu.rs
│       ├── lib.rs
│       └── net.rs // 定义了 virtio 网卡驱动

其他文件

Cargo.toml
make_cvitek_nic.sh // 编译脚本

框架代码分析

httpserver 应用 (arceos 文档)

step 1

init

After executed all initial actions, then arceos calls main function in memtest app.

step 2

fn http_server(mut stream: TcpStream) -> io::Result {
    ...
    stream.read(&mut buf)?;
	...
    stream.write_all(reponse.as_bytes())?;
    ...
}

fn accept_loop() -> io::Result {
    let (addr, port) = (IpAddr::from_str(LOCAL_IP).unwrap(), LOCAL_PORT);
    let mut listener = TcpListener::bind((addr, port).into())?;
    ...
    loop {
        match listener.accept() {
            Ok((stream, addr)) => {
                task::spawn(move || match http_server(stream) {
                    Err(e) => error!("client connection error: {:?}", e),
                    Ok(()) => info!("client {} closed successfully", i),
                });
            }
            Err(e) => return Err(e),
        }
        i += 1;
    }
}

#[no_mangle]
fn main() {
    println!("Hello, ArceOS HTTP server!");
    accept_loop().expect("test HTTP server failed");
}

step 2.1

let (addr, port) = (IpAddr::from_str(LOCAL_IP).unwrap(), LOCAL_PORT);
let mut listener = TcpListener::bind((addr, port).into())?;

flow chart

graph TD;
T["libax::net::tcp::TcpStream::bind()"]
T-->A["smoltcp::wire::ip::IpAddr::from_str()"]
T-->B["axnet::smoltcp_impl::tcp::TcpSocket::new()"]
T-->C["axnet::smoltcp_impl::tcp::TcpSocket::bind()"]
T-->D["axnet::smoltcp_impl::tcp::TcpSocket::listen()"]
B-->E["axnet::smoltcp_impl::SocketSetWrapper::new_tcp_socket()"]
E-->F["axsync::mutex< smoltcp::iface::socket_set::SocketSet >"]
F-->G["managed::slice::ManagedSlice< smoltcp::iface::socket_set::SocketStorage >"]
G-->H["smoltcp::iface::socket_meta::Meta + smoltcp::socket::Socket"]
H-->I["SocketHandle + NeighborState"]
H-->J["Raw + Icmp + udp + tcp"]

D-->K["ListenTable: Box< [Mutex< Option< Box< ListenTableEntry > > >] >(tcp)"]
K-->L["ListenTableEntry: VecDeque< SocketHandle >(syn_queue)"]
L-->M["Tcp is a multi-wrapped sync queue of SocketHandle"]

Loading

step 2.2

match listener.accept() {
    Ok((stream, addr)) => {
		...
    }
    Err(e) => return Err(e),
}

flow chart

graph TD;
T["libax::net::tcp::TcpListener::accept()"]
T-->A["axnet::smoltcp_impl::tcp::TcpSocket::accept()"]
A-->B["Mutex< SocketSet >.poll_interfaces()"]
B-->C["axnet::smoltcp_impl::InterfaceWrapper< axdriver::VirtIoNetDev >.poll"]
C-->Z["many things"]
A-->D["axnet::smoltcp_impl::listen_table::ListenTable::accept()"]
D-->E["check the sync queue"]

Loading

step 2.3

stream.read(&mut buf)?;
stream.write_all(reponse.as_bytes())?;

flow chart

graph TD;
    A["impl Read, Write for libax::TcpStream"] --> B["libax::TcpStream::read"]
    A["impl Read, Write for libax::TcpStream"] --> C["libax::TcpStream::write"]
    B --> D["smoltcp_impl::TcpSocket::recv(buf)"]
    C --> E["smoltcp_impl::TcpSocket::send(buf)"]

Loading

可以看到现有ArceOS的网络部分使用了 smoltcp 这个项目, 为了兼容其实现，需要按照smoltcp 提供的 trait 来实现网卡驱动：

https://github.com/rcore-os/smoltcp/blob/main/src/phy/mod.rs

Access to networking hardware.

The `phy` module deals with the *network devices*. It provides a trait
for transmitting and receiving frames, [Device](trait.Device.html)
and implementations of it

按照如下的框架实现的网络设备即可和 smoltcp 兼容

impl Device for DeviceWrapper

struct DeviceWrapper {
    inner: RefCell<AxNetDevice>, // use `RefCell` is enough since it's wrapped in `Mutex` in `InterfaceWrapper`.
    rx_buf_queue: VecDeque<RxBuf>,
}

而 AxNetDevice 会在初始化时和我们定义的网卡驱动设备绑定, 在这里 AxNetDevice 展开是这样的:

pub type AxNetDevice = driver_net::cvitek::CvitekNic<CvitekNicTraitsImpl>

/// modules/axdriver/src/macros.rs
macro_rules! register_net_driver {
    ($driver_type:ty, $device_type:ty) => {
        /// The unified type of the NIC devices.
        #[cfg(not(feature = "dyn"))]
        pub type AxNetDevice = $device_type;
    };
}

下面定义了需要实现的方法:

/// crates/driver_net/src
/// Operations that require a network device (NIC) driver to implement.
pub trait NetDriverOps: BaseDriverOps 

下面是方法的具体实现:

crates/driver_net/src/cvitek/mod.rs
impl<A:CvitekNicTraits> NetDriverOps for CvitekNic<A> {
	// 里面定义了网卡驱动需要实现的方法(NetDriverOps),
	// 这些方法会被 modules/axnet/src/smoltcp_impl/mod.rs 调用并进一步封装,
    // 同时这里会用到在crates/cvitek-nic/src/cvitek_main.rs 中提供的 CvitekNicDevice 的实现和其他一些辅助方法.   
}

pub struct CvitekNic<A>
where
    A: CvitekNicTraits,
{
    device: CvitekNicDevice<A>,
    phantom: PhantomData<A>,
}

实现我们的 CvitekNic 设备还需要用到在 crates/cvitek-nic/crates/cvitek-nic/src/cvitek_main.rs实现的 CvitekNicDevice 结构和方法，这样就可以自由的编写我们网卡驱动的整体逻辑，最后只需要实现出方便调用的接口即可。

总体而言, 框架搭好后, 只需要实现自己的网卡驱动并且为其实现 NetDriverOps 特征即可。

有了框架以后, 实现网卡驱动需要修改的文件：

// TODO!

crates/driver_net/src/cvitek/mod.rs // 实现 NetDriverOps 特征

crates/cvitek-nic // 网卡驱动相关实现

参考实现:

​ https://github.com/yuoo655/arceos

// TODO! smoltcp代码分析

[shzy2012]

Synopsys 手册
https://picture.iczhiku.com/resource/eetop/shKwlwegHhsoOCbV.pdf

DWC Ether MAC 10/100/1000 Universal
DWC Ether MAC 10/100 Universal

[shzy2012]

华山派 cvitek 代码：
https://github.com/sophgo/sophpi-huashan/tree/master/cvi_mmf_sdk/u-boot-2021.10/board/cvitek

[h888866j]

AliOS 网卡驱动初始化过程分析：

graph TB

ethernet_init
==>csi_eth_mac_phy_init 

==> csi_eth_mac_initialize 
==> csi_eth_phy_initialize 
==> csi_eth_phy_initialize_complete
==> csi_eth_mac_connect_phy
==> csi_eth_mac_phy_enable

g_mac_phy_init_finish
==> csi_eth_mac_phy_init_Complete([csi_eth_mac_phy_init_Complete])
==> aos_task_new_ext["aos_task_new_ext(&eth_hdl, 'eth_init', 
eth_init_func, NULL, 8192,
AOS_DEFAULT_APP_PRI+1);"] --- taskCreate["一系列task create，
entry就是eth_init_func"]
==> eth_init_func-subgraph1


designware_eth_init --- regs_manipulation1["dma_reg manipulation
mac_reg manipulation"] -.-> rx_descs_init 
regs_manipulation1 -.-> tx_descs_init --- tx_descs_init-step["转换handle参数成mac_dev指针
从mac_dev获取priv指针
从priv获取dma_regs指针
从priv获取tx_mac_descrtable[0]指针
从priv胡获取txbuffs[0]指针
struct dmamacdescr *desc_p;
(rx_descs_init里多了 Flush rxbuff)
循环tx_mac_descrtable 更新成员
desc_p->dmamac_addr 和 dmamac_next
(rx_descs_init里多了 dmamac_cntl 和txrx_status)
更新最后一个成员的next 形成环形
Flush all Tx buffer descriptors at once
更新dma_reg
dma_reg->txdesclistaddr = (unsigned long)&desc_table_p[0];
priv->tx_currdescnum = 0;"]


csi_eth_mac_phy_enable -.-> csi_eth_mac_control -.->|Step 1| designware_eth_start -.-> designware_eth_init
csi_eth_mac_phy_enable ==> csi_eth_mac_control ====>|step 5| designware_adjust_link === csi_eth_mac_phy_enable_Complete === g_mac_phy_init_finish

csi_eth_mac_phy_enable -.-> csi_eth_mac_control -..->|step 3|designware_eth_enable[designware_eth_enable TX and RX]
csi_eth_mac_phy_enable -..->|step 2| csi_eth_phy_power_control 
csi_eth_mac_phy_enable -...->|step 4| csi_eth_mac_set_macaddr

csi_eth_mac_set_macaddr["csi_eth_mac_set_macaddr(handle,mac)"] -..- MemCopy2["gmac_dev_t *mac_dev = (gmac_dev_t *)handle;
memcpy(mac_dev->mac_addr, mac->b,"]
-.->designware_write_hwaddr["designware_write_hwaddr(handle)"]
---|操作macaddr寄存器| MacID["mac_reg->macaddr0hi = macid_hi;
	mac_reg->macaddr0lo = macid_lo;"]

csi_eth_phy_power_control -.call.- eth_phy_start -.call.-> phyStart["dev->start(handle)"] --> cv181x_start1

csi_eth_phy_initialize -. "call it to generate phy_dev" .-> eth_connect_phy["eth_connect_phy 
ret phy_dev"] -->|"then call with phy_dev"| eth_phy_reset -- then --> eth_phy_config -- then ---> ret1["return phy_dev ptr"] --> csi_eth_phy_initialize_complete([csi_eth_phy_initialize_complete]) 

eth_connect_phy -.call.-> eth_config 

eth_connect_phy-..->|then call|eth_get_phy_by_mask["eth_get_phy_by_mask
return phydev"] -.call.-> eth_read_phy_id 

eth_get_phy_by_mask -->|return phy_dev pointer| eth_connect_phy

eth_phy_config -."call, passin handle/phy_dev".->  config["dev.config(handle)"] -.call.-> cv181x_config1

eth_get_phy_by_mask -..->|then call| eth_get_phy_device["ret eth_get_phy_device"] -->|get,update and ret| ss["eth_phy_devices[0]"]	-->|it is cv181x_device| cv181x_device{{cv181x_device}} -->|cv181x_device.config函数指针指向_所谓connect|cv181x_config1 

subgraph cv181x_config1
	direction TB
	cv181x_config-->|"一堆mmio_write_32 配置"| ConfigPHY -."call,传入参数dev/handle".->genphy_config1
end

subgraph genphy_config1
	direction TB
	genphy_config --> feature_config[一堆feature config] -.call.->eth_phy_read --> feature_config2[一堆feature config] -.最后call并返回0.-> genphy_config_aneg1
end

subgraph genphy_config_aneg1
	direction TB
	genphy_config_aneg -.call.->genphy_setup_forced
	genphy_setup_forced -.nextcall.->genphy_config_advert
	genphy_config_advert -.nextcall.->genphy_restart_aneg
end

cv181x_config1 o-.- ret1

csi_eth_mac_initialize -.-o  csi_eth_mac_initialize1

subgraph csi_eth_mac_initialize1
	direction TB
	B["gmac_dev_t *mac_dev=&gmac_instance[idx]"] --> B3["给mac_dev.base/irq/cn_evenet赋值"] --> |"dw_gmac_priv *priv, *priv_unalign="|B2[memalign] 
	--- |DMA 区域清零|memset 
	---|mac regs pointer|priv.mac_regs_p 
	---|dma regs pointer|priv.dma_regs_p 
	---|将 priv和priv_unalign 保存到 mac_dev中| mac_dev.priv["mac_dev->priv = priv;"] 
	---request_irq
	---|return|mac_dev
end

subgraph cv181x_start1
	direction TB	
	cv181x_start --> genphy_update_link --"if not ret 0 then return"----> cv181x_parse_status["cv181x_parse_status(dev);
	parse and save to priv"] 
	
	genphy_update_link -.eth_phy_read.->  return-fn_phy_read? --> csi_eth_mac_phy_read
	
end

subgraph eth_init_func-subgraph1
	direction TB	
	eth_init_func
	==> tcpip_init["lwip::tcpip::tcpip_init(initfunc, arg)"]
	==> netif_add["lwip::netif_add(&eth_xnetif, &ipaddr, &netmask, 
	&gw, NULL, ethif_init, tcpip_input);"]
	-.-> nethif_init-subgraph1

	netif_add
	====> |Registers the default network interface.| netif_set_default
	==>|"When the netif is fully 
	configured this function must be called."| netif_set_up
	==> netif_set_status_callback
	==> netmgr_dev_eth_init	
	==> event_service_init
	==> netmgr_service_init
	==> netifapi_dhcp_start

	tcpip_init
	-.-> lwip_inited{lwip_inited=1}

	lwip_inited --> |Yes|initfunc["initfunc(arg) then return"]
	lwip_inited ---> |No|lwip_init

	-.-> stats_init
	--> sys_init
	--> mem_init
	--> memp_init
	--> pbuf_init
	--> netif_init
	--> ip_init
	--> etharp_init
	--> raw_init
	--> udp_init
	--> tcp_init
	--> igmp_init
	--> dns_init
	--> ppp_init
	--> sys_timeouts_init

	lwip_init 
	--> sys_mbox_new
	--> sys_thread_new["sys_thread_new(TCPIP_THREAD_NAME, tcpip_thread,
	 NULL, TCPIP_THREAD_STACKSIZE, TCPIP_THREAD_PRIO);"]
	-.-> tcpip_thread
	-.-> tcpip_init_done
	--> tcpip_timeouts_mbox_fetch["tcpip_timeouts_mbox_fetch(&tcpip_mbox, (void **)&msg)"]
	--> tcpip_thread_handle_msg["tcpip_thread_handle_msg(msg)"]
end


subgraph nethif_init-subgraph1
	direction TB
	ethif_init
	--> netif-setup["设置netif结构体的 hostname，output，
	linkoutput， output_ip6 具体指向的函数"]
	--> |initialize the hardware| low_level_init
	-.call.-> setup2["设置netif结构体的hwaddr_len，
	mtu， flags"]
	--> |Create a task| eth_rx
	-------> |Create a task| _eth_phy_update_link_task

	eth_rx -.-> ethernetif_input -.-> low_level_input["p = low_level_input(netif)"]
	-.-> netif-input["调用netif->input(p, netif)"]
	-.- tcpip_input["lwip::tcpip_input"]
	-.-> tcpip_inpkt["return lwip::tcpip_inpkt
	(p, inp, ethernet_input);"]

	_eth_phy_update_link_task 
	-.-> csi_eth_phy_get_linkstate

end

Loading

[h888866j]

LWIP协议介绍：
https://blog.csdn.net/sinat_31039061/article/details/104575815
https://blog.csdn.net/sinat_31039061/category_9784844.html

LWIP协议解析
应用层调用API发送接收数据流程：

网卡接收数据的流程

ARP:

IP 数据报发送

IP 数据报接收

TCP 层的工作流程示意图

网络接口管理：
网卡有多种多样，怎么能让 LwIP 使用同样的软件能兼容不同的硬件呢？原来 LwIP 使用一个数据结构——netif 来描述一个网卡。LwIP 提供统一的接口，但是底层的实现需要用户自己去完成，比如网卡的初始化， 网卡的收发数据，当 LwIP 底层得到了网络的数据之后，才会传入内核中去处理；同理， LwIP 内核需要发送一个数据包的时候，也需要调用网卡的发送函数，这样子才能把数据从硬件接口到软件内核无缝连接起来。简单来说， netif 是 LwIP 抽象出来的网卡， LwIP 协议栈可以使用多个不同的接口，而ethernetif.c 文件则提供了 netif 访问各种不同的网卡，每个网卡有不同的实现方式， 用户只需要修改 ethernetif.c 文件即可。

netif数据结构：

pbuf数据结构：

[kunyuanxu-star]

华山派驱动开发目前共四个任务：
任务一：在华山派上运行alios，测试其网卡驱动和华山派网卡的功能
任务二：整理需要用到的MAC寄存器信息
任务三：研究华山派phy驱动代码
任务四：整理相关的文档资料

[ZhiyuanSue]

Reconciliation子层将MII映射到PLS服务原语

PLS服务原语对应的MII信号

1、PLS_DATA.request(OUTPUT_UNIT)

总共三个信号，1，0，以及DATA_COMPLETE，TXD的四位分别表示一个0或者1，从3-0，一个序列，当TX_EN置位的时候就传递这个信息，当TX_EN deassertion的时候传递DATA_COMPLETE消息。用TX_CLK传递同步消息。

TX_ER（transmit coding error）

TXD<3:0>（transmit data）

TX_EN（transmit enable）

TX_CLK（transmit clock）

这个是时钟信号，由PHY提供，因为TXD总共4位，所以，PHY提供的时钟信号应当是正常传输数据信号的1/4。比如100Mbps，就应当提供25MHz的一个信号。

这几个信号的组合有几种可能，然后会有不同的结果，具体见Table22-1（709页左右）

里面有个LPI的情况，感觉是低功耗状态（？）

2、PLS_SIGNAL.indication

COL

包括signal_error和no_signal_error

col置位的时候表示error，反过来则no error

COL也不需要同步，0.8寄存器位置位时，行为未指定

3、PLS_DATA.indication(INPUT_UNIT)

这个只有0和1，由RXD四位表示，同样从3-0分别表示

RXD<3:0>（receive data）

对RX_DV置位的每个RX_CLK指示的周期，将四位数据从PHY传输到reconciliation 子层。

RX_ER

RX_CLK（receive clock）

这个时钟信号同样由PHY提供，（因为接收数据的时钟并不完全对齐），所以PHY可以从接收的数据中回复RX_CLK基准，也可以从TX_CLK等时钟基准中获取RX_CLK时钟。

这里面没有了TX_EN，也就是说，传送这件事情需要有包结束信号，但是接收这件事情不需要。

同样的，和TX一样(在TX_EN不置位的时候)，RX_DV不置位的时候，用于指示LPI等等相关信号。

4、PLS_CARRIER.indication

CRS

包括两个信号: carrier_on和carrier_off

如果接收和发送介质非空闲，CRS应当由PHY置位，如果都空闲则取消。

这个信号不需要与TX_CLK或者RX_CLK同步

如果控制寄存器的0.8也就是双工模式位置位，或者自协商选择了全双工模式，那么CRS的行为未指定。

5、PLS_DATA_VALUE.indication

RX_DV（receive data valid）

在帧接收的时候，RX_DV和RX_ER如果都置位了，那么会指示这个帧有一个FrameCheckError。

包括两个值：DATA_VALUE和DATA_NOT_VALUE

这个我看了感觉还用于指示一些同步的问题。

其他

MDC

MDC作为MDIO的时钟信号参考。

MDIO

MDIO是PHY和STA之间的双向信号。

MII数据流

数据包在MII上的传送应当具有以下的格式

< inter-frame >< preamble >< sfd >< data >< efd >

每个8位字节作为两个半字节进行发送和接收。

Inter-frame

帧间周期不会发生任何数据活动，RX_DV信号取消和TX_EN信号取消置位表示不存在数据活动。

Preamble

发送的情况，七个10101010

收包的情况，只能收到一个前导的10101011，这七个10101010没了。

SFD

10101011

MDIO

MDIO使用简单的双线串行接口，用于链接PHY并控制PHY，称为MII Management Interface

管理接口通过一对MII或者GMII传输的信号，帧格式和协议规范，以及通过这些帧读取和写入的寄存器集合组成。

MII使用两个基本寄存器，GMII使用了第三个。

MII基本寄存器 由两个寄存器组成，分别是控制寄存器（寄存器0）和状态寄存器（寄存器1）

GMII在这俩之外还包括了寄存器15（扩展状态寄存器）

这个status和ctrl功能被认为是100Mbps和1000Mbps的基本功能。（也就是说，这三个寄存器才是最基本的）

寄存器2-14是扩展寄存器集合的一部分

寄存器4-10的格式是为了使用特定的自协商协议定义的。这些寄存器格式由寄存器1和15定义

寄存器

具体而言，前16个寄存器0-15是有规定好功能定义的

后面16-31是厂家自己设计的。

（但是为什么在phy.h中对后面的寄存器也有呢？？？）

关于这16个寄存器，功能分别如下记录

使用X.Y方式记录，比如0.15就表示第0号寄存器的第15个bit。

这些寄存器都是16位的。

0号寄存器-Ctrl（MII和GMII下都是基本寄存器）

Bit(s）	Name	Description	读写情况
0.15	Reset	默认是0，位置位1表示reset，该位置为0表示正常工作，每次phy复位应当在0.5s内完成，复位过程中保持bit15为1，复位之后自动清零。需要注意的是，一般要改变端口工作模式，比如速率或者协商信息的，需要设置完相应寄存器之后，再reset phy来让配置生效。	可读写，自清理
0.14	Loopback	逻辑上会把发出去的再送回来，但有些会导致直接linkdown，默认情况下是0。	可读写
0.13和0.16	Speed Selection	0.6/0.13: 1/1保留，1/0表示1000Mbps，0/1表示100Mbps，0/0表示10Mbps	可读写
0.12	auto-negotion-enable	置位表示允许自动协商，否则不允许	可读写
0.11	Power Down	置位表示下电，为0则表示正常工作	可读写
0.10	Isolate	将PHY和MII或者GMII隔离开来	可读写
0.9	Restart auto-negotiation	1表示重启自动协商	可读写且自清理
0.8	duplex mode	1表示全双工模式，0表示半双工模式	可读写
0.7	collision test	1表示启用COL信号，0表示禁止	可读写
0.5	unidirectional enable	当0.12置位且0.8为0，也就是半双工模式下自协商，这一位没啥用，当0.12为0且0.18为1，全双工模式下，无自协商，0.5置位表示启用从独立于媒体的接口传输，无论PHY是否已经确定建立有效连接，不置位表示只有PHY确定有有效连接的时候，才置位。	可读写
剩下的保留			可读写

1号寄存器-Status（MII和GMII下都是基本寄存器）

Bit(s)	Name	Description	读写情况
1.15	100-BASE-T4	从上到下这些都是1表示支持该模式，0表示不支持该模式	只读
1.14	100-BASE-X全双工		只读
1.13	100-BASE-X半双工		只读
1.12	10Mbps全双工		只读
1.11	10Mbps半双工		只读
1.10	100BASE-T2全双工		只读
1.9	100BASE-T2半双工		只读
1.8	扩展状态位	置位表示15号寄存器启用	只读
1.7	Unidirectional ability	和0.5的内容差不多，只不过0.5表示的是置位的方式，这个是status，所以不需要0.12和0.8	只读
1.6	MF preamble suppression	置位表示接受管理帧，无论是否带前导码	只读
1.5	Auto-negotiation complete	1表示完成自动协商工作了	只读
1.4	Remote-Fault	1表示检测到远程错误	只读
1.3	Auto-negotiation ability	置位表示PHY可以接受自动协商	只读
1.2	Link Status	置位表示Link up	只读
1.1	Jabber Detect	（没看明白）	只读
1.0	扩展的能力	置位表示15号寄存器可以启用	只读

这里对寄存器说明有Latching low和Latching high（不太懂翻译成中文是啥，但是说了全都是只读的）

2号寄存器-PHY_id

3号寄存器-PHY_id

2和3都是用来做这个的。2为高16位，3为低16位。

4号寄存器-Auto-Negotiation-Advertisement

5号寄存器-Auto-Negotiation-Link-Partner-Base-Page-Ability

6号寄存器-Auto-Negotiation-Expansion

7号寄存器-Auto-Negotiation-Next-Page-Transmit

8号寄存器-Auto-Negotiation-Link-Partner-Received-Next-Page

9号寄存器-Master-Slave-Control-Register

10号寄存器-Master-Slave-Status-Register

上面的自动协商的寄存器看28.2.4.1和37.2.5.1

主从模式的9和10看32.5和40.5

11号寄存器-PSE-Ctrl-Register

看33.5.1.1

12号寄存器-PSE-Status-Register

33.5.1.2

13号寄存器-MMD-Access-Ctrl-Register

Bit(s)	Name	Description	读写位
13.15:14	Function	00=address，01=数据，没有post自增，10=数据，当读写的时候	可读写
13.13:5	保留		可读写
13.4:0	DEVAD	设备地址	可读写

14号寄存器-MMD-Access-Address-Data-Register

全都用来表示地址数据

15号寄存器-Extended-Status（GMII下是基本寄存器）

bit(s)	Name	description	读写
15.15	1000BASE-X全双工	和1号寄存器差不多	只读
15.14	1000BASE-X半双工		只读
15.13	1000BASE-T全双工		只读
15.12	1000BASE-T半双工		只读
15.11：0	全都保留		只读

剩余寄存器-厂商自定义

（好多呀。。。）

[jackyliu16]

BCM54213PE_datasheet.PDF: https://gitee.com/bigmagic/raspi_sd_fw/blob/master/doc/raspi4/BCM54213PE_datasheet.PDF

[ZhiyuanSue]

我这边phy驱动的框架也已经搭建好了，在张轩铬的基础上完成的
仓库在https://github.com/ZhiyuanSue/arceos_hsp
分支是cvitek-nic-phy-dev
编译命令是make A=apps/net/cvitek_nic_test ARCH=riscv64 SMP=1 NET=y LOG=info cv1811
运行截图如下：

之后会在该分支上继续写phy的代码

[h888866j]

目前ArceOS riscv 平台只启用了时钟中断（register和dispatch时 把 timer和其他中断做了区分）。

• irq enable 部分还是 TODO 状态，参见 register_handler_common 里的 set_enable。
• 然后 dispatch_irq 部分，除了时钟中断有对应处理之外，其他中断都是固定传入 0 作为中断号，没有实际作用，也是TODO。

// modules/axhal/src/platform/qemu_virt_riscv/irq.rs

/// Enables or disables the given IRQ.
pub fn set_enable(scause: usize, _enabled: bool) {
    if scause == S_EXT {
        // TODO: set enable in PLIC
    }
}

/// Dispatches the IRQ.
///
/// This function is called by the common interrupt handler. It looks
/// up in the IRQ handler table and calls the corresponding handler. If
/// necessary, it also acknowledges the interrupt controller after handling.
pub fn dispatch_irq(scause: usize) {
    with_cause!(
        scause,
        @TIMER => {
            trace!("IRQ: timer");
            TIMER_HANDLER();
        },
        @EXT => crate::irq::dispatch_irq_common(0), // TODO: get IRQ number from PLIC
    ); // <<<<<<< 这里没有获取中断号，固定写成了0，时钟中断
}

[kunyuanxu-star]

dw_gmac_mars 代码平移到Rust的工作主要涉及了以下函数

• dw_gmac_irqhandler：这个函数是中断处理函数，用于处理以太网控制器的中断事件，如发送完成、接收完成、错误等。
• dw_dump_register：这个函数用于打印以太网控制器的寄存器值，用于调试和分析。
• designware_read_hwaddr：这个函数用于读取以太网控制器的硬件地址（MAC地址）。
• designware_write_hwaddr：这个函数用于写入以太网控制器的硬件地址（MAC地址）。
• tx_descs_init：这个函数用于初始化发送描述符链表，用于存储发送数据包的信息。
• rx_descs_init：这个函数用于初始化接收描述符链表，用于存储接收数据包的信息。
• designware_adjust_link：这个函数用于调整以太网控制器的链路状态，如速度、双工模式等。
• designware_eth_init：这个函数用于初始化以太网控制器的基本配置，如时钟、DMA、中断等。
• designware_eth_enable：这个函数用于使能以太网控制器的工作模式，如发送、接收等。
• designware_eth_disable：这个函数用于禁止以太网控制器的工作模式，如发送、接收等。
• designware_eth_start：这个函数用于启动以太网控制器的数据传输，如启动DMA、使能中断等。
• designware_eth_stop：这个函数用于停止以太网控制器的数据传输，如停止DMA、禁止中断等。
• designware_eth_send：这个函数用于发送一个数据包，如将数据包写入发送描述符、触发DMA传输等。
• designware_eth_recv：这个函数用于接收一个数据包，如从接收描述符读取数据包、释放描述符等。
• designware_free_pkt：这个函数用于释放一个数据包的内存空间，如回收缓冲区等。
• designware_mdio_reset：这个函数用于复位MDIO总线，用于与PHY芯片通信。
• csi_eth_mac_connect_phy：这个函数用于连接PHY芯片，如检测PHY芯片的类型、地址等。
• csi_eth_mac_phy_read：这个函数用于从PHY芯片读取一个寄存器的值。
• csi_eth_mac_phy_write：这个函数用于向PHY芯片写入一个寄存器的值。
• csi_eth_mac_initialize：这个函数用于初始化以太网MAC层，如注册回调函数、设置工作模式等。
• csi_eth_mac_uninitialize：这个函数用于反初始化以太网MAC层，如注销回调函数、清除工作模式等。
• csi_eth_mac_get_macaddr：这个函数用于获取以太网MAC层的硬件地址（MAC地址）。
• csi_eth_mac_set_macaddr：这个函数用于设置以太网MAC层的硬件地址（MAC地址）。
• csi_eth_mac_send_frame：这个函数用于发送一个帧，如调用底层驱动的发送函数等。
• csi_eth_mac_read_frame：这个函数用于读取一个帧，如调用底层驱动的接收函数等。
• drv_eth_mac_request_frame：这个函数用于请求一个帧的内存空间，如分配缓冲区等。
• drv_eth_mac_release_frame：这个函数用于释放一个帧的内存空间，如调用底层驱动的释放函数等。
• csi_eth_mac_start：这个函数用于启动以太网MAC层的数据传输，如调用底层驱动的启动函数等。
• csi_eth_mac_control：这个函数用于控制以太网MAC层的工作状态，如设置速度、双工模式、环回模式等。

[yuoo655]

https://github.com/yuoo655/arceos_net 星光一代,星光二代网卡驱动仓库地址,找对应分支即可。 代码未整理，还比较乱

[yuoo655]

https://github.com/yuoo655/arceos_net/tree/hsp 华山派网卡收发包功能完成. 没法再fork一次,目前是直接把zy的仓库代码复制过来修改

[jackyliu16]

我找到了个图片，感觉可以方便理解