在 2023 年的 RISC-V 中国峰会上,cyy 和万呆呆见到了一款看起来只是一款平平无奇的交换机,但他既然出现在了这个会场上,那就肯定和 RISC-V 有那么几毛钱关系。这个交换机采用的轩辕 1030M 以太网交换芯片来自武汉飞思灵,而里面用于管理的 CPU 就是基于 RISC-V 架构的,主频 400MHz。除此之外,这个芯片还集成了 8 路 10/100/1000BASE-T 或 100BASE-FX 的 PHY、4 路支持 1000BASE-X、SGMII 的 1G serdes、2 路支持 1000BASE-X、10GBASE-R、SGMII、QSGMII、O-USGMII 的 10G serdes,接口数量还算客观、对于各类 SFP(+) 模块的支持也不会有多大困难。另外一些参数如下:
- 最大帧长 16000 字节
- 片上缓存 1.5MB
- MAC 表 16K 项
- VLAN 支持 4K 个
- 二层组播支持 4K 个
- ACL 支持 256 条
- 典型功耗 4.5W
参数很好看,作为一个办网专家,背包里怎能不常备 10G 网卡、光纤跳线、光模块等必备工具?cyy、Easton Man、Yuuta 三人共凑出 x86/ARM MacBook 各一台、ConnectX-4/AQC107 芯片的网卡各一张,并使用 DAC 线和光模块+跳线两种方式,当场对该交换机的 10G 口双向转发能力和 RSTP 工作能力进行了测试,均正常完成。因此群友们也都挺期待该交换机面市。前两天 Milk-V 在淘宝店上架该交换机后,群友马上组团进行了购买。数辆泥头车从深圳启程,创(撞)向群友的家中。
收到以后,我连晚饭都没来得及吃就开始拆箱。该交换机一共有 8 个 1G 电口、4 个 1G SFP 接口、2 个 10G SFP+ 接口,还有一个用于连接 UART 和 JTAG 的 USB-C 精致调试接口。他没有附送 USB-C 线可以理解,毕竟只是调试接口需要,并不是一个必备的东西,但居然连电源线也不给一根,十分小气。好在我有 12V 的 PD 协商模块,配合 5.5x2.1 转 5.5x2.5 的 DC 头,可以使其正常上电。
吃完饭后便着手开始测试,首先将其连接到了电脑和家中一台闲置的路由器上,为了测试 SFP 口,还插入了闲置的 GPON/EPON 光猫 SFP 模块一根。所有端口均正常工作,并在默认配置的情况下,所有业务均能相互访问,一切工作正常。
接上串口,在开机的时候可见 OpenSBI 信息。
OpenSBI v0.7
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
Platform Name : Nuclei UX600
Platform Features : timer,mfdeleg
Platform HART Count : 1
Boot HART ID : 0
Boot HART ISA : rv64imafdcsu
BOOT HART Features : pmp,scounteren,mcounteren,time
BOOT HART PMP Count : 16
Firmware Base : 0x41000000
Firmware Size : 76 KB
Runtime SBI Version : 0.2
接下来按照背面贴纸的说明,在电脑上配置了 192.168.40.0/24 内不与 .253 冲突的地址,使用 admin/admin 访问了交换机管理页面。从管理页面可以看出,该交换机有 802.1q、QinQ(及 map)、基于 MAC/IPv4 子网/以太网协议的 VLAN、风暴抑制、端口限速、流量控制、802.1p、DSCP、GVRP、GMRP、LLDP、IGMP、静态组播、基于 MAC/IPv4/IPv6 地址的 ACL、ERPS、静态/LACP 端口汇聚、RSTP、802.1x、RADIUS 服务器、SNMP、RMON、端口镜像等功能。
我试着配置 VLAN trunk,看看能否与图中下面那台 NEC 路由器(也有点灵,因此我称该测试为“灵车对创”)互联互通,测试是能用的。就是我配置某个端口 tagged 1-4094 的时候网页卡了好几秒,以至于我以为被我配掉线了,又等了几秒,发现页面的列表上直接多了 4094 个 VLAN,太暴力了。
后面我还测试了一些能测试的功能,比如 SNMP、LLDP 等,都能用。光猫 SFP 模块也能正常协商、使用。运行了几个小时后,整机温度还好,温热,似乎不烫。至于转发性能之类的,cyy 在 8 月份已经测试过,就不做另外的测试了,更高级的测试我也没办法进行。
好,就介绍到这里,下面可以不用看了。799 元买到支持这么多功能的、带 2x10G+12x1G 口的管理型交换机,要啥自行车啊!
在进行完基本测试后,开始对他进行深入分析。首先尝试拆机,但是螺丝上太紧了,放弃拆机。反正 cyy 在八月份有拍过,这里借一下他的图片。
串口的登录凭据是 root/milkv,一进去便可以注意到 /root 下是有东西的:
root@dev:/root> ls -lah
total 13M
drwxrwxrwx 2 1000 1000 1.1K Jan 1 1970 .
drwxr-xr-x 17 1000 1000 1.2K Dec 12 12:03 ..
-rw------- 1 root root 763 Jan 1 1970 .ash_history
lrwxrwxrwx 1 root root 16 Jan 1 1970 config.fhme -> /mnt/config.fhme
-rwxrwxr-x 1 1000 1000 35.8K Dec 12 11:48 config_pll.sh
lrwxrwxrwx 1 root root 19 Jan 1 1970 config_reg.txt -> /mnt/config_reg.txt
-rwxrwxrwx 1 1000 1000 219.3K Dec 12 11:49 fhcli
-rwxrwxrwx 1 1000 1000 16.5K Dec 12 11:48 i2c_dev_msg_muti
-rwxrwxrwx 1 1000 1000 20.1K Dec 12 11:48 i2cdetect
-rwxrwxrwx 1 1000 1000 23.4K Dec 12 11:48 i2cdump
-rwxrwxrwx 1 1000 1000 19.3K Dec 12 11:48 i2cget
-rwxrwxrwx 1 1000 1000 22.4K Dec 12 11:48 i2cset
-rwxrwxrwx 1 1000 1000 20.2K Dec 12 11:48 i2ctransfer
-rwxrwxrwx 1 1000 1000 16.5K Dec 12 11:49 led_164.ko
-rwxrwxrwx 1 1000 1000 12.9M Dec 12 11:49 libsdk.so
-rwxrwxrwx 1 1000 1000 36.7K Dec 12 11:49 xy1000_net.ko
首先我们先不去吐槽这些程序、动态库和 kmod 为什么会在 /root,为什么会有 1000:1000 的所有者。首先映入眼帘的就是那个 .ash_history
,我们打开看一下。哇,看起来 MAC 和 SN 都是直接在 shell 里面写入的!这个可能是自动程序完成的,但是万呆呆也发出了他的文件,和群友的数据对比了一下,发现 3 台机子各不相同。甚至和我有着相邻 MAC、SN 的机子一开始还误写成了我的 MAC、SN。可见这个交换机真的是手工匠心之作,MAC 地址、序列号都是纯人工写入的。
作为一个持有 OUI(MAC 地址前缀)分配的冤大头,在看到 MAC 地址的时候总会去查查 OUI 数据库,看看这个 MAC 地址属于哪个组织,该组织拥有多大的分配。对于网络设备(如网卡、交换机等),这个地址一般是由该设备的生产厂商烧入。然而我查询了这个 MAC 地址以后,发现是属于 Realtek 的,但在主板的拆机图中没能见到任何 Realtek 芯片。根据搜索引擎的结果,这个前缀的 MAC 早就在 20 年前由 Realtek 开始使用,理论上早已分配完毕,更不可能提供给 Milk-V 用于制造交换机(况且他们也没用 Realtek 芯片)。所以 MAC 地址都是偷的,不能保证其唯一性了,此处建议 Milk-V 去 IEEE 申请一下 OUI 再来生产网络设备。
接着我们继续欣赏他的 rootfs,可以注意到有着大量 user=1000 group=1000 并带着 777 权限位的文件,或者是带上了执行位权限的配置文件,比如 /etc/group、/etc/hosts。打包该系统的人的水平实在不敢恭维。但还是那句话,又不是不能用,对吧。
系统的 model 为 nuclei,ux600fd
,nuclei 即芯来科技。设备树非常短,除去 CPU、中断控制器、UART、GPIO 等,就是一个 ethernet 节点了。这个节点的 compatible 是 fsl,fsl-mac
,fsl 即武汉飞思灵,是交换机数据平面。在内核中对应的驱动是 xy1000_net,该驱动会在内核中将其创建为一个网络接口 eth0,这个接口经由交换模块直通面板上的调试口(不是 UART/JTAG 那个 USB-C)。该调试口默认配置是 0 号口,我没有测试,不确定是面板标注的 G1 还是 XG1,不过在 Vega 的出厂配置(/mnt/config.fhme
)中也并没有启用这个调试口的 CPU 直通(cpu_port_enable=0
),所以该口也只是一个普通交换接口。同时还有一个 vir0 接口,这个接口是交换机上的一个 access 接口,只会接收管理 VLAN 的、目的地为 CPU 的数据。管理 IP 和 MAC 就是配置在这个接口上的。
片上一些能力的配置是通过一串 i2c 操作脚本实现的,没有写成驱动,因此开机会刷一屏 i2c ioctl 的调试信息。根据这个网页管理页面的 URL 规则(setup.cgi?todo=
和 setup.cgi?next_file=
),我搜索到了 NETGEAR 的路由器,不知道他们之间有什么关联。
结合支持的功能,再看看这么灵车的情况,这个 SoC 十有八九是买的核拼的吧。这 Milk-V Vega 大概只能算轩辕 1030M 的开发板或者评估板,在家里用没关系,但在严肃的场合是没办法去作为一个真正的交换机使用的。资料公开得还是比较全的,U-Boot、Linux Kernel、SBI 的代码等都公开在了 GitHub milkv-vega/vega-buildroot-sdk 这一个仓库中,深刻践行了 monorepo 思想,避免用户切换多个仓库,commit 历史也只有干净简洁的 1 条。另外,飞思灵这个轩辕 1030M 芯片的各种文档也都公开在了 GitHub milkv-vega/vega-files,可以学习到交换芯片的一些内幕,有兴趣的大佬也能用来移植或开发。
是峰会第一天吗,我好像有拍到你们()
reply
是第一天,不过不是“我们”,他们现场测网,我是云观看(
reply
群号方便send一下嘛
reply
是 cyy 的个人群,你认识那肯定就有机会知道了(
reply
老登特有的 chmod 777,哈哈
reply
现在千兆有点可惜,要是 2.5G 多好
reply