OpenWrt Forum Archive

Topic: Atheros AR7100

The content of this topic has been archived between 30 Mar 2018 and 1 May 2018. Unfortunately there are posts – most likely complete pages – missing.

yes, but you will notice bad performance in this way. a additional workaround is required

acoul wrote:
BrainSlayer wrote:

just my five cents. yes the rx dma bug in the ar7100 chipset is a well known bug, but i wrote a workaround for it. so i can get full performance out of it even if the cpu load is now higher. i'm running it on a ubiquiti litestation x prototype (ar7100) and got full possible speed out of it. but the 300 mhz minimum clock is really required todo this. this bug does not affect 802.11n (ar5416,ar9060,ar9280) atheros chipsets. just ar5006 and older.
the bug is that the rx dma size must be used with 4 bytes length instead of 128. otherwise the bus will hang and crash the system. this increases cpu load for sure. atheros tried to cover this bug in the hal sourcecode, but the solution covered just 2 chipsets, but much more are affected.

Hello BrainSlayer, do you have any further pointers with discussions about this bug?

BrainSlayer wrote:

the new hal release i'm preparing together with nbd does cover this issue. there will be a separate ar7100 hal in it

I thought that the hal part is a closed binary code from Atheros who releases it every now and then and that madwifi.org along with the linux kernel developers are switching to the ath5k development which is the open source reverse engineer of the closed hal binary code.

you can write me a email to s.gottschall@newmedia-net.de if you want to discuss it. and yes the hal is closed. but i have access to the hal sources directly from atheros and also good personal contacts to this company and i'm working together with nbd since a long time (almost 2 years now), to make it better. we contribute also patches back to sam leffler. but we are close now for a own hal release (madwifi trunk compatible)
even if ath5k is a good solution for the madwifi developers or you, its not ready yet for me. alot of important features are missing and for my system i'm happy that all is working now with great performance and extended featureset. i dont want to destroy this, by playing with new code. and in this way i also get the chance to implement always the latest chipset support, since atheros is only maintaining the hal officially (but they are working also on ath5k, but dont expect too much from it)

so in fact, everyone can get the hal sourcecode. you just need to get a source license under nda for it. its not that easy, but possible.

jal2 wrote:
BrainSlayer wrote:

the bug is that the rx dma size must be used with 4 bytes length instead of 128. otherwise the bus will hang and crash the system. this increases cpu load for sure.

Thanks for giving more information on this issue.

Is this a bug in the PCI controller of the AR71xx? Does it affect DMA in both directions (CPU->PCI and PCI->CPU)?

Are there any implications for running other, non-Atheros, cards (RaLink, Prism54)?

@oceanyounger: Any plans on Atheros' side for fixing it?

it just affects RX and only ar5006 and older chipsets. i have not played with other cards right now. maybe i will run into the same problem. i dont know right now. maybe i play with it later. i'm focused on atheros solutions

atheros told me that there are no plans for fixing it, since atheros designed it only for 802.11n cards originally and want to focus on these chipsets in future too. so as stupid it sounds, it seems like that atheros has no real reason for fixing it.
all 802.11n chipsets (ar5416,ar9001,ar9280) are not affected by this bug
but maybe i'm wrong and atheros turns his mind and will release a third revision of the ar7100 (there are already 2) for older chipset support.

BrainSlayer wrote:

yes, but you will notice bad performance in this way. a additional workaround is required

You mean, that setting pci rx buf to 4B will not solve the problem ? Or there is another different workaround ?

Brainslayer wrote:

atheros told me that there are no plans for fixing it, since atheros designed it only for 802.11n cards originally and want to focus on these chipsets in future too. so as stupid it sounds, it seems like that atheros has no real reason for fixing it.
all 802.11n chipsets (ar5416,ar9001,ar9280) are not affected by this bug

Is this really a bug in the AR71xx or in the older Atheros chipsets? While AR9280 is PCIe (difficult to connect to an AR71xx) and AR9001 has the WLAN baseband integrated into the SoC, the AR5416 still has a PCI interface.

BrainSlayer wrote:

so in fact, everyone can get the hal sourcecode. you just need to get a source license under nda for it. its not that easy, but possible.

I would guess that signing this NDA will prevent you from ever being able to contribute to ath5k.

I wonder which madwifi HAL Mikrotik is using in their RouterOS? AFAIK they currently support older Atheros chipset.

