I am still wondering a bit as the change log of 22.03.3 lists a few new router models that were added.
Thanks for offering to provide a new sysupgrade image. That might help people who buy this router at the moment as v1 is not on sale any longer. I was able to use the diff from 22.03.2 for 22.03.3 and compiled the image. Your changes still work like a charm. 
I leave here a sysupgrade binary for those who do not want to compile the binary.
I have the v3 version and the v2 version (snapshot) doesn't boot.
The Cudy provided openwrt version (same file for v2/v3) works fine.
It reports to be:
OpenWrt 22.03.0, r19685-512e76967f
However I can not use openwrt provided kernel modules with it:
root@OpenWrt:~# opkg install kmod-l2tp-eth
Unknown package 'kmod-l2tp-eth'.
Collected errors:
Any help, please?
can't use openwrt kernel modules with a custom built Cudy image/kernel.
For the record. I have rebuilt the image from source code and modified the v2 dts file so the SPI frequency is 10MHz, as per original Cudy dts v2/v3 file, not 80MHz as in the source code taken from v1:
Now, everything is fine and the snapshot is booting on v3 version without a problem.
It seems to me that the v3 does not support 80Mhz because I know of another case like yours, but it does support 40Mhz.
Try setting 40Mhz. It will work just as well and will run a little better.
Actually, I have had the router boot up with 80 MHz like maybe 1:10 times, but when it finally did I got loads of SPI error messages in dmesg:
> [ 7.225356] random: ubusd: uninitialized urandom read (4 bytes read)
> [ 7.233649] random: ubusd: uninitialized urandom read (4 bytes read)
> [ 7.240742] random: ubusd: uninitialized urandom read (4 bytes read)
> [ 7.250768] procd: - init -
> [ 7.683426] SQUASHFS error: xz decompression failed, data probably corrupt
> [ 7.690389] SQUASHFS error: Failed to read block 0x20f92c: -5
> [ 7.696165] SQUASHFS error: Unable to read fragment cache entry [20f92c]
> [ 7.702913] SQUASHFS error: Unable to read page, block 20f92c, size 33ec
> [ 7.709654] SQUASHFS error: Unable to read fragment cache entry [20f92c]
> [ 7.716428] SQUASHFS error: Unable to read page, block 20f92c, size 33ec
> [ 7.723215] SQUASHFS error: Unable to read fragment cache entry [20f92c]
> [ 7.729943] SQUASHFS error: Unable to read page, block 20f92c, size 33ec
> [ 7.736727] SQUASHFS error: Unable to read fragment cache entry [20f92c]
> [ 7.743477] SQUASHFS error: Unable to read page, block 20f92c, size 33ec
> [ 7.750265] SQUASHFS error: Unable to read fragment cache entry [20f92c]
> [ 7.757029] SQUASHFS error: Unable to read page, block 20f92c, size 33ec
With 10 MHz it runs comparably fast to other mt7621 based routers (Tplink Archer C6, Xiaomi Mi 4A).
So, as the spi errors come gradualy with clock speed increase (and may be related to other factors like pcb temperature) I'll rather stick to safe 10 MHz instead of giving chances 
Stability first.
Well it must be a v3 problem, I have a v2 at 80Mhz and have never had a single SPI problem. In fact I have a log file of the router with all the history of the router (since I put it to work the first time) and nothing.
Do you regularely check the kernel logs for file system errors, so that you can definitely rule out any SPI issues?
[edit] Oops, sorry I had overlooked what you wrote about the log file, but that doesn't invalidate the rest of my post. [/edit]
I've seen cases of my v1 device showing such errors without any apparent malfunction of the device, so the SPI hickups might not always be visible although they are there.
Secondly I think the different versions of the WR1300 (especially v2 and v3) are so similar that it would be a surprise if only v1 and v3 devices are affected by these SPI problems, but not a single v2 device. I rather think that the 80 MHz are so close to the limit of the board design that it is a matter of individual devices whether it works or not, depending on deviation of the electronic parts and operating conditions.
But given that precompiled binaries from downloads.openwrt.org should absolutely work for each and every copy of the WR1300, I strongly propose to lower the default to 40 MHz. Otherwise you force inexperienced users to self-compile or give up on OpenWrt for the convenience of experienced users who want to drive their devices to the limit, but would self-compile their images anyway.
I even doubt that this has much influence at operation speed or boot time, because the boot loader loads the kernel and initrd at only 10 MHz anyway and during normal operation the working set of the flash content is cached in RAM.
Yes. I actually have the full device log (I rlog it to another machine so nothing is lost) and I have re-audited that log, no problems.
There are at least 3 cases of v2 (all that I know of) that do not fail at 80Mhz. Anyway, it is clear that if you want to get to a firware that works in v2 and v3 you would have to change the value from 80Mhz to 40Mhz.
I'm a little busy these days. I don't know if you can send a merge request with the change in the repository https://github.com/openwrt/openwrt (and the moment you do it I'll give it my vote) if not I'll try to do it in the next days.
What is the point of sticking to 40 MHz 'it works on the devices I have' instead of using manufacturer provided 10 MHz, that should work on any and all hardware?
It's not the device operating speed, the boot process takes appx. 25-30 seconds from power up to system ready and actually is faster than for example Mi Router 4A.
Well, there seems to be some consensus in the community that manufacturers tend to set the SPI speed unnecessarily low, maybe for lazyness, while the hardware is often capable to do much better.
That's why it got cranked up to 80 MHz initially for the WR1300. I think given that this works for some devices, but not for others is a good indication that it is too much, but not way too much, so 40 MHz seems to be a good compromise. But as soon as we get just a single report of a device that can't even cope with 40 MHz, I'll be all for lowering it further.
Allright, I have rebuilt the image with 40 MHz SPI and have been hammering it since yesterday.
No single error in the kernel log so far so it appears you are right. Thank You!
Ok. I just sent a merge request with the frequency change. If you can, please comment on it to get it approved as soon as possible.
The branch is already merged! 
Hi,
I just bought a Cudy WR1300 V3. I'm just curious about the benefits I can get from installing openWRT in it.
The only option I'm missing in it is limiting speed for specific devices. Will it be available in openWRT?
Thanks in advance for your reply.
The benefits of having pure OpenWrt versus the one offered by the manufacturer are several. For example, updates will always be faster if you use pure OpenWrt, on the other hand with pure OpenWrt you will not have bloatware (extra packages installed by the manufacturer that you may never use).
As for the speed issue, don't worry about that. The manufacturer in this case is much more restrained than we are. In any case it is the read/write speed of the non-volatile memory chip, something that is only read at router startup (then everything is loaded into the router's memory) and is only written if you make any persistent configuration changes, so it does not affect the daily operation.
In any case you can try OpenWrt and, if you are not convinced, go back to the original firmware. On the manufacturer's website there is a guide on how to do it (a PDF in the V2,V3 file).
Hi, just saw that 22.03.4 has been released. But the split between v1 and v2/v3 has not been taken over in the regular builds. Still only snapshot image for v2/v3. Do you have any idea when your code will be merged finally? Thanks for your great work!
As far as I know the new devices are added in the next major version. So the change will not go into the stable version until 23.x.x is released.
I think I've also seen such simple additions for new devices based on already supported SoCs in patch releases, but nobody submitted it to that branch.