因为我的固件可能有内存泄漏，所以想办法定时释放内存。其实就是用 Linux 的方式。
在管理界面 > 系统 > 计划任务，加入下面代码。每天5点和17点自动释放内存。
Login
0 5,17 * * * sync && echo 1 > /proc/sys/vm/drop_caches我这基于 OpenWrt 的路由器可以说是超级强大，不仅仅是一个无线路由器，插上 U 盘可以变身为 NAS+下载机，可以运行 Python 小程序，甚至还有人在上面搭建 LNMP 运行 Owncloud。可以说是一台 VPS 可以干的事情我都可以在宿舍的路由器上实现，十分强大。
然而最近才了解到，这颗 580MHz 的 MTK7260A 仅仅是一颗智能路由器当中处于中低端的 CPU，说实话我是不信的，于是打算用 UnixBench 来客观测试一下这个小家伙的真实水平。
UnixBench 是基于 Perl 并拥有 30 年历史的基准测试软件，也就是跑分软件。通过运行一系列科学计算函数测试 CPU 性能，以及 OS 的任务执行效率、硬盘性能等。最终得到一个分数。
路由器：Newifi Mini
OS：LEDE 17.01.2（一个 OpenWrt 的著名分支）
Linux Kernel：4.4.71
架构：MIPS
RAM：128M
ROM：16M
系统基本为纯净的 LEDE，除了正在运行着路由器的基本网络服务外，跑分时运行了一个 PPTP VPN Client 服务。
OpenWrt 的 libgcc 套件体积 22M 的样子，但正如上面所写，我的路由器 ROM 总共只有 16M，挂载分区什么的不是很有必要，于是我使用交叉编译 UnixBench。
简单介绍一下交叉编译的步骤吧：
1、找一台 x64 的 Linux 机器，按照 <https://wiki.openwrt.org/doc/devel/crosscompile> 步骤开始接下来的操作。必须得要 x64 的主机。
2、下载你的路由器当前系统当前机型对应的 DevPack，比如我的 LEDE 在这里下载的：<http://downloads.lede-project.org/releases/17.01.2/targets/ramips/mt7620/lede-sdk-17.01.2-ramips-mt7620_gcc-5.4.0_musl-1.1.16.Linux-x86_64.tar.xz>，OpenWrt 请在 <https://downloads.openwrt.org/> 下寻找。
3、按照官方 Wiki 的步骤将编译器添加到环境变量。
4、下载 UnixBench 的源代码并解压：<https://github.com/kdlucas/byte-unixbench>
5、开始编译。这里注意官方 Wiki 有误，请使用 make CC=mipsel-openwrt-linux-musl-gcc LD=mipsel-openwrt-linux-musl-ld 命令使用指定编译器进行编译。
6、编译失败？根据提示删除 Makefile 中编译器无法识别的两个参数，即可完成编译。
7、将除了 /src 外的文件 scp 到路由器。
8、安装相关依赖：opkg install perlbase-posix perl perlbase-time perlbase-io perlbase-findbin coreutils-od，跑分完后即可删除。
9、尝试运行 ./Run，你会发现弹出错误，根据错误内容做出以下修改。
10、修改 ./Run，注释掉 use strict 和两处尝试执行 make all 的语句。
11、这时再运行 ./Run，就已经自动开始跑分了。虽然会有几个 Wrong 弹出，但是不要紧。
========================================================================
BYTE UNIX Benchmarks (Version 5.1.3)
System: : GNU/Linux
OS: GNU/Linux -- 4.4.71 -- #0 Wed Jun 7 19:24:41 2017
Machine: mips (unknown)
Language: (charmap=, collate=)
17:01:34 up 13:01, load average: 0.25, 0.49, 0.34; runlevel
------------------------------------------------------------------------
Benchmark Run: Sun Sep 24 2017 17:01:34 - 17:37:25
0 CPUs in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 1261494.8 lps (10.0 s, 7 samples)
Double-Precision Whetstone 24.3 MWIPS (9.9 s, 7 samples)
Execl Throughput 452.5 lps (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 41.0 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 18.5 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 115.4 KBps (30.0 s, 2 samples)
Pipe Throughput 154847.5 lps (10.0 s, 7 samples)
Pipe-based Context Switching 51157.7 lps (10.0 s, 7 samples)
Process Creation 1260.9 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 43.2 lpm (61.1 s, 2 samples)
Shell Scripts (8 concurrent) 6.5 lpm (64.3 s, 2 samples)
System Call Overhead 308931.8 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 1261494.8 108.1
Double-Precision Whetstone 55.0 24.3 4.4
Execl Throughput 43.0 452.5 105.2
File Copy 1024 bufsize 2000 maxblocks 3960.0 41.0 0.1
File Copy 256 bufsize 500 maxblocks 1655.0 18.5 0.1
File Copy 4096 bufsize 8000 maxblocks 5800.0 115.4 0.2
Pipe Throughput 12440.0 154847.5 124.5
Pipe-based Context Switching 4000.0 51157.7 127.9
Process Creation 126.0 1260.9 100.1
Shell Scripts (1 concurrent) 42.4 43.2 10.2
Shell Scripts (8 concurrent) 6.0 6.5 10.9
System Call Overhead 15000.0 308931.8 206.0
========
System Benchmarks Index Score 11.3
总分 11.3 是什么水平呢，我用我的洛杉矶服务器也跑了一下，3.5GHz 的 E3 处理器，不过是共享主机，并且只有单核的使用权。得到的分数为 1245.
这说明，这个功率为 10W 不到的路由器综合能力果然很弱，哈哈哈。。。
不过就算再弱，竟然可以跑完整的 Linux 4.4，能够运行起 Python、Nginx、MySQL、PHP-FPM、SSHD、Samba、DNS 等等一系列服务，还非常的稳定，不得不让人对 Linux 竖起大拇指呀~
后来我又换了 K3 路由器，ARM 双核 1.4GHz，可以代表着当前家用路由的最高水平，我用它跑了一遍 UnixBench，结果见下一页。
正如About所描述的，希望在这里记录一些难以查找的信息：网络接入和局域网设备升级踩的坑
历经多次宽带因为单一运营商垄断，价格高到离谱，之前在学校测过4G是可以跑到100Mbps的下行速率的，买过4G路由器做接入，后来因为SIM卡不够用就出掉了
在5G时代，闲置的4G手机完全可以用来作为网络接入设备，我用刷了OpenWrt的小米R3G有线连接退役的iPhone SE做了一个简单的4G路由器，找个4G信号好的地方固定，测速还行就可以开始用了
因为有部分模块依赖于内核，加上平时编译不太方便，所以采用官方固件，参考官网教程 Smartphone USB tethering
我记录的一些需要装的包
# 换源
sed -i 's_downloads\.openwrt\.org_mirrors.ustc.edu.cn/lede_' /etc/opkg/distfeeds.conf
# 装包
opkg install kmod-usb-net-ipheth kmod-usb-net kmod-usb-ohci kmod-usb-uhci kmod-usb2 libimobiledevice-utils libusbmuxd-utils usbmuxd
opkg install luci-compat
用了一段时间后发现了如下问题，当然也还有其他的手机可以尝试，但是我觉得4G的问题更大：
ios更新14之后，以上教程提到的方法就失效了，后续就没有在ios上再尝试过了；随着第一代5G手机在2022年陆陆续续退役，5G手机USB共享网络给OpenWrt路由器却没有达到预想中的那么快，考虑到在手机上经过了一次NAT，存在硬件开销以及调度和功耗限制，这还是不适合作为一个长期方案
于是开始关注5G CPE，恰好就遇到了2020年刚上市的华为的5G CPE Pro 2 (型号H122-373，以下简称H122)，幸好买的早，后来芯片荒价格一路水涨船高，直到后来智选的5G CPE铺货
当时刚好手上有可以跑千兆5G卡，至少在下载速率上可以超过绝大多数家庭宽带了，缺点也还是有的：
写出来有点多，但不可否认的是在很长一段时间里H122就是能买到的最强的5G CPE，在我这稳定运行了三年，因为是价格低位购入，还能直接用天际通物联网卡（23年已经限速到200Mbps，没有了5G SA，只能用4G）
最后需要担心的其实是流量问题，因为5G的流量消耗速度非常快，实时监控流量消耗情况也是必要的，如用iOS小组件；因为华为5G CPE当前已经无法收到短信，流量告警只能自行编写脚本等方式实现
这里使用的是DJI增强图传模块连接OpenWrt路由器USB接口接入的4G网络
2022年大疆在Mavic3发布之后发布了与之配套的4G图传模块（DJI Cellular），然而自带的增强图传服务只有一年的套餐，后续如果要继续使用就需要以每年99续费增强图传服务，对于只是想超视距飞行过把瘾的人来说，增强图传服务到期之后模块自然就闲置了（大疆2023年新品不兼容该模块），二手市场上挂出的非常多，感觉出手比较困难（原价699，2023.11二手大把的450），而全新的同规格的Cat4速率的4G USB网卡120可以买到，既然如此，还不如留着当4G网卡发挥余热
该方法在ImmortalWrt 23.05.1的ARM和MT7621的路由器上测试成功
opkg install qmi-utils usb-modeswitch kmod-mii kmod-nls-base kmod-usb-core kmod-usb-ehci kmod-usb2 kmod-usb-net kmod-usb-wdm kmod-usb-net-qmi-wwan wwan uqmi luci-proto-qmi
ls /dev/应该看到cdc-wdm3这个设备了
echo "2ca3 4006 0 2c7c 0125" > /sys/bus/usb/drivers/qmi_wwan/new_id
/dev/cdc-wdm3（最关键，下图是借用的其他教程的截图作为参考），其余的信息保持默认； 在防火墙设置，给这个接口分配防火墙区域为wan，保存设置即可
如果此时4G图传模块上的灯是绿色的，即模块正常连上了4G网络，很快能看到刚刚创建的接口已经获取到了IPv6的地址，并且系统自动生成了名为DJI_4的IPv4地址的虚拟接口，此时路由器应该就能通过4G模块访问互联网
第一次成功驱动并设置好QMI拨号的接口后，可以将命令
echo "2ca3 4006 0 2c7c 0125" > /sys/bus/usb/drivers/qmi_wwan/new_id
添加到开机启动脚本中（网页LuCI界面->系统->启动项->本地启动脚本），添加到文本框中exit 0这一行之前即可，后续重启也无需任何的操作，随时插入4G模块后一段时间就能正常上网了
在大疆论坛上有用户尝试了Windows上驱动并成功让PC能接入4G网络，后续大疆又发布了模块的Windows驱动，其中主要提供了以下的信息：
搜索OpenWrt上驱动模块的资料，发现在OpenWrt上移植EG25驱动的经验是空白的，主要都是移植EC2X的，其中《挂载移远EC20、EC21、EC25、AG35等4G模块》参考了官方的Linux驱动文档，EG25在文档发中和EC25的PID和VID是相同的(2C7C, 0125)，但是与4G图传模块的(2CA3, 4006)不同，即使移植了EG25的驱动也未必能识别到4G图传模块
直到看到论坛里有人发了4G图传模块用于Linux系统上网尝试，用到了将USB设备的PID和VID写入/sys/bus/usb/drivers/…/new_id处理驱动识别的方法，另外又查到了23年11月的OpenWrt 下实现移远 4G 模块上网 中提到在OpenWrt 22.03在无需改内核代码就能驱动EC20
在运行echo "2ca3 4006 0 2c7c 0125" > /sys/bus/usb/drivers/qmi_wwan/new_id后，可以用cat /sys/kernel/debug/usb/devices查看到4G模块被qmi_wwan驱动（设备对应的信息出现Driver=qmi_wwan字样）
在/dev目录下可以看到/dev/cdc-wdm[0-3]一共4个设备，最开始尝试了/dev/cdc-wdm0发现无法拨号就差点放弃，最后尝试了下/dev/cdc-wdm3发现拨号可以获取到IP了
uqmi命令可以与模块通信并输出一些状态的信息，其中个人比较关注的主要是信号
root@XDR6088:~# uqmi -d /dev/cdc-wdm3 --get-signal-info
{
"type": "lte",
"rssi": -55,
"rsrq": -6,
"rsrp": -79,
"snr": 14.800000
}
4G模块的速率标准为Cat4（下行速率最高150Mbps，上行最高为50Mbps），实测在以上信号强度的电信4G上下行均为50Mbps左右，日常用这速率也算能接受吧，联想到我测试过最快的4G是2018年在iPhoneSE（4G Cat6最高下行速率300Mbps）上跑出了100Mbps的下行
关于IPv6，首先路由器时可以获取到公网IPv6地址的（以及64位前缀的PD），并且在LAN默认的IPv6设置下，可以向下分配地址，另外就是传入连接的连接性，实测发现有运营商的差异：移动的IPv6地址无法从外网访问路由器，联通和电信的IPv6地址则可以
由于CPE和4G模块获取的IPv6地址是不含短于64位的前缀的，所以在使用二级路由的情况下，二级路由下的设备无法获取公网IPv6地址，这个时候需要配置“IPv6中继+NDP代理”，OpenWrt 23.05的LuCI界面的设置过程如下：
正常情况下，连接在路由器下面的设备就能获取到公网IPv6地址了，但是可能还打不开IPv6网站：http://test6.ustc.edu.cn，这个时候可能需要ping一下wan6接口的IPv6地址，让地址被NDP代理学习（可以用ip -6 neigh和LuCI上的系统->路由表->IPv6邻居看IPv6地址对应的接口来观察NDP代理的效果）我的网络结构是CPE做一级路由，OpenWrt做二级路由，因为华为5G CPE本身防火墙的原因，二级路由下面的设备可以获取到IPv6地址，但是无法从外网访问
但是如果CPE或者4G模块支持桥模式，那么OpenWrt路由器大概率是不受CPE或者4G模块的防火墙影响的，放开OpenWrt的防火墙之后，只剩下运营商屏蔽了传入连接的可能性
局域网肯定还是要用一台OpenWrt路由器作为主路由，如果一台主路由能解决问题是最好，列出来的要求有点多：
在从2020年到2023年这一段时间里，涌现了一大批可以刷OpenWrt的WiFi6路由器：Qnap-301w、红米AX6，AX6000、中兴NX30 Pro，以及可能有QSDK固件的小米万兆路由，对比以上的要求有明显的短板，直到某一天看到B站上有人给TP-LINK XDR6088刷机的教程：TP-link路由器XDR6088、6086、4288刷openWRT，我终于发现了一台有潜力的机器：
可以查到的获取终端操作权限刷入U-boot（bootloader）的方法源于：TP-LINK XDR6086/XDR6088 反弹 SHELL 并开启 SSH
综合亲手实践以及上面的视频教程，有几点需要特别注意
{"error_code":0}nc -l -p 9995 > backup.img），不能用Powershell（备份传输完成后，校验的话就会发现用Powershell运行同样的命令会得到不一样的文件），因为这一条操作失误导致我刷OpenWrt后刷回原厂系统的过程中导致变砖我只刷了视频教程的固件，基本上是截至到当时最新的R23.5.1，2.5G网口和WiFi稳定的运行两周，这里先放下收集到的参数的对比，至少CPU的参数在当前WiFi6末期可刷机硬路由中基本上是第一档的
| 路由器 | CPU | RAM | ROM |
|---|---|---|---|
| Newifi Y1 | MT7620 1C@580MHz | 128MB | 16MB |
| K2P | MT7621AT 2C4T@880MHz | 128MB | 16MB |
| XDR6088 | MT7986A 12nm 4*A53@2.0GHz | 512MB DDR3 | 128MB |
| NX30 Pro | MT7981B 12nm 2*A53@1.3GHz | 256MB DDR3 | 128MB |
| Qnap-301w | IPQ8072A 12nm 4*A53@2.2GHz | 1GB DDR3-1600 | 4GB |
| K3 | BCM4709 40nm 2*A9@1.4GHz | 512MB DDR3-1600 | 128MB |
| N1 | S905D 28nm 4*A53@1.5Ghz | 2GB | 8GB |
上文提到Powershell下使用nc命令重定向的备份大小异常的问题，相关的原因查明在：Powershell与bash的重定向的差异，在搞清楚其中的原理后，我理解无法通过简单的操作使得备份还原，于是在论坛找到了别人的备份的mtdblock9尝试救砖，参考
因为我之前给T440s修改BIOS买了CH341A编程器和8pin的夹子，所以就鼓起勇气拆机，经过艰难的掰卡口后，很快就遇到了问题：
红米AX6000救砖中提到建议改CH341的输出电压为3.3v，这个要飞线，我没有工具：
我查了下ThinkPad BIOS芯片W25Q32V的datasheet，发现支持的也是2.7~3.6V，之前成功刷上了BIOS，通过不严谨的推测，不修改CH341的输出电压也能刷2.7~3.6V的F50L1G41LB
店家给的CH341的编程器刷写软件不支持F50L1G41LB，红米AX6000救砖中提到“NeoProgrammer不知道如何写入单独分区，我选择了SNANDer”：
最棘手的问题在于，F50L1G41LB相比W25Q32V，夹子的触点难以夹到芯片的针脚，无法稳定连接就无法写入，红米AX6000救砖中用的漆包线飞线
在OpenWrt官方23.05正式版支持XDR-6088的固件后，参考了TL-XDR6088/6086 刷入官方 Openwrt/Immortalwrt，原文已经记录的相当的详细，此处仅摘录用到的步骤（因为独立博客的域名过期之后就很可能找不到原文了）
本文写作时，最新的是23.05.0-rc3版。将来请用更新的稳定版本，目前Immortalwrt官方固件已经支持：
- 双 2.5Gb 网口的正常驱动（但LED灯还不亮）
- WiFi6 160Mhz
- 硬件流量分载
- WED (Wireless Ethernet Dispatch) 无线加速
- 硬件 NAT 加速
- Fullcone NAT
4.2 如果路由器已经刷了其它版本的 Openwrt
在 Openwrt 中运行
cat /proc/mtd，得到mtd设备的真实命名，再用命令来写入（将下面的BL2或FIP改成你在上面看到的名字，注意大小写）md5sum /tmp/preloader.bin mtd erase BL2 mtd write /tmp/preloader.bin BL2 mtd verify /tmp/preloader.bin BL2 md5sum /tmp/bl31-uboot.fip mtd erase FIP mtd write /tmp/bl31-uboot.fip FIP mtd verify /tmp/bl31-uboot.fip FIP注意查看上传的两个文件 md5 并和本地文件对比，查看两次 mtd verify 最后是否输出输出 Success，没问题才可进行下一步。
5. 通过 tftp 载入 recovery 镜像
这时候你可以拔掉路由器的电源，然后插上。直接拔电源可能是最安全的，因为如果你用 reboot 命令，可能会有一些后台程序运行（包括可能你之前在慌乱中没有杀掉的误操作了的 dd）导致路由器变砖。别问我是怎么知道的。
此时 tftp 服务器上应该已经有提示了，路由器在请求的文件名为 openwrt-mediatek-filogic-tplink_tl-xdr6088-initramfs-recovery.itb 。你只需要把结尾为 recovery.itb 的文件，改名为这个就行了。
如果没动静，你可以拔下电源，然后顶住 reset 孔不放，同时插入电源，应该会看到 LAN 口的灯齐闪一下。大约10秒钟，应该就会进入 recovery 模式。确保网线插在 1Gb LAN 口上，网口的灯应该会亮的。
前面提到了WiFi6 160MHz普及之后，局域网传输的瓶颈主要在千兆的有线网口上，考虑到外置USB网卡（USB 3.0外置网卡最大速率为5Gbps）可能因为发热等因素不稳定，首选的话还是PCIe的网卡，而且由于数据中心万兆网卡下架，市面上有较多的低成本的选择，在网络讨论的最多的是浪潮X540-T2拆机卡，价格大概70左右，特别之处在于PCIE插槽是X8+X1，如果要用的话x1要绝缘屏蔽，我实际使用发现卡兼容性不太好:
最后捡到一张180的带华为物料编码的x540，有几乎覆盖整个卡面的黑色散热片，插上群晖DS1621可以直接用，对于装了驱动的Z370-I也是
简单测了下，这张x540的空载功耗大约是8w，看卡背面的便签写着silicom PE210G2I40E，查到了silicom官网关于电口万兆网卡的功耗，找到了“电口功耗高”的依据：
PE开头的NIC（网卡）均为silicom官网上的网卡的功耗数据（均为所有端口Link/Idel 的功耗的整卡功耗），可以看到x540的功耗一骑绝尘，考虑到网卡的成本以及长期电费，最后我找了一张AQC107的网卡LREC6880BT，也把数据列到了下面：
| NIC | Controller | 无Link | GE | XGE | |
|---|---|---|---|---|---|
| PE310G2I50-T | X550-AT2 | 4.62W | 5.4W | 8.16W | x4 PCIe 3.0 |
| PE210G2I40-T | X540 | 7.23W | 7.92W | 14.28W | x8 PCIe 2.1 |
| PE310G2I71-T | X710-AT2 | 3.6W | 5.52w | 8.28W | x8 PCIe 3.0 |
| PE310G2I71 | X710BM2 | 3~4W | 4.6~4.8W | x8 PCIe 3.0 | |
| PE210G2SPI9A | 82599ES | 4~6W | 6W | x8 PCIe 2.0 | |
| LREC6880BT | AQC 107 | 网卡4.7W | x4 PCIe v2.1 |
数据中心下架的卡基本上都有些年头了，关于网卡的控制器、发布时间、制程、TDP，2022年末的二手价如下:
| NIC | Controller | TDP | Release | Process | Price |
|---|---|---|---|---|---|
| 华为SP230电 | X540-AT2 | 12.5W | 12Q1 | 40nm | 250左右 |
| Intel X550 | X550-AT2 | 11W | 15Q4 | 28nm | 1200左右 |
| Intel X710-T4 | XL710-BM1 | 7W | 15Q4 | 28nm | 2450 |
| X520-DA1 | 82599ES | 09Q2 | 65nm | ||
| LREC6880BT | AQC107 | 6W | 17Q4 | 28nm |
在网上看到说Intel的X540和X550在群晖的DSM系统中是免驱的（其实是DSM的Linux带了驱动），因为X550太贵，所以把目光投向了价格和功耗都合适的AQC107，因为群晖E10G18-T1 10G等群晖官方的万兆电口卡也是用的AQC107，我天真的以为第三方AQC107也是免驱的
网上我能找到两个中文的经验：
详细的要二次编译成功再补充，大概是下次DSM系统版本/内核版本更新
因为不涉及到后面的修改BIOS文件就能上64GB内存，这里直接上结论：
在我的平台上，用最新的3005的BIOS反而会导致莫名其妙的自动重启
因为在互联网上找不到Z370-I成功实践的经验，所以这里留个记录：
Asus Z370-I是一块ITX主板，只有两个内存插槽，装机的时候切好碰上DDR4内存天价，所以很长一段时间里只有双通道16GB 3000MHz，这块主板在官网上参数写着最大支持32GB内存，也就是2X16GB，然而随着内存降价，发现23年单条32GB的内存已经很便宜了，想着直接上到双通道64GB，以后这台机器退役也能当服务器用
因为是捡垃圾买到的“Fury DDR4 32GB 3200MHz”，想要知道超频情况，无法在thaiphoon burner中识别出具体的镁光颗粒，所以只能通过拆内存条散热马甲查看颗粒的FBGA Code（或者叫Market Code：颗粒第二行的编码，例如比较流行的镁光超频内存条C9BJZ），然后在官网Micron FBGA and component marking decoder查询，然而如下的丝印代码在官网是查不到的:
3CE22
Z9XJP
最后是在电子元器件网站上检索到了颗粒的型号（Part Number）：MT40A4G8VNE-062H ES:B；根据镁光的PART NUMBER命名规则表，可以获取到如下信息：
然后因为网上搜索不到相同的颗粒，所以超频抄作业可以不用想了，只能搜索到酷兽银甲单条32g 颗粒分析和超频也是叠die颗粒超频：“3200频率下1.45V时序可压c14-18-18-34，这里简单调了下一二时序，能效可以达到4.8w左右”，我看到了这个之后就按照文中提到的时序调整，实测不需要以上那样的参数，1.35v c14-18-18-32即可，其他的时序参考网上的超频教程进一步收紧，TM5跑不过就放开一点（tRFC为500），最后时延能控制在52ns左右（收紧的话可以49ns但是TM5报错）
我搜到了CHH的帖子：首发！Z170/Z370 突破内存64g可用的上限限制，精华在评论里，总结如下：
如何使 H310C/B365/Z370 的 BIOS 支持最大 128G 内存：
1.UEFITool提取SiInitPreMem模块，GUID为A8499E65-A6F6-48B0-96DB-45C266030D83 2.UEFITool搜索“C786….000000….00”，其中“..”为任意HEX值 3.第一处“….”不用理会，第二处“….”如果是“8000”那么就是最大64G，如果是“0001”就是最大128G 4.将“8000”修改为“0001”可破除64G限制 5.100/200系BIOS内也有此内容，理论上6-9代的IMC支持的内存没差，6700+Z170也能128G内存（已测试可行） 6.我这边看，MSI的Z370，18年底的BIOS还是8000，19年4月的BIOS就是0001了，ASUS的BIOS一水的都还是8000 7.ME 需要禁用（修改Flash Descriptor的HAP Bit，但要注意部分主板有校验不允许这么改，改后无法开机） 8.部分BIOS需设置 Chipset->System Agent (SA) Configuration->Above 4GB MMIO BIOS assignment->Disabled 不同 BIOS 位置不同，且可能被隐藏，无法直接修改
注：参考后面的引用，第七步为：将 0x102h的位置 +1
限制内存大小的字段，在我的主板上看到的是
# 3005 BIOS (2000 我觉得是单条16G，或者单DIMM 32G)
#Hex pattern "C786....000000....00" found as "C7866F25000000200000" in TE image section at header-offset 388FCh
C7 86 6F 25 00 00 00 20 00 00 EB 20
6A 00 56 E8 B4 E0 FE FF 59 59 0F B6
# 纯血的370ROG已经提供了128G的bios( 2021-2-15 )
# 3004 BIOS 2021-04-16 发生了变化，没有了老版的第二行
C7 86 6F 25 00 00 00 20 00 00 EB 20
# 1802 BIOS
C7 86 6F 25 00 00 00 20 00 00 EB 0A
C7 86 6F 25 00 00 00 80 00 00
# 1410 BIOS
Hex pattern "C786....000000800000" found as "C7866F25000000800000" in TE image section at header-offset 384ACh
C7 86 6F 25 00 00 00 20 00 00 EB 0A
C7 86 6F 25 00 00 00 80 00 00 8B C3
“18年底的BIOS还是8000，19年4月的BIOS就是0001了”的这一行去掉发生3004（更新日志：主要是添加了Win11的支持，没有提内存上线变化）,我找了M10H ROG MAXIMUS X HERO BIOS变更日志中有内存上限修改(Support Max DRAM Total Capacity up to 128 GB.)的新老BIOS看了下，也是去掉了8000这一行
这个问题能搜索到公开的文字信息不多，主要的问题是用了一段时间之后散热能力迅速衰减，比如新购入可以压制170w发热的CPU（已经开盖换液态金属），然而老化之后散热能力在CPU功耗80w左右温度就冲击100度，网上能搜索到的维修和拆解分析的经验：
我拆开水冷头之后，果然如上面引用所述是杂志堵塞了水冷头的微水道，用蒸馏水冲洗了几轮水路，最后换了蒸馏水之后散热能力重回170w，另外水冷的大风扇，对内存散热也要更友好（换用了一段时间的AXP100，内吹的时候内存太烫了）
介绍VLAN的基本概念和几种场景下的应用，而OpenWrt下VLAN处理机制和一般交换机有些不同，这里做了一个对比并给出了一种两台路由器之间的单线复用的方案
计算机网络的教材对VLAN一笔带过，作业的却要用到交换机互联，之前看的VLAN的文章貌似都对应不到OpenWrt上去，也就很难有实践的机会；下面根据个人在宿舍组网上遇到的问题，一步步来探究VLAN的用法
后面又看到了N1盒子基于VLAN的单臂路由，又做了一些补充
宿舍是上床下桌，每一张桌子下面有一个百兆的网口，通过负载均衡，很早就可以把网速跑到100Mbps了，这显然不够啊，因为宿舍WiFi是共用的，自然而然想到连接相邻的两个床位的网口，这样就有300Mbps了，这也是多线拨号的第一步
上图就是将LAN3与LAN4作双线接入，通过VLAN分别对应到eth0.3和eth0.4
此时LAN4与WAN是“直通”的，效果上来说，就是LAN4也可以插网线用电脑拨号了，如果是要给路由器做双线接入的话，则需要添加VLAN，再把一个LAN口添加到新VLAN中，最后建立接口拨号即可
然而舍友还是需要网口拨号的，所以如果需要长期占用的话偶尔肯定是不太方便的，所以需要交换机来扩展一下网口，这一步已经可以通过简单的修改下OpenWrt路由器的Switch来实现，將LAN4和WAN划到同一个VLAN，两个接口就相当于在同一交换机下：
然而，仅仅通过untagged只能实现多条线路的“汇聚”，能够达到100Mbps+的只有一台路由器而已，并没有实现“互通”，即每一台路由器都可以上到100Mbps+；不仅如此，还要实现相邻床位的路由器之间只用一根线连接就可以达到同样的网速，更具体的就是在一根网线传输不同的来源（网口）的数据
而VLAN的一个重要的功能恰好就是实现交换机之间的互通
这个需求源于有一台N1，之前看过VLAN的接入网络的方法，觉得网络结构更清晰，以此可以解决主路由算力不足的问题，但之前一直没有刷上OpenWrt，刷完之后发现居然没有交换机的Switch选项，赶紧翻出了之前看到的帖子：N1做主路由，新3做AP的最正统vlan连法教程，想起之前文档刚好有部分没看懂，刚好可以补充上
首先还是OpenWrt的文档：VLAN，很早就读过，但是因为缺少具体的有解释的例子，当时没弄清楚VLAN tagged的机制
所以这里先结合华为的文档了解下基础的概念
首先需要理解VLAN标签是被添加到以太帧内部的一个4个字节的片段，其中VID也就是常说的VLAN ID
在一个VLAN交换网络中，以太网帧主要有以下两种形式：
常用设备中：
VID也就是数据帧中的12bit的VLAN ID，表示该数据帧所属VLAN的编号，而PVID（Port Default VLAN ID）又称为缺省VLAN，可以用于和VID做比较来判断Tag的情况
最主要的应用是划分广播域，这部分可以参考图文并茂VLAN详解，然而和本文的关系不是很大
为了提高处理效率，设备内部处理的数据帧一律都是Tagged帧，例如在交换机内部的，在数据帧进入交换机的时候可能会按照一定的规则被打上VLAN Tag以方便下一步的处理，OpenWrt的Old Wiki的一张图很好地体现了这一点：
以太帧进入端口后被打上VLAN Tag，之后在传输的CPU的线路内（Port5-CPU），就同时传输带两种VLAN Tag的包
另外在交换机之间，可以在一条链路上使用两个VLAN也叫做Ethernet trunking，也有人称作单线复用，常见的应用：
这里参考的是上面的华为的交换机的文档，不同交换机可能有些不一样
以收发的设备作为主体，指的是数据帧到达接口而没有完全进出交换机内部，举个例子：
配置VLAN：为了适应不同的连接和组网，设备定义了Access接口、Trunk接口和Hybrid接口3种接口类型，以及接入链路（Access Link）和干道链路（Trunk Link）两种链路类型，如下图所示
根据接口连接对象以及对收发数据帧处理的不同，以太网接口分为：
Access接口一般用于和不能识别Tag的用户终端相连，只能收发Untagged帧，且只能为Untagged帧添加唯一VLAN的Tag
Trunk接口一般用于连接交换机、路由器、AP以及可同时收发Tagged帧和Untagged帧的语音终端。它可以允许多个VLAN的帧带Tag通过，但只允许一个VLAN的帧从该类接口上发出时不带Tag（即剥除Tag）
Hybrid接口可以允许多个VLAN的帧带Tag通过，且允许从该类接口发出的帧根据需要配置某些VLAN的帧带Tag（即不剥除Tag）、某些VLAN的帧不带Tag（即剥除Tag）
Hybrid接口和Trunk接口在很多应用场景下可以通用，但在某些应用场景下，必须使用Hybrid接口。比如一个接口连接不同VLAN网段的场景（如图所示的Router连接Hub的接口）中，因为一个接口需要给多个Untagged报文添加Tag，所以必须使用Hybrid接口。
OpenWrt对VLAN Tag的处理机制见后文引用文档的加粗部分，此处暂作为理解的参考
OpenWrt的文档没怎么提及接口类型的概念，OpenWrt对VLAN设置的组织形式和普通的交换机有所不同，从机制介绍来看是比较接近Trunk端口的：发出的数据帧只有一个VLAN的数据帧不带Tag
OpenWrt文档所提到的：An untagged port can have only 1 VLAN ID 反映在：OpenWrt中的Switch设置VLAN时单个untagged Port无法再再其他VLAN上为Untagged，否则回提示：LAN 1 is untagged in multiple VLANs!
故抛开之前的端口类型，遵守VLAN的规则，兼容且实用就行
另外，不是所有OpenWrt设备都有Switch这个LuCI的配置选项，比如N1就没有，但是照样可以配置VLAN，位置在Interface的接口物理配置部分，由于无法像Switch那样有Tag之类的选项，
官方文档对Tag机制的介绍如下(散落在两处):
- Tagged on “CPU (eth0)” means that the two VLAN ID tags used in this example (1, 2) are sent to the router CPU “as tagged data”. Remember: you can only send Tagged data to VLAN-aware devices configured to deal with it properly.
- Untagged means that on these ports the switch will accept only the incoming traffic without any VLAN IDs (i.e. normal ethernet traffic). The switch will remove VLAN IDs on outgoing data in such ports. Each port can only be assigned as “untagged” to exactly one VLAN ID.
- Off: no traffic to or from the tagged ports of this VLAN ID will reach these ports.
Ports can be tagged or untagged:
- The tagged port (t is appended to the port number) is the one that forces usage of VLAN tags, i.e. when the packet is outgoing, the VLAN ID tag with vlan value is added to the packet, and when the packet is incoming, the VLAN ID tag has to be present and match the configured vlan value(s).
- The untagged port is removing the VLAN ID tag when leaving the port – this is used for communication with ordinary devices that does not have any clue about VLANs. When the untagged packet arrives to the port, the default port VLAN ID (called pvid) is assigned to the packet automatically. The pvid value can be selected by the switch_port section.
特别指出，但是一般也用不上，在LuCI界面上看不到的PVID设置，设置具体在uci network switch_port部分：
Port PVID; the VLAN tag to assign to untagged ingress packets
官方文档的位置在 Creating driver-level VLANs 一节，配置方式是通过在接口设置，选择自定义接口，在名称在做文章：如在物理网卡eth1上，通过自定义eth1.2接口的方式建立一个VLAN ID为2的接口，在使用Switch设置VLAN，如添加VLAN ID为3的VLAN之后，接口处也会出现eth0.3，逻辑上还是统一的；下面来看下文档对处理机制的描述：
If the incoming packet arrives to the interface with software VLANs (incoming packet to eth1) and has a VLAN ID tag set, it appears on the respective software-VLAN-interface instead (VLAN ID 2 tag arrives on eth1.2) – if it exists in the configuration! Otherwise the packet is dropped. Non-tagged packets are deliveded to non-VLAN interface (eth1) as usual.
即处理流入的包：接口只接收有相应Tag的包，相当于Switch中的VLAN在该接口设置为Tag
这样一来，一个物理网口可以同时收发带Untagged帧和Tagged帧，故使用VLAN来实现单臂路由也就很好理解了，配置的方式也不唯一
回到本文开头提到的问题，仿照上面的Switch内部VLAN机制的图的形式，画了一张两台OpenWrt路由器通过VLAN互通，进而实现让两台路由器可以得到宿舍三个网口合计300Mbps的接入
需要说明的是：
最后的在宿舍的书桌背后的路由器如图
以下方法经本人验证通过，环境如下：
Win10 下安装Ubuntu 20.04.4 LTS
Boos4721 的固件
前言：家中主路由器为小米AX3600路由器，为实现一些个人需求，因此一直刷的是论坛上他人编译好的Openwrt固件，近期因有一些个人需求该固件并不支持，思来想去，决定自己编译。
第一步：安装ubuntu 20.04.4 LTS
首先使用管理员身份运行windows Power-Shell,执行以下命令后重启
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
然后在Microsoft Store 搜索 ubuntu 20.04.4 LTS 并安装，安装完成后点击打开，新建一个用户名及密码即可
第二步：设置代理
考虑到网络环境，建议将V2ray设置全局代理
然后将win10的V2rayN软件参数设置里面勾选“允许来自局域网的连接”
接着，在 ubuntu 20.04.4 LTS 中，输入命令 vim .bashrc，编辑配置文件，在文件中加入以下内容后保存
# proxy list alias proxy='export http_proxy=socks5://127.0.0.1:10808; export https_proxy=socks5://127.0.0.1:10808' alias unproxy='unset http_proxy; unset https_proxy'
10808是win10中v2ray的监听端口，可依据自己配置修改
最后命令行输入 proxy 即可开启代理
第三步：更新软件包列表和软件包
依次输入以下命令
sudo apt-get update
sudo apt-get -y install build-essential asciidoc binutils bzip2 gawk gettext git libncurses5-dev libz-dev patch python3 python2.7 unzip zlib1g-dev lib32gcc1 libc6-dev-i386 subversion flex uglifyjs git-core gcc-multilib p7zip p7zip-full msmtp libssl-dev texinfo libglib2.0-dev xmlto qemu-utils upx libelf-dev autoconf automake libtool autopoint device-tree-compiler g++-multilib antlr3 gperf wget curl swig rsync
第四步：获取源代码并配置
输入以下命令获取Boos4721的固件
git clone -b stable https://github.com/Boos4721/openwrt
进入目录
cd openwrt
更新源
./scripts/feeds update -a ./scripts/feeds install -a -f
进入定制界面进行个性化配置
make menuconfig
选择 IPQ8097x , AX3600
进入LuCI 的 Applications 自定义所需的插件
最后Save保存配置即可
第五步：编译
输入以下命令下载DLL库、编译，-j16表示16线程，我使用的16线程，供参考
make -j16 download V=s
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin make -j16 V=s
编译完成后win10文件资源管理器中输入如下地址即可看到编译好的固件
\\wsl$\Ubuntu-20.04\home\xxx(第一步创建的用户名)\openwrt\bin\targets\ipq807x\generic
如果您喜欢这篇文章，或者它给您带来了帮助，您可以请我们喝一杯咖啡，我们将非常感谢您的支持！
