I think I was wrong with the firmware splitter, is not tplink type but denx,uimage, try this new image
also the recovery u-boot from first commit
Set your Ethernet adapter to 192.168.0.10. Enable your TFTP
server with the firmware image in the root named fw.bin
(can be any name, just change the tftp command that comes later)
When the router starts its boot process,
press “enter” to interrupt auto boot.
Enter the following commands:
tftp 0x80060000 fw.bin
erase 0x9f040000 +${filesize}
cp.b 0x80060000 0x9f040000 ${filesize}
reset
Based on Archer A7/C7 v5 work, I created ath79 DTS for Archer C7 v4 (see https://github.com/openwrt/openwrt/pull/1726). There are some fixes that I think should be also in C7 v5 (like missing LED aliases led-boot and others, and fixing ar8327 init values - if there are no LEDs on the back panel with ethernet ports, LED initialization is useless), but because I do not have one, I have not tried to fix them. So enjoy C7 v4
The contents of build_dir/target-mips_24kc_musl/linux-ath79_nand/linux-4.14.93/drivers/mtd/, including nand/Kconfig, didn't provide any insight about available NAND drivers for the qca95xx chips (qca9563, of particular interest to me). Yes, my branch is a bit behind, based on commit 62dadcb86c from January 19, 2019.
But it requires 4.19 to not have to backport pretty much the whole MTD and SPI subsystems_
Please re-spin the patch as soon as we have kernel 4.19 support. The approach was already NAK'ed upstream and I don't see much gain in adding the hack if the next major kernel in OpenWrt will provide a suitable solution.
Tried uploading an ath79 sysupgrade image from luci and command line for wr842nd/v1 and the upgrade aborted. Tried prebuilt image from snapshot and from self built image using imagebuilder and got same result.
"The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform."
Have used the prebuilt snapshot ath79 image for wr703 with no reported errors.
Am reluctant to try and force a sysupgrade on the wr842 device.
Tried searching the forum but haven't found anything that would suggest a way forward. Any suggestions on where to look/proceed?
edit: fixed typo, target device is wr842n/v1
Hi @jeff, @dioni21, are you trying to upgrade over an ath79 or ar71xx image?
I had the same issue with my WNDR3800 when I tried to upgrade over an ar71xx image, and the -F flag worked fine.
Hope this helps.
Interesting -- both of these problems are where the current image's sense of "its" device doesn't correspond with the report of the owner. Were these "official" OpenWrt builds, or a "community" build or the like?
(There is a facility in the build system to accommodate expected name changes, such as when the OpenWrt "name" for the device changes between releases or when moving from ar71xx to ath79.)
No, it's only necessary if BOARD_NAME differs between ar71xx and ath79, which it often does (device naming is an inconsistent mess in ar71xx, in some cases you also have historical precedence of images having been evolved from other devices, e.g. tl-wdr3600 and tl-wdr4300).
From a quick glance at target/linux/ath79/image/image.mk and picking the first one with SUPPORTED_DEVICES, the "new" name is buffalo_bhr-4grv and it should upgrade "smoothly" from a device that has an image for wzr-hp-g450h already flashed.
I'm wondering why are you hijacking this forum thread with support requests, this probably belongs to separate forum thread, IRC or at https://bugs.openwrt.org
Please stop recommending usage of sysupgrade -F to general audience on forums, unless that person has serial console access and ideally (s)he knows what (s)he is doing. This command can brick the router easily if flashed with the wrong image.
If there's a problem with upgrade from ar71xx to ath79, please report it on IRC, mailing list or at https://bugs.openwrt.org so it can be fixed, we want to provide seamless upgrade for everybody if it's doable. Posting this upgrade issues on forums might be easier for you, but it could be missed by the developers easily as well, since it's quite hard to follow every communication channel available.
Has anyone picked up where in ATH79 devicetree one would enable GPIO 26 and 27 by setting bit 18 in the bootstrap register (0x180600AC ) ( Onion omega, Arduino Yun, TP-link MR2020,mr3040 V2, wr703 and wr741nd-v4 uses these, there are probably others. )
There is a function in ar71xx ( example in mach-arduino-yun ) that sets bit 18 of the bootstrap register so that GPIO 26 and 27 can be used as GPIO.
t = ath79_reset_rr(AR933X_RESET_REG_BOOTSTRAP);
t |= AR933X_BOOTSTRAP_MDIO_GPIO_EN;
ath79_reset_wr(AR933X_RESET_REG_BOOTSTRAP, t);
It doesn't seem to be set in any of the dts configurations i've found for the ATH79 port and I've found no references to the bootstrap register in the dts "tree" ( in ath79.dtsi, ar9330.dtsi, ar9331.dtsi or the device specific dts )
Outputs from io utility on the 2 ports are :
ar71xx : io -r -4 0x180600AC
180600ac: 0006220e (bit 18 set)
ATH79 : io -r -4 0x180600AC
180600ac: 0000220e ( bit 18 not set )
Would it make sense to place it in ar9330.dtsi as another pinmux entry or is there a better place in the tree to have this ?
I'm not sure which other devices use MDIO to speak to external switches/Phys which use the MDIO bus functionality of these GPIOs