OpenWRT AR7 platform
Re: OpenWRT AR7 platform
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 ?
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 ?
Re: OpenWRT AR7 platform
yepmstombs 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.
This is exactly where the problem lies...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)
Could this be related? https://dev.openwrt.org/ticket/3124
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: 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!
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.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.
Re: OpenWRT AR7 platform
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.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
You can see the supported chipsets here:
https://dev.openwrt.org/wiki/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.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 ?
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
Re: OpenWRT AR7 platform
Cool Can't promise anything yet, really. Still in R&D phase, major learning curvethechief wrote:As always, all useful patches will be gratefully accepted
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.
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.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.
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
- thechief
- RouterTech Team
- Posts: 12067
- Joined: Wed Feb 01, 2006 10:22 pm
- Location: England, the Centre of Africa
- Contact:
Re: OpenWRT AR7 platform
Looking forward to your contributions for porting that to RT.geekgirl wrote:I think this would give routertech a whole lot more advantages
The Chief: 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.
No support via PM. Ask all questions on the open forum.
Re: OpenWRT AR7 platform
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?
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?
Re: OpenWRT AR7 platform
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!
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!
Re: OpenWRT AR7 platform
hmmm?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.
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
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
src/ddc/csl/board/acx_hw.h
So I doubt this was intended to work the 1350A in the WAG354G v2. bleh..
Re: OpenWRT AR7 platform
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.thechief wrote:As always, all useful patches will be gratefully acceptedgeekgirl 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.
Having said that, one recent development since I've last written on the topic, which I just now realized:
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)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
that includes:Timestamp: 08/19/10 16:56:16 (7 months ago)
Author: florian
Message: [ar7] remove fixed phy support, enable most ar7 switch drivers.
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):
I think this is quite REMARKABLE progress, and very promisingAnother 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.
Re: OpenWRT AR7 platform
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!
Re: OpenWRT AR7 platform
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:
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
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:
look in the ar7 directory: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/
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
-
- Newbie
- Posts: 8
- Joined: Tue Apr 19, 2011 4:39 pm
Re: OpenWRT AR7 platform
How do you find that out? I'd like to know how you tell which changesets affect which architecture?geekgirl wrote: There have been a few changesets which affect AR7 since,
I tried to ask on the relevant bug but didn't get an answer from vbelo.vbelo wrote:WPA2 in Access Point / Client mode is working for ACX111 when you compile it from git.
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!
Re: OpenWRT AR7 platform
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.
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.
Re: OpenWRT AR7 platform
Just go to:SimonIremonger wrote:How do you find that out? I'd like to know how you tell which changesets affect which architecture?
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
http://sourceforge.net/projects/acx100/developSimonIremonger wrote:Do you know what he means by compiling ACX111 from git? What git repository where?
acx-mac80211 git tree
http://acx100.git.sourceforge.net/git/g ... x-mac80211
firmwares here:
http://acx100.erley.org/acx/fw
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.htmlSimonIremonger 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!
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.
- thechief
- RouterTech Team
- Posts: 12067
- Joined: Wed Feb 01, 2006 10:22 pm
- Location: England, the Centre of Africa
- Contact:
Re: OpenWRT AR7 platform
Shouldn't this discussion be taking place in an Openwrt forum?
The Chief: 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.
No support via PM. Ask all questions on the open forum.