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!
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
