Porting guide ar71xx to ath79?

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.

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

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

2 Likes

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_TITLE := Buffalo BHR-4GRV
  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
endef
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!

2 Likes

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

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

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

Try to use just pinmux definition, for example:
Switching GPIO0 to CS1 on AR724X SoC:

	...
	...
	/* Add this two lines to spi enum */
	pinctrl-names = "default";
	pinctrl-0 = <&enable_cs1_bit>;
	...
	...
&pinmux {
	enable_cs1_bit: pinmux_enable_cs1_bit {
		pinctrl-single,bits = <
			/*
			 * Set AR724X_GPIO_FUNC_SPI_CS_EN1 BIT(13) to 1,
			 * i.e. enable hardware CS1 but it turn-off GPIO0;
			 * Formula: *addr = (*addr & ~sub-mask) |
			 * (value & sub-mask);
			 * Where: addr is 0x18000000 + 0x40000 + 0x28 is
			 * base address of AR724X GPIO functions;
			 * <addr_offset value sub-mask>
			 */
			0x0 0x2000 0x2000
		>;
	};
 };

Configure GPIO11 to CS1 on AR934X SoC:

	...
	...
	/* Add this two lines to spi enum */
	pinctrl-names = "default";
	pinctrl-0 = <&gpio11_to_cs1_bit>;
	...
	...
&pinmux {
	gpio11_to_cs1_bit: pinmux_gpio11_to_cs1_bit {
		pinctrl-single,bits = <
			/*
			 * Set AR934X_GPIO_OUT_SPI_CS1 7 value to GPIO11,
			 * i.e. enable hardware CS1 but it turn-off GPIO11;
			 * Formula: *addr = (*addr & ~sub-mask) |
			 * (value & sub-mask);
			 * Where: addr is 0x18000000 + 0x40000 + 0x2C is
			 * base address of AR934X GPIO Output functions;
			 * <addr_offset value sub-mask>;
			 */
			/*
			 * 0x2c+0x8 addr_offset for GPIO11(Bit 31:24);
			 * 0x2c+0xc addr_offset for GPIO12-GPIO15;
			 * 0x2c+0x10 addr_offset for GPIO16-GPIO19;
			 * 0x7 value (with Bitwise Left Shift) for mux CS1
			 * use 0x8 value for mux CS2;
			 */
			0x8 0x7000000 0xff000000
		>;
	};
 };

Link
Use your shift "addr_offset" regarding of base GPIO addres - It be different because, it depends on your platform!
Example:
For AR9330 - pinmux: pinmux@18040028 where the addr is 0x18000000 + 0x40000 + 0x28 is base address of AR724X/AR9330 GPIO functions.

Next, you need to shift to AR71XX_RESET_BASE (0x18060000) and your AR933X_RESET_REG_BOOTSTRAP(0xac) addres - (0x18040028-0x28+0x00020000+0xac=0x200D4).

I.e. try to use just pinmux:

&pinmux {
		mdio_gpio: pinmux_mdio_gpio {
				pinctrl-single,bits = <0x200D4 0x40000 0x40000>;
		};
 };

If it works, be sure to add a comment what we do (as mine example above).

Than you for the explanation,

should the offset not be 0x20084 ?
( 0x18040028 + 0x20084 = 0x180600AC )

is the offset /shift calculated from the base address of the GPIO functions ( 0x18004000 ) or from the address of the pinmux entry as in the dts " pinmux: pinmux@18040028... " - it points to GPIO_FUNCTION_1

I've added the pinmux snippet and it compiles without issue but it doesn't set the bits as expected, could this be because offset is larger than the the pinmux "size" of 8 , but we're asking it to jump a lot further than that.

from ar9300.dtsi :

pinmux: pinmux@18040028 { 
   compatible = "pinctrl-single";
   reg = <0x18040028 0x8>;
   ...

should map to a valid range of 0x18040028 - 0x1804002F which seems to cover the general GPIO mux and settings registers GPIO_FUNCTION_1, GPIO_IN_ETH_SWITCH_LED and GPIO_FUNCTION_2

( only realized now I'm using the datasheets form your github repo, thank you for those... )

Actual, you have wrong calculate the value.
Value bit18 must be:

0b100000000000000000 = 0x20000 (hex)
  ^          <<< 321
bit18            

Use this: https://ostermiller.org/calc/calculator.html

I.e. that value waht you read via io 0006220e (ar71xx) cantent one other custom bits for other needs (0b1100010001000001110 = bit19, bi18...)
Formula to write here the same as in example above.

    0b10001000001110 = your previous ATH79 value 0x220e
0b100010001000001110 = must be this 0x2220e value when bit18 is set.

In short:

&pinmux {
		pinmux_mdio_gpio {
				pinctrl-single,bits = <0x200D4 0x20000 0x20000>;
		};
 };

Corrected!
It did not work for you, because it was waiting for the mention of the link mdio_gpio
Use corrected example without link.
Now it must write this bit18 as it should.

I built it with your corrected version it still does not set the bit in the register at 0x180600AC , ( I used the mdio_gpio refrence in my gpio-export part before but get the same behaviour)

My built devicetree pinmux section looks like this ( you can decompile the dtb in openwrt/build_dir/target-mips*/linux-ath79* )

pinmux@18040028 {
compatible = "pinctrl-single";
	reg = <0x18040028 0x8>;
	pinctrl-single,bit-per-mux;
	pinctrl-single,register-width = <0x20>;
	pinctrl-single,function-mask = <0x1>;
	#pinctrl-cells = <0x2>;

	pinmux_jtag_disable_pins {
		pinctrl-single,bits = <0x0 0x1 0x1>;
	};

	pinmux_switch_led_pins {
		pinctrl-single,bits = <0x0 0x0 0xf8>;
		linux,phandle = <0xb>;
		phandle = <0xb>;
	};

	pinmux_mdio_gpio {
		pinctrl-single,bits = <0x200d4 0x20000 0x20000>;
	};
  • disabled eJTAG ( bit 0 is "1" ),
  • switch LED pins are GPIO (bit 3,4,5,6 are "0")
  • Reset control register > RST_BOOT_STRAP bit 18 is set to enable GPIO - i think 0x20000 sets bit 17 ( counting form 0 ), but it won't cause any issue here as it doesn't seem to get written to the register at all.

could this be related to the size given in the pinmux definition ( only 8 )

pinmux: pinmux@18040028 { 
   compatible = "pinctrl-single";
   reg = <0x18040028 0x8>;
...
  • I don't know how the system behaves when you offset further than the size, whether it wraps around, undefined, or simply does an out of bounds access ( my background is OS-less embedded, and they don't care for boundaries much ).

I tested pinmux on my own ath79 platform and I can confirm, that is there limit of register address by 0x8*8:

root@OpenWrt:~# dmesg | grep pin
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 8128
[    0.135282] pinctrl core: initialized pinctrl subsystem
[    0.361419] pinctrl-single 18040028.pinmux: 64 pins at pa b8040028 size 8

Any way, if you want to do a pull request /or/ patch for Openwrt(for your platform), then your mentor will be will ask you to create bootstrap: bootstrap@180400ac(or he/she will do it) - it will be correct way.

Buy the way:
You were right about the correct address(0x20084).
But the bit18 value must be 0x20000 0x20000(instead 0x40000):smiley:

in the end the only way i found to "elegantly" ( for a given definition of elegant ) enable GPIO 26 and 27 by setting MDIO_GPIO_EN bit in the BOOT_STRAP register ( 0x180600AC ) was to add another pinmux entry into ar9330.dtsi with a named node, so that it will not get used unless its explicitly included in the board specific dts.

I added this snippet to ar9330.dtsi

pinmux_mdio: pinmux_mdio@180600ac {
		compatible = "pinctrl-single";
		reg = <0x180600AC 0x4>
		pinctrl-single,bit-per-mux;
		pinctrl-single,register-width = <32>;
		pinctrl-single,function-mask = <0x1>;
		#pinctrl-cells = <2>;

		mdio_gpio: pinmux_mdio_gpio {
			pinctrl-single,bits = <0x0 0x40000 0x40000>;
		};

	};

in the board specific dts one would inlcude this to enable pins 26 and 27 as GPIO.
pinctrl-0 = <&mdio_gpio>;

in a similar manner to using jtag_disable_pins or switch_led_pins to enable the use of GPIO 11, or set GPIOs 13,14,15,16 as Switch LEDs ( this PR sets them as GPIO by default rather than switch controlled )

it seems a bit hackey, but might do a PR to add it to the ar9330.dtsi file, unless there's a way of me adding something to the apb node from the device specific dtsi, but that feels like heading back to the ar71xx way of very large custom board definitions.

1 Like

Hi,

the TP-Link Archer C5 v1, which is indeed the same as Archer C7 v2 https://openwrt.org/toh/tp-link/archer-c5-c7-wdr7500 only appears on the ar71xx list.

Also I only see an image for archer-c5-v1-squashfs-factory.bin on https://downloads.openwrt.org/snapshots/targets/ar71xx/generic/ so I think this device is not migrated from ar71xx to ath79. Since the device is the same as C7 v2 which is already on ath79: what is needed to migrate the C5 v1 to ath79 also?

If it is really the same, then someone needs to port it to ath79 the same way as the other one.
For instance you can do it.

1 Like

I made a new test build for WNDR3700 and included the patch for speedying up the eeprom firmware extraction from @Pilot6 (and being tested by @chunkeey in his staging tree). That enables for the first time a functioning ath9k wifi right after the flashing. No need for a separate reboot for getting wifi to work. :wink: :wink:

https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commitdiff;h=68ce451227f5f9b61690132447fdc7e2311001c5;hp=839382ebe77ba8c609a572524888a341e6bf70c1

http://patchwork.ozlabs.org/patch/1046790/

Many thanks for that.

1 Like