OpenWRT AR7 platform

Talk about anything you like here: as long as it's technical, doesn't fit into the other categories and is within the rules. Questions and discussions about operating systems, programming, websites, hosting, ADSL etc. are particularly welcome here.
mstombs
RouterTech Team
RouterTech Team
Posts: 3753
Joined: Wed Jan 10, 2007 11:54 pm

Re: OpenWRT AR7 platform

Post by mstombs » Sun Mar 14, 2010 10:49 pm

One event which passed me by was the incorporation of the Texas Instruments AR7 into the mainline Linux kernel

http://kernelnewbies.org/Linux_2_6_31
http://git.kernel.org/linus/7ca5dc145bc ... 4af9cebefc

Its basically the OpenWRT code s far as I can see. Pity Texas Instruments don't even make the chip any more... might now be the Lantiq XWAY™ AR7 ?
geekgirl
Regular
Regular
Posts: 72
Joined: Sat Feb 27, 2010 3:23 pm
Location: Egypt
Contact:

Re: OpenWRT AR7 platform

Post by geekgirl » Mon Mar 15, 2010 12:25 am

mstombs wrote: it has a single Ethernet port, so I think those OpenWRT bugs are very relevant, I guess someone has patched it to assume a switch when the autodetect fails.
yep
mstombs wrote:

Code: Select all

Fixed MDIO Bus: probed
cpmac-mii: probed
cpmac cpmac.1: no PHY present, falling back to switch mode
cpmac: device eth0 (regs: 08612800, irq: 41, phy: 0:01, mac: 00:12:17:73:00:00)
cpmac: device eth1 (regs: 08610000, irq: 27, phy: 1:1f, mac: 00:12:17:73:00:00)
This is exactly where the problem lies...
Could this be related? https://dev.openwrt.org/ticket/3124
mstombs wrote: I can get an arp-response from the modem if I down eth0 and up eth1, confirming it has the hardware misconfigured - it also gets the MAC address wrong - I didn't add those zeros! If I take br-lan down I can get ping to work, and I can now see the web gui, but it crashes when looking at lan dhcp settings, presumably because the lan bridge down!
Maybe this could be worked-around if you alter the default "/etc/config/network" from commandline ? (you may need to issue `/etc/init.d/network restart` after the edits and before accessing luci)
mstombs wrote: Guess need to try an older version so can raise an OpenWRT ticket for advice on how to select the correct single Ethernet interface. The last 'released' version kamikaze/8.09.2 works, so it is bug in the cpmac driver introduced since then.
Yep, I'm guessing one of the patches in the ticket I linked above, which was not backported to 8.09.2, but applied in trunk.
geekgirl
Regular
Regular
Posts: 72
Joined: Sat Feb 27, 2010 3:23 pm
Location: Egypt
Contact:

Re: OpenWRT AR7 platform

Post by geekgirl » Mon Mar 15, 2010 12:38 am

mstombs wrote:One event which passed me by was the incorporation of the Texas Instruments AR7 into the mainline Linux kernel

http://kernelnewbies.org/Linux_2_6_31
http://git.kernel.org/linus/7ca5dc145bc ... 4af9cebefc
Yep! Thought I mentioned this (AR7 Mainlined in 2.6.31) in the DSL-2640T thread a while back, since its been known for quite some time.
You can see the supported chipsets here:
https://dev.openwrt.org/wiki/ar7
Its basically the OpenWRT code s far as I can see. Pity Texas Instruments don't even make the chip any more... might now be the Lantiq XWAY™ AR7 ?
No idea... I definitely do hear now your sentiment on "AR7 will be obseleted before a fully working DSL/Wifi router solution". While DSL works, with pretty recent firmware (7.0.x), OpenWRT ar7 port still reflects "DSL needs rewrite". I see now its not going to happen anytime soon, especially with no one working on ACX drivers for the 1130/1350A (except 1 contributor on ACX mailing list, only 2 months ago), and lack of switch support.

Though someone (buytenh) in openwrt forum mentioned, around end of 2008, that he submitted 88E6060 (and other model) drivers to the linux netdev mailing list.
Getting ANY switch drivers working for AR7 has been one of the longest standing issues in OpenWRT, lol..
https://dev.openwrt.org/ticket/99
Royally sux :P
geekgirl
Regular
Regular
Posts: 72
Joined: Sat Feb 27, 2010 3:23 pm
Location: Egypt
Contact:

Re: OpenWRT AR7 platform

Post by geekgirl » Mon Mar 15, 2010 1:22 am

thechief wrote:As always, all useful patches will be gratefully accepted ;)
Cool :) Can't promise anything yet, really. Still in R&D phase, major learning curve :)

I just checked out gargoyle's sources earlier today along with kamikaze 8.09 of course, built it, but now rebuilding it after taking out some uneeded stuff and patching the pppoa-doesn't-start-at-boot bug, and building it now to test it all out and get an idea about how the QoS stuff is implemented, the bare-minimums needed, and how well it all works..
Besides the QoS stuff, I'm also interested to see how bwmon-gargoyle (bandwidth monitor) and webmon-gargoyle (web monitor) works and how it all fits together in the web interface, and most importantly, to get ideas for possible improvements to RouterTech in terms of bandwidth monitoring / accounting.

Another thought that came to mind during research, is dropping "darkstat" & "ipt_account" (IP Accounting) in favor of "bandwidthd". While bandwidthd is slightly smaller than darkstat alone - in (installed) size, and while both depend on libpcap, bandwidthd appears to be much more flexible than darkstat+ipt_account combined, in terms of comprehensive reporting.
BandwidthD tracks usage of TCP/IP network subnets and builds html files with graphs to display utilization. Charts are built by individual IPs, and by default display utilization over 2 day, 8 day, 40 day, and 400 day periods. Furthermore, each ip address's utilization can be logged out at intervals of 3.3 minutes, 10 minutes, 1 hour or 12 hours in cdf format, or to a backend database server. HTTP, TCP, UDP, ICMP, VPN, and P2P traffic are color coded.
..
Bandwidthd now produces output in 2 ways. The first is as a standalone application that produces static html and png output every 200 seconds. The second is as a sensor that transmits it's data to a backend database which is then reported on by dynamic php pages. The visual output of both is simular, but the database driven system allows for searching, filtering, multiple sensors and custom reports.
The second mode (running as a sensor that transmits it's data to a backend db) is most interesting, and I think a lot of people can find this VERY useful. Not only is this solution much more comprehensive than a ipt_account / darkstat with storage/backup-via-cifs solution, it is also much more reliable, efficient, faster, and much safer because we would not be vulnerable to log-data loss, or worse; data corruption, at power outages, intermittent reboots/lockups as is the case when logging to CIFS shares.
For more info & screenshots, see: http://bandwidthd.sourceforge.net/

The only additional cost for bandwidthd are two dependancies, libpng + libgd for the standard mode, which look like they need under 500kb of space - installed (from looking at openwrt prebuilt package list info), which I think we can afford, given a 4mb flash :)

I think this would give routertech a whole lot more advantages :)
User avatar
thechief
RouterTech Team
RouterTech Team
Posts: 12067
Joined: Wed Feb 01, 2006 10:22 pm
Location: England, the Centre of Africa
Contact:

Re: OpenWRT AR7 platform

Post by thechief » Mon Mar 15, 2010 8:53 am

geekgirl wrote:I think this would give routertech a whole lot more advantages :)
Looking forward to your contributions for porting that to RT. ;)
The Chief: :afro: Be sure to read the Firmware FAQ and do a Forum Search before posting!
No support via PM. Ask all questions on the open forum.
geekgirl
Regular
Regular
Posts: 72
Joined: Sat Feb 27, 2010 3:23 pm
Location: Egypt
Contact:

Re: OpenWRT AR7 platform

Post by geekgirl » Thu Mar 18, 2010 1:13 pm

mstombs,

just wondering, have you seen this (tiap source)?
http://groups.google.com/group/neptune3 ... e374038287

I know it's a bit old - based on APDK 5.7, and I know the 1350A's typically used APDK 6.3 (in the firmwares I've seen) and have seen a mention of 7.2, but.. the WAG354v2 has a 1350A, and neptune354 firmware is supposedly for both v1/v2. So it makes me wonder. I looked in the sources, and of course, no mention of 1350. I wonder how he even got the APDK 5.7 source.. What do you think?
mstombs
RouterTech Team
RouterTech Team
Posts: 3753
Joined: Wed Jan 10, 2007 11:54 pm

Re: OpenWRT AR7 platform

Post by mstombs » Thu Mar 18, 2010 10:22 pm

Yes I've seen those Tiap sources before, probably in a Linksys or Netgear GPL release, and are too different in detail to the Ti nsp reference design as used by Acorp/RouterTech to be much use to us. I don't know how Linksys get away from the need to store the wireless EEPROM values in env vars in the WAG200G - their drivers must be quite different.

I still haven't got a recent OpenWRT svn compile to run usefully on router, with no switch or wireless it should be fully supported - but the openWRT pppoa.sh script doesn't support a lot of features that pppd provides and are optionally used by RouterTech firmware!
geekgirl
Regular
Regular
Posts: 72
Joined: Sat Feb 27, 2010 3:23 pm
Location: Egypt
Contact:

Re: OpenWRT AR7 platform

Post by geekgirl » Fri Mar 19, 2010 7:15 am

mstombs wrote:I don't know how Linksys get away from the need to store the wireless EEPROM values in env vars in the WAG200G - their drivers must be quite different.
hmmm?

in cfg/wcfg_storage.h:

Code: Select all

#if defined(CONFIG_MIPS_AR7WI) || defined(CONFIG_MIPS_AR7VWI) || defined(CONFIG_MIPS_AR7WRD)
#define WCFG_BOOTLOADER "/proc/ticfg/env"
#elif CONFIG_MIPS_PUMAS
#define WCFG_BOOTLOADER "/proc/avalanche/env"
#else
#error Unknown board type.
#endif
The device appears to be booted via Serial EEPROM, see:
src/ddc/csl/board/acx_hw.c

And the API for it:
src/ddc/hal/AcxControl/whalAcxEeprom.h

But then, insmod'ing that driver is not enough to work it, that's why you get a "cli" and "init" binary from compiling the "cfg" directory, the "init" binary initializes the device, and cli configures it

example:

Code: Select all

insmod tiap.o
./init /usr/sbin/wpa_authenticator /lib/modules/2.4.17_mvl21-malta-mips_fp_le/kernel/drivers/net/tiap.o wlan0 br0

Though, the driver is obviously only for 1100/1130 chips, from looking at source file:
src/ddc/csl/board/acx_hw.h

So I doubt this was intended to work the 1350A in the WAG354G v2. bleh..
geekgirl
Regular
Regular
Posts: 72
Joined: Sat Feb 27, 2010 3:23 pm
Location: Egypt
Contact:

Re: OpenWRT AR7 platform

Post by geekgirl » Fri Apr 01, 2011 12:14 am

thechief wrote:
geekgirl wrote:A lot of what I mentioned is already implemented in Gargoyle. I actually gave it a dry-run from memdisk just to see how it looks live (though haven't yet actually tried building it for AR7 / testing its actual functionalities). Would love to see this (or similar) in Routertech. This could easily turn into a summer project, but I'm not really interested to invest so much time in this. Perhaps I may just attempt to add basic functionalities (via command line only), and report back with PoC patches/sources/binaries if I do succeed in getting any of this done.
As always, all useful patches will be gratefully accepted ;)
Sorry about the undelivered promise. I swear I spent so much time and effort working on it back then, and had made extensive changes to the code to add support to ADM6996, by adapting from the original D-Link GPL source to RT (I think was 2.92 at the time?), but reached a point where some of the changes (which I thought were possibly needed) weren't well documented nor clear, and I got stuck at that and somehow lost interest to continue further. So never really attempted to wrap it all up, cook, and flash to test and see if it worked at all. :(

Having said that, one recent development since I've last written on the topic, which I just now realized:
geekgirl wrote:Though someone (buytenh) in openwrt forum mentioned, around end of 2008, that he submitted 88E6060 (and other model) drivers to the linux netdev mailing list.
Getting ANY switch drivers working for AR7 has been one of the longest standing issues in OpenWRT, lol..
https://dev.openwrt.org/ticket/99
Royally sux :P
is that #99 has been closed and marked as fixed by florian 7 months ago, per the changeset r22727, which added 970-remove_fixed_phy.patch (though later reopened, for reasons outlined below)
Timestamp: 08/19/10 16:56:16 (7 months ago)
Author: florian
Message: [ar7] remove fixed phy support, enable most ar7 switch drivers.
that includes:
CONFIG_ADM6996_PHY=y
CONFIG_IP17XX_PHY=y
CONFIG_MVSWITCH_PHY=y

Then, changeset r22770 which added 971-cpmac_cleanup.patch (cleanup the cpmac phy mask)

and, changeset r22771 which added 972-cpmac_multi_probe.patch for adm6996 switches to work on tnetd7200 and tnetd7300

Some people mentioned it introduced compatibility issues with the mv88e6060 switch, particularly cpmac patches 970 to 972
then vbelo ported to 2.6.36 (without 970-972), see #8524
and florian said that he had since reworked the titan patch and so integrated his patches, and ported to 2.6.37, see r25569
I see he also added 972-cpmac_fixup.patch & 973-cpmac_handle_mvswitch.patch , and more importantly, ADM6996 and IP17XX are still enabled in config :)

in #8525, florian says that this (problems with 88e6060) should be now be fixed with r25675 [ar7] switch to 2.6.37.1 (5 weeks ago), which Simon Iremonger reported (12 hours ago) that he built and is going to test soon, and kindly provided a link for anyone who wants to help test:
http://hermes.enyc.org.uk/openwrt-2011-02-23-r25675/

There have been a few changesets which affect AR7 since, namely:
r25730 fix MII register ioremap on when high cpmac is available
r25755 use kmod-acx-mac80211 by default
r26226 update to 2.6.37.4

Moreover, of particular interest is what vbelo additionally mentioned in #99 (3 months ago, on a 2.6.36.2 kernel based build on his device):
Another thing : WPA2 in Access Point / Client mode is working for ACX111 when you compile it from git. It's now enough stable. My router's wireless is up for a week without failure.
I think this is quite REMARKABLE progress, and very promising :)
mstombs
RouterTech Team
RouterTech Team
Posts: 3753
Joined: Wed Jan 10, 2007 11:54 pm

Re: OpenWRT AR7 platform

Post by mstombs » Fri Apr 01, 2011 12:47 am

Thanks for the reminder, I also mean to look occasionally. Unfortunately I suspect that with most current devices with 4MB flash, and no USB hard disk a custom build is almost always going to be essential, but just removing wireless for a non-wireless device proved difficult for me, despite the great build system that downloads half the internet to get original sources for everything! The standard generic builds needed an internet connection via the lan port to install a number of packages before the ADSL was usable, for example. It is cool to see your old router boot with a up-todate kernel though!
geekgirl
Regular
Regular
Posts: 72
Joined: Sat Feb 27, 2010 3:23 pm
Location: Egypt
Contact:

Re: OpenWRT AR7 platform

Post by geekgirl » Fri Apr 01, 2011 3:51 am

lol @ "downloads half the internet"

btw, i did include a URL of AR7 builds which Simon kindly made for others wanting to test. It's not the most bleeding edge, but it's quite recent:
geekgirl wrote:in #8525, florian says that this (problems with 88e6060) should be now be fixed with r25675 [ar7] switch to 2.6.37.1 (5 weeks ago), which Simon Iremonger reported (12 hours ago) that he built and is going to test soon, and kindly provided a link for anyone who wants to help test:
http://hermes.enyc.org.uk/openwrt-2011-02-23-r25675/
look in the ar7 directory:
http://hermes.enyc.org.uk/openwrt-2011- ... 25675/ar7/
the generics:
openwrt-ar7-jffs2-128k.bin 31Mar2011 01:49 3670020
openwrt-ar7-jffs2-64k.bin 31Mar2011 01:49 3670020
openwrt-ar7-squashfs.bin 31Mar2011 01:49 2818052

And all packages prebuilt:
http://hermes.enyc.org.uk/openwrt-2011- ... /packages/

afair, I never needed to download anything to get ADSL working on the DSL-2640T.. maybe I got lucky?
but totally agreed: customizing + building from scratch is a pain.

For me, it's not just about an up-to-date kernel. A more standardish (hardware-independent) QoS support and L7-filter capability alone is a steal! (It's what made gargoyle stand out more, along with its user-friendly interface.) Add to that the ability to install any package you want - though limited on space availability of jffs2, and dependency on an external storage that is always available. And now the promising progress of support for all/most AR7 switches (including ADM6996), and better/more-stable ACX111 driver w/ WPA2 support, and all that is open-source :)
SimonIremonger
Newbie
Newbie
Posts: 8
Joined: Tue Apr 19, 2011 4:39 pm

Re: OpenWRT AR7 platform

Post by SimonIremonger » Tue Apr 19, 2011 4:50 pm

geekgirl wrote: There have been a few changesets which affect AR7 since,
How do you find that out? I'd like to know how you tell which changesets affect which architecture?
vbelo wrote:WPA2 in Access Point / Client mode is working for ACX111 when you compile it from git.
I tried to ask on the relevant bug but didn't get an answer from vbelo.

Do you know what he means by compiling ACX111 from git? What git repository where? Does this mean getting from git and then replacing in the kernel source before building openwrt? Does this mean rebuilding the module on a completed build-environment? Is this necessary with the new 2.6.37 kernel and acx???-mac80211 drivers?

I haven't quite figured out the relationship between the various driver development sites yet...
Puzzling!
mstombs
RouterTech Team
RouterTech Team
Posts: 3753
Joined: Wed Jan 10, 2007 11:54 pm

Re: OpenWRT AR7 platform

Post by mstombs » Tue Apr 19, 2011 7:25 pm

Welcome Simon,

I guess they mean the sf acx100 project - http://sourceforge.net/projects/acx100/develop the git looks to be active, whereas the bz2 download hasn't been updated since 2008.

I've seen reference here as to how you can sometimes take mini-pci wireless cards from a router to use as wireless nic in Linux PC, which must be client mode, though wireless security was an issue.

As to OpenWrt, they have pretty good svn with webview - but the head AR7 branch wouldn't compile for me when I last tried - same error already reported by others.
geekgirl
Regular
Regular
Posts: 72
Joined: Sat Feb 27, 2010 3:23 pm
Location: Egypt
Contact:

Re: OpenWRT AR7 platform

Post by geekgirl » Tue Apr 19, 2011 7:56 pm

SimonIremonger wrote:How do you find that out? I'd like to know how you tell which changesets affect which architecture?
Just go to:
https://dev.openwrt.org/browser/trunk/target/linux/ar7
Then click on the 'view changes' button at the bottom of the page, decrement/increment the from/to revision to widen/narrow your search results
SimonIremonger wrote:Do you know what he means by compiling ACX111 from git? What git repository where?
http://sourceforge.net/projects/acx100/develop

acx-mac80211 git tree
http://acx100.git.sourceforge.net/git/g ... x-mac80211

firmwares here:
http://acx100.erley.org/acx/fw
SimonIremonger wrote:Does this mean getting from git and then replacing in the kernel source before building openwrt? Does this mean rebuilding the module on a completed build-environment? Is this necessary with the new 2.6.37 kernel and acx???-mac80211 drivers?
I haven't quite figured out the relationship between the various driver development sites yet...
Puzzling!
I believe it involves injecting the driver in the wireless-testing tree of the kernel, as described here http://acx100.erley.org/acx/nl80211_master_mode.html
Unfortunately, that page is outdated, and the official acx100 wiki (on sf.net) is blank at the moment, and google cache of the said wiki caches a page linking to a .cc domain which has been suspended. The only google cached page is the Firmware page.
User avatar
thechief
RouterTech Team
RouterTech Team
Posts: 12067
Joined: Wed Feb 01, 2006 10:22 pm
Location: England, the Centre of Africa
Contact:

Re: OpenWRT AR7 platform

Post by thechief » Tue Apr 19, 2011 10:01 pm

Shouldn't this discussion be taking place in an Openwrt forum?
The Chief: :afro: Be sure to read the Firmware FAQ and do a Forum Search before posting!
No support via PM. Ask all questions on the open forum.
Post Reply