Set your computer to use 10.10.10.254 as its IP address
With your router shut down, hold down the power button until the first
white LED lights up.
Push and hold the reset button and release the power button. Continue
holding the reset button for 30 seconds or until it begins searching
for files on your TFTP server, whichever comes first.
The router (10.10.10.128) will look for your computer at 10.10.10.254
and install the two files. Once it has finished installation, it will
automatically reboot and start up OpenWrt.
On the long term, wouldn't it be better if we had a working mainstream u-boot for these RAVPower/HooToo devices? I understand that it would make restoring the devices to factory firmware harder, but it would also allow us to establish a custom (and proper!) MTD layout, stripping out the manufacturer's idiocy (swapping up factory and u-boot-env partitions' usage, pushing u-boot-env between kernel and rootfs, or limiting kernel to 1.5MB, just to name a handful). After all, porting OpenWrt to a device shouldn't just be "made it boot with factory everything", but to provide actual support of the hardware, often ignoring the software fallacies of the manufacturer.
The RP-WD009 apparently already boots from mainline U-Boot versions, and I don't think the WD03/HT-TM05 is too much different, given they're all products of SunValleyTek - same engineering department, same development mistakes, and so on. Especially for continued support, I think we should roll an OpenWrt-specific U-Boot with these stupid limits removed.
As blocktrron said earlier, this is something for a community build, IMHO.
A working mainstream u-boot is a valuable thing, but in this case it's not better compared to current support of HT-TM05.
Current implementation removes all limitations and works around all the idiocy of SunValleyTek and brings almost 100% device support in exchange of 64 K (but at least 4 K) wasted space:
Tested and working:
- Ethernet
- 2.4 GHz WiFi (Correct MAC-address)
- Installation from TFTP (recovery)
- OpenWRT sysupgrade (Preserving and non-preserving), through the usual
ways: command line and LuCI
- LEDs (except as noted above)
- Button (reset)
- I2C, which is needed for reading battery charge status and level
- U-Boot environment / variables (from U-Boot, and OpenWrt)
Could someone (@xabolcs perhaps?) please take care of the devicepage https://openwrt.org/toh/ravpower/ravpower_rp-wd03 and update the installation procedure (and maybe write down the back to stock procedure which is currently only linked to the forum)? It's better when someone with this device in his hands does this
And I still disagree with that sentiment. The point of OpenWrt support shouldn't be "eh, it boots, it mostly works, it's fine", but to actually properly create support for said device, in certain cases including the replacement of the bootloader.
I agree that unnecessary changes should be avoided, but to me it feels like this is a necessary change for full support. Not to mention that there are other devices that require the replacement of the bootloader - e.g. the Mi Router 3/3G.
The current support is a hacky software layer solution to combine 3 partitions. I'm not sure about the performance impact of this (since an extra bit of software needs to manage the blocks), but it requires extra loader support, extra bits of software that otherwise would be unnecessary... I understand that you've worked a lot on getting OKLI working on the WD03/TM05, but why do that when a simple mainstream u-boot build with the right partition map would've fixed the issue right off the bat? Especially since we have official sources for u-boot right from SunValleyTek.
@tmomas for officially supported devices, would it be possible to host the official firmware for the back-to-stock steps? RAVPower has had issues with their site before, and generally I'd feel more secure if there was a known good backup on OpenWrt side.
I'm really hesitant regarding hosting OEM firmwares on OpenWrt servers.
I see it as the OEMs duty to provide his firmware on his servers, and I would like to avoid creating a precedent. If we would create a precedent, then suddenly all cheapo manufacturers around the world which are unable or unwilling to provide an OEM firmware download service to their paying customers could lay back and say "Why should we care about own servers, when OpenWrt hosts our OEM firmware for free?".
I understand the hesitance, however as it has happened before, it's not too unlikely for smaller brands like RAVPower to go under suddenly, removing all resources available. I'm obviously not suggesting hosting all OEM firmwares, more like a "conversion kit" that returns the device to the earliest supported OEM firmware. Definitely not meant to host the latest OEM firmware, just a backup in case hits the fan.
Aside from the precedent, and the legal issues the vendor could bring up (distributing trademarked material) - hosting would imply distribution, which would impose and extend the burden of license compliance for the OEM firmware to OpenWrt as well (GPL compliance, does a GPL tarball exist and is it complete). This really isn't a good idea, nor viable.
hits the fan.
).
.
.