[OpenWrt-Devel,v3,3/5] ath79: add support for Netgear WNR2000 v3
diff mbox series

Message ID 20190811224446.3334b7e6@kosmio.komorska
State Superseded
Headers show
Series
  • ath79: add support for some Netgear WNR routers
Related show

Commit Message

Michal Cieslakiewicz Aug. 11, 2019, 8:44 p.m. UTC
This patch adds ath79 support for Netgear WNR2000v3.
Router was previously supported by ar71xx target only.
Note: this is a 4_32 device with limited upgrade capabilities.

Specification
=============
  * Description: Netgear WNR2000 v3
  * Loader: U-boot
  * SOC: Atheros AR7241 (360 MHz)
  * RAM: 32 MiB
  * Flash: 4 MiB (SPI NOR)
	- U-boot binary: 256 KiB
	- U-boot environment: 64 KiB
	- Firmware: 3712 KiB
	- ART: 64 KiB
  * Ethernet: 4 x 10/100 LAN + 1 x 10/100 WAN
  * Wireless: 2.4 GHz b/g/n (Atheros AR9287)
  * USB: no
  * Buttons:
	- Reset
	- WiFi (rfkill)
	- WPS
  * LEDs:
	- Power (amber/green)
	- WAN (amber/green)
	- WLAN (blue)
	- 4 x LAN (amber/green)
	- WPS (green)
  * UART: 4-pin connector JP1, 3.3V (Vcc, TX, RX, GND), 115200 8N1
  * Power supply: DC 12V 1A

Installation
============
  * TFTP recovery
  * TFTP via U-boot prompt
  * sysupgrade
  * Web interface

Test build configuration
========================
CONFIG_TARGET_ath79=y
CONFIG_TARGET_ath79_tiny=y
CONFIG_TARGET_ath79_tiny_DEVICE_netgear_wnr2000-v3=y
CONFIG_ALL_KMODS=y
CONFIG_DEVEL=y
CONFIG_CCACHE=y
CONFIG_COLLECT_KERNEL_DEBUG=y
CONFIG_IMAGEOPT=y
CONFIG_KERNEL_DEBUG_INFO=y
CONFIG_KERNEL_DEBUG_KERNEL=y

Signed-off-by: Michal Cieslakiewicz <michal.cieslakiewicz@wp.pl>
---
 .../ath79/base-files/etc/board.d/01_leds      |  12 +
 .../ath79/base-files/etc/board.d/02_network   |   1 +
 .../etc/hotplug.d/firmware/10-ath9k-eeprom    |   1 +
 .../ath79/dts/ar7241_netgear_wnr2000-v3.dts   | 212 ++++++++++++++++++
 target/linux/ath79/image/tiny-netgear.mk      |  16 ++
 5 files changed, 242 insertions(+)
 create mode 100644 target/linux/ath79/dts/ar7241_netgear_wnr2000-v3.dts

Comments

Adrian Schmutzler Aug. 12, 2019, 12:22 p.m. UTC | #1
Hi, comments below, too:

> diff --git a/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom b/target/linux/ath79/base-
> files/etc/hotplug.d/firmware/10-ath9k-eeprom
> index ec597dd1d4..747c1aab58 100644
> --- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
> +++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
> @@ -165,6 +165,7 @@ case "$FIRMWARE" in
>  	winchannel,wb2000)
>  		ath9k_eeprom_extract "art" 20480 1088
>  		;;
> +	netgear,wnr2000-v3|\
>  	netgear,wnr612-v2|\
>  	on,n150r|\
>  	pcs,cap324|\

You are using mtd-cal-data in DTS for this device. Does this work? Then you should be able to remove the entries in 10-ath9k-eeprom. Otherwise, remove mtd-cal-data. Based on the result, you may want to change the other devices accordingly.

> +&pcie {
> +	status = "okay";
> +
> +	ath9k: wifi@0,0 {
> +		compatible = "pci168c,002e";
> +		reg = <0x0000 0 0 0 0>;
> +		mtd-mac-address = <&art 0x0>;
> +		mtd-mac-address-increment = <1>;
> +		mtd-cal-data = <&art 0x1000>;

Despite comments from above, we have the same situation regarding MAC address here. Is the MAC address read via cal-data already? Then act as described in the previous patch annotation.

> +	};
> +};
> +
> +&uart {
> +	status = "okay";
> +};
> +
> +&gpio {
> +        status = "okay";
> +};

Leading spaces here. Change to tabs. And maybe check all your files, as I just found this by accident and did not look everywhere ...

Best

Adrian
Michal Cieslakiewicz Aug. 12, 2019, 2:29 p.m. UTC | #2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, 12 Aug 2019 14:22:52 +0200
"Adrian Schmutzler" <mail@adrianschmutzler.de> wrote:

> Hi, comments below, too:
> 
> > diff --git
> > a/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
> > b/target/linux/ath79/base-
> > files/etc/hotplug.d/firmware/10-ath9k-eeprom index
> > ec597dd1d4..747c1aab58 100644 ---
> > a/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
> > +++
> > b/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
> > @@ -165,6 +165,7 @@ case "$FIRMWARE" in winchannel,wb2000)
> > ath9k_eeprom_extract "art" 20480 1088 ;;
> > +	netgear,wnr2000-v3|\
> >  	netgear,wnr612-v2|\
> >  	on,n150r|\
> >  	pcs,cap324|\  
> 
> You are using mtd-cal-data in DTS for this device. Does this work?
> Then you should be able to remove the entries in 10-ath9k-eeprom.
> Otherwise, remove mtd-cal-data. Based on the result, you may want to
> change the other devices accordingly.
> 
> > +&pcie {
> > +	status = "okay";
> > +
> > +	ath9k: wifi@0,0 {
> > +		compatible = "pci168c,002e";
> > +		reg = <0x0000 0 0 0 0>;
> > +		mtd-mac-address = <&art 0x0>;
> > +		mtd-mac-address-increment = <1>;
> > +		mtd-cal-data = <&art 0x1000>;  
> 
> Despite comments from above, we have the same situation regarding MAC
> address here. Is the MAC address read via cal-data already? Then act
> as described in the previous patch annotation.
> 

Hi Adrian,

Thanks - I've just tested it on WNR2000v3 and apparently
10-ath9k-eeprom is the working solution. So mtd-cal-data will be
removed in v4 patches from all WNR* DTSes.

> > +	};
> > +};
> > +
> > +&uart {
> > +	status = "okay";
> > +};
> > +
> > +&gpio {
> > +        status = "okay";
> > +};  
> 
> Leading spaces here. Change to tabs. And maybe check all your files,
> as I just found this by accident and did not look everywhere ...
>

Yep, I've missed it... Fixed in v4.

Cheers
Michal
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEi7ylFMzTSbpOuOZIHU8//LdGKWsFAl1Rd8cACgkQHU8//LdG
KWt2yg//T291n1+luMfAaldqSDWJ8gLIkRCzxsI4S9uKNUCzNFzp0L22pu9/a/9y
EmcXJVhUbLx0iKO3HBKQKMmnUrNy12bJP6FFQQgRbaLyoawRI1rqOirpQjYSP31p
pde+KVEmxL87RjGZP6yhN1hb8QMHpZuHrHOI3BWI4XvQtGlpHMmzz82dn4na/u+K
CQ1SZf4w3UPFSUt17/ujAFzec++fRoDCYy9PKPVLPcjuY6Th8KuA2f0+WeJefGQg
z+D05HrKPFz8iXqPXLU+MAe76c4ZMYvpT6c9jalDCzte9y6H3CWpDrzPz0hTdr/a
qNMLds8weDZoR+Db0+vG21qX1f0IzbQ0pnoS8Nc/mEoALZEpZWuEOzwI9VMG/dqp
k1PpVRcInNr+FkLlOu2a5DgLvLRX6ao7g5deE31SgAR+F6RwFXtMgNMpnmZhgt9C
QL/dnxwrjFvRxROu8Cg2ep0L/Bj+fpeHD5HlM7YxVPb8KY24wJc8njjZZ9u4k9kd
CbREMM3Avq/BMz3iL40mTPlsb1ywiDqkBXrPPAvNY4PVgLY5vbbCSK0d5/vjIgPT
CfojnIwmp2/M3CvQZxXTXg0nxkJ6xDqDJfKb/CooDBgx14j/m14qInYRnisIm5OE
f8J84b0oxsCtEi6v32aadrmdrOvZGKeaB2yyI0T7qc3WnYb2J9s=
=dRDJ
-----END PGP SIGNATURE-----
Michal Cieslakiewicz Aug. 14, 2019, 8:59 a.m. UTC | #3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello Adrian,

Thanks for helping me with WNR patchset, one question came to my mind
in the process of developing it and after reading one of your emails.
Sorry if it has been answered elsewhere...

/etc/hotplug.d/firmware/10-ath9k-eeprom for these routers just extracts
4k of calibration data from ART to bin file in /lib/firmware. I
compared bin file to mtd area and they are identical. Why ath9k cannot
use this data directly accessing /dev/mtd6? Is that 'mtd-cal-data' dts
option for? If so, why does it not work in this case? (tested, ath9k
initialization ends with error)
I recall there was no such operation in ar71xx target and older
kernels...

Best regards
Michal
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEi7ylFMzTSbpOuOZIHU8//LdGKWsFAl1TzWoACgkQHU8//LdG
KWs+Bw/8DJHoJV8rfG8DYDHriwRa9vmRH8Ay4PVA7VDSoA1BJwE990qRmWdyfSQ7
y7v6l3Aq7SowmZ5UBK4K8HPOjQRy17AY4G8WXNjecPhs8Hs2neE3QrJ/LmqXvUOL
RnMyfaLnhkO66hA3I6QMVVYKI2VPCd/mp3EQllJSIZJEohC7OBvimmUc/8Wqhzn5
mtgLYEueSLWQO0jei9Yho7ZEF5auxkyEjDrvhdYimbBqolEYmpw21CCs124AAxVH
Ou11Q+lnLaZo68iA6k/8COjw4ScVKc2m6W0EgjGYRs5OC7lQ2Uu9kpC+NcFGkSik
AZyIC/unFQB6TJsxUkJ+m26DxokOGksk51DjBdUtAOmccfGkc/otHHYDP7YWNcoc
HRhaidJR+ybG+bRTqz9slNJjSJxdPPF5WnVSsPNmlyjd4CP+XZ8P+SdqZg+Ft25Z
PMIVrjgWsUsrFRaIu9zqGlP7F+Tsg0fES8LMXUQT3vE/YFBxzl/i1uRxyxqXpmv3
c/vr+VySe1+kmfQ89qdVAHB2lTFweKOJAEaI4Cdxf0DqSirsyySG0A92pEmv23U0
4xRysEm863e0qdqzaha5RrjTKK+VrmtGvjD9OWHAt6rbwsd69EJlKmQry3assO24
oA/gx/JIcj0etbJCEVEprryWzbjy3OJOX2w1J0iJXY4LXCT6yDI=
=CoJn
-----END PGP SIGNATURE-----
Dmitry Tunin Aug. 14, 2019, 9:56 a.m. UTC | #4
> /etc/hotplug.d/firmware/10-ath9k-eeprom for these routers just extracts
> 4k of calibration data from ART to bin file in /lib/firmware. I
> compared bin file to mtd area and they are identical. Why ath9k cannot
> use this data directly accessing /dev/mtd6? Is that 'mtd-cal-data' dts
> option for? If so, why does it not work in this case? (tested, ath9k
> initialization ends with error)
> I recall there was no such operation in ar71xx target and older
> kernels...

ath9k node doesn't have 'mtd-cal-data' property.
Regarding ar71xx there were special mach procedures that could
directly load caldata from mtd.
Chuanhong Guo Aug. 14, 2019, 12:06 p.m. UTC | #5
Hi!

On Wed, Aug 14, 2019 at 4:59 PM Michal Cieslakiewicz
<michal.cieslakiewicz@wp.pl> wrote:
> /etc/hotplug.d/firmware/10-ath9k-eeprom for these routers just extracts
> 4k of calibration data from ART to bin file in /lib/firmware. I
> compared bin file to mtd area and they are identical. Why ath9k cannot
> use this data directly accessing /dev/mtd6? Is that 'mtd-cal-data' dts
> option for? If so, why does it not work in this case? (tested, ath9k
> initialization ends with error)

mtd-cal-data is part of a local hack for wmac devices only:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/kernel/mac80211/patches/ath/552-ahb_of.patch;h=1170fc64bd9092d374ee78285060b504a699b720;hb=HEAD
It loads calibration data and create an ath9k_platform_data struct.

>I recall there was no such operation in ar71xx target

In ar71xx, calibration data is loaded through ath9k_platform_data for
newer wifi cards and for older cards, there's a piece of code feeding
caldata in arch/mips/ath79/pci-ath9k-fixup.c before ath9k loads (in
ath79 and lantiq this is replaced by owl-loader).

Regards,
Chuanhong Guo
Martin Blumenstingl via openwrt-devel Aug. 15, 2019, 10:49 p.m. UTC | #6
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
Hi Michal,

On Wed, Aug 14, 2019 at 10:59 AM Michal Cieslakiewicz
<michal.cieslakiewicz@wp.pl> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hello Adrian,
>
> Thanks for helping me with WNR patchset, one question came to my mind
> in the process of developing it and after reading one of your emails.
> Sorry if it has been answered elsewhere...
>
> /etc/hotplug.d/firmware/10-ath9k-eeprom for these routers just extracts
> 4k of calibration data from ART to bin file in /lib/firmware. I
> compared bin file to mtd area and they are identical. Why ath9k cannot
> use this data directly accessing /dev/mtd6? Is that 'mtd-cal-data' dts
> option for? If so, why does it not work in this case? (tested, ath9k
> initialization ends with error)
> I recall there was no such operation in ar71xx target and older
> kernels...
(I am the one who brought the /lib/firmware based caldata upstream -
these are my thoughts on this topic)

upstream ath9k has support for retrieving the caldata through the
request_firmware mechanism (which requires copying it to
/lib/firmware).
some out-of-tree patches have/had a special mtd-cal-data property to
achieve a similar goal (passing the caldata to devices without a
physical EEPROM).

while I upstreamed the ath9k patches for request_firmware support
there was a bit of a discussion.
the discussion was whether the NVMEM subsystem should be used instead
of relying on request_firmware.
my primary target was the BT HomeHub 5A which stores the calibration
data inside a UBI volume which cannot be referenced from devicetree
(yet - or at least at the time I upstreamed the patches it could not
be referenced) so I still chose to push the request_firmware part
forward.

most devices have the caldata at a fixed location on the flash, so the
NVMEM subsystem can be used for this.
if someone wants to get rid of the caldata copy in /lib/firmware then
support for reading the caldata using the NVMEM framework could be
implemented in ath9k (and owl-loader).
the result would be close to what the mtd-cal-data provides, assuming
that the NVMEM subsystem can read the underlying data structures on
flash (AFAIK this currently excludes NAND with UBI, which is used by
the minority of the boards with an ath9k chip).


Martin
Michal Cieslakiewicz Aug. 16, 2019, 8:49 a.m. UTC | #7
Hello Martin,

Thank you (and Dmitry Tunin and Chuanhong Guo) for explaining this topic
to me. Now it is perfectly clear. So the idea of reading mtd isn't
completely abandoned, Martin's approach just seems to be more flexible
and universal. On the other hand, I've never assumed sparing this 4k
(even less, as I guess it's squashed) will yield any reasonable gain for
tiny flash devices, it was more of internal design curiosity.

Best regards
Michal

Patch
diff mbox series

diff --git a/target/linux/ath79/base-files/etc/board.d/01_leds b/target/linux/ath79/base-files/etc/board.d/01_leds
index f1d738ba9f..4e919e7576 100755
--- a/target/linux/ath79/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/base-files/etc/board.d/01_leds
@@ -103,6 +103,18 @@  glinet,gl-ar300m-lite)
 glinet,gl-x750)
 	ucidef_set_led_netdev "wan" "WAN" "$boardname:green:wan" "eth1"
 	;;
+netgear,wnr2000-v3)
+	ucidef_set_led_netdev "wan-amber" "WAN (amber)" "netgear:amber:wan" "eth0"
+	ucidef_set_led_default "wan-green" "WAN (green)" "netgear:green:wan" "0"
+	ucidef_set_led_switch "lan1green" "LAN1 (green)" "netgear:green:lan1" "switch0" "0x02" "0x04"
+	ucidef_set_led_switch "lan2green" "LAN2 (green)" "netgear:green:lan2" "switch0" "0x04" "0x04"
+	ucidef_set_led_switch "lan3green" "LAN3 (green)" "netgear:green:lan3" "switch0" "0x08" "0x04"
+	ucidef_set_led_switch "lan4green" "LAN4 (green)" "netgear:green:lan4" "switch0" "0x10" "0x04"
+	ucidef_set_led_switch "lan1amber" "LAN1 (amber)" "netgear:amber:lan1" "switch0" "0x02" "0x02"
+	ucidef_set_led_switch "lan2amber" "LAN2 (amber)" "netgear:amber:lan2" "switch0" "0x04" "0x02"
+	ucidef_set_led_switch "lan3amber" "LAN3 (amber)" "netgear:amber:lan3" "switch0" "0x08" "0x02"
+	ucidef_set_led_switch "lan4amber" "LAN4 (amber)" "netgear:amber:lan4" "switch0" "0x10" "0x02"
+	;;
 netgear,wnr612-v2|\
 on,n150r)
 	ucidef_set_led_netdev "wan" "WAN" "netgear:green:wan" "eth0"
diff --git a/target/linux/ath79/base-files/etc/board.d/02_network b/target/linux/ath79/base-files/etc/board.d/02_network
index 99b9d421f4..aff62274b6 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -195,6 +195,7 @@  ath79_setup_interfaces()
 		ucidef_add_switch_port_attr "switch0" 2 led 9
 		ucidef_add_switch_port_attr "switch0" 5 led 2
 		;;
+	netgear,wnr2000-v3|\
 	netgear,wnr612-v2|\
 	on,n150r|\
 	tplink,tl-wr740n-v1|\
diff --git a/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom b/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
index ec597dd1d4..747c1aab58 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
@@ -165,6 +165,7 @@  case "$FIRMWARE" in
 	winchannel,wb2000)
 		ath9k_eeprom_extract "art" 20480 1088
 		;;
+	netgear,wnr2000-v3|\
 	netgear,wnr612-v2|\
 	on,n150r|\
 	pcs,cap324|\
diff --git a/target/linux/ath79/dts/ar7241_netgear_wnr2000-v3.dts b/target/linux/ath79/dts/ar7241_netgear_wnr2000-v3.dts
new file mode 100644
index 0000000000..22f27f5313
--- /dev/null
+++ b/target/linux/ath79/dts/ar7241_netgear_wnr2000-v3.dts
@@ -0,0 +1,212 @@ 
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+#include "ar7241.dtsi"
+
+/ {
+	compatible = "netgear,wnr2000-v3", "qca,ar7241";
+	model = "Netgear WNR2000 v3";
+
+	chosen {
+		bootargs = "console=ttyS0,115200n8";
+	};
+
+	aliases {
+		led-boot = &power_amber;
+		led-failsafe = &power_amber;
+		led-running = &power_green;
+		led-upgrade = &power_amber;
+	};
+
+	keys {
+		compatible = "gpio-keys";
+
+		wps {
+			label = "wps";
+			linux,code = <KEY_WPS_BUTTON>;
+			gpios = <&gpio 11 GPIO_ACTIVE_LOW>;
+			debounce-interval = <60>;
+		};
+	};
+
+	ath9k-keys {
+		compatible = "gpio-keys-polled";
+		poll-interval = <20>;
+
+		reset {
+			label = "reset";
+			linux,code = <KEY_RESTART>;
+			gpios = <&ath9k 8 GPIO_ACTIVE_LOW>;
+			debounce-interval = <60>;
+		};
+
+		rfkill {
+			label = "rfkill";
+			linux,code = <KEY_RFKILL>;
+			gpios = <&ath9k 9 GPIO_ACTIVE_LOW>;
+			debounce-interval = <60>;
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&jtag_disable_pins &switch_led_disable_pins &clks_disable_pins>;
+
+		wan_green {
+			label = "netgear:green:wan";
+			gpios = <&gpio 0 GPIO_ACTIVE_LOW>;
+		};
+
+		wan_amber {
+			label = "netgear:amber:wan";
+			gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
+		};
+
+		lan1_green {
+			label = "netgear:green:lan1";
+			gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
+		};
+
+		lan1_amber {
+			label = "netgear:amber:lan1";
+			gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
+		};
+
+		lan2_green {
+			label = "netgear:green:lan2";
+			gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
+		};
+
+		lan2_amber {
+			label = "netgear:amber:lan2";
+			gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
+		};
+
+		lan3_green {
+			label = "netgear:green:lan3";
+			gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
+		};
+
+		lan3_amber {
+			label = "netgear:amber:lan3";
+			gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
+		};
+
+		lan4_green {
+			label = "netgear:green:lan4";
+			gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
+		};
+
+		lan4_amber {
+			label = "netgear:amber:lan4";
+			gpios = <&gpio 12 GPIO_ACTIVE_LOW>;
+		};
+
+		wps_green {
+			label = "netgear:green:wps";
+			gpios = <&gpio 7 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	ath9k-leds {
+		compatible = "gpio-leds";
+
+		power_green: power_green {
+			label = "netgear:green:power";
+			gpios = <&ath9k 3 GPIO_ACTIVE_LOW>;
+		};
+
+		power_amber: power_amber {
+			label = "netgear:amber:power";
+			gpios = <&ath9k 2 GPIO_ACTIVE_LOW>;
+			default-state = "keep";
+		};
+
+		wlan_blue {
+			label = "netgear:blue:wlan";
+			gpios = <&ath9k 1 GPIO_ACTIVE_LOW>;
+			linux,default-trigger = "phy0tpt";
+		};
+	};
+};
+
+&spi {
+	status = "okay";
+	num-cs = <1>;
+
+	flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <25000000>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition@0 {
+				label = "u-boot";
+				reg = <0x0 0x40000>;
+				read-only;
+			};
+
+			partition@40000 {
+				label = "u-boot-env";
+				reg = <0x40000 0x10000>;
+			};
+
+			partition@50000 {
+				label = "firmware";
+				reg = <0x50000 0x3a0000>;
+				compatible = "netgear,uimage";
+			};
+
+			art: partition@3f0000 {
+				label = "art";
+				reg = <0x3f0000 0x10000>;
+				read-only;
+			};
+		};
+	};
+};
+
+&eth0 {
+	status = "okay";
+
+	mtd-mac-address = <&art 0x0>;
+};
+
+&eth1 {
+	status = "okay";
+
+	compatible = "qca,ar7241-eth", "syscon", "simple-mfd";
+	mtd-mac-address = <&art 0x6>;
+};
+
+&pcie {
+	status = "okay";
+
+	ath9k: wifi@0,0 {
+		compatible = "pci168c,002e";
+		reg = <0x0000 0 0 0 0>;
+		mtd-mac-address = <&art 0x0>;
+		mtd-mac-address-increment = <1>;
+		mtd-cal-data = <&art 0x1000>;
+		qca,no-eeprom;
+		#gpio-cells = <2>;
+		gpio-controller;
+	};
+};
+
+&uart {
+	status = "okay";
+};
+
+&gpio {
+        status = "okay";
+};
diff --git a/target/linux/ath79/image/tiny-netgear.mk b/target/linux/ath79/image/tiny-netgear.mk
index 2f17d79757..b5fed1b88b 100644
--- a/target/linux/ath79/image/tiny-netgear.mk
+++ b/target/linux/ath79/image/tiny-netgear.mk
@@ -27,3 +27,19 @@  define Device/on_n150r
   SUPPORTED_DEVICES += n150r
 endef
 TARGET_DEVICES += on_n150r
+
+define Device/netgear_wnr2000-v3
+  ATH_SOC := ar7241
+  DEVICE_MODEL := WNR2000
+  DEVICE_VARIANT := v3
+  NETGEAR_KERNEL_MAGIC := 0x32303033
+  NETGEAR_BOARD_ID := WNR2000V3
+  NETGEAR_HW_ID := 29763551+04+32
+  IMAGE_SIZE := 3712k
+  IMAGE/default := append-kernel | pad-to $$$$(BLOCKSIZE) | netgear-squashfs | append-rootfs | pad-rootfs
+  IMAGES += factory-NA.img
+  IMAGE/factory-NA.img := $$(IMAGE/default) | netgear-dni NA | check-size $$$$(IMAGE_SIZE)
+  SUPPORTED_DEVICES += wnr2000-v3
+  $(Device/netgear_ath79)
+endef
+TARGET_DEVICES += netgear_wnr2000-v3