[OpenWrt-Devel] [PATCH] ath79: add D-Link DIR-615 rev. E4

[Paul Fertser]

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 at 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 at 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 at 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!

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav at gmail.com

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel