Unfortunately it didn’t work either, goes to 3% then “unable to update”
Same behavior for
Could tftp server work? https://openwrt.org/docs/guide-user/troubleshooting/tftpserver
Strange. Did you try a factory reset with the stock firmware? TFTP should also work.
I’m wondering if there are different stock firmwares for US and EU models.
Yes I did, same result. Okey I’ll test it.
Probably, I’m guessing your file is the us-version? Since my should be EU.
Tried to do tftp, didn't work. So I might need to go back to openwrt then do it. If you're not able to generate a EU-version also?
Not 100% sure, but I think this has to do with the OpenWRT factory.bin image setting the version to "2.0.0" for reasons described above in this thread. This becomes set in the devices "soft-version" partition when factory.bin is flashed. Sysupgrade can only modify the "firmware" partition (which overlaps the original "os-image" and "file-system" partitions). So after sysupgrade restores the OEM firmware, when you later try upgrade to the later OEM firmware, it doesn't work because the version is still set at "2.0.0" which is too high. Usually the OpenWRT firmwares use "0.0.0" so this doesn't happen.
It's a bit tricky to workaround. AFAIK one way to change it would be to change the "config" partition here to not read-only, rebuild+flash, then carefully hexedit the soft-version location in the /dev/mtd file. The other way would be read-change-write with an external flash programmer.
TFTP restore would also easily fix this, but lately TP-Link don't have that automatically enabled in some of their devices's u-boot firmware, and it requires serial console access 
The device will be supported in the next stable. 22.03.0 You can find a Release Candidate (testing version) here
Is it safe to SYSUPGRADE from " Powered by LuCI Master (git-21.168.56661-e57f866) / OpenWrt SNAPSHOT r16957-3d026d2425" to this version, or what is the recommanded way?
Yes, it was safe to upgrade. RC4 works well.
My RE305 v3 with OpenWrt 22.03 (being used as dumb access point) was constantly failing with the errors below:
SQUASHFS error: xz decompression failed, data probably corrupt
SQUASHFS error: Unable to read fragment cache entry
SQUASHFS error: Unable to read page, block xxxx, size yyyy
Initially I thought that it could be a hardware problem with device's flash, but with factory firmware it was working perfectly.
Searching the web I've found this was a quite common problem with some Mediatek devices:
So I gave up running OpenWrt on this device and returned it to factory firmware.
However today I've noticed the following commit in OpenWrt master:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=540377010532d9840ebe0778c2af991bd4b67052
So I did a new build and after 4 hours of uptime the issue has not appeared yet. So hopefully the above commit fixed the issue!
It looks like that commit was part of this patch series on /master for the 5.15 kernel, and doesn't look like its on the /openwrt-22.03 branch (which has 5.10), but I only did a quick look.
22.03.4 is due to he released in the next week or so, you might want to check with the patch author in that PR if it can be included in time for the release (or ping the mailing list with your findings above, there might be other affected devices)
An alternative to that patch, something else to quickly check on /openwrt-22.03 is whether lowering the spi-max-frequency in the dts file prevents this corruption. That would be a simple patch likely to be accepted quickly.
Its currently set to:
spi-max-frequency = <50000000>;
It's possible different flash chips are being used in some devices compared to the one the original author had.
Here are all the frequency for similar SoCs:
$ grep spi-max-frequency mt7628an*
mt7628an_alfa-network_awusfree1.dts: spi-max-frequency = <10000000>;
mt7628an_asus_rt-ac1200.dtsi: spi-max-frequency = <58000000>;
mt7628an_asus_rt-n1x.dtsi: spi-max-frequency = <40000000>;
mt7628an_buffalo_wcr-1166ds.dts: spi-max-frequency = <40000000>;
mt7628an_comfast_cf-wr617ac.dts: spi-max-frequency = <40000000>;
mt7628an_comfast_cf-wr758ac.dtsi: spi-max-frequency = <50000000>;
mt7628an_cudy_wr1000.dts: spi-max-frequency = <10000000>;
mt7628an_dlink_dap-1325-a1.dts: spi-max-frequency = <50000000>;
mt7628an_d-team_pbr-d1.dts: spi-max-frequency = <40000000>;
mt7628an_d-team_pbr-d1.dts: spi-max-frequency = <40000000>;
mt7628an_duzun_dm06.dts: spi-max-frequency = <60000000>;
mt7628an_elecom_wrc-1167fs.dts: spi-max-frequency = <40000000>;
mt7628an_glinet_gl-mt300n-v2.dts: spi-max-frequency = <10000000>;
mt7628an_glinet_vixmini_microuter.dtsi: spi-max-frequency = <10000000>;
mt7628an_hak5_wifi-pineapple-mk7.dts: spi-max-frequency = <50000000>;
mt7628an_hilink_hlk-7628n.dts: spi-max-frequency = <10000000>;
mt7628an_hilink_hlk-7688a.dts: spi-max-frequency = <40000000>;
mt7628an_hilink_hlk-7688a.dts: spi-max-frequency = <40000000>;
mt7628an_hiwifi_hc5x61a.dtsi: spi-max-frequency = <80000000>;
mt7628an_iptime.dtsi: spi-max-frequency = <40000000>;
mt7628an_jotale_js76x8.dtsi: spi-max-frequency = <40000000>;
mt7628an_keenetic_kn-1613.dts: spi-max-frequency = <32000000>;
mt7628an_kroks.dtsi: spi-max-frequency = <25000000>;
mt7628an_linksys_e5400.dts: spi-max-frequency = <40000000>;
mt7628an_mediatek_linkit-smart-7688.dts: spi-max-frequency = <40000000>;
mt7628an_mediatek_linkit-smart-7688.dts: spi-max-frequency = <40000000>;
mt7628an_mediatek_mt7628an-eval-board.dts: spi-max-frequency = <10000000>;
mt7628an_mercury_mac1200r-v2.dts: spi-max-frequency = <10000000>;
mt7628an_minew_g1-c.dts: spi-max-frequency = <40000000>;
mt7628an_motorola_mwr03.dts: spi-max-frequency = <80000000>;
mt7628an_netgear_r6xxx.dtsi: spi-max-frequency = <86000000>;
mt7628an_onion_omega2.dtsi: spi-max-frequency = <40000000>;
mt7628an_onion_omega2.dtsi: spi-max-frequency = <40000000>;
mt7628an_rakwireless_rak633.dts: spi-max-frequency = <10000000>;
mt7628an_ravpower_rp-wd009.dts: spi-max-frequency = <40000000>;
mt7628an_skylab_skw92a.dts: spi-max-frequency = <10000000>;
mt7628an_tama_w06.dts: spi-max-frequency = <10000000>;
mt7628an_totolink_lr1200.dts: spi-max-frequency = <40000000>;
mt7628an_tplink_8m.dtsi: spi-max-frequency = <10000000>;
mt7628an_tplink_8m-split-uboot.dtsi: spi-max-frequency = <10000000>;
mt7628an_tplink_re200.dtsi: spi-max-frequency = <50000000>;
mt7628an_tplink_re305-v1.dts: spi-max-frequency = <50000000>;
mt7628an_tplink_re305-v3.dts: spi-max-frequency = <50000000>;
mt7628an_tplink_tl-mr3020-v3.dts: spi-max-frequency = <50000000>;
mt7628an_tplink_tl-wr840n-v5.dts: spi-max-frequency = <10000000>;
mt7628an_tplink_tl-wr841n-v14.dts: spi-max-frequency = <10000000>;
mt7628an_unielec_u7628-01-16m.dts: spi-max-frequency = <12000000>;
mt7628an_vocore_vocore2.dtsi: spi-max-frequency = <10000000>;
mt7628an_wavlink_wl-wn531a3.dts: spi-max-frequency = <40000000>;
mt7628an_wavlink_wl-wn570ha1.dts: spi-max-frequency = <10000000>;
mt7628an_wavlink_wl-wn575a3.dts: spi-max-frequency = <10000000>;
mt7628an_wavlink_wl-wn576a2.dts: spi-max-frequency = <40000000>;
mt7628an_wavlink_wl-wn577a2.dts: spi-max-frequency = <40000000>;
mt7628an_wavlink_wl-wn578a2.dts: spi-max-frequency = <40000000>;
mt7628an_widora_neo.dtsi: spi-max-frequency = <40000000>;
mt7628an_widora_neo.dtsi: spi-max-frequency = <40000000>;
mt7628an_wiznet_wizfi630s.dts: spi-max-frequency = <40000000>;
mt7628an_wrtnode_wrtnode2.dtsi: spi-max-frequency = <10000000>;
mt7628an_wrtnode_wrtnode2r.dts: spi-max-frequency = <10000000>;
mt7628an_xiaomi_mi-router-4c.dts: spi-max-frequency = <40000000>;
mt7628an_xiaomi_mi-router-4.dtsi: spi-max-frequency = <10000000>;
mt7628an_xiaomi_miwifi-3c.dts: spi-max-frequency = <40000000>;
mt7628an_xiaomi_miwifi-nano.dts: spi-max-frequency = <40000000>;
mt7628an_zbtlink_zbt-we1226.dts: spi-max-frequency = <10000000>;
mt7628an_zyxel_keenetic-extra-ii.dts: spi-max-frequency = <32000000>;
Well, for now I'm using the snapshot build and it is up and running for a couple of days without any corruption so far.
Since the new stable release 23.0? is around the corner, it will certainly include this fix.
Here is the latest SNAPSHOT build of the /openwrt-22.03 release branch if you want to test what will be on the next 22.03.4 release (maybe minus Luci).
I only did a quick check, but the new commit you linked to above appears to only be applied to the /master git branch and not also on the /openwrt-22.03 branch, so it would not be a part of any 22.03.* release until that patch is backported to /openwrt-22.03.
How likely that is, you'd have to ask the original committer. That is why I suggested also testing the simpler possible fix of taking /openwrt-22.03 and building a test image with lower spi-max-frequency. If that fixes the issue, it would be a much simpler fix to get into 22.03 before the next release.
@dsouza,
Here is a test build of this patch against /openwrt-22.03 you can try.
diff --git a/target/linux/ramips/dts/mt7628an_tplink_re305-v3.dts b/target/linux/ramips/dts/mt7628an_tplink_re305-v3.dts
index 652aebec83..21df0fb3e6 100644
--- a/target/linux/ramips/dts/mt7628an_tplink_re305-v3.dts
+++ b/target/linux/ramips/dts/mt7628an_tplink_re305-v3.dts
@@ -13,7 +13,7 @@
flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
- spi-max-frequency = <50000000>;
+ spi-max-frequency = <10000000>;
partitions {
compatible = "fixed-partitions";
If it works and reduces the errors, can you post a copy of your dmesg output and we can see what flash chip you have. Maybe TPLink changed the SPI flash chip between the time of original support and your unit.
I'm running my RE305v3 as an access point in my kitchen. So I do my own builds (very minimal) for this device (removing firewall, dnsmaq, dhcp, etc).
I just did a new build from 22.03-snapshot, and I've manually changed the file mt7628an_tplink_re305-v3.dts reducing the spi-max-frequency to 10000000 per your patch.
It is running just for a couple of minutes now, let's see if this will also solve the problem. If so I do agree with you that this "quick fix" should be merged into the 22.03 branch for the next stable 22.03 release.
EDITED: BTW, below is the SPI from dmesg:
(...)
[ 1.206953] spi-mt7621 10000b00.spi: sys_freq: 193333333
[ 1.231472] spi-nor spi0.0: en25qh64 (8192 Kbytes)
(..)
EDITED 2: below is a photo from the actual SPI in my RE305v3. It is a cFeon QH64A. Searching the web it seems equivalent to EN25QH64 as identified by kernel.
Great,
Reported sys_freq frequency seems a bit high, but any dmesgs I see on other devices often show it at slightly different values than what is set in DTS.
Just to double-check, did you build from source or using ImageBuilder? AFAIK the DTS files are only recompiled into DTBs during a source build. (To do it in ImageBuilder requires a manual compiler step).
I guess it just matters that its lower than the original 22.03.3 version. There is no bootlog on the wiki page to compare against yet.
I did a full build from the source (in an Ubuntu Server VM). After git checkout/feeds updates/menuconfig and before the actual build I manually changed the DTS file in my local copy of the source files reducing the spi frequency.
EDITED: BTW, the following dmesg messages look suspicious. Maybe the DTS file was not correctly configured by the original dev from the beginning?
[ 1.253755] OF: Bad cell count for /palmbus@10000000/spi@b00/flash@0/partitions
[ 1.268276] OF: Bad cell count for /palmbus@10000000/spi@b00/flash@0/partitions
[ 1.283250] OF: Bad cell count for /palmbus@10000000/spi@b00/flash@0/partitions
[ 1.297798] OF: Bad cell count for /palmbus@10000000/spi@b00/flash@0/partitions
EDITED 2: see below. It seems that 10Mhz (10000000 -> 0x00989680) is correctly configured and the 193333333 reported by dmesg is wrong:
# hexdump /sys/class/spi_master/spi0/of_node/flash@0/spi-max-frequency
0000000 9800 8096
0000004
Yes, I noticed that in other recent builds, seems to be this unrelated issue which affects many other devices. "Should be harmless". I'm guessing someone will fix it at some stage.
Okay sounds like it's set as expected. If it fixes the stability issues, then we can submit a patch this evening for 22.03 (I can do that if you like). The 22.03.4 release hasn't been tagged yet so hopefully there is still time.
PR created for the SPI flash speed issue above, hopefully not too late for 22.03.4 which will start to be released very soon.
Hello,
Is here some nice person who would be kind enough to dump full image of RE305V3 flash? Doesn't matter if stock or OpenWRT. I flashed something terribly wrong and now I don't get anything on serial, no lights are on, no respond to resetting ;(
Thanks in advance
Hi. I ended up bricking my RE305 V3 due to a bad flash (used factory instead of upgrade from shell), and am now trying to flash via serial port following https://openwrt.org/docs/guide-user/installation/generic.flashing.serial
But it has a warning:
DO NOT USE THESE VALUES. FIND OUT THE RIGHT ONES! NO, NOT KIDDING.
What are the correct values for RE 305 v3 firmware?
The flash layout? It's listed on the wiki: https://openwrt.org/toh/tp-link/re305_v3#flash_layout
But, if you already managed to connect through serial, you probably saw the boot menu, right? You could boot from TFTP and run the (normal) flashing process from there -- this way you ensure the image is running correctly before committing permanent changes (and IIRC you don't need to worry about manually adjusting the flash addresses etc.). See https://openwrt.org/docs/techref/image.format#initramfs