If Atheros is targeting the 802.11n router market only with the AR71xx, I'd guess that it will disappear soon from their product list replaced by a two-chip solution (radio+bb/mac/cpu) based on the AR9132.

Maybe we should ask Mikrotik about guaranteed availability of the RB4xx and support for non-Atheros miniPCI cards?

jal2 wrote:

I wonder which madwifi HAL Mikrotik is using in their RouterOS? AFAIK they currently support older Atheros chipset.

Mikrotik use their own driver, AFAIK, based on some old (end of 2003 year) sources of HAL. Or may be now they have signed NDA and get HAL sources.

Does the bug affect only wireless operation?
Is the RB411, without pci board installed, working normally (serial, ethernet, core system)?

(Last edited by Slammer on 25 Jun 2008, 11:58)

Slammer wrote:

Does the bug affect only wireless operation?

All bugs in ath5k affect wireless operation. Bug with pci rx buffer size hangs system, bug in rx tasklet (crc32 at the tail of frame not stripped out) affect only some special ethernet protocols (not ip)

bitbucket wrote:
Slammer wrote:

Does the bug affect only wireless operation?

All bugs in ath5k affect wireless operation. Bug with pci rx buffer size hangs system, bug in rx tasklet (crc32 at the tail of frame not stripped out) affect only some special ethernet protocols (not ip)

So, is the source ready to support RB450 without problems? Maybe is time to include the sources, at least for RB450, in the SVN.

Slammer wrote:

So, is the source ready to support RB450 without problems? Maybe is time to include the sources, at least for RB450, in the SVN.

I have only rb411.

bitbucket wrote:
BrainSlayer wrote:

yes, but you will notice bad performance in this way. a additional workaround is required

You mean, that setting pci rx buf to 4B will not solve the problem ? Or there is another different workaround ?

its the initial workaround to get it to work. but another workaround is required to get performance. i cannot give you too much details without breaking the NDA i signed, but its a pretty simple workaround. just one line

jal2 wrote:
Brainslayer wrote:

atheros told me that there are no plans for fixing it, since atheros designed it only for 802.11n cards originally and want to focus on these chipsets in future too. so as stupid it sounds, it seems like that atheros has no real reason for fixing it.
all 802.11n chipsets (ar5416,ar9001,ar9280) are not affected by this bug

Is this really a bug in the AR71xx or in the older Atheros chipsets? While AR9280 is PCIe (difficult to connect to an AR71xx) and AR9001 has the WLAN baseband integrated into the SoC, the AR5416 still has a PCI interface.

? AR9001 (AR9160 chipset)
is standard mac + rf combination. no soc
you can buy a very bad minipci from sparklan and the ubiquiti SR71A is based on it as well. but without saying too much, the mac has a bug too. we are currently trying todo a workaround in our hal
the follow up chipset ar9280 is a single chip (mac/rf) solution. nothing special. almost made for 2x2 and 1x1 mimo

you mean the ub91 usb variant which is soc, but this is completelly different

BrainSlayer wrote:

so in fact, everyone can get the hal sourcecode. you just need to get a source license under nda for it. its not that easy, but possible.

I would guess that signing this NDA will prevent you from ever being able to contribute to ath5k.
not at all. there are still undocumented things in the atheros hal. if i find out such things without any document base, i can contribute it.

I wonder which madwifi HAL Mikrotik is using in their RouterOS? AFAIK they currently support older Atheros chipset.

mikrotik doesnt use the hal or ar5k. as far as i know the driver is based on the atheros calibration tool sources. (nbd found this out)


If Atheros is targeting the 802.11n router market only with the AR71xx, I'd guess that it will disappear soon from their product list replaced by a two-chip solution (radio+bb/mac/cpu) based on the AR9132.
the radio+bb/mac/cpu (ap81/ap82) is designed as low cost solution. the pb42/ar71xx has also audio interface, usb etc.
originally it was not designed as single minipci solution. the reference design has 2 minipci slots, usb, audio in and outputs and various other stuff and the ar71xx is faster. it can run up to 600 mhz

Maybe we should ask Mikrotik about guaranteed availability of the RB4xx and support for non-Atheros miniPCI cards?

maybe we should ask mikrotik about the gpl sources first
i will try to add support for wavesat wimax next time into the ar71xx. i hope it works. if not, i will find out how to get it to work

BrainSlayer wrote:

its the initial workaround to get it to work. but another workaround is required to get performance. i cannot give you too much details without breaking the NDA i signed, but its a pretty simple workaround. just one line

Just one line in hal or kernel ? Because both cpu and wireless nic are made by atheros. If it is closed by nda, don't tell. Somebody sooner or later will found it.

I know one workaround to get performance: it is disabling the TXDONE interrupt. It helps on x86 hardware, but it needs to check how it will works on ar7130. Also, mikrotik's driver (and routeros) for atheros chipset consume all ar7130 CPU on high load.

BrainSlayer wrote:

? AR9001 (AR9160 chipset)
is standard mac + rf combination. no soc

True. I referred to the  AR9001AP-2/3NX only, which contains an AR9132. Missed the AR9001AP-2/3NX2 with AR9160 on the Atheros page.

If the bug doesn't affect 802.11n chipsets, it can't be a simple bug in the PCI controller like "no read burst triggered by a  PCI card can have a length > 4 byte" unless these chipsets don't issue read bursts.

jal2 wrote:
BrainSlayer wrote:

? AR9001 (AR9160 chipset)
is standard mac + rf combination. no soc

True. I referred to the  AR9001AP-2/3NX only, which contains an AR9132. Missed the AR9001AP-2/3NX2 with AR9160 on the Atheros page.

If the bug doesn't affect 802.11n chipsets, it can't be a simple bug in the PCI controller like "no read burst triggered by a  PCI card can have a length > 4 byte" unless these chipsets don't issue read bursts.

the strange thing is that the 802.11n chipsets are using the same rxburst mechanism. i really dont know the reason. i just know the result and how to get around

bitbucket wrote:
BrainSlayer wrote:

its the initial workaround to get it to work. but another workaround is required to get performance. i cannot give you too much details without breaking the NDA i signed, but its a pretty simple workaround. just one line

Just one line in hal or kernel ? Because both cpu and wireless nic are made by atheros. If it is closed by nda, don't tell. Somebody sooner or later will found it.

I know one workaround to get performance: it is disabling the TXDONE interrupt. It helps on x86 hardware, but it needs to check how it will works on ar7130. Also, mikrotik's driver (and routeros) for atheros chipset consume all ar7130 CPU on high load.

its a hal one liner. the kernel is not affected in any way

i compared routeros speed with my solution and mine was faster. about 60 mbit TCP in 802.11a turbo mode was possible without any issues. (usually some more with some tricks)

BrainSlayer wrote:

its a hal one liner. the kernel is not affected in any way

As always, atheros hide some special 'killer feature' from us. smile We'll keep searching.

I think, that card can't transmit faster than it does when sending self looped TX descriptor with TXDONE IRQ event off. Also, adjusting some interframe timings (sifs, aifs, postbackoff) may boost performance, but not such much.

BrainSlayer wrote:

i compared routeros speed with my solution and mine was faster. about 60 mbit TCP in 802.11a turbo mode was possible without any issues. (usually some more with some tricks)

At which platform ? ag7130 @ 300MHz with build in CPU ethernet IC ?
Because it is possible get 60Mbit in one way at 36Mbit trubo rate without compression. But I used faster cpu (x86).

bitbucket wrote:
qyx wrote:

after loading to rb411 there is only mess on serial terminal...

may be serial console rate wrong ?
Check kernel's .config for right cmdline:
CONFIG_CMDLINE="board=411 HZ=300 console=ttyS0,115200"

I have successfully compiled a load for the RB450 but am also seeing only invalid data on the console port.  My kernel command line is:

console=ttyS0,115200n81 board=450 HZ=300 rootfstype=squashfs,jffs2 init=/etc/preinit

The bootloader on the RB450 spits out the following so I'm relatively confident that I have the HZ parameter right.

RouterBOOT booter 2.14                           
                                                 
RouterBoard 450                                 
                                                 
CPU frequency: 300 MHz
  Memory size:  32 MB

Any ideas on where to look next?

update.  I get the following error on the ethernet driver directory:

  CC      drivers/net/ag7100/ipPhy.o
drivers/net/ag7100/ipPhy.c:15:26: error: linux/config.h: No such file or directory
In file included from drivers/net/ag7100/ipPhy.c:21:
drivers/net/ag7100/ag7100_phy.h: In function 'ag7100_get_link_status':
drivers/net/ag7100/ag7100_phy.h:151: error: implicit declaration of function 'ip_phyIsUp'
drivers/net/ag7100/ag7100_phy.h:152: error: implicit declaration of function 'ip_phyIsFullDuplex'
drivers/net/ag7100/ag7100_phy.h:153: error: implicit declaration of function 'ip_phySpeed'
drivers/net/ag7100/ipPhy.c:183:5: warning: "DEBUG" is not defined
drivers/net/ag7100/ipPhy.c: At top level:
drivers/net/ag7100/ipPhy.c:524: error: conflicting types for 'ip_phySpeed'
drivers/net/ag7100/ag7100_phy.h:153: error: previous implicit declaration of 'ip_phySpeed' was here
drivers/net/ag7100/ipPhy.c:565: warning: conflicting types for 'ip_phyIsUp'
drivers/net/ag7100/ag7100_phy.h:151: warning: previous implicit declaration of 'ip_phyIsUp' was here
drivers/net/ag7100/ipPhy.c: In function 'ip_phyIsUp':
drivers/net/ag7100/ipPhy.c:612: warning: 'return' with a value, in function returning void
drivers/net/ag7100/ipPhy.c:629:5: warning: "DEBUG" is not defined
make[8]: *** [drivers/net/ag7100/ipPhy.o] Error 1

(Last edited by acoul on 27 Jun 2008, 20:04)

acoul wrote:

update.  I get the following error on the ethernet driver directory:

  CC      drivers/net/ag7100/ipPhy.o
drivers/net/ag7100/ipPhy.c:15:26: error: linux/config.h: No such file or directory
In file included from drivers/net/ag7100/ipPhy.c:21:
drivers/net/ag7100/ag7100_phy.h: In function 'ag7100_get_link_status':
drivers/net/ag7100/ag7100_phy.h:151: error: implicit declaration of function 'ip_phyIsUp'
drivers/net/ag7100/ag7100_phy.h:152: error: implicit declaration of function 'ip_phyIsFullDuplex'
drivers/net/ag7100/ag7100_phy.h:153: error: implicit declaration of function 'ip_phySpeed'
drivers/net/ag7100/ipPhy.c:183:5: warning: "DEBUG" is not defined
drivers/net/ag7100/ipPhy.c: At top level:
drivers/net/ag7100/ipPhy.c:524: error: conflicting types for 'ip_phySpeed'
drivers/net/ag7100/ag7100_phy.h:153: error: previous implicit declaration of 'ip_phySpeed' was here
drivers/net/ag7100/ipPhy.c:565: warning: conflicting types for 'ip_phyIsUp'
drivers/net/ag7100/ag7100_phy.h:151: warning: previous implicit declaration of 'ip_phyIsUp' was here
drivers/net/ag7100/ipPhy.c: In function 'ip_phyIsUp':
drivers/net/ag7100/ipPhy.c:612: warning: 'return' with a value, in function returning void
drivers/net/ag7100/ipPhy.c:629:5: warning: "DEBUG" is not defined
make[8]: *** [drivers/net/ag7100/ipPhy.o] Error 1

I've gotten past this point.  PM me with your e-mail address and I'll send you my ar7100 tarball.  Mine compiles fine but has the console port problem I mentioned above.

number6 wrote:

console=ttyS0,115200n81 board=450 HZ=300 rootfstype=squashfs,jffs2 init=/etc/preinit

May be something wrong witch serial port clock settings. Which patch you used to make kernel for rb450 ?

acoul wrote:

update.  I get the following error on the ethernet driver directory:

http://narod.ru/disk/1160646000/ag7100.tgz.html - working driver. Put it to ag7100 to drivers/net and *.h files to include/asm/mach-rb
(to download file enter digits on image and press green button)

bitbucket wrote:
number6 wrote:

console=ttyS0,115200n81 board=450 HZ=300 rootfstype=squashfs,jffs2 init=/etc/preinit

May be something wrong witch serial port clock settings. Which patch you used to make kernel for rb450 ?

I used acoul's 3rd tarball plus my own modifications to make it compile.

bitbucket wrote:
number6 wrote:

console=ttyS0,115200n81 board=450 HZ=300 rootfstype=squashfs,jffs2 init=/etc/preinit

May be something wrong witch serial port clock settings. Which patch you used to make kernel for rb450 ?

i used the same sources as number6 (including modifications posted above), i tried all possible standard baudrates

update.

Good news:
* everything compiles fine
* successful login through telnet @ 192.168.1.1
* openwrt netboot image available

Bad news:
* no serial console (yet)
* network dies on ping with large packet size

ping -s 65507 192.168.1.1

