[OpenWrt-Devel] ath79: add D-Link DIR-615 rev. E4
diff mbox series

Message ID 20191103113247.9782-1-fercerpav@gmail.com
State Superseded, archived
Headers show
Series
  • [OpenWrt-Devel] ath79: add D-Link DIR-615 rev. E4
Related show

Commit Message

Paul Fertser Nov. 3, 2019, 11:32 a.m. UTC
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

Comments

Paul Fertser Nov. 3, 2019, 11:39 a.m. UTC | #1
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.
Adrian Schmutzler Nov. 4, 2019, 4:16 p.m. UTC | #2
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 = &eth0;

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;
> +			};
> +		};
> +	};
> +};
> +
> +&eth0 {
> +	status = "okay";
> +
> +	/* ethernet MAC is stored in nvram */
> +};
> +
> +&eth1 {
> +	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
Adrian Schmutzler Nov. 4, 2019, 4:18 p.m. UTC | #3
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
Paul Fertser Nov. 4, 2019, 4:54 p.m. UTC | #4
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!
Paul Fertser Nov. 4, 2019, 9:19 p.m. UTC | #5
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).
Adrian Schmutzler Nov. 5, 2019, 12:41 p.m. UTC | #6
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
Thomas Endt Nov. 6, 2019, 10:31 p.m. UTC | #7
Hi Paul,

> Support ported from ar71xx.
>
> Signed-off-by: Paul Fertser <fercerpav@gmail.com>

[...]

Can you please add installation instructions?

Thanks!

Thomas
Paul Fertser Nov. 7, 2019, 5:19 a.m. UTC | #8
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!
Paul Fertser Nov. 8, 2019, 7:50 a.m. UTC | #9
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.
Lars Melin Nov. 8, 2019, 8:12 a.m. UTC | #10
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
Enrico Mioso Nov. 8, 2019, 9:10 a.m. UTC | #11
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
Adrian Schmutzler Nov. 8, 2019, 2:53 p.m. UTC | #12
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
Paul Fertser Nov. 8, 2019, 4:41 p.m. UTC | #13
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.
Paul Fertser Nov. 8, 2019, 4:47 p.m. UTC | #14
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
Paul Fertser Dec. 11, 2019, 11:10 a.m. UTC | #15
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?

Patch
diff mbox series

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 = &eth0;
+	};
+
+	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;
+			};
+		};
+	};
+};
+
+&eth0 {
+	status = "okay";
+
+	/* ethernet MAC is stored in nvram */
+};
+
+&eth1 {
+	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|\