Porting guide ar71xx to ath79?


#886

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.


#887

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


#888

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.

Thanks


#889

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
#890

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.


#891

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


#892

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.
root@netgear:/tmp# 

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?


#893

Just use argument -F to proceed


#894

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.


#895
 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
#896

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


#897

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

#898

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


#899

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


#900

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?


#901

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

#902

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!


#903

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

#904

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


#905

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