While flashing WR3000s there was a clumsy power cut.
What is my best course of action to bring it back to life, or is it a total loss?
Cudy routers can be restored with OEM software using TFTP. It's pretty easy. After this you can reinstall OpenWrt.
Thanks! Pity they don't have instructions for people on other platforms than windows, like linux. Will be for the weekend …
It's pretty much the same, and I would assume that a Linux user would be more aware of TFTP than a Windows user 
There's a TFTP server built into dnsmasq, if you have an additional Openwrt device, you already have everything you need (but will most likely require an IP change).
recovered, thank you!
Other question, does the uboot version work like normal uboot? Press reset and be offered uboot window to update the firmware?
Don't think it's documented anywhere - Cudy WR3000P unusable after 25.12.2 update. What went wrong? - #13 by konus.
Thanks. Is it possible the reset button one day can do uboot GUI instead of cudy tftp method? Are you guys working on that? (I wouldn't have a clue how to)
Uboot isn't Openwrt, if there's already a built in GUI, it's only a matter of enabling it.
If not, someone would have to write it.
The commit only describes a partition layout change, and how to flash. AFAIK there is no custom GUI involved. Unless you have a specific need for ubootmod, I would recommend to keep the device in its original layout.
If I understood @frollic 's link comment, default reset button behavior doesn't work anymore. Hence restoring the device will imply a serial access.
I think me and kronus (mainly them) concluded reset button at boot triggers initramfs poll over TFTP.
Ok, so it should still work. Good to know just in case.
I put the ubootmod code into chatgpt and it drew this flowchart.
Here's the boot flow represented as a text flowchart:
Power On
│
▼
U-Boot Environment
│
▼
run _firstboot ? (first init)
│
▼
run boot_first
│
┌────────────┴────────────┐
│ │
▼ ▼
Reset button pressed? No reset
│ │
Yes │ │
▼ ▼
Turn on recovery LED Show boot menu
│
▼
boot_tftp_recovery
(load recovery via TFTP)
│
▼
set flag_recover=1
│
▼
run boot_default
│
▼
flag_recover exists?
│
┌───────┴────────┐
│ │
Yes No
│ │
│ ▼
│ run bootcmd
│ │
│ ▼
│ pstore check succeeds?
│ │
│ ┌────────┴────────┐
│ │ │
│ Yes No
│ │ │
│ ▼ ▼
│ boot_recovery boot_ubi
│ │
│ ▼
│ boot_production
│ │
│ Production OK?
│ │
│ ┌──────────┴─────────┐
│ │ │
│ Yes No
│ │ │
│ ▼ ▼
│ Boot Linux boot_recovery
│ │
│ Recovery OK?
│ │
│ ┌───────────┴──────────┐
│ │ │
│ Yes No
│ │ │
│ ▼ ▼
│ Boot Linux boot_tftp_forever
│ │
│ ▼
│ Infinite TFTP Recovery
│ (retry every second)
│
▼
boot_recovery
│
Recovery OK?
│
┌──────┴──────┐
│ │
Yes No
│ │
▼ ▼
Boot Linux TFTP Recovery Loop
Normal Boot Path
In the healthy case:
Power On
│
▼
bootcmd
│
▼
pstore check fails (normal)
│
▼
boot_ubi
│
▼
boot_production
│
▼
Read UBI volume "fit"
│
▼
bootm
│
▼
OpenWrt starts
Recovery Path
If the production image is damaged:
boot_production
│
▼
ubi_read_production fails
│
▼
boot_recovery
│
▼
ubi_read_recovery succeeds
│
▼
bootm recovery image
│
▼
Recovery OpenWrt starts
Last-Chance Recovery
If both production and recovery are damaged:
boot_production fails
│
▼
boot_recovery fails
│
▼
boot_tftp_forever
│
▼
while true:
tftpboot recovery.itb
boot image
sleep 1
This router effectively has three layers of protection:
- Production firmware (
fitUBI volume) - Recovery firmware (
recoveryUBI volume) - Network recovery via TFTP (infinite retry loop)
That's why this particular OpenWrt U-Boot mod is very difficult to permanently brick unless the BL2/FIP bootloader partitions themselves become corrupted.
This should be on a wiki page about ubootmod.
yes I think that is a good idea. I've got a wiki login but never added an article on there. I find the interface confusing / not very intuitive.
Edit: I've started a wiki article over here: