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

[Adrian Schmutzler]

Hi,

> > > +			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.
> 
[...]
> 
> 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 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!)

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 at gmail.com
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20191108/0d2bb7b2/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel