Porting guide ar71xx to ath79?


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 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}

here are the links
factory https://drive.google.com/open?id=1rsiW0SB58mQ9BI9QhoiQyWbQQOR8xd94
sysupgrade https://drive.google.com/open?id=1jwfTodOhkVQavTMxbG-4a1yNk1_iOuZA


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 :slight_smile:


What is the current status of NAND drivers with the ath79 target?

I've found a few posts from the June, 2018 timeframe suggesting that there was work to be done, as well as an inquiry in October, 2018.

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.

Edit: I have since found https://github.com/openwrt/openwrt/pull/1428 which, in closing comment, states:

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.

Still interested in any updates on the topic.


At least 19.0x would still be on 4.14 AFAIK. But I suppose you're comfortable enough running master once that bumps to 4.19 :slight_smile:.


FYI, I have some ar71xx devices that don't seem to have been ported to ath79 :

  • HORNETUB (this seems to have disappeared from ar71xx snapshots ...)
  • onion-omega
  • carambola2
  • wpj344
  • wrt160nl

If there's anything I can do to help, let me know. In particular, I'm happy to test snapshots.



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

Ath79 image builder problem for wr842n/v1

What does sysupgrade -v --test /tmp/your_upgrade_image return?

At least on current master, I don't see an image for the v1:

jeff@deb-devel:~/devel/openwrt/target/linux/ath79/image$ fgrep 841 * | fgrep 'define Device'
grep: lzma-loader: Is a directory
tiny-tp-link.mk:define Device/tplink_tl-wr841-v5
tiny-tp-link.mk:define Device/tplink_tl-wr841-v7
tiny-tp-link.mk:define Device/tplink_tl-wr841-v8
tiny-tp-link.mk:define Device/tplink_tl-wr841-v9
tiny-tp-link.mk:define Device/tplink_tl-wr841-v11

Edit: A new thread would be a good place to pose the question and receive responses, as this is somewhat off-topic.


My typo error should have been wr842n/v1 not 841
edit: new topic here https://forum.openwrt.org/t/ath79-image-builder-problem-for-wr842n-v1/30197?u=greybeard


Jeff, I just had the same error on my netgear WNDR3800, and the command above gave:

root@netgear:/tmp# sysupgrade -v --test openwrt-ath79-generic-netgear_wndr3800-squashfs-sysupgrade.bin 
Device wndr3700 not supported by this image
Supported devices: netgear,wndr3800 wndr3800
Image check 'fwtool_check_image' failed.

The current image installed is simply today's snapshot for openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin

Maybe we need some adjustment on either version?


Just use argument -F to proceed


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.

 sysupgrade -v --test openwrt-ath79-generic-tplink_tl-wr842n-v1-squashfs-sysupgrade.bin
Device tl-mr3420 not supported by this image
Supported devices: tplink,tl-wr842n-v1
Image check 'fwtool_check_image' failed.

i'll try the -F option and see how it goes.

Ath79 image builder problem for wr842n/v1

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.)


1st report above was for an imagebuilder image I created.
This report is from yesterdays snapshot build

sysupgrade -v --test openwrt-ath79-generic-tplink_tl-wr842n-v1-squashfs-sysupgrade.bin
Device tl-mr3420 not supported by this image
Supported devices: tplink,tl-wr842n-v1
Image check 'fwtool_check_image' failed.

ie, same reported issue.

and from an 18.06.01 imagebuilder image

 sysupgrade -v --test openwrt-18.06.1-ar71xx-generic-tl-wr842n-v1-squashfs-sysupgrade.bin
Image metadata not found


I thought -F was always necessary when migrating from ar71xx to ath79, because board values and whatnot would differ?


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).


I did sysupgrade -F and it worked!!! Thanks a lot for all the answers.

I still suggest that somehow the upgrade process is made simpler before next release, or, at least, this is explained at https://openwrt.org/docs/techref/targets/ar71xx-ath79 or https://openwrt.org/toh/netgear/wndr3800 (and other equipment in need).

Does someone confirm this?


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.

define Device/buffalo_bhr-4grv
  ATH_SOC := ar7242
  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport
  IMAGE_SIZE := 32256k
  IMAGES += factory.bin tftp.bin
  IMAGE/default := append-kernel | pad-to $$$$(BLOCKSIZE) | append-rootfs | pad-rootfs | check-size $$$$(IMAGE_SIZE)
  IMAGE/factory.bin := $$(IMAGE/default) | buffalo-enc BHR-4GRV 1.99 | buffalo-tag BHR-4GRV 3
  IMAGE/tftp.bin := $$(IMAGE/default) | buffalo-tftp-header
  SUPPORTED_DEVICES += wzr-hp-g450h
TARGET_DEVICES += buffalo_bhr-4grv


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

  1. 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.

  2. 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.

Thanks for help with ath79 testing!


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);
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

bootstrap: bootstrap@180400ac {
		compatible = "pinctrl-single";
		reg = <0x180400AC 0x8>;

		pinctrl-single,register-width = <32>;
		pinctrl-single,function-mask = <0x1>;
		#pinctrl-cells = <2>;
		mdio_gpio: pinmux_mdio_gpio {
				pinctrl-single,bits = <0x0 0x40000 0x40000>;