here is the dmesg:

Linux version 2.6.23.17 (alex@extreme) (gcc version 4.2.4) #1 Sat Jun 28 10:27:09 EEST 2008
CPU revision is: 00019374
Determined physical RAM map:
User-defined physical RAM map:
 memory: 02000000 @ 00000000 (usable)
Initrd not found or empty - disabling initrd
On node 0 totalpages: 8192
  Normal zone: 64 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 8128 pages, LIFO batch:0
  Movable zone: 0 pages used for memmap
Built 1 zonelists in Zone order.  Total pages: 8128
Kernel command line: console=ttyS0,115200 gpio=4031 mem=32M kmac=00:0C:42:19:CE:F9 board=411 boot=1
Primary instruction cache 64kB, physically tagged, 4-way, linesize 32 bytes.
Primary data cache 32kB, 4-way, linesize 32 bytes.
Synthesized TLB refill handler (20 instructions).
Synthesized TLB load handler fastpath (32 instructions).
Synthesized TLB store handler fastpath (32 instructions).
Synthesized TLB modify handler fastpath (31 instructions).
Cache parity protection disabled
PID hash table entries: 128 (order: 7, 512 bytes)
Using 150.000 MHz high precision timer.
console [ttyS0] enabled
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 28360k/32768k available (1902k kernel code, 4408k reserved, 281k data, 804k init, 0k highmem)
Calibrating delay loop... 199.47 BogoMIPS (lpj=997376)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
registering PCI controller with io_map_base unset
Generic PHY: Registered new driver
NET: Registered protocol family 2
Time: MIPS clocksource has been installed.
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP reno registered
squashfs: version 3.0 (2006/03/15) Phillip Lougher
Registering mini_fo version $Id$
JFFS2 version 2.2. (NAND) (SUMMARY)  Β© 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler deadline registered (default)
Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing disabled
ICPlus IP175C: Registered new driver
Infineon ADM6996: Registered new driver
Marvell 88E6060: Registered new driver
AG7100: Length per segment 1536
AG7100: Max segments per packet 2
AG7100: Max tx descriptor count    256
AG7100: Max rx descriptor count    128
AG7100: fifo cfg 3 008001ff
AG7100CHH: Mac address for unit 0 '00:0c:42:19:ce:f9'
TCP vegas registered
NET: Registered protocol family 1
NET: Registered protocol family 17
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
Freeing unused kernel memory: 804k freed
Algorithmics/MIPS FPU Emulator v1.5
ag7100_ring_alloc Allocated 3072 at 0x8106b000
ag7100_ring_alloc Allocated 1536 at 0x805dd000
AG7100: cfg1 0xf cfg2 0x7014
ksz_phy: autonegotiation does not completed
AG7100: unit 0 phy is up...GMii 100Mbps full duplex
AG7100: pll reg 0x18050010: 0x1099  AG7100: cfg_1: 0x1ff0000
AG7100: cfg_2: 0x3ff
AG7100: cfg_3: 0x8001ff
AG7100: cfg_4: 0xffff
AG7100: cfg_5: 0x7ffef
AG7100: done cfg2 0x7115 ifctl 0x10000 miictrl 0x10
Writing 4
ag7100_ring_free Freeing at 0x8106b000
ag7100_ring_free Freeing at 0x805dd000
ag7100_ring_alloc Allocated 3072 at 0x8106b000
ag7100_ring_alloc Allocated 1536 at 0x805dd000
AG7100: cfg1 0xf cfg2 0x7115
ksz_phy: autonegotiation is not supported
Writing 4
ag7100_ring_free Freeing at 0x8106b000
ag7100_ring_free Freeing at 0x805dd000
ag7100_ring_alloc Allocated 3072 at 0x8106b000
ag7100_ring_alloc Allocated 1536 at 0x805dd000
AG7100: cfg1 0xf cfg2 0x7115
ksz_phy: autonegotiation is not supported
Writing 4
AG7100: unit 0 phy is up...GMii 100Mbps full duplex
AG7100: pll reg 0x18050010: 0x1099  AG7100: cfg_1: 0x1ff0000
AG7100: cfg_2: 0x3ff
AG7100: cfg_3: 0x8001ff
AG7100: cfg_4: 0xffff
AG7100: cfg_5: 0x7ffef
AG7100: done cfg2 0x7115 ifctl 0x10000 miictrl 0x10

(Last edited by acoul on 28 Jun 2008, 08:43)