Binary hal support fort the ar531x based SOCs using ath_ahb bus

forwarded to atheros

Also, I tried to use 0.9.15.1 HAL with AR2313A SOC(AR2112A ROC) and I am at the same situation, the Hal cannot be attached. There is a point that is not clear for me. Which hal file should I use for my embedded system? There are 3 different hal files for mips devices:mips,mips1 and mipsisa32. I know the one I use is MIPS3 type, so I try to use mipsisa32 but I get an error message "linking 32-bit code with 64-bit code-failed to merge target specific data of file hal.o". On the other hand, if I exchange the mipsisa32 with mips... I don't get any error at compilation, but I still cannot use driver.

I have the same problem as jirif...

More snip

Is curious ,when i run this code before ath_attach, it show the device name correctly:

athname = ath_hal_probe(ATHEROS_VENDOR_ID, devid);

printk(KERN_INFO "%s: %s: mem=0x%lx, irq=%d\n",

dev->name, athname ? athname : "Atheros ???", dev->mem_start, dev->irq);

So it mean the binary driver working, detecting devices but is not linked with the SOC support

Jiri

LOL sorry it was not show the code correctly, i forgot add the code block:

athname = ath_hal_probe(ATHEROS_VENDOR_ID, devid);
        printk(KERN_INFO "%s: %s: mem=0x%lx, irq=%d\n",
               dev->name, athname ? athname : "Atheros ???", dev->mem_start, dev->irq);

Jiri

I removed the assignment from br1, since Bruno won't be able to take care of this issue for some time. I'll try to renegotiate wit Atheros about this issue.

Any news about it?

Not yet. My queue is full, and the "contact Atheros to negotiate about open issues" is still in it. :(

Forwarded this issue to Atheros today.

Hi! Any news about it? Troubles found long time ago... :-(

Some news about 5311 SoC There: http://wiki.openwrt.org/AtherosPort?action=AttachFile&do=get&target=vmlinux I found work linux kernel 2.4.25 with embedded ramdisk in witch all if's of atheros work ok!

NetBSD changelog:

ath driver: Import HAL 0.9.17.2, which adds support for WiSoC platforms (AR531x devices), and 32-bit SPARC.

and madwifi?

MadWifi has imported HAL 0.9.17.2 in r1631.

AR531x (WiSoC) device does not work with this madwifi (r1631)

NetBSD changelog: This HAL is tested and known to work for ... and AR5312 WiSoC devices.

"Does not work" is no proper error report. However, this ticket is not the proper place to discuss that.

First, check the related tickets (most important: #501). If this matches your situation, please add missing details there. If your situation is mostly different from what is described in existing tickets, please open a new ticket. Provide us with a detailed description of your environment, of the steps you took trying to get the WiSoC stuff up and running, and of the error messages you see. Stuff like that.

I close this ticket, since the original request is basically fulfilled (WiSoC architectures are supported in HAL since 0.9.17.0 which has been imported in r1606). In case it's not working, please follow the instructions given in the previous paragraph.

I am another person waiting a new hal to solve this problem. Our old problem was getting "'No hardware present or device not yet supported' (HAL status 1)" error. Using WiSoC HALs, we get the error printed below:

<6>ath_hal: 0.9.17.2 (AR5212, AR5312, RF5111, RF5112)
<6>wlan: 0.8.4.2 (0.9.1)
<6>ath_rate_sample: 1.2 (0.9.1)
<6>ath_ahb: 0.9.4.5 (0.9.1)
<1>Unable to handle kernel paging request at virtual address 00000008, epc == c04a1e50, ra == c04a1df8
<4>Oops in fault.c::do_page_fault, line 206:
<4>$0 : 00000000 1000f100 00000000 00000003 80b18000 00000003 c04a00b0 c04a01f0
<4>$8 : 0000ffff 80b1a8d2 00000010 00000000 00000000 801639b4 00000003 00000000
<4>$16: 00000003 80b18000 80b18000 80b22000 80029870 80c63da8 80b23744 80b25000
<4>$24: 00000010 ba2e8ba3                   80c62000 80c63c50 100fb768 c04a1df8
<4>Hi : 00000000
<4>Lo : 00000000
<4>epc   : c04a1e50    Tainted: P
<4>Status: 1000f103
<4>Cause : 00800008
<4>PrId  : 0001800a
<4>Process insmod (pid: 118, stackpage=80c62000)
<4>Stack:    80c63c58 c00630c0 80043c3c 80c63d30 80163c60 00000000 00000000
<4> 000001f0 80b18000 800407b0 00000004 c006301c 00195603 80cc3320 801c3930
<4> 801c3938 000001f0 80b22160 00000000 80040b28 00000003 80b18000 80b18000
<4> c04a1df8 000052f0 80b22160 c048b2f0 c048b2d0 35f28b84 801750a0 00000001
<4> 8002e09c 00000000 80b18000 c04a1b84 c0491a30 35f28b84 80c63d90 8001a9b8
<4> 80064a6c ...
<4>Call Trace:   [<80043c3c>] [<800407b0>] [<80040b28>] [<c04a1df8>] [<c048b2f0>]
<4> [<c048b2d0>] [<8002e09c>] [<c04a1b84>] [<c0491a30>] [<8001a9b8>] [<80064a6c>]
<4> [<c049fa14>] [<800293b8>] [<80013344>] [<80029870>] [<c048b800>] [<8004365c>]
<4> [<c048b080>] [<8006f5b0>] [<80071da0>] [<800407b0>] [<c04e01b4>] [<80013bac>]
<4> [<80040b28>] [<c04e2508>] [<c04f5244>] [<c04f2474>] [<80024338>] [<c04f22f4>]
<4> [<c04f2684>] [<8002421c>] [<8002421c>] [<c04f2824>] [<c04f2814>] [<c04f4d5c>]
<4> [<c04f4d4c>] [<800258e0>] [<800297f0>] [<8004365c>] [<c04e0060>] ...
<4>
<4>Code: afb00050  00808825  8e220010 <8c430008> 10a00090  00001025  10600005  24020001  10620006
Segmentation fault

Linux Kernel: 2.4.25 Target Device: ap43 which is sold as "Dlink dwl2200"

@g_mutlu: Please test a recent snapshot with HAL v0.9.18.0. If the described issue still exists, check existing (open) bug reports for possible matches, and if you can not find a matching ticket, please open a new one.

The original subject of this ticket was general support for ar531x/ath_ahb, which is available now. If there are any issues with that support, it should be kept in an independant ticket. Which, by the way, was already detailed in a previous comment.

Bottom line: the original "issue" reported by this ticket has been fixed in v0.9.1.

This problem still existed in AP61 !!!

wlan: 0.8.4.2 (svn r1796) ath_hal: 0.9.18.0 (AR5212, AR5312, RF2317) ath_rate_sample: 1.2 (svn r1796) wlan: mac acl policy registered ath_ahb: 0.9.4.5 (svn r1796) Data bus error, epc == c0137338, ra == c013718c Oops in traps.c::do_be, line 385: $0 : 00000000 00000000 bc003090 ffffffff a87f00f8 a87fffff c0140000 8018c1a0 $8 : 00000000 00000e2d 00000e2d 00000e0d 801c0000 801c0000 801c0000 801c0000 $16: 00000001 c0126000 00592e10 ffffffea 00000060 803c4a60 80ca9000 0057f0a0 $24: 801be9e4 ba2e8ba3 80e1e000 80e1fe58 00000007 c013718c Hi : ffffd9ff Lo : 00000cab epc : c0137338 Tainted: P Status: 10009503 Cause : 1080041c PrId? : 00019064 Process insmod (pid: 137, stackpage=80e1e000) Stack: 00592e10 ffffffea 80053584 c0126000 00592e10 ffffffea 80053584

c0137554 00000007 c01399f8 c0139a00 801aac80 00000007 800549fc 80e1fe90 000001f2 000007df 801a0000 00000060 c0124000 c0126060 00013fcc 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ...

Call Trace: [<80053584>] [<80053584>] [<c0137554>] [<c01399f8>] [<c0139a00>]

[<800549fc>] [<c0126060>] [<80048a40>] [<8009bedc>]

Code: ac449f04 3c02bc00 34423090 <8c420000> 00021202 305000ff 24020057 1202000c 2a020058 AHB interrupt: PROCADDR=0x00000000 PROC1=0x80e1fc90 DMAADDR=0x00000440 DMA1=0x10009500

The "Oops" you get is caused by different kernel configuration parameters that is defined in your build environment and public madwifi source code. You can check them in /ath/if_ath_ahb.c file. For example you may be using COBRA definition instead of AR2315 in your build environment. On the other hand; althought, all modules are successfully loaded, ath_ahb module prints "'No hardware present or device not yet sup ported' (HAL status 1)" message. So, this bug is partly solved.

I already made changes for madwifi but still got Oops! Belows are my patchs: --- madwifi-ng-r1796-20061110.old/ath/if_ath_ahb.c Wed Sep 20 16:45:13 2006 +++ madwifi-ng-r1796-20061110.new/ath/if_ath_ahb.c Mon Nov 13 22:49:21 2006 @@ -283,7 +283,7 @@

if (dev->irq)

free_irq(dev->irq, dev);

sysType = get_system_type();

- if (!strcmp(sysType, "Atheros AR5315"))

+ if ((!strcmp(sysType, "Atheros AR5315")) (!strcmp(sysType, "Atheros AR531X_COBRA")))

devid = (u_int16_t) (sysRegRead(AR5315_SREV) &

(AR5315_REV_MAJ_M | AR5315_REV_MIN_M));

else

@@ -388,7 +388,7 @@

u_int16_t devid, radioMask; const char *sysType; sysType = get_system_type();

- if (!strcmp(sysType,"Atheros AR5315")) {

+ if ((!strcmp(sysType,"Atheros AR5315")) (!strcmp(sysType, "Atheros AR531X_COBRA"))) {

devid = (u_int16_t) (sysRegRead(AR5315_SREV) &

(AR5315_REV_MAJ_M | AR5315_REV_MIN_M));

if ((devid & AR5315_REV_MAJ_M) == AR5315_REV_MAJ)

diff -urN madwifi-0.9.2.old/ath/if_ath_ahb.c madwifi-0.9.2.new/ath/if_ath_ahb.c --- madwifi-0.9.2.old/ath/if_ath_ahb.c Mon May 22 12:39:55 2006 +++ madwifi-0.9.2.new/ath/if_ath_ahb.c Mon Nov 13 14:06:15 2006 @@ -55,8 +55,8 @@

• more than 500KB. */

dataFound = 0;

- for (bd_config = (char *)0xbffff000; - bd_config > (char *)0xbff80000; + for (bd_config = (char *)0xa87f0000; + bd_config > (char *)0xa8000000;

bd_config -= 0x1000) {

if ( *(int *)bd_config == AR531X_BD_MAGIC) {

dataFound = 1;

@@ -84,8 +84,8 @@

• at a time until we find non-0xffffffff. */

dataFound = 0;

- for (radio_config = ((char *) ar5312_boardConfig) + 0x1000; - radio_config < (char *)0xbffff000; + for (radio_config = ((char *) ar5312_boardConfig) + 0xf8; + radio_config < (char *)0xa8800000;

radio_config += 0x1000) {

if (*(int *)radio_config != 0xffffffff) {

dataFound = 1;

@@ -93,15 +93,15 @@

}

}

- if (!dataFound) { /* AR2316 relocates radio config to new location */ + if (!dataFound) { /* Non-AR2316 relocates radio config to new location */

dataFound = 0;

- for (radio_config = ((char *) ar5312_boardConfig) + 0xf8; - radio_config < (char *)0xbffff0f8; - radio_config += 0x1000) { - if (*(int *)radio_config != 0xffffffff) { - dataFound = 1; - break; - } + for (radio_config = ((char *) ar5312_boardConfig) + 0x1000; + radio_config < (char *)0xa8800000; + radio_config += 0x1000) { + if (*(int *)radio_config != 0xffffffff) { + dataFound = 1; + break; + }

}

}

@Eric:

If you have to paste a patch in your comment, then please quote it correctly (see WikiFormatting for details). Previewing your comment prevents format desasters as the one in your previous comments.

However, it's better to attach your patch as a separate file to the ticket. And if you expect your patch being committed sooner or later, you have to sign it off.

@Eric:

And just to mention it again: this ticket is closed, since the originally reported issue has been fixed as stated above. You seem to face a different issue - in case you're sure that this is a driver bug (and only then), you should open a new ticket and provide a proper description. If you're not sure, you should report your issue to our regular support channels, discuss it there and eventually file a ticket for it once it's clear that you found a bug.

Please refrain from adding any more comments to this ticket, they will be silently ignored.