Porting guide ar71xx to ath79?

did you tried ?


	keys {
		compatible = "gpio-keys";
		#address-cells = <1>;
		#size-cells = <0>;


and not gpio-keys-polled on every device I tried this worked

Hi there would you be so kind to port for dir505 too? Thx!

I removed those, because maintainers said that made no difference.
I tested it before the change. really the same thing.

I have

	keys {
		compatible = "gpio-keys";
		poll-interval = <20>;

		reset {
			label = "reset";
			linux,code = <KEY_RESTART>;
			gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
			debounce-interval = <60>;
		};

		wps {
			label = "wps";
			linux,code = <KEY_WPS_BUTTON>;
			gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
			debounce-interval = <60>;
		};
	};

Increasing poll-interval doesn't change things. Probably it is ignored.

Changed to compatible = "gpio-keys-polled"; and all is OK now.

Without the correct compatible string other things are ignored by OF.

I closed both PRs. The requirements are too high for me. Anyone welcome to proceed.

That is not a dumb question. No idea if that is really needed, but to my knowledge it has not yet been implemented.

1 Like

:pensive:

But please, do not delete those branches!

The pr will still exist also if the used branch is deleted...

2 Likes

I will do the PR for WNDR3800.

I already wrote the patch for the kernel driver patch 681-NET-add-of_get_mac_address_mtd.patch so that the MACs in WNDR3800 can be straightened out. MAC of eth0 gets bit 2 set in the first byte, so that it becomes unique:

root@OpenWrt:/# ifconfig | grep HW
br-lan    Link encap:Ethernet  HWaddr 76:44:xx:xx:A3:E7
eth0      Link encap:Ethernet  HWaddr 76:44:xx:xx:A3:E7
eth0.1    Link encap:Ethernet  HWaddr 76:44:xx:xx:A3:E7
eth1      Link encap:Ethernet  HWaddr 74:44:xx:xx:A3:E8
wlan0     Link encap:Ethernet  HWaddr 74:44:xx:xx:A3:E9
wlan1     Link encap:Ethernet  HWaddr 74:44:xx:xx:A3:E7

Interestingly, wlan0 and wlan1 seem to have changed position from the original one in ar71xx where wlan0 was 2G and wlan1 was 5G. In the ath79 version, wlan0 is now 5GHz. Apparently the DTS definition causes wlans to be detected in a different order.

root@OpenWrt:/# iwinfo
wlan0     ESSID: "xx5xxxxx"
          Access Point: 74:44:xx:xx:A3:E9
          Mode: Master  Channel: 36 (5.180 GHz)
...
          Type: nl80211  HW Mode(s): 802.11an
          Hardware: 168C:0029 168C:A094 [Atheros AR9220]
...
          Supports VAPs: yes  PHY name: phy0

Sorry for the long delay Mr @lucize , was busy with been slave in my job, but I'm ready to continue with this project.

I still don't apply the patch that you suggest me. Some days before been busy at work, I made some progress in other aspects of the device (different from the mdio detection)

In the 02_network file.

	"phicomm,k2t")
		ucidef_add_switch "switch0" \
			"0@eth0" "3:lan:1" "5:lan:2" "4:wan"
		;;

	"linksys,linksys-e2100l")
		ucidef_set_interfaces_lan_wan "eth0.1" "eth1"
		ucidef_add_switch "switch0" \
			"0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4@eth0"
		;;

	*)
		ucidef_set_interfaces_lan_wan "eth0" "eth1"
		;;

...
...
...

	phicomm,k2t)
		lan_mac=$(k2t_get_mac "lan_mac")
		wan_mac=$(k2t_get_mac "wan_mac")
		;;
	linksys,linksys-e2100l)
		lan_mac=$(mtd_get_mac_ascii nvram "lan_hwaddr")
		wan_mac=$(macaddr_add "$lan_mac" 1)
		;;
	esac

	[ -n "$lan_mac" ] && ucidef_set_interface_macaddr "lan" $lan_mac
	[ -n "$wan_mac" ] && ucidef_set_interface_macaddr "wan" $wan_mac
  • The port layout I take it from the wrt160nl
  • I was getting a incorrect lan mac address, it seem from the old match file that the lan mac address is read from the nvram partition
	if (ath79_nvram_parse_mac_addr(nvram, E2100L_NVRAM_SIZE,
				       "lan_hwaddr=", mac) == 0) {
		ath79_init_mac(ath79_eth0_data.mac_addr, mac, 0);
		ath79_init_mac(ath79_eth1_data.mac_addr, mac, 1);
	}

With this changes, it seem that the switch gets somehow detected but I still don't get dhcp ip addess in lan ports, here is the luci switch config changing my lan cable from my laptop to any of the lan ports

Mr @lucize, do you still recommend that try to apply the patch that you suggest me?

I added two pull requests that implement wifi for WNDR3800.
The wifi support is not yet perfect, but works.


Known issues / work-to-do:

  • wifi does not get enabled at the boot after flash.
    It starts ok at subsequent reboots.
    Hypothesis: firmware file creation is tried too early, before jffs2 is ready in the first boot.
  • antenna group adjustment has not been done
  • wlan0 and wlan1 get swapped. Contrary to ar71xx, pci0000:00/0000:00:11.0 seems to lead to 5GHz radio

@lucize Regarding the 1043nd. I found u-boot source on Tp-link site.
But it is not easy to find what they write to switch register early.

1 Like

Anybody else having issues ath79.dtsi?
DTC wont compile it into dtb.
Spits out the following error

target/linux/ath79/dts/ath79.dtsi:2.1-2 syntax error
FATAL ERROR: Unable to parse input tree

Did you write /dts-v1/; in device dts?
I also remember the same error when I forget to write it.

Forgot that completely.
Error message is really not helpfull.

Thanks

sorry I'm again away for a while from the devices, can't investigate

Would that be good news for the WNDR3700 as well? I don't know how much they differ internally.

Yes. It is quite identical. After the memory size property was removed a while ago, 3700v2 and 3800 are practically identical except the board ID. But 3700 (v1) has only 8 MB flash, so it needs a separate flash definition in DTS. Otherwise no differences to my knowledge.

But if you see the discussion on my PRs, the wifi functionality in 3800 is not yet perfect.

(I have now run WNDR3800 with ath79 based kernel 4.14 as my main router since yesterday, and so far no problems.)

If WNDR3800 wifi gets fixed, I will also issue the changes for 3700v2 that I can test. But my old 3700 v1 is currently located at relatives, so I can't test that...

2 Likes

That sounds great. I have a spare 3700 v1 so I'd be happy to test.

And I have WNDR3700V2 and i'd be happy to test too :grinning: