返回博客列表

Cudy TR3000 256MB：过渡包→解锁 FIP→写入 U-Boot→maximum-240m 布局的刷机与校验流程

2026年1月16日 | Ruichen Zhou | 约 16 分钟阅读
OpenWrtImmortalWrtU-BootCudy TR3000MT7981刷机

Cudy TR3000 256MB：过渡包→解锁 FIP→写入 U-Boot→maximum-240m 布局的刷机与校验流程

本文记录一次在 Cudy TR3000 256MB v1（MT7981） 上的刷机实践：按教程从原厂固件刷入“过渡包”，再刷入 可写 FIP 的解锁环境，随后把第三方 U-Boot 写入 FIP 分区，最后在 U-Boot Web 中选择 maximum-240m 布局并刷回稳定可用的系统固件。

这篇文章面向以下场景：

  • 你有一台 TR3000 256MB，希望获得一个可用的 U-Boot Web 恢复入口（便于后续刷机、切换布局、救砖）。
  • 你希望把闪存布局切到 maximum-240m 以充分利用 256MB NAND。
  • 你希望执行过程尽量可控：每一步都有校验点、能停下来确认，而不是“一把梭”。

⚠️ 警告：本文涉及对 FIP 分区写入 U-Boot。写错文件或中途断电可能导致无法启动，需要串口或更底层手段恢复。请在执行前确保已经备份关键分区，并保证供电稳定。

本文的特点：完整备份和检查

常见教程的“最短路径”一般是：

  1. 原厂固件 → 刷 过渡包
  2. 过渡包 → 直接刷 FIP 分区只读破解包/解锁环境
  3. 解锁环境 → 写入 U-Boot（FIP）
  4. 进入 U-Boot Web → 选布局 → 刷入想用的固件

本文确实走了这条主线，但中间多了一步：刷完过渡包后，我又刷了一次官方 OpenWrt 24.10.5，后来想补齐 U-Boot 才回到解锁环境写入 FIP，因此比“最短路径”多了一个步骤。

为了避免读者误解，本文会在流程中明确哪些步骤是必要步骤，哪些是本文因为“中途先上系统再回头补 bootloader”而产生的可省略步骤。

环境与前提

机型与分区识别（必须确认）

设备信息应明确是 256MB v1（而不是 128MB 或特殊批次）：

ubus call system board
cat /proc/mtd

关键分区示例（cat /proc/mtd）：

mtd0: 00100000 ... "BL2"
mtd1: 00080000 ... "u-boot-env"
mtd2: 00200000 ... "Factory"
mtd3: 00040000 ... "bdinfo"
mtd4: 00200000 ... "FIP"
mtd5: 0e600000 ... "ubi"

其中：

  • BL2 = 1MiB
  • FIP = 2MiB

这两项会直接决定后续备份与写入命令里的 count/文件大小预期。机型不匹配、分区大小不一致时不要继续。

文件准备（强制按机型匹配）

本文涉及三类文件（示例文件名）：

  1. 过渡包（256MB 版本） cudy_tr3000-256mb-v1-sysupgrade.bin

  2. FIP 分区只读破解包 / 解锁环境（256MB 对应 sysupgrade） immortalwrt-24.10.3-mediatek-filogic-cudy_tr3000-256mb-v1-squashfs-sysupgrade.bin

  3. 第三方 U-Boot（写入 FIP 的 bin） dhcp-mt7981_cudy_tr3000-fip-fixed-parts-multi-layout-256M.bin

此外，本文最终回到系统使用的是：

  • openwrt-24.10.5-mediatek-filogic-cudy_tr3000-256mb-v1-squashfs-sysupgrade.bin

⚠️ 重点提醒：目录里往往会混有 128MB、或特定 SN（例如 2544）专用文件。本文对象是 256MB，不要把 128MB 文件（或 2544 专用）写入到 256MB 设备。

总体流程概览（标注可省略项）

标准最短路径（多数教程推荐）

  1. 原厂固件 → 刷入 过渡包
  2. 过渡包 → 直接刷入 解锁环境（FIP 只读破解包）
  3. 解锁环境 → 备份关键分区 → 写入 U-Boot（FIP） → verify
  4. 进入 U-Boot Web → 选布局（例如 maximum-240m）→ 刷入目标固件

本文实际路径（多了一步“先上官方系统”）

  1. 原厂固件 → 过渡包（与最短路径一致）
  2. 过渡包 → 官方 OpenWrt 24.10.5（可省略）
  3. 官方 OpenWrt → 发现 FIP 不可写 → 再刷解锁环境（回到主线）
  4. 解锁环境 → 写入 U-Boot（FIP）→ verify
  5. U-Boot Web → maximum-240m → 刷回官方 OpenWrt 24.10.5

结论：过渡包后不一定要刷官方固件。 过渡包的核心作用是“为后续刷解锁环境创造条件”。若你的目标是补齐 U-Boot，一般从过渡包直接进入解锁环境更省事。

Step 0：参考资料与原始教程

本文的过渡包刷机步骤参考了这篇文章（后续也有多处流程一致）：

Step 1：原厂固件 → 刷入过渡包（必要步骤）

操作入口

进入原厂管理后台（一般在“高级设置/固件升级”等位置），上传并刷入过渡包：

  • cudy_tr3000-256mb-v1-sysupgrade.bin

刷入后的检查点

  1. 重启后能进入过渡包页面（常见为 OpenWrt/类 OpenWrt 界面）
  2. 能 SSH 登录并查看基础信息：
cat /etc/openwrt_release
ubus call system board

为什么需要过渡包

过渡包的价值通常在于：

  • 让设备进入一个“可继续 sysupgrade”的环境；
  • 为下一步刷入 FIP 分区只读破解包/解锁环境（从而写入 U-Boot）打通路径。

Step 2：过渡包 → 解锁环境（多数情况下可直接做）

这一步可以省略官方固件

很多教程在过渡包之后，直接在 LuCI 的“备份/升级”里刷入解锁环境：

  • immortalwrt-24.10.3-...-cudy_tr3000-256mb-v1-...-sysupgrade.bin

并且强调：

  • 不要勾选“保留配置”（跨环境升级最容易引发配置兼容问题）

刷入后的检查点

解锁环境启动后（本文示例 IP 为 192.168.6.1），确认：

ubus call system board | grep -E 'model|board_name|revision' -n

输出里应出现：

  • model: Cudy TR3000 256MB v1
  • board_name: cudy,tr3000-256mb-v1

Step 2.1：本文多做了一步：过渡包 → 官方 OpenWrt 24.10.5（可省略）

本文当时的选择是：刷完过渡包后，先把系统升级到官方稳定版 OpenWrt 24.10.5 并开始使用。后来决定补齐 U-Boot，才又回头刷解锁环境写入 FIP。

这一步的意义仅在于：

  • 提前得到一个可用、稳定的 OpenWrt 系统；
  • 但对“补齐 U-Boot”来说并不是必要步骤。

Step 3：关键分区备份（强烈建议，属于“安全流程”的核心）

这一步的目的：为写入引导相关分区提供回退条件。至少建议备份：

  • BL2（mtd0）
  • u-boot-env（mtd1）
  • Factory（mtd2）
  • bdinfo（mtd3）
  • FIP（mtd4）

在路由器上执行（示例以 /tmp 为落盘位置）：

cd /tmp

# BL2: 1 MiB
dd if=/dev/mtd0ro of=backup_BL2.bin bs=64k count=16

# u-boot-env: 512 KiB
dd if=/dev/mtd1ro of=backup_uboot_env.bin bs=64k count=8

# Factory: 2 MiB
dd if=/dev/mtd2ro of=backup_Factory.bin bs=64k count=32

# bdinfo: 256 KiB
dd if=/dev/mtd3ro of=backup_bdinfo.bin bs=64k count=4

# FIP: 2 MiB
dd if=/dev/mtd4ro of=backup_FIP.bin bs=64k count=32

sync
ls -lh /tmp/backup_*.bin

备份后的检查点

预期看到类似大小：

  • backup_BL2.bin：1.0M
  • backup_uboot_env.bin：512K
  • backup_Factory.bin：2.0M
  • backup_bdinfo.bin：256K
  • backup_FIP.bin：2.0M

如任一文件大小不符合预期，不要继续写入。

下载到本机（避免 sftp-server 坑）

Windows scp 有时会默认走 SFTP，路由器缺少 sftp-server 会失败。解决是强制旧 SCP：

scp -O root@192.168.1.1:/tmp/backup_*.bin .

Step 4：在官方 OpenWrt 环境里尝试写 FIP 失败（解释“为什么要刷解锁环境”）

在官方 OpenWrt 24.10.5 下尝试：

mtd unlock FIP

可能出现：

Could not open mtd device: FIP

这说明：当前系统环境下 mtd 无法以读写方式打开引导相关分区。此时不应强行写入（避免误判），而应该切换到“可写 FIP 的解锁环境”。

这也是本文最终刷入 ImmortalWrt 解锁环境的原因。

Step 5：上传 U-Boot bin、校验、写入 FIP、verify（核心步骤）

5.1 本机先算 SHA256（作为后续一致性标准）

(Get-FileHash ".\dhcp-mt7981_cudy_tr3000-fip-fixed-parts-multi-layout-256M.bin" -Algorithm SHA256).Hash

示例：

CC580152DDBEEF14A204DE296D8F58D7A21D787B3DE80573BCE09FEE090DBD4C

5.2 上传到解锁环境（示例 IP 192.168.6.1）

scp -O ".\dhcp-mt7981_cudy_tr3000-fip-fixed-parts-multi-layout-256M.bin" root@192.168.6.1:/tmp/

5.3 路由器端校验文件存在与 SHA256（写入前必须做）

ls -lh /tmp/dhcp-mt7981_cudy_tr3000-fip-fixed-parts-multi-layout-256M.bin
sha256sum /tmp/dhcp-mt7981_cudy_tr3000-fip-fixed-parts-multi-layout-256M.bin
cat /proc/mtd | grep -w FIP

检查点：

  • 文件大小约 733K，且 明显小于 FIP 的 2MiB
  • sha256 与本机一致
  • FIP 分区存在且大小为 00200000

5.4 解锁与写入（高风险操作）

⚠️ 警告：确认供电稳定、不要断电。 下面操作写入引导相关分区，执行前再次确认文件与机型匹配。

mtd unlock FIP
mtd write /tmp/dhcp-mt7981_cudy_tr3000-fip-fixed-parts-multi-layout-256M.bin FIP
sync
mtd verify /tmp/dhcp-mt7981_cudy_tr3000-fip-fixed-parts-multi-layout-256M.bin FIP

必须看到 mtd verify ... Success 才能继续重启。

Step 6：进入 U-Boot Web，选择布局 maximum-240m，并刷入目标系统

写入成功后重启，设备进入 U-Boot Web（也可通过按住 Reset 上电进入），浏览器访问 http://192.168.1.1。

选择 mtd 布局

本文最终选择：

  • maximum-240m

这是 256MB NAND 更符合预期的空间利用方式。

刷入目标系统固件

本文刷入的是：

  • openwrt-24.10.5-mediatek-filogic-cudy_tr3000-256mb-v1-squashfs-sysupgrade.bin

刷完重启后进入 OpenWrt 24.10.5，系统正常运行。

常见错误与排查思路

1) scp 报 sftp-server: not found

原因：Windows scp 默认走 SFTP，路由器不带 sftp-server。 解决：使用 -O 强制旧 SCP：

scp -O <本地文件> root@<IP>:/tmp/

2) mtd unlock FIP 在官方 OpenWrt 下失败

现象：Could not open mtd device: FIP 思路：不要硬写；切换到解锁环境（FIP 可写的固件）后再操作。

3) mtd verify 写入前 Failed 是正常的，写入后 Failed 才需要停

  • 写入前 verify：失败说明“还没写进去”，属预期
  • 写入后 verify：失败说明写入未生效/文件不匹配，应立即停下排查

总结

这次操作的“特色”不在于刷了多少次固件，而在于把高风险过程拆成了一组可复核的检查点：

  1. 机型与分区信息先确认 ubus call system board + cat /proc/mtd，确保是 256MB v1，确认 BL2/FIP 分区大小。

  2. 写入引导分区前先备份 BL2/FIP/Factory/bdinfo/u-boot-env 至少五项备份并落到本机，避免“写坏后无回退”。

  3. 文件一致性三段校验

    • 本机计算 SHA256
    • 上传后路由器 sha256sum 对照
    • 写入后 mtd verify 确认 Success 每一步都能停下来判断是否继续，而不是依赖“看起来没报错”。

  4. 不追求最短路径，但明确哪些步骤可省略 过渡包之后可以直接刷解锁环境完成 U-Boot；本文因为先上了官方系统又回头补 bootloader，导致步骤更多，但检查点更完整。

若以后再次操作类似设备，我会更倾向于：

  • 先按最短路径补齐 U-Boot 与布局；
  • 再刷入长期使用的系统固件；
  • 但无论路径如何，检查点（机型/分区/备份/校验/verify）必须保留。