| Message ID | 20190811224446.3334b7e6@kosmio.komorska |
|---|---|
| State | Superseded |
| Headers | show |
| Series | ath79: add support for some Netgear WNR routers | expand |
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
-----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-----
-----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-----
> /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.
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
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
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
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; + }; + }; + }; +}; + +ð0 { + status = "okay"; + + mtd-mac-address = <&art 0x0>; +}; + +ð1 { + 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
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