[PATCH 0/2] ar9170-fw: Roll-your-own toolchain

[PATCH 0/2] ar9170-fw: Roll-your-own toolchain

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

Hi,

excited about the announcement of a free ar9170 firmware and
specifically the chance to get AP mode working with my DWA-160a, I
wanted to give this a try ASAP. As I'm somehow allergic when I have to
register for downloading Open Source, I hacked up a Makefile that
retrieves and builds a home-brewed m2-capable toolchain (the advertised
rpms only support m3 or even just m4).

The toolchain consists of latest binutils (2.19.1) and newlib (1.17.0),
but "only" gcc 4.3.3 as 4.4.0 drove the AP build into troubles: the
.data segment was reported to exceed the available space by a hundred
bytes. So I switched one version back for now.

On the other hand, the AP firmware doesn't work on my DWA-160a anyway
("device is in a bad state"), only the STA version (but that one
dislikes my access point, just like the original firmware, though).
Guess there is still enough room for improvements...

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [PATCH 0/2] ar9170-fw: Roll-your-own toolchain

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

On Sat, 2009-06-06 at 19:12 +0200, Jan Kiszka wrote:

> On the other hand, the AP firmware doesn't work on my DWA-160a anyway
> ("device is in a bad state"), 

This is normal. Not sure what's wrong with that, but I don't really care
either.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH 0/2] ar9170-fw: Roll-your-own toolchain

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

Johannes Berg wrote:
> On Sat, 2009-06-06 at 19:12 +0200, Jan Kiszka wrote:
> 
>> On the other hand, the AP firmware doesn't work on my DWA-160a anyway
>> ("device is in a bad state"), 
> 
> This is normal. Not sure what's wrong with that, but I don't really care
> either.

But does you device enter an endless reset loop?

[ 5337.468082] usb 2-2: new high speed USB device using ehci_hcd and address 30
[ 5337.648024] usb 2-2: New USB device found, idVendor=07d1, idProduct=3c10
[ 5337.648032] usb 2-2: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[ 5337.648038] usb 2-2: Product: USB2.0 WLAN
[ 5337.648042] usb 2-2: Manufacturer: ATHER
[ 5337.648046] usb 2-2: SerialNumber: 12345
[ 5337.648235] usb 2-2: configuration #1 chosen from 1 choice
[ 5337.764060] usb 2-2: reset high speed USB device using ehci_hcd and address 30
[ 5338.940054] usb 2-2: firmware: requesting ar9170.fw
[ 5340.552081] usb 2-2: device is in a bad state. please reconnect it!
[ 5341.552118] ar9170usb: probe of 2-2:1.0 failed with error -110
[ 5341.556838] usb 2-2: USB disconnect, address 30
[ 5341.800076] usb 2-2: new high speed USB device using ehci_hcd and address 31
...

Obviously not usable that way for me.

Maybe a toolchain issue - could you throw some AP firewire over that
works for you?

Thanks,
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [PATCH 0/2] ar9170-fw: Roll-your-own toolchain

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

On Sat, 2009-06-06 at 19:26 +0200, Jan Kiszka wrote:

> But does you device enter an endless reset loop?
> 
> [ 5337.468082] usb 2-2: new high speed USB device using ehci_hcd and address 30
> [ 5337.648024] usb 2-2: New USB device found, idVendor=07d1, idProduct=3c10
> [ 5337.648032] usb 2-2: New USB device strings: Mfr=16, Product=32, SerialNumber=48
> [ 5337.648038] usb 2-2: Product: USB2.0 WLAN
> [ 5337.648042] usb 2-2: Manufacturer: ATHER
> [ 5337.648046] usb 2-2: SerialNumber: 12345
> [ 5337.648235] usb 2-2: configuration #1 chosen from 1 choice
> [ 5337.764060] usb 2-2: reset high speed USB device using ehci_hcd and address 30
> [ 5338.940054] usb 2-2: firmware: requesting ar9170.fw
> [ 5340.552081] usb 2-2: device is in a bad state. please reconnect it!
> [ 5341.552118] ar9170usb: probe of 2-2:1.0 failed with error -110
> [ 5341.556838] usb 2-2: USB disconnect, address 30
> [ 5341.800076] usb 2-2: new high speed USB device using ehci_hcd and address 31
> ...

Yes. With the AP firmware, that is. I don't care about that firmware at
all.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH 0/2] ar9170-fw: Roll-your-own toolchain

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]

Johannes Berg wrote:
> On Sat, 2009-06-06 at 19:26 +0200, Jan Kiszka wrote:
> 
>> But does you device enter an endless reset loop?
>>
>> [ 5337.468082] usb 2-2: new high speed USB device using ehci_hcd and address 30
>> [ 5337.648024] usb 2-2: New USB device found, idVendor=07d1, idProduct=3c10
>> [ 5337.648032] usb 2-2: New USB device strings: Mfr=16, Product=32, SerialNumber=48
>> [ 5337.648038] usb 2-2: Product: USB2.0 WLAN
>> [ 5337.648042] usb 2-2: Manufacturer: ATHER
>> [ 5337.648046] usb 2-2: SerialNumber: 12345
>> [ 5337.648235] usb 2-2: configuration #1 chosen from 1 choice
>> [ 5337.764060] usb 2-2: reset high speed USB device using ehci_hcd and address 30
>> [ 5338.940054] usb 2-2: firmware: requesting ar9170.fw
>> [ 5340.552081] usb 2-2: device is in a bad state. please reconnect it!
>> [ 5341.552118] ar9170usb: probe of 2-2:1.0 failed with error -110
>> [ 5341.556838] usb 2-2: USB disconnect, address 30
>> [ 5341.800076] usb 2-2: new high speed USB device using ehci_hcd and address 31
>> ...
> 
> Yes. With the AP firmware, that is. I don't care about that firmware at
> all.

I do as it shall upgrade my soft-AP from an oldish rt2500 to this
dwa-160 stick.

Are you at least interested in porting the missing AP bits into the STA
version (likely the best long-term approach anyway)? And do you have a
rough idea which bits are missing / where to look at?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [PATCH 0/2] ar9170-fw: Roll-your-own toolchain

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

On Sat, 2009-06-06 at 19:37 +0200, Jan Kiszka wrote:

> > Yes. With the AP firmware, that is. I don't care about that firmware at
> > all.
> 
> I do as it shall upgrade my soft-AP from an oldish rt2500 to this
> dwa-160 stick.

No, you don't actually need AP software for that. The STA software
supports most of AP already.

> Are you at least interested in porting the missing AP bits into the STA
> version (likely the best long-term approach anyway)? And do you have a
> rough idea which bits are missing / where to look at?

Yes, that would be the plan. No, I have no idea what's missing. There
are tools like diff though :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH 0/2] ar9170-fw: Roll-your-own toolchain

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]

Johannes Berg wrote:
> On Sat, 2009-06-06 at 19:37 +0200, Jan Kiszka wrote:
> 
>>> Yes. With the AP firmware, that is. I don't care about that firmware at
>>> all.
>> I do as it shall upgrade my soft-AP from an oldish rt2500 to this
>> dwa-160 stick.
> 
> No, you don't actually need AP software for that. The STA software
> supports most of AP already.

The last statement I read was: "haven't found a way to properly transmit
multicast frames after DTIM". Does this still apply on the new STA
firmware? What is the state of AP mode in the driver source? Just
disabled, some bits missing - or even ready to work?

> 
>> Are you at least interested in porting the missing AP bits into the STA
>> version (likely the best long-term approach anyway)? And do you have a
>> rough idea which bits are missing / where to look at?
> 
> Yes, that would be the plan. No, I have no idea what's missing. There
> are tools like diff though :)

Yeah:
# diff -up nice-code-1.c nice-code-2.c | manual-filter
...
-rxBBReg = reg_read_PHY(0x1c5960); //*(volatile u32_t*)(0x1c5960); /* 0x1c8960 write only */
+rxBBReg = *(volatile u32_t*)(0x1c5960); /* 0x1c8960 write only */
...

That will be a "nice" job... :)


Another silly question: You wrote that 802.11n works with the firmware,
and I blindly assumed that this of course includes a/b/g. I was right?
My current AP works in g-mode when association with the ar9170 fails...

Thanks so far,
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [PATCH 0/2] ar9170-fw: Roll-your-own toolchain

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

On Sat, 2009-06-06 at 19:58 +0200, Jan Kiszka wrote:

> The last statement I read was: "haven't found a way to properly transmit
> multicast frames after DTIM". Does this still apply on the new STA
> firmware? 

Yes.

> What is the state of AP mode in the driver source? Just
> disabled, some bits missing - or even ready to work?

It works if you're willing to live with the above limitation, by just
enabling the AP bit. I've used it before.

> Another silly question: You wrote that 802.11n works with the firmware,
> and I blindly assumed that this of course includes a/b/g. I was right?
> My current AP works in g-mode when association with the ar9170 fails...

I never said anything works...

Anyhow, I _really_ can't support the firmware in any way. I just hacked
on it for fun and it turns out it ended up kinda working...

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]