| Message ID | 20191103113247.9782-1-fercerpav@gmail.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | [OpenWrt-Devel] ath79: add D-Link DIR-615 rev. E4 | expand |
Hello dear reviewers, On Sun, Nov 03, 2019 at 02:32:47PM +0300, Paul Fertser wrote: > + mac: partition@3b0000 { > + reg = <0x3b0000 0x10000>; > + label = "mac"; > + read-only; > + }; > + > + lp: partition@3c0000 { > + reg = <0x3c0000 0x30000>; > + label = "lp"; > + read-only; > + }; These two I'm not sure about. They do not seem to contain anything useful but I haven't checked running vendor firmware. They waste 256 KiB of precious flash space. > + ath9k: wifi@0,0 { > + compatible = "pci168c,002b"; This is a weird node. It doesn't match (actual PID is 0x002e) and yet the driver loads and works. Probably it shouldn't be used at all? > + dlink,dir-615-e4) > + caldata_extract "art" 0x1000 0x1000 > + ath9k_patch_mac_crc $(mtd_get_mac_ascii "nvram" "lan_mac") 0x10c lan mac seems to be used for wlan as is (without +1/-1) by ar71xx code.
Hi, > diff --git a/target/linux/ath79/dts/ar7240_dlink_dir-600-a1.dtsi > b/target/linux/ath79/dts/ar7240_dlink_dir-600-a1.dtsi > new file mode 100644 > index 0000000000..e6206f6f42 > --- /dev/null > +++ b/target/linux/ath79/dts/ar7240_dlink_dir-600-a1.dtsi > @@ -0,0 +1,173 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT > + > +#include <dt-bindings/gpio/gpio.h> > +#include <dt-bindings/input/input.h> > + > +#include "ar7240.dtsi" > + > +/ { > + aliases { > + led-boot = &power_amber; > + led-failsafe = &power_amber; > + led-running = &power_green; > + led-upgrade = &power_amber; > + label-mac-device = ð0; This only works when the address is set in DT, but you use 02_network. > + }; > + > + keys { > + compatible = "gpio-keys"; > + > + reset { > + label = "reset"; > + linux,code = <KEY_RESTART>; > + gpios = <&gpio 8 GPIO_ACTIVE_LOW>; > + debounce-interval = <60>; > + }; > + > + wps { > + label = "wps"; > + linux,code = <KEY_WPS_BUTTON>; > + gpios = <&gpio 12 GPIO_ACTIVE_LOW>; > + debounce-interval = <60>; > + }; > + }; > + > + gpio-leds { Use "leds". > + compatible = "gpio-leds"; > + pinctrl-names = "default"; > + pinctrl-0 = <&switch_led_pins>; > + > + power_green: power_green { > + label = "d-link:green:power"; It's policy to use boardname instead of "d-link" here, except for tplink as far as I know. > + gpios = <&gpio 6 GPIO_ACTIVE_HIGH>; > + }; > + > + power_amber: power_amber { > + label = "d-link:amber:power"; > + gpios = <&gpio 1 GPIO_ACTIVE_HIGH>; > + }; > + > + wps { > + label = "d-link:blue:wps"; > + gpios = <&gpio 0 GPIO_ACTIVE_LOW>; > + }; > + > + lan1 { > + label = "d-link:green:lan1"; > + gpios = <&gpio 13 GPIO_ACTIVE_LOW>; > + }; > + > + lan2 { > + label = "d-link:green:lan2"; > + gpios = <&gpio 14 GPIO_ACTIVE_LOW>; > + }; > + > + lan3 { > + label = "d-link:green:lan3"; > + gpios = <&gpio 15 GPIO_ACTIVE_LOW>; > + }; > + > + lan4 { > + label = "d-link:green:lan4"; > + gpios = <&gpio 16 GPIO_ACTIVE_LOW>; > + }; > + > + wan_amber { > + label = "d-link:amber:wan"; > + gpios = <&gpio 7 GPIO_ACTIVE_HIGH>; > + }; > + > + wan_green { > + label = "d-link:green:wan"; > + gpios = <&gpio 17 GPIO_ACTIVE_LOW>; > + }; > + }; > +}; > + > +&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>; > + > + uboot: partition@0 { > + reg = <0x0 0x30000>; > + label = "u-boot"; > + read-only; > + }; > + > + nvram: partition@30000 { > + reg = <0x30000 0x10000>; > + label = "nvram"; > + read-only; > + }; > + > + firmware: partition@40000 { > + compatible = "denx,uimage"; > + reg = <0x40000 0x370000>; 3520k? Does this even build with standard buildbot settings? Be aware that you might not find someone willing to merge this. > + label = "firmware"; > + }; > + > + mac: partition@3b0000 { > + reg = <0x3b0000 0x10000>; > + label = "mac"; Why is there a partition labelled mac that is not used for MAC addresses? Have you checked the partition for MAC addresses? > + read-only; > + }; > + > + lp: partition@3c0000 { > + reg = <0x3c0000 0x30000>; > + label = "lp"; > + read-only; > + }; > + > + art: partition@3f0000 { > + reg = <0x3f0000 0x10000>; > + label = "art"; > + read-only; > + }; > + }; > + }; > +}; > + > +ð0 { > + status = "okay"; > + > + /* ethernet MAC is stored in nvram */ > +}; > + > +ð1 { > + status = "okay"; > + > + /* ethernet MAC is stored in nvram */ > +}; > + > +&pcie { > + status = "okay"; > + > + ath9k: wifi@0,0 { > + compatible = "pci168c,002b"; > + reg = <0x0000 0 0 0 0>; > + qca,no-eeprom; > + /* LAN MAC is supposed to be used for wifi */ > + #gpio-cells = <2>; > + gpio-controller; > + }; > +}; > + > +&pinmux { > + switch_led_pins: pinmux_switch_led_pins { > + pinctrl-single,bits = <0x0 0x0 0xf8>; > + }; > +}; > + > +&uart { > + status = "okay"; > +}; > diff --git a/target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts > b/target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts > new file mode 100644 > index 0000000000..7ea6e8a583 > --- /dev/null > +++ b/target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts > @@ -0,0 +1,19 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT > +/dts-v1/; > + > +#include "ar7240_dlink_dir-600-a1.dtsi" > + > +/ { > + model = "D-Link DIR-615 rev. E4"; Remove the "rev.". > + compatible = "dlink,dir-615-e4", "qca,ar7240"; > + > + ath9k-leds { > + compatible = "gpio-leds"; > + > + wlan { > + label = "d-link:green:wlan"; > + gpios = <&ath9k 1 GPIO_ACTIVE_LOW>; > + linux,default-trigger = "phy0tpt"; > + }; > + }; > +}; > diff --git a/target/linux/ath79/image/tiny.mk > b/target/linux/ath79/image/tiny.mk > index 8f867575af..a4aed65684 100644 > --- a/target/linux/ath79/image/tiny.mk > +++ b/target/linux/ath79/image/tiny.mk > @@ -13,6 +13,22 @@ define Device/buffalo_whr-g301n > endef > TARGET_DEVICES += buffalo_whr-g301n > > +define Device/dlink_dir-615-e4 > + ATH_SOC := ar7240 > + DEVICE_VENDOR := D-Link > + DEVICE_MODEL := DIR-615 > + DEVICE_VARIANT := E4 > + IMAGE_SIZE := 3520k > + FACTORY_IMAGE_SIZE := 3456k > + IMAGES += factory.bin > + IMAGE/default := append-kernel | append-rootfs | pad-rootfs > + IMAGE/sysupgrade.bin := $$(IMAGE/default) | append-metadata | > check-size $$$$(IMAGE_SIZE) > + IMAGE/factory.bin := $$(IMAGE/default) | check-size > $$$$(FACTORY_IMAGE_SIZE) | \ > + pad-to $$$$(FACTORY_IMAGE_SIZE) | append-string > "AP99-AR7240-RT-091105-05" > + SUPPORTED_DEVICES += dir-615-e4 > +endef > +TARGET_DEVICES += dlink_dir-615-e4 > + > define Device/pqi_air-pen > ATH_SOC := ar9330 > DEVICE_VENDOR := PQI > diff --git a/target/linux/ath79/tiny/base-files/etc/board.d/01_leds > b/target/linux/ath79/tiny/base-files/etc/board.d/01_leds > index bb1799c645..80877929f4 100755 > --- a/target/linux/ath79/tiny/base-files/etc/board.d/01_leds > +++ b/target/linux/ath79/tiny/base-files/etc/board.d/01_leds > @@ -15,6 +15,13 @@ buffalo,whr-g301n) > ucidef_set_led_switch "lan3" "LAN3" "$boardname:green:lan3" > "switch0" "0x08" > ucidef_set_led_switch "lan4" "LAN4" "$boardname:green:lan4" > "switch0" "0x10" > ;; > +dlink,dir-615-e4) > + ucidef_set_led_netdev "wan" "WAN" "d-link:green:wan" "eth0" > + ucidef_set_led_switch "lan1" "LAN1" "d-link:green:lan1" "switch0" > "0x02" > + ucidef_set_led_switch "lan2" "LAN2" "d-link:green:lan2" "switch0" > "0x04" > + ucidef_set_led_switch "lan3" "LAN3" "d-link:green:lan3" "switch0" > "0x08" > + ucidef_set_led_switch "lan4" "LAN4" "d-link:green:lan4" "switch0" > "0x10" > + ;; If you use boardname for leds as indicated above, you can merge this with buffalo,whr-.... > netgear,wnr1000-v2|\ > netgear,wnr2000-v3) > ucidef_set_led_netdev "wan-amber" "WAN (amber)" > "netgear:amber:wan" "eth0" > diff --git a/target/linux/ath79/tiny/base-files/etc/board.d/02_network > b/target/linux/ath79/tiny/base-files/etc/board.d/02_network > index 49fccc0b2e..ff12975063 100755 > --- a/target/linux/ath79/tiny/base-files/etc/board.d/02_network > +++ b/target/linux/ath79/tiny/base-files/etc/board.d/02_network > @@ -35,6 +35,7 @@ ath79_setup_interfaces() > ucidef_add_switch "switch0" \ > "0@eth0" "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" > ;; > + dlink,dir-615-e4|\ > netgear,wnr1000-v2|\ > netgear,wnr2000-v3|\ > netgear,wnr612-v2|\ > @@ -75,6 +76,10 @@ ath79_setup_macs() > local board="$1" > > case "$board" in > + dlink,dir-615-e4) > + lan_mac=$(mtd_get_mac_ascii "nvram" "lan_mac") > + wan_mac=$(mtd_get_mac_ascii "nvram" "wan_mac") > + ;; I didn't find a reference to "wan_mac" in nvram in ar71xx. Did you deduce that by yourself? Best Adrian
Hi, > > + dlink,dir-615-e4) > > + caldata_extract "art" 0x1000 0x1000 > > + ath9k_patch_mac_crc $(mtd_get_mac_ascii "nvram" "lan_mac") > 0x10c > > lan mac seems to be used for wlan as is (without +1/-1) by ar71xx > code. That's not uncommon, however you'll only know for sure if you check with vendor firmware. Best Adrian
Hello, Thank you for the review indeed! On Mon, Nov 04, 2019 at 05:16:15PM +0100, Adrian Schmutzler wrote: > > + power_green: power_green { > > + label = "d-link:green:power"; > > It's policy to use boardname instead of "d-link" here, except for tplink as far as I know. My bad, I was using tp-link 741 code for inspiration. > > + firmware: partition@40000 { > > + compatible = "denx,uimage"; > > + reg = <0x40000 0x370000>; > > 3520k? Does this even build with standard buildbot settings? I did not know I need to check with standard buildbot settings, I haven't noticed anything like that in the patch guide. That said, I find these settings meaningful for a home AP+router: CONFIG_TARGET_ath79=y CONFIG_TARGET_ath79_tiny=y CONFIG_TARGET_ath79_tiny_DEVICE_dlink_dir-615-e4=y CONFIG_PACKAGE_6in4=y # CONFIG_PACKAGE_iwinfo is not set CONFIG_PACKAGE_kmod-iptunnel=y CONFIG_PACKAGE_kmod-iptunnel4=y # CONFIG_PACKAGE_kmod-ppp is not set CONFIG_PACKAGE_kmod-sit=y # CONFIG_PACKAGE_libiwinfo is not set # CONFIG_PACKAGE_openwrt-keyring is not set # CONFIG_PACKAGE_ppp is not set # CONFIG_PACKAGE_uboot-envtools is not set # CONFIG_PACKAGE_usign is not set # CONFIG_SIGNATURE_CHECK is not set # CONFIG_SIGNED_PACKAGES is not set With that I have 6 eraseblocks left for the rootfs_data partition (5 is the absolute minimum jffs2 allows). > Be aware that you might not find someone willing to merge this. I do not think this device is any worse than the other 4M devices supported by ath79. Moreover, it can easily (two usb pulldown resistors and two series) be modded to add a USB port (much easier than TL-WR741ND). Regarding the firmware partition size, it can be made 4 eraseblocks more if the next two useless partitions are merged into it. > > + mac: partition@3b0000 { > > + reg = <0x3b0000 0x10000>; > > + label = "mac"; > > Why is there a partition labelled mac that is not used for MAC > addresses? Have you checked the partition for MAC addresses? I have, and it certainly doesn't have the address printed on device label. I would guess the partition is a rudiment of Cameo99 reference design or something like that, and D-Link in their wisdom decided to store MACs elsewhere. > > + lp: partition@3c0000 { > > + reg = <0x3c0000 0x30000>; > > + label = "lp"; > > + read-only; > > + }; This I have no idea what can be used for. hexdumping it reveals some filenames and "whiteout" strings which might hint at using it as some kind of a writeable overlay. I can't be sure I still have the factory data in it though, but I do not remember specifically overwriting or anyhow abusing it either, probably it was done before me. Anyway, I do not see any good reason to care much about running factory (old, buggy and flawed) vendor firmware on this ancient device (it came with an old-school 50Hz transformer PSU, you can imagine how old it is!) > > case "$board" in > > + dlink,dir-615-e4) > > + lan_mac=$(mtd_get_mac_ascii "nvram" "lan_mac") > > + wan_mac=$(mtd_get_mac_ascii "nvram" "wan_mac") > > + ;; > > I didn't find a reference to "wan_mac" in nvram in ar71xx. Did you deduce that by yourself? Yes, that's where I deviate from code in ar71xx. I grepped strings in nvram partition and noticed lan_mac and wan_mac, both made perfect sense. Regarding wlan mac in vendor firmware, I do not think I've ever seen vendor firmware running on this board so I can't tell. Guess whoever added support for it (and the other 3 almost identical boards) in ar71xx have checked all the options. All your other points noted, thanks a lot!
On Mon, Nov 04, 2019 at 05:16:15PM +0100, Adrian Schmutzler wrote: > > + power_green: power_green { > > + label = "d-link:green:power"; > > It's policy to use boardname instead of "d-link" here, except for tplink as far as I know. But in this case there're three other boards that can be supported by almost the same code (they lack "wlan" led but they also get a bigger firmware partition becase they have no "lp" partition). I am not sure how to properly add support for all of them, especially given I have no way to test on real hardware (except for the E4).
Hi, > -----Original Message----- > From: openwrt-devel [mailto:openwrt-devel-bounces@lists.openwrt.org] On > Behalf Of Paul Fertser > Sent: Montag, 4. November 2019 22:20 > To: Adrian Schmutzler <mail@adrianschmutzler.de> > Cc: openwrt-devel@lists.openwrt.org > Subject: Re: [OpenWrt-Devel] [PATCH] ath79: add D-Link DIR-615 rev. E4 > > On Mon, Nov 04, 2019 at 05:16:15PM +0100, Adrian Schmutzler wrote: > > > + power_green: power_green { > > > + label = "d-link:green:power"; > > > > It's policy to use boardname instead of "d-link" here, except for tplink as far as I > know. > > But in this case there're three other boards that can be supported by > almost the same code (they lack "wlan" led but they also get a bigger > firmware partition becase they have no "lp" partition). I am not sure > how to properly add support for all of them, especially given I have > no way to test on real hardware (except for the E4). I've just looked into ar71xx leds definitions and it seems like d-link has been used there consistently. So, ignore my comment in this context and keep your current d-link:green... Concerning adding further devices: No merge without testing on device. You can try to build a patch and then look for other people testing, either in the forum or as WIP Pull-Request. You can try to check older commits for that device to ask people for help. But without proper testing we won't accept a support patch, no matter whether it's a new device or just migrated from ar71xx. The only exception may be made when there is clear evidence on a 100 % clone of a supported device just with different name. Best Adrian
Hi Paul, > Support ported from ar71xx. > > Signed-off-by: Paul Fertser <fercerpav@gmail.com> [...] Can you please add installation instructions? Thanks! Thomas
Hello Thomas, On Wed, Nov 06, 2019 at 11:31:23PM +0100, tmo26@gmx.de wrote: > > Support ported from ar71xx. > > > > Signed-off-by: Paul Fertser <fercerpav@gmail.com> > > [...] > > Can you please add installation instructions? Please notice that this patch is WiP and some additional changes are to be introduced in v2. I would expect -factory.bin to be flashable by vendor firmware. Closely looking at hexdump -C doesn't reveal any differences between generated images by existing support in ar71xx target and this ath79 port. Upgrading from OpenWrt is possible with sysupgrade. TFTP to uboot doesn't work for me (I receive ARP request and send replies back but they're apparently never heard) but with "loady" I'm able to bootm an initramfs image and then sysupgrade from it. I see there's some http server mentioned in the wiki article, haven't tried it yet (and I can't understand what "simple" web browser it talks about, probably there should be a curl command instead?), and in my opinion it's ok to wait for a few minutes for slow serial upload as it's to be performed only once anyway but if you can figure a reliable http method it would be a nice alternative. Where would you like to have the additional installation instructions, on the wiki or in the commit message itself? BTW, as a device user, what's your opinion regarding mac and lp partitions, do you consider keeping them wasteful or not? Thank you!
On Thu, Nov 07, 2019 at 08:19:27AM +0300, Paul Fertser wrote: > I see there's some http server mentioned in the wiki article, haven't > tried it yet (and I can't understand what "simple" web browser it > talks about, probably there should be a curl command instead?), So I gave it a try but the results are not fruitful. This command should work: curl http://192.168.0.1/cgi/index -F Send=@built/targets/ath79/tiny/openwrt-ath79-tiny-dlink_dir-615-e4-squashfs-factory.bin BUT the recovery HTTP server is using a very old uIP implementation that seems to be unable to play well along with the current TCP stack in Linux. The result is a very slow upload (left it overnight and it's still not finished). From working with uIP before on an embedded target I know that it doesn't support delayed ACKs in any form, for any packet it sends it waits for an ACK before sending the next, and I would guess that for any packet it receives it's better to wait for its ACK before sending the next (as I see plenty of duplicated ACKs from this backup server all confirming just the first packet received, and then long wait before retransmission). The problem is in the number of packets sent, not the size (so changing MTU/MSS doesn't help much). I haven't been able to find a way to trick it into behaving, sorry.
On 11/8/2019 14:50, Paul Fertser wrote: > On Thu, Nov 07, 2019 at 08:19:27AM +0300, Paul Fertser wrote: >> I see there's some http server mentioned in the wiki article, haven't >> tried it yet (and I can't understand what "simple" web browser it >> talks about, probably there should be a curl command instead?), > > So I gave it a try but the results are not fruitful. This command > should work: > > curl http://192.168.0.1/cgi/index -F Send=@built/targets/ath79/tiny/openwrt-ath79-tiny-dlink_dir-615-e4-squashfs-factory.bin > > BUT the recovery HTTP server is using a very old uIP implementation > that seems to be unable to play well along with the current TCP stack > in Linux. The result is a very slow upload (left it overnight and it's > still not finished). > > From working with uIP before on an embedded target I know that it > doesn't support delayed ACKs in any form, for any packet it sends it > waits for an ACK before sending the next, and I would guess that for > any packet it receives it's better to wait for its ACK before sending > the next (as I see plenty of duplicated ACKs from this backup server > all confirming just the first packet received, and then long wait > before retransmission). The problem is in the number of packets sent, > not the size (so changing MTU/MSS doesn't help much). > > I haven't been able to find a way to trick it into behaving, sorry. > Don't complicate simple things, all D-Link routers have a recovery web page and you access it with your browser, not with curl. /Lars
On Fri, 8 Nov 2019, Lars Melin wrote: > > Don't complicate simple things, all D-Link routers have a recovery web page > and you access it with your browser, not with curl. > > /Lars > Some things maybe simple to you, yet complicated to me, and vice-versa. To me,using "curl" to perform recovery may prove to be much simpler than having to open a web browser. And if recovery is localized in a language I don't know (e.g.: Chinese), having a "curl" shortcut is really valuable. and not only because I use assistive technologies to perform those things. :) thanks to you and all for your great work, Enrico
Hi, > > > + firmware: partition@40000 { > > > + compatible = "denx,uimage"; > > > + reg = <0x40000 0x370000>; > > > > 3520k? Does this even build with standard buildbot settings? > > I did not know I need to check with standard buildbot settings, I > haven't noticed anything like that in the patch guide. > [...] > > With that I have 6 eraseblocks left for the rootfs_data partition (5 > is the absolute minimum jffs2 allows). > > > Be aware that you might not find someone willing to merge this. > > I do not think this device is any worse than the other 4M devices > supported by ath79. [...] Well, TP-Link devices have 0x3d0000, Netgear has 0x3a0000, ... > > Regarding the firmware partition size, it can be made 4 eraseblocks > more if the next two useless partitions are merged into it. > > > > + mac: partition@3b0000 { > > > + reg = <0x3b0000 0x10000>; > > > + label = "mac"; > > > > Why is there a partition labelled mac that is not used for MAC > > addresses? Have you checked the partition for MAC addresses? > > I have, and it certainly doesn't have the address printed on device > label. I would guess the partition is a rudiment of Cameo99 reference > design or something like that, and D-Link in their wisdom decided to > store MACs elsewhere. > > > > + lp: partition@3c0000 { > > > + reg = <0x3c0000 0x30000>; > > > + label = "lp"; > > > + read-only; > > > + }; > > This I have no idea what can be used for. hexdumping it reveals some > filenames and "whiteout" strings which might hint at using it as some > kind of a writeable overlay. I can't be sure I still have the factory > data in it though, but I do not remember specifically overwriting or > anyhow abusing it either, probably it was done before me. > > Anyway, I do not see any good reason to care much about running > factory (old, buggy and flawed) vendor firmware on this ancient device > (it came with an old-school 50Hz transformer PSU, you can imagine how > old it is!) Well, on the other hand the question is whether we want to deviate from the principle of keeping vendor partitions to add support for a 4/32 device, especially since the partition size will be still small in comparison afterwards. If it might stop building anyway soon, we could also keep the partitions in official repo and whoever wants to use it will have to mess with the code. Best Adrian > > > > case "$board" in > > > + dlink,dir-615-e4) > > > + lan_mac=$(mtd_get_mac_ascii "nvram" "lan_mac") > > > + wan_mac=$(mtd_get_mac_ascii "nvram" "wan_mac") > > > + ;; > > > > I didn't find a reference to "wan_mac" in nvram in ar71xx. Did you deduce that > by yourself? > > Yes, that's where I deviate from code in ar71xx. I grepped strings in > nvram partition and noticed lan_mac and wan_mac, both made perfect > sense. Regarding wlan mac in vendor firmware, I do not think I've ever > seen vendor firmware running on this board so I can't tell. Guess > whoever added support for it (and the other 3 almost identical boards) > in ar71xx have checked all the options. > > All your other points noted, thanks a lot! > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fercerpav@gmail.com > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Hi Adrian, On Fri, Nov 08, 2019 at 03:53:59PM +0100, Adrian Schmutzler wrote: > > With that I have 6 eraseblocks left for the rootfs_data partition (5 > > is the absolute minimum jffs2 allows). > > > > > Be aware that you might not find someone willing to merge this. > > > > I do not think this device is any worse than the other 4M devices > > supported by ath79. [...] > > Well, TP-Link devices have 0x3d0000, Netgear has 0x3a0000, ... With the useless partitions concatenated with firmware it'll be 0x3b0000, more than Netgear, same as many 4M ramips devices. My current guess is that "mac" partition initially contains MAC (but it is not used as D-Link specifies their own in nvram) and "lp" might be a "language pack" which is to be downloaded and flashed separately when using vendor firmware. But even with 0x370000 I showed a sensible set of software that still allows to have 6 eraseblocks for rootfs_data. I think the only possibly essential part missing is DNSSEC but that would assume one is using such an old and limited device as his or her border gateway which is unlikely; yet this old 2x2 router can still serve nicely as a "wireless extender" or just a "dumb AP". > Well, on the other hand the question is whether we want to deviate > from the principle of keeping vendor partitions to add support for a > 4/32 device, especially since the partition size will be still small > in comparison afterwards. If it might stop building anyway soon, we > could also keep the partitions in official repo and whoever wants to > use it will have to mess with the code. For my own use I'm certainly planning to self-build and to have firmware partition span till the beginning of "art". With regard to the official tree, I guess that's up to the target maintainer (and possibly the end-users?) to decide.
On Fri, Nov 08, 2019 at 07:41:33PM +0300, Paul Fertser wrote: > "lp" might be a "language pack" which is to be downloaded and > flashed separately when using vendor firmware. One forum post[1] says that the only language pack the person was able to ever find for this device was for "taiwanese language" :D [1] http://4pda.ru/forum/lofiversion/index.php?t446257-1580.html
Hello Lars, On Fri, Nov 08, 2019 at 03:12:02PM +0700, Lars Melin wrote: > On 11/8/2019 14:50, Paul Fertser wrote: > > From working with uIP before on an embedded target I know that it > > doesn't support delayed ACKs in any form, for any packet it sends it > > waits for an ACK before sending the next, and I would guess that for > > any packet it receives it's better to wait for its ACK before sending > > the next (as I see plenty of duplicated ACKs from this backup server > > all confirming just the first packet received, and then long wait > > before retransmission). The problem is in the number of packets sent, > > not the size (so changing MTU/MSS doesn't help much). > > > > I haven't been able to find a way to trick it into behaving, sorry. > > > > Don't complicate simple things, all D-Link routers have a recovery web page > and you access it with your browser, not with curl. You quoted my message and it doesn't contradict "having a recovery web page" idea. However, it clearly says that I can't meaningfully use it _anyhow_, neither with curl nor with my browser. Please reread the quote and you'll see it is not simple. Do you want me to send you a PCAP file as a proof?
diff --git a/target/linux/ath79/dts/ar7240_dlink_dir-600-a1.dtsi b/target/linux/ath79/dts/ar7240_dlink_dir-600-a1.dtsi new file mode 100644 index 0000000000..e6206f6f42 --- /dev/null +++ b/target/linux/ath79/dts/ar7240_dlink_dir-600-a1.dtsi @@ -0,0 +1,173 @@ +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT + +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/input/input.h> + +#include "ar7240.dtsi" + +/ { + aliases { + led-boot = &power_amber; + led-failsafe = &power_amber; + led-running = &power_green; + led-upgrade = &power_amber; + label-mac-device = ð0; + }; + + keys { + compatible = "gpio-keys"; + + reset { + label = "reset"; + linux,code = <KEY_RESTART>; + gpios = <&gpio 8 GPIO_ACTIVE_LOW>; + debounce-interval = <60>; + }; + + wps { + label = "wps"; + linux,code = <KEY_WPS_BUTTON>; + gpios = <&gpio 12 GPIO_ACTIVE_LOW>; + debounce-interval = <60>; + }; + }; + + gpio-leds { + compatible = "gpio-leds"; + pinctrl-names = "default"; + pinctrl-0 = <&switch_led_pins>; + + power_green: power_green { + label = "d-link:green:power"; + gpios = <&gpio 6 GPIO_ACTIVE_HIGH>; + }; + + power_amber: power_amber { + label = "d-link:amber:power"; + gpios = <&gpio 1 GPIO_ACTIVE_HIGH>; + }; + + wps { + label = "d-link:blue:wps"; + gpios = <&gpio 0 GPIO_ACTIVE_LOW>; + }; + + lan1 { + label = "d-link:green:lan1"; + gpios = <&gpio 13 GPIO_ACTIVE_LOW>; + }; + + lan2 { + label = "d-link:green:lan2"; + gpios = <&gpio 14 GPIO_ACTIVE_LOW>; + }; + + lan3 { + label = "d-link:green:lan3"; + gpios = <&gpio 15 GPIO_ACTIVE_LOW>; + }; + + lan4 { + label = "d-link:green:lan4"; + gpios = <&gpio 16 GPIO_ACTIVE_LOW>; + }; + + wan_amber { + label = "d-link:amber:wan"; + gpios = <&gpio 7 GPIO_ACTIVE_HIGH>; + }; + + wan_green { + label = "d-link:green:wan"; + gpios = <&gpio 17 GPIO_ACTIVE_LOW>; + }; + }; +}; + +&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>; + + uboot: partition@0 { + reg = <0x0 0x30000>; + label = "u-boot"; + read-only; + }; + + nvram: partition@30000 { + reg = <0x30000 0x10000>; + label = "nvram"; + read-only; + }; + + firmware: partition@40000 { + compatible = "denx,uimage"; + reg = <0x40000 0x370000>; + label = "firmware"; + }; + + mac: partition@3b0000 { + reg = <0x3b0000 0x10000>; + label = "mac"; + read-only; + }; + + lp: partition@3c0000 { + reg = <0x3c0000 0x30000>; + label = "lp"; + read-only; + }; + + art: partition@3f0000 { + reg = <0x3f0000 0x10000>; + label = "art"; + read-only; + }; + }; + }; +}; + +ð0 { + status = "okay"; + + /* ethernet MAC is stored in nvram */ +}; + +ð1 { + status = "okay"; + + /* ethernet MAC is stored in nvram */ +}; + +&pcie { + status = "okay"; + + ath9k: wifi@0,0 { + compatible = "pci168c,002b"; + reg = <0x0000 0 0 0 0>; + qca,no-eeprom; + /* LAN MAC is supposed to be used for wifi */ + #gpio-cells = <2>; + gpio-controller; + }; +}; + +&pinmux { + switch_led_pins: pinmux_switch_led_pins { + pinctrl-single,bits = <0x0 0x0 0xf8>; + }; +}; + +&uart { + status = "okay"; +}; diff --git a/target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts b/target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts new file mode 100644 index 0000000000..7ea6e8a583 --- /dev/null +++ b/target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts @@ -0,0 +1,19 @@ +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT +/dts-v1/; + +#include "ar7240_dlink_dir-600-a1.dtsi" + +/ { + model = "D-Link DIR-615 rev. E4"; + compatible = "dlink,dir-615-e4", "qca,ar7240"; + + ath9k-leds { + compatible = "gpio-leds"; + + wlan { + label = "d-link:green:wlan"; + gpios = <&ath9k 1 GPIO_ACTIVE_LOW>; + linux,default-trigger = "phy0tpt"; + }; + }; +}; diff --git a/target/linux/ath79/image/tiny.mk b/target/linux/ath79/image/tiny.mk index 8f867575af..a4aed65684 100644 --- a/target/linux/ath79/image/tiny.mk +++ b/target/linux/ath79/image/tiny.mk @@ -13,6 +13,22 @@ define Device/buffalo_whr-g301n endef TARGET_DEVICES += buffalo_whr-g301n +define Device/dlink_dir-615-e4 + ATH_SOC := ar7240 + DEVICE_VENDOR := D-Link + DEVICE_MODEL := DIR-615 + DEVICE_VARIANT := E4 + IMAGE_SIZE := 3520k + FACTORY_IMAGE_SIZE := 3456k + IMAGES += factory.bin + IMAGE/default := append-kernel | append-rootfs | pad-rootfs + IMAGE/sysupgrade.bin := $$(IMAGE/default) | append-metadata | check-size $$$$(IMAGE_SIZE) + IMAGE/factory.bin := $$(IMAGE/default) | check-size $$$$(FACTORY_IMAGE_SIZE) | \ + pad-to $$$$(FACTORY_IMAGE_SIZE) | append-string "AP99-AR7240-RT-091105-05" + SUPPORTED_DEVICES += dir-615-e4 +endef +TARGET_DEVICES += dlink_dir-615-e4 + define Device/pqi_air-pen ATH_SOC := ar9330 DEVICE_VENDOR := PQI diff --git a/target/linux/ath79/tiny/base-files/etc/board.d/01_leds b/target/linux/ath79/tiny/base-files/etc/board.d/01_leds index bb1799c645..80877929f4 100755 --- a/target/linux/ath79/tiny/base-files/etc/board.d/01_leds +++ b/target/linux/ath79/tiny/base-files/etc/board.d/01_leds @@ -15,6 +15,13 @@ buffalo,whr-g301n) ucidef_set_led_switch "lan3" "LAN3" "$boardname:green:lan3" "switch0" "0x08" ucidef_set_led_switch "lan4" "LAN4" "$boardname:green:lan4" "switch0" "0x10" ;; +dlink,dir-615-e4) + ucidef_set_led_netdev "wan" "WAN" "d-link:green:wan" "eth0" + ucidef_set_led_switch "lan1" "LAN1" "d-link:green:lan1" "switch0" "0x02" + ucidef_set_led_switch "lan2" "LAN2" "d-link:green:lan2" "switch0" "0x04" + ucidef_set_led_switch "lan3" "LAN3" "d-link:green:lan3" "switch0" "0x08" + ucidef_set_led_switch "lan4" "LAN4" "d-link:green:lan4" "switch0" "0x10" + ;; netgear,wnr1000-v2|\ netgear,wnr2000-v3) ucidef_set_led_netdev "wan-amber" "WAN (amber)" "netgear:amber:wan" "eth0" diff --git a/target/linux/ath79/tiny/base-files/etc/board.d/02_network b/target/linux/ath79/tiny/base-files/etc/board.d/02_network index 49fccc0b2e..ff12975063 100755 --- a/target/linux/ath79/tiny/base-files/etc/board.d/02_network +++ b/target/linux/ath79/tiny/base-files/etc/board.d/02_network @@ -35,6 +35,7 @@ ath79_setup_interfaces() ucidef_add_switch "switch0" \ "0@eth0" "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" ;; + dlink,dir-615-e4|\ netgear,wnr1000-v2|\ netgear,wnr2000-v3|\ netgear,wnr612-v2|\ @@ -75,6 +76,10 @@ ath79_setup_macs() local board="$1" case "$board" in + dlink,dir-615-e4) + lan_mac=$(mtd_get_mac_ascii "nvram" "lan_mac") + wan_mac=$(mtd_get_mac_ascii "nvram" "wan_mac") + ;; tplink,tl-wr941-v2|\ tplink,tl-wr941n-v7-cn) base_mac=$(mtd_get_mac_binary u-boot 0x1fc00) diff --git a/target/linux/ath79/tiny/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom b/target/linux/ath79/tiny/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom index 3da95cc161..5952a40195 100644 --- a/target/linux/ath79/tiny/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom +++ b/target/linux/ath79/tiny/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom @@ -14,6 +14,10 @@ case "$FIRMWARE" in tplink,tl-wr941-v4) caldata_extract "art" 0x1000 0xeb8 ;; + dlink,dir-615-e4) + caldata_extract "art" 0x1000 0x1000 + ath9k_patch_mac_crc $(mtd_get_mac_ascii "nvram" "lan_mac") 0x10c + ;; netgear,wnr1000-v2|\ netgear,wnr2000-v3|\ netgear,wnr612-v2|\
Support ported from ar71xx. Signed-off-by: Paul Fertser <fercerpav@gmail.com> --- .../ath79/dts/ar7240_dlink_dir-600-a1.dtsi | 173 ++++++++++++++++++ .../ath79/dts/ar7240_dlink_dir-615-e4.dts | 19 ++ target/linux/ath79/image/tiny.mk | 16 ++ .../ath79/tiny/base-files/etc/board.d/01_leds | 7 + .../tiny/base-files/etc/board.d/02_network | 5 + .../etc/hotplug.d/firmware/10-ath9k-eeprom | 4 + 6 files changed, 224 insertions(+) create mode 100644 target/linux/ath79/dts/ar7240_dlink_dir-600-a1.dtsi create mode 100644 target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts