From andy at plausible.org  Wed May  1 12:27:04 2013
From: andy at plausible.org (Andy Ross)
Date: Wed, 01 May 2013 09:27:04 -0700
Subject: Host mode instability & device lockups
Message-ID: <51814258.5010501@plausible.org>

I'm having a rough time with these devices.  They are fairly reliably
locking up for me under hostapd use after a few hours to a day or use.
I've tried 2 separate TP-Link TL-WN821Nv3 (AR7101) units and 3
separate NetGear WNA1100 (AR9271) without success.  I've tried voodoo
like attaching a heat sink to the TP-Link chip (it does get awfully
hot) and disabling hwcrypt in the driver without effect.

What I'm seeing is that the device just stops responding, looking at
usbmon (I'm on the Fedora 18 3.8 kernel and a firmware build from
yesterday with a quick hack to revert the version number change) I see
things like:

    ffff8801914ae9c0 2368252447 S Bo:1:007:4 -115 16 = 01000008 0188ffff 00142241 00052008
    ffff880191575240 2368352456 S Bo:1:007:4 -115 20 = 0100000c 0188ffff 00152242 00052008 fffffffb
    ffff8801914ae780 2369252420 S Bo:1:007:4 -115 16 = 01000008 0188ffff 00142243 00052008
    ffff880191575180 2369352447 S Bo:1:007:4 -115 20 = 0100000c 0188ffff 00152244 00052008 fffffffb
    ffff88019ef35000 2370252409 S Bo:1:007:4 -115 16 = 01000008 0188ffff 00142245 00052008
    ffff880191575540 2370352445 S Bo:1:007:4 -115 20 = 0100000c 0188ffff 00152246 00052008 fffffffb
    ffff88019ef350c0 2371252447 S Bo:1:007:4 -115 16 = 01000008 0188ffff 00142247 00052008
    ffff880191575600 2371352446 S Bo:1:007:4 -115 20 = 0100000c 0188ffff 00152248 00052008 fffffffb
    ...

Which looks to me (I'm no expert on the kernel USB layer) like the
driver is submitting ("S") pairs of packets (spaced 100ms apart) every
second, forever, without a reply (a "C" callback record).  My
assumption is that these transactions are going un-ACKed at the USB
layer.

Now, this right here seems like a driver bug, becuase if my
understanding is right these urb requests are going to build up
forever and eventually exhaust memory.  The driver really should be
detecting this case and backing out or trying to reset, and it
doesn't.  (And in fact it's worse, because trying to rmmod the module
in this state actually locks up the host network layer somehow!
Routing still works, but I can no longer open new connections or ssh
in.)

But what can be done at the firmware level?  Surely something has
gotten confused here, and shouldn't there be some watchdogging
available to effect a device reset that can be seen by the host?

Any ideas?  I'd really like to get these receivers running reliably as
host nodes, but right now they're basically useless.  The fact that
I've tried two different chips and five units with almost identical
behavior seems to argue strongly against simple hardware instability.

Andy



From adrian at freebsd.org  Wed May  1 12:35:57 2013
From: adrian at freebsd.org (Adrian Chadd)
Date: Wed, 1 May 2013 09:35:57 -0700
Subject: Host mode instability & device lockups
In-Reply-To: <51814258.5010501@plausible.org>
References: <51814258.5010501@plausible.org>
Message-ID: <CAJ-Vmomc0ZV9EhBjUm4-pvnQHVn43Ac8pwFiAnjfGDudkjpNPw@mail.gmail.com>

Well, does bringing the interface down/up fix it? I guess not.

I wonder if the firmware has crashed here. Unfortunately you'll need
to add a couple UART pins to your NIC to enable/see debugging output.



adrian

On 1 May 2013 09:27, Andy Ross <andy at plausible.org> wrote:
> I'm having a rough time with these devices.  They are fairly reliably
> locking up for me under hostapd use after a few hours to a day or use.
> I've tried 2 separate TP-Link TL-WN821Nv3 (AR7101) units and 3
> separate NetGear WNA1100 (AR9271) without success.  I've tried voodoo
> like attaching a heat sink to the TP-Link chip (it does get awfully
> hot) and disabling hwcrypt in the driver without effect.
>
> What I'm seeing is that the device just stops responding, looking at
> usbmon (I'm on the Fedora 18 3.8 kernel and a firmware build from
> yesterday with a quick hack to revert the version number change) I see
> things like:
>
>     ffff8801914ae9c0 2368252447 S Bo:1:007:4 -115 16 = 01000008 0188ffff 00142241 00052008
>     ffff880191575240 2368352456 S Bo:1:007:4 -115 20 = 0100000c 0188ffff 00152242 00052008 fffffffb
>     ffff8801914ae780 2369252420 S Bo:1:007:4 -115 16 = 01000008 0188ffff 00142243 00052008
>     ffff880191575180 2369352447 S Bo:1:007:4 -115 20 = 0100000c 0188ffff 00152244 00052008 fffffffb
>     ffff88019ef35000 2370252409 S Bo:1:007:4 -115 16 = 01000008 0188ffff 00142245 00052008
>     ffff880191575540 2370352445 S Bo:1:007:4 -115 20 = 0100000c 0188ffff 00152246 00052008 fffffffb
>     ffff88019ef350c0 2371252447 S Bo:1:007:4 -115 16 = 01000008 0188ffff 00142247 00052008
>     ffff880191575600 2371352446 S Bo:1:007:4 -115 20 = 0100000c 0188ffff 00152248 00052008 fffffffb
>     ...
>
> Which looks to me (I'm no expert on the kernel USB layer) like the
> driver is submitting ("S") pairs of packets (spaced 100ms apart) every
> second, forever, without a reply (a "C" callback record).  My
> assumption is that these transactions are going un-ACKed at the USB
> layer.
>
> Now, this right here seems like a driver bug, becuase if my
> understanding is right these urb requests are going to build up
> forever and eventually exhaust memory.  The driver really should be
> detecting this case and backing out or trying to reset, and it
> doesn't.  (And in fact it's worse, because trying to rmmod the module
> in this state actually locks up the host network layer somehow!
> Routing still works, but I can no longer open new connections or ssh
> in.)
>
> But what can be done at the firmware level?  Surely something has
> gotten confused here, and shouldn't there be some watchdogging
> available to effect a device reset that can be seen by the host?
>
> Any ideas?  I'd really like to get these receivers running reliably as
> host nodes, but right now they're basically useless.  The fact that
> I've tried two different chips and five units with almost identical
> behavior seems to argue strongly against simple hardware instability.
>
> Andy
>
>
> _______________________________________________
> ath9k_htc_fw mailing list
> ath9k_htc_fw at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath9k_htc_fw


From andy at plausible.org  Wed May  1 12:49:17 2013
From: andy at plausible.org (Andy Ross)
Date: Wed, 01 May 2013 09:49:17 -0700
Subject: Host mode instability & device lockups
In-Reply-To: <CAJ-Vmomc0ZV9EhBjUm4-pvnQHVn43Ac8pwFiAnjfGDudkjpNPw@mail.gmail.com>
References: <51814258.5010501@plausible.org>
 <CAJ-Vmomc0ZV9EhBjUm4-pvnQHVn43Ac8pwFiAnjfGDudkjpNPw@mail.gmail.com>
Message-ID: <5181478D.3050209@plausible.org>

On 05/01/2013 09:35 AM, Adrian Chadd wrote:
> Well, does bringing the interface down/up fix it? I guess not.
> 
> I wonder if the firmware has crashed here. Unfortunately you'll need
> to add a couple UART pins to your NIC to enable/see debugging output.

Yeah.  I saw the posts about the SMT pins, but let's just say I'm
going to need a lot more than five test units to make that work. ;)

I guess I was hoping for an answer like "here's the watchdog code, it
runs out of a timer interrupt and checks this word for an update, such
that if it doesn't see XXX from the host every NN ms it will reset and
emit YYY from endpoint 2" or whatever.  Then I could write a script to
check for that in the usbmon output and maybe see if I could get the
driver to recover.

As it is, I'm at least hopeful I can get the driver fixed such that it
doesn't hang the machine.

Andy


From linux at rempel-privat.de  Wed May  1 13:05:53 2013
From: linux at rempel-privat.de (Oleksij Rempel)
Date: Wed, 01 May 2013 19:05:53 +0200
Subject: Host mode instability & device lockups
In-Reply-To: <5181478D.3050209@plausible.org>
References: <51814258.5010501@plausible.org>
 <CAJ-Vmomc0ZV9EhBjUm4-pvnQHVn43Ac8pwFiAnjfGDudkjpNPw@mail.gmail.com>
 <5181478D.3050209@plausible.org>
Message-ID: <51814B71.8090408@rempel-privat.de>

Am 01.05.2013 18:49, schrieb Andy Ross:
> On 05/01/2013 09:35 AM, Adrian Chadd wrote:
>> Well, does bringing the interface down/up fix it? I guess not.
>>
>> I wonder if the firmware has crashed here. Unfortunately you'll need
>> to add a couple UART pins to your NIC to enable/see debugging output.
>
> Yeah.  I saw the posts about the SMT pins, but let's just say I'm
> going to need a lot more than five test units to make that work. ;)
>
> I guess I was hoping for an answer like "here's the watchdog code, it
> runs out of a timer interrupt and checks this word for an update, such
> that if it doesn't see XXX from the host every NN ms it will reset and
> emit YYY from endpoint 2" or whatever.  Then I could write a script to
> check for that in the usbmon output and maybe see if I could get the
> driver to recover.

That would lead to workaround, so no body will care about broken 
firmware. Or some one will as why restart firwmare every hour. If it is 
an firmware issue, we need to fix it.

> As it is, I'm at least hopeful I can get the driver fixed such that it
> doesn't hang the machine.

Did just removed module or did rmmmod --force?


-- 
Regards,
Oleksij


From andy at plausible.org  Wed May  1 13:11:04 2013
From: andy at plausible.org (Andy Ross)
Date: Wed, 01 May 2013 10:11:04 -0700
Subject: Host mode instability & device lockups
In-Reply-To: <51814B71.8090408@rempel-privat.de>
References: <51814258.5010501@plausible.org>
 <CAJ-Vmomc0ZV9EhBjUm4-pvnQHVn43Ac8pwFiAnjfGDudkjpNPw@mail.gmail.com>
 <5181478D.3050209@plausible.org> <51814B71.8090408@rempel-privat.de>
Message-ID: <51814CA8.4000309@plausible.org>

On 05/01/2013 10:05 AM, Oleksij Rempel wrote:
> That would lead to workaround, so no body will care about broken 
> firmware. Or some one will as why restart firwmare every hour. If it is 
> an firmware issue, we need to fix it.

Indeed, and distinguishing a firmware crash from other things like
truly latched-up logic seems important, no?  If there's no existing watchdog
facility, then clearly that idea won't work (though it makes me a little
sad).

>> > As it is, I'm at least hopeful I can get the driver fixed such that it
>> > doesn't hang the machine.
>
> Did just removed module or did rmmmod --force?

Fedora's kernels don't include CONFIG_MODULE_FORCE_UNLOAD, so no.

Andy


From greearb at candelatech.com  Wed May  1 14:21:47 2013
From: greearb at candelatech.com (greearb at candelatech.com)
Date: Wed,  1 May 2013 11:21:47 -0700
Subject: [PATCH] Update build instructions.
Message-ID: <1367432507-28429-1-git-send-email-greearb@candelatech.com>

From: Ben Greear <greearb at candelatech.com>

I found no ./build script, but 'make firmware' appears to
do the trick.

Signed-off-by: Ben Greear <greearb at candelatech.com>
---
 README | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README b/README
index 18af41f..15c003c 100644
--- a/README
+++ b/README
@@ -61,7 +61,7 @@ You're in for a treat.
 
   * Linux:
 
-  $ ./build
+  $ make firmware
 
   * FreeBSD:
 
@@ -70,7 +70,7 @@ You're in for a treat.
   $ ./build
 
 You will end up with two .fw files - one for the AR7010 and one for
-the AR9271.
+the AR9271 in the target_firmware directory.
 
 
 Then what?
-- 
1.7.11.7



From linux at rempel-privat.de  Thu May  2 02:52:42 2013
From: linux at rempel-privat.de (Oleksij Rempel)
Date: Thu, 02 May 2013 08:52:42 +0200
Subject: uart interface issues (fixed)
In-Reply-To: <517D2F6F.2050307@rempel-privat.de>
References: <517CC77B.7070007@rempel-privat.de>
 <CAJ-VmonMZRWe-YLW7sF5vapZwWxE+x3OR0k3KNOfHDOMM6zocg@mail.gmail.com>
 <517D2F6F.2050307@rempel-privat.de>
Message-ID: <51820D3A.6030209@rempel-privat.de>

Am 28.04.2013 16:17, schrieb Oleksij Rempel:
> Am 28.04.2013 13:38, schrieb Adrian Chadd:
>> .. is it triggering BREAK interrupts or something?
>
> I don't know, there is no serial output on this stage. JTAG may help if
> the protocol is some how similar to EJTAG. Are there any documentation
> about Xtensa dubug interface ;)?
> I will need to dig in it, but not this week.
>
>
>> That may be something that the boot ROM code interprets as a magical
>> "don't start" sequence or something.

So, this issue is fixed now.

ttl TX >------[2K]--------o RX pin on AR7010
                      |----[4K pull up]---< 3,3V

In attachment are pictures from my setup ;)

-- 
Regards,
Oleksij
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Image001-5.jpg
Type: image/jpeg
Size: 378799 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath9k_htc_fw/attachments/20130502/df85317a/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Image001-6.jpg
Type: image/jpeg
Size: 365451 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath9k_htc_fw/attachments/20130502/df85317a/attachment-0003.jpg>

From k.eugene.e at gmail.com  Thu May  2 03:15:00 2013
From: k.eugene.e at gmail.com (Eugene Krasnikov)
Date: Thu, 2 May 2013 09:15:00 +0200
Subject: uart interface issues (fixed)
In-Reply-To: <51820D3A.6030209@rempel-privat.de>
References: <517CC77B.7070007@rempel-privat.de>
 <CAJ-VmonMZRWe-YLW7sF5vapZwWxE+x3OR0k3KNOfHDOMM6zocg@mail.gmail.com>
 <517D2F6F.2050307@rempel-privat.de>
 <51820D3A.6030209@rempel-privat.de>
Message-ID: <CAFSJ42aiXxkcBYOSJHZ-ztyBkLgE5kiniMjST0EtRwgbyVrvTQ@mail.gmail.com>

Hi Oleksij,

Have you tried remote debugging? Or it's only about garbing logs from
the chip. Have you tried to send commands to the chip?

2013/5/2 Oleksij Rempel <linux at rempel-privat.de>:
> Am 28.04.2013 16:17, schrieb Oleksij Rempel:
>>
>> Am 28.04.2013 13:38, schrieb Adrian Chadd:
>>>
>>> .. is it triggering BREAK interrupts or something?
>>
>>
>> I don't know, there is no serial output on this stage. JTAG may help if
>> the protocol is some how similar to EJTAG. Are there any documentation
>> about Xtensa dubug interface ;)?
>> I will need to dig in it, but not this week.
>>
>>
>>> That may be something that the boot ROM code interprets as a magical
>>> "don't start" sequence or something.
>
>
> So, this issue is fixed now.
>
> ttl TX >------[2K]--------o RX pin on AR7010
>                      |----[4K pull up]---< 3,3V
>
> In attachment are pictures from my setup ;)
>
> --
> Regards,
> Oleksij



-- 
Best regards,
Eugene


From linux at rempel-privat.de  Thu May  2 03:20:10 2013
From: linux at rempel-privat.de (Oleksij Rempel)
Date: Thu, 02 May 2013 09:20:10 +0200
Subject: uart interface issues (fixed)
In-Reply-To: <CAFSJ42aiXxkcBYOSJHZ-ztyBkLgE5kiniMjST0EtRwgbyVrvTQ@mail.gmail.com>
References: <517CC77B.7070007@rempel-privat.de>
 <CAJ-VmonMZRWe-YLW7sF5vapZwWxE+x3OR0k3KNOfHDOMM6zocg@mail.gmail.com>
 <517D2F6F.2050307@rempel-privat.de> <51820D3A.6030209@rempel-privat.de>
 <CAFSJ42aiXxkcBYOSJHZ-ztyBkLgE5kiniMjST0EtRwgbyVrvTQ@mail.gmail.com>
Message-ID: <518213AA.1010408@rempel-privat.de>

Am 02.05.2013 09:15, schrieb Eugene Krasnikov:
> Hi Oleksij,
>
> Have you tried remote debugging? Or it's only about garbing logs from
> the chip. Have you tried to send commands to the chip?

Yes, it works. You need this resistors to make chip start with ttl 
adapter attached. Without them this chip may not start.

> 2013/5/2 Oleksij Rempel <linux at rempel-privat.de>:
>> Am 28.04.2013 16:17, schrieb Oleksij Rempel:
>>>
>>> Am 28.04.2013 13:38, schrieb Adrian Chadd:
>>>>
>>>> .. is it triggering BREAK interrupts or something?
>>>
>>>
>>> I don't know, there is no serial output on this stage. JTAG may help if
>>> the protocol is some how similar to EJTAG. Are there any documentation
>>> about Xtensa dubug interface ;)?
>>> I will need to dig in it, but not this week.
>>>
>>>
>>>> That may be something that the boot ROM code interprets as a magical
>>>> "don't start" sequence or something.
>>
>>
>> So, this issue is fixed now.
>>
>> ttl TX >------[2K]--------o RX pin on AR7010
>>                       |----[4K pull up]---< 3,3V
>>
>> In attachment are pictures from my setup ;)
>>
>> --
>> Regards,
>> Oleksij
>
>
>


-- 
Regards,
Oleksij


From k.eugene.e at gmail.com  Thu May  2 03:22:39 2013
From: k.eugene.e at gmail.com (Eugene Krasnikov)
Date: Thu, 2 May 2013 09:22:39 +0200
Subject: uart interface issues (fixed)
In-Reply-To: <518213AA.1010408@rempel-privat.de>
References: <517CC77B.7070007@rempel-privat.de>
 <CAJ-VmonMZRWe-YLW7sF5vapZwWxE+x3OR0k3KNOfHDOMM6zocg@mail.gmail.com>
 <517D2F6F.2050307@rempel-privat.de>
 <51820D3A.6030209@rempel-privat.de>
 <CAFSJ42aiXxkcBYOSJHZ-ztyBkLgE5kiniMjST0EtRwgbyVrvTQ@mail.gmail.com>
 <518213AA.1010408@rempel-privat.de>
Message-ID: <CAFSJ42YMWqOCnSY+_5fEndvczstTTjKhexCwnSaCfno4xrYexA@mail.gmail.com>

What kind of commands did you try to send? I will try the same with my
dongle and update you if that works or not;)

2013/5/2 Oleksij Rempel <linux at rempel-privat.de>:
> Am 02.05.2013 09:15, schrieb Eugene Krasnikov:
>
>> Hi Oleksij,
>>
>> Have you tried remote debugging? Or it's only about garbing logs from
>> the chip. Have you tried to send commands to the chip?
>
>
> Yes, it works. You need this resistors to make chip start with ttl adapter
> attached. Without them this chip may not start.
>
>
>> 2013/5/2 Oleksij Rempel <linux at rempel-privat.de>:
>>>
>>> Am 28.04.2013 16:17, schrieb Oleksij Rempel:
>>>>
>>>>
>>>> Am 28.04.2013 13:38, schrieb Adrian Chadd:
>>>>>
>>>>>
>>>>> .. is it triggering BREAK interrupts or something?
>>>>
>>>>
>>>>
>>>> I don't know, there is no serial output on this stage. JTAG may help if
>>>> the protocol is some how similar to EJTAG. Are there any documentation
>>>> about Xtensa dubug interface ;)?
>>>> I will need to dig in it, but not this week.
>>>>
>>>>
>>>>> That may be something that the boot ROM code interprets as a magical
>>>>> "don't start" sequence or something.
>>>
>>>
>>>
>>> So, this issue is fixed now.
>>>
>>> ttl TX >------[2K]--------o RX pin on AR7010
>>>                       |----[4K pull up]---< 3,3V
>>>
>>> In attachment are pictures from my setup ;)
>>>
>>> --
>>> Regards,
>>> Oleksij
>>
>>
>>
>>
>
>
> --
> Regards,
> Oleksij



-- 
Best regards,
Eugene


From linux at rempel-privat.de  Thu May  2 03:29:21 2013
From: linux at rempel-privat.de (Oleksij Rempel)
Date: Thu, 02 May 2013 09:29:21 +0200
Subject: uart interface issues (fixed)
In-Reply-To: <CAFSJ42YMWqOCnSY+_5fEndvczstTTjKhexCwnSaCfno4xrYexA@mail.gmail.com>
References: <517CC77B.7070007@rempel-privat.de>
 <CAJ-VmonMZRWe-YLW7sF5vapZwWxE+x3OR0k3KNOfHDOMM6zocg@mail.gmail.com>
 <517D2F6F.2050307@rempel-privat.de> <51820D3A.6030209@rempel-privat.de>
 <CAFSJ42aiXxkcBYOSJHZ-ztyBkLgE5kiniMjST0EtRwgbyVrvTQ@mail.gmail.com>
 <518213AA.1010408@rempel-privat.de>
 <CAFSJ42YMWqOCnSY+_5fEndvczstTTjKhexCwnSaCfno4xrYexA@mail.gmail.com>
Message-ID: <518215D1.8050300@rempel-privat.de>

Am 02.05.2013 09:22, schrieb Eugene Krasnikov:
> What kind of commands did you try to send? I will try the same with my
> dongle and update you if that works or not;)

all command are here:
./target_firmware/magpie_fw_dev/target/cmnos/dbg_api.c

working commands:
help
info ram
wdt rst (restart system)
wdt off (turn off watchdog)
wdt on (...)
memdmp 50000 50010 (memdump of 0x50000 0x50010 area)

be careful with memdmp command. If watchdog enabled i can be triggered 
on memdmp, so disable it. If you hit some prottected memory area, system 
on chip will oops.

> 2013/5/2 Oleksij Rempel <linux at rempel-privat.de>:
>> Am 02.05.2013 09:15, schrieb Eugene Krasnikov:
>>
>>> Hi Oleksij,
>>>
>>> Have you tried remote debugging? Or it's only about garbing logs from
>>> the chip. Have you tried to send commands to the chip?
>>
>>
>> Yes, it works. You need this resistors to make chip start with ttl adapter
>> attached. Without them this chip may not start.
>>
>>
>>> 2013/5/2 Oleksij Rempel <linux at rempel-privat.de>:
>>>>
>>>> Am 28.04.2013 16:17, schrieb Oleksij Rempel:
>>>>>
>>>>>
>>>>> Am 28.04.2013 13:38, schrieb Adrian Chadd:
>>>>>>
>>>>>>
>>>>>> .. is it triggering BREAK interrupts or something?
>>>>>
>>>>>
>>>>>
>>>>> I don't know, there is no serial output on this stage. JTAG may help if
>>>>> the protocol is some how similar to EJTAG. Are there any documentation
>>>>> about Xtensa dubug interface ;)?
>>>>> I will need to dig in it, but not this week.
>>>>>
>>>>>
>>>>>> That may be something that the boot ROM code interprets as a magical
>>>>>> "don't start" sequence or something.
>>>>
>>>>
>>>>
>>>> So, this issue is fixed now.
>>>>
>>>> ttl TX >------[2K]--------o RX pin on AR7010
>>>>                        |----[4K pull up]---< 3,3V
>>>>
>>>> In attachment are pictures from my setup ;)
>>>>
>>>> --
>>>> Regards,
>>>> Oleksij
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Regards,
>> Oleksij
>
>
>


-- 
Regards,
Oleksij


From linux at rempel-privat.de  Thu May  2 04:27:44 2013
From: linux at rempel-privat.de (Oleksij Rempel)
Date: Thu, 02 May 2013 10:27:44 +0200
Subject: disabling boot from spi on ar7010
Message-ID: <51822380.8040009@rempel-privat.de>

Hello all,

how to disable SPISEL or boot from SPI on ar7010? There is probably some 
pin for this :)
I wont to test if it possible to workaround this watchdog issue.


-- 
Regards,
Oleksij


From adrian at freebsd.org  Thu May  2 04:30:08 2013
From: adrian at freebsd.org (Adrian Chadd)
Date: Thu, 2 May 2013 01:30:08 -0700
Subject: disabling boot from spi on ar7010
In-Reply-To: <51822380.8040009@rempel-privat.de>
References: <51822380.8040009@rempel-privat.de>
Message-ID: <CAJ-VmokELqS4-NzW0qEd_WHaZi-LmSKXfLNur2z5CB45-_6xLQ@mail.gmail.com>

On 2 May 2013 01:27, Oleksij Rempel <linux at rempel-privat.de> wrote:
> Hello all,
>
> how to disable SPISEL or boot from SPI on ar7010? There is probably some pin
> for this :)
> I wont to test if it possible to workaround this watchdog issue.
>

What do you want to achieve by doing that? Nothing will work if you
disable the boot code?



Adrian


From linux at rempel-privat.de  Thu May  2 04:36:36 2013
From: linux at rempel-privat.de (Oleksij Rempel)
Date: Thu, 02 May 2013 10:36:36 +0200
Subject: disabling boot from spi on ar7010
In-Reply-To: <CAJ-VmokELqS4-NzW0qEd_WHaZi-LmSKXfLNur2z5CB45-_6xLQ@mail.gmail.com>
References: <51822380.8040009@rempel-privat.de>
 <CAJ-VmokELqS4-NzW0qEd_WHaZi-LmSKXfLNur2z5CB45-_6xLQ@mail.gmail.com>
Message-ID: <51822594.6090900@rempel-privat.de>

Am 02.05.2013 10:30, schrieb Adrian Chadd:
> On 2 May 2013 01:27, Oleksij Rempel <linux at rempel-privat.de> wrote:
>> Hello all,
>>
>> how to disable SPISEL or boot from SPI on ar7010? There is probably some pin
>> for this :)
>> I wont to test if it possible to workaround this watchdog issue.
>>
>
> What do you want to achieve by doing that? Nothing will work if you
> disable the boot code?

I have two ar7010 adapter one with spi, second without it. I assume, 
that one without SPI, starts from internal ROM. I wont to test, if code 
in ROM is better then on SPI.

I do not use adapter without SPI for debugging.

PS: Beside in Rom, seems to be there lost of interesting things: Pope, 
Basilica ;)


-- 
Regards,
Oleksij


From adrian at freebsd.org  Thu May  2 04:39:21 2013
From: adrian at freebsd.org (Adrian Chadd)
Date: Thu, 2 May 2013 01:39:21 -0700
Subject: disabling boot from spi on ar7010
In-Reply-To: <51822594.6090900@rempel-privat.de>
References: <51822380.8040009@rempel-privat.de>
 <CAJ-VmokELqS4-NzW0qEd_WHaZi-LmSKXfLNur2z5CB45-_6xLQ@mail.gmail.com>
 <51822594.6090900@rempel-privat.de>
Message-ID: <CAJ-Vmo=Zeyut_YQ2Gg_SsBnLxjFv1N6eCOtPK8+cRP7g748-wQ@mail.gmail.com>

The SPI flash may just be for calibration data rather than booting from. :-)

But, hm. I have no idea how to configure the thing to boot from ROM
rather than SPI. I'll have to re-read the datasheet and see.



Adrian


From linux at rempel-privat.de  Sat May  4 13:12:42 2013
From: linux at rempel-privat.de (Oleksij Rempel)
Date: Sat, 04 May 2013 19:12:42 +0200
Subject: disabling boot from spi on ar7010
In-Reply-To: <CAJ-Vmo=Zeyut_YQ2Gg_SsBnLxjFv1N6eCOtPK8+cRP7g748-wQ@mail.gmail.com>
References: <51822380.8040009@rempel-privat.de>
 <CAJ-VmokELqS4-NzW0qEd_WHaZi-LmSKXfLNur2z5CB45-_6xLQ@mail.gmail.com>
 <51822594.6090900@rempel-privat.de>
 <CAJ-Vmo=Zeyut_YQ2Gg_SsBnLxjFv1N6eCOtPK8+cRP7g748-wQ@mail.gmail.com>
Message-ID: <5185418A.4000808@rempel-privat.de>

Am 02.05.2013 10:39, schrieb Adrian Chadd:
> The SPI flash may just be for calibration data rather than booting from. :-)
>
> But, hm. I have no idea how to configure the thing to boot from ROM
> rather than SPI. I'll have to re-read the datasheet and see.

any updates? .)

-- 
Regards,
Oleksij


From adrian at freebsd.org  Sat May  4 13:15:11 2013
From: adrian at freebsd.org (Adrian Chadd)
Date: Sat, 4 May 2013 10:15:11 -0700
Subject: disabling boot from spi on ar7010
In-Reply-To: <5185418A.4000808@rempel-privat.de>
References: <51822380.8040009@rempel-privat.de>
 <CAJ-VmokELqS4-NzW0qEd_WHaZi-LmSKXfLNur2z5CB45-_6xLQ@mail.gmail.com>
 <51822594.6090900@rempel-privat.de>
 <CAJ-Vmo=Zeyut_YQ2Gg_SsBnLxjFv1N6eCOtPK8+cRP7g748-wQ@mail.gmail.com>
 <5185418A.4000808@rempel-privat.de>
Message-ID: <CAJ-VmokmckkDKxd6K6p7FYrwXBkiiTyNKCVm8KesFF6AcbKEig@mail.gmail.com>

On 4 May 2013 10:12, Oleksij Rempel <linux at rempel-privat.de> wrote:
> Am 02.05.2013 10:39, schrieb Adrian Chadd:
>
>> The SPI flash may just be for calibration data rather than booting from.
>> :-)
>>
>> But, hm. I have no idea how to configure the thing to boot from ROM
>> rather than SPI. I'll have to re-read the datasheet and see.
>
>
> any updates? .)

Nope, not yet sorry. I've been preoccupied with another set of bugs in
FreeBSD. :(



Adrian


From k.eugene.e at gmail.com  Mon May  6 08:12:54 2013
From: k.eugene.e at gmail.com (Eugene Krasnikov)
Date: Mon, 6 May 2013 14:12:54 +0200
Subject: [PATCH] Add build information to the beginning of the binary
In-Reply-To: <CAFSJ42YNkjsrm-n4DBbd=KyYRH1iJSGUDoAqZn9Vko40A3RskQ@mail.gmail.com>
References: <1366657752-15750-1-git-send-email-k.eugene.e@gmail.com>
 <CAFSJ42aOqu-K-RFPiFarWTJ8iNTAgY98DFxJy=TqsPUcSHHq3Q@mail.gmail.com>
 <CAFSJ42YNkjsrm-n4DBbd=KyYRH1iJSGUDoAqZn9Vko40A3RskQ@mail.gmail.com>
Message-ID: <CAFSJ42YV+a2feq7dw=TKwKSoGoF-u879OXve55o7ftNmNJk3Jw@mail.gmail.com>

Hi Adrian,

What do you think about the idea behind this implementation?:)

2013/4/22 Eugene Krasnikov <k.eugene.e at gmail.com>:
> Please let me know if you want me to attach driver patch. Also on top
> of this i can add one more patch to generate 2 binaries with and
> without build information if needed.
>
> 2013/4/22 Eugene Krasnikov <k.eugene.e at gmail.com>:
>> Hi Adrian and All,
>>
>> This is a draft version of the patch that will add build information
>> to the beginning of the binary file. This patch is not ideal so i will
>> rework it later but it is more about showing the concept. So please
>> feedback?:)
>>
>> As soon as we agree on concept i'll send out final patch.
>>
>> 2013/4/22 Eugene Krasnikov <k.eugene.e at gmail.com>:
>>> With this commit both htc_9271.fw and htc_7010.fw will have build
>>> information in the beginning of the file. Driver can read this
>>> information even before loading fw to the chip.
>>>
>>> Build information format:
>>>         u32     major;
>>>         u32     minor;
>>>         u32     tag;
>>>         char    commit_id[40];
>>>         char    user_name[32];
>>>
>>> Signed-off-by: Eugene Krasnikov <k.eugene.e at gmail.com>
>>> ---
>>>  .../magpie_fw_dev/build/utility/athfw2lnx/Makefile |    2 +-
>>>  .../build/utility/athfw2lnx/athfw2lnx.c            |   21 ++++++++++++++++++++
>>>  2 files changed, 22 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/target_firmware/magpie_fw_dev/build/utility/athfw2lnx/Makefile b/target_firmware/magpie_fw_dev/build/utility/athfw2lnx/Makefile
>>> index f13c296..e5957f9 100644
>>> --- a/target_firmware/magpie_fw_dev/build/utility/athfw2lnx/Makefile
>>> +++ b/target_firmware/magpie_fw_dev/build/utility/athfw2lnx/Makefile
>>> @@ -5,7 +5,7 @@ $(error "ERROR: usage: make ATH_FW=fw.c")
>>>  endif
>>>
>>>  athfw2lnx: athfw2lnx.c $(ATH_FW)
>>> -       gcc -o $@ athfw2lnx.c $(ATH_FW)
>>> +       gcc -o $@ athfw2lnx.c $(ATH_FW) -DHOSTNAME=\"$(shell hostname)\"  -DCOMMIT_HASH=\"$(shell git rev-parse --short HEAD)\"
>>>
>>>  clean:
>>>         rm -f athfw2lnx
>>> diff --git a/target_firmware/magpie_fw_dev/build/utility/athfw2lnx/athfw2lnx.c b/target_firmware/magpie_fw_dev/build/utility/athfw2lnx/athfw2lnx.c
>>> index aa74e8f..1513f14 100644
>>> --- a/target_firmware/magpie_fw_dev/build/utility/athfw2lnx/athfw2lnx.c
>>> +++ b/target_firmware/magpie_fw_dev/build/utility/athfw2lnx/athfw2lnx.c
>>> @@ -35,14 +35,35 @@
>>>  #include <sys/stat.h>
>>>  #include <fcntl.h>
>>>  #include <stdint.h>
>>> +#include <string.h>
>>>
>>>  /* These names may vary but this is typical */
>>>  extern const uint32_t zcFwImage[];
>>>  extern const uint32_t zcFwImageSize;
>>>
>>> +#define WLAN_BUILD_VER_MAJOR 1
>>> +#define WLAN_BUILD_VER_MINOR 1
>>> +#define WLAN_BUILD_VER_TAG 1
>>> +
>>> +struct build_info {
>>> +       uint32_t        major;
>>> +       uint32_t        minor;
>>> +       uint32_t        tag;
>>> +       char            commit_id[40];
>>> +       char            user_name[32];
>>> +};
>>>  int main()
>>>  {
>>>         uint32_t i;
>>> +       struct build_info binfo;
>>> +
>>> +       binfo.major     = WLAN_BUILD_VER_MAJOR;
>>> +       binfo.minor     = WLAN_BUILD_VER_MINOR;
>>> +       binfo.tag       = WLAN_BUILD_VER_TAG;
>>> +       memcpy(binfo.user_name, HOSTNAME, strlen(HOSTNAME));
>>> +       memcpy(binfo.commit_id, COMMIT_HASH, strlen(COMMIT_HASH));
>>> +       write(1, &binfo, sizeof(binfo));
>>> +
>>>         for (i = 0; i < zcFwImageSize/4; i++)
>>>                 write(1, &zcFwImage[i], 4);
>>>  }
>>> --
>>> 1.7.9.5
>>>
>>
>>
>>
>> --
>> Best regards,
>> Eugene
>
>
>
> --
> Best regards,
> Eugene



-- 
Best regards,
Eugene


From adrian at freebsd.org  Mon May 13 11:42:18 2013
From: adrian at freebsd.org (Adrian Chadd)
Date: Mon, 13 May 2013 08:42:18 -0700
Subject: updates - sorry, been on holidays!
Message-ID: <CAJ-VmokycXA651Ja++Gddn4WdUEXp-korajdY_2sO8Kq9XMChg@mail.gmail.com>

Hi!

Sorry I've been on holidays.

I'm going to cut another firmware build/release before I merge in a
bunch more fixes. I'll do that today.

I also messed up the submission to linux-firmware. I'll submit 1.3,
1.3.1 and 1.3.2 to linux-firmware sometime today or tonight.

I'll then merge in the work people have been doing.

Thanks,



Adrian


From k.eugene.e at gmail.com  Mon May 13 11:50:07 2013
From: k.eugene.e at gmail.com (Eugene Krasnikov)
Date: Mon, 13 May 2013 17:50:07 +0200
Subject: updates - sorry, been on holidays!
In-Reply-To: <CAJ-VmokycXA651Ja++Gddn4WdUEXp-korajdY_2sO8Kq9XMChg@mail.gmail.com>
References: <CAJ-VmokycXA651Ja++Gddn4WdUEXp-korajdY_2sO8Kq9XMChg@mail.gmail.com>
Message-ID: <CAFSJ42YeCXmRyyvvLMfUYC6t9n0ccoQetc6nUdJTLeiSoackxA@mail.gmail.com>

Hi Adrian,

Could you please also update with the plan forward? What are the next steps?

2013/5/13 Adrian Chadd <adrian at freebsd.org>:
> Hi!
>
> Sorry I've been on holidays.
>
> I'm going to cut another firmware build/release before I merge in a
> bunch more fixes. I'll do that today.
>
> I also messed up the submission to linux-firmware. I'll submit 1.3,
> 1.3.1 and 1.3.2 to linux-firmware sometime today or tonight.
>
> I'll then merge in the work people have been doing.
>
> Thanks,
>
>
>
> Adrian
>
> _______________________________________________
> ath9k_htc_fw mailing list
> ath9k_htc_fw at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath9k_htc_fw



-- 
Best regards,
Eugene


From adrian at freebsd.org  Mon May 13 11:58:39 2013
From: adrian at freebsd.org (Adrian Chadd)
Date: Mon, 13 May 2013 08:58:39 -0700
Subject: updates - sorry, been on holidays!
In-Reply-To: <CAFSJ42YeCXmRyyvvLMfUYC6t9n0ccoQetc6nUdJTLeiSoackxA@mail.gmail.com>
References: <CAJ-VmokycXA651Ja++Gddn4WdUEXp-korajdY_2sO8Kq9XMChg@mail.gmail.com>
 <CAFSJ42YeCXmRyyvvLMfUYC6t9n0ccoQetc6nUdJTLeiSoackxA@mail.gmail.com>
Message-ID: <CAJ-VmokGbkWiX3sNUMkE2Q-WYUZ6EE9KBrYurXY8r53gA9JM6A@mail.gmail.com>

On 13 May 2013 08:50, Eugene Krasnikov <k.eugene.e at gmail.com> wrote:
> Hi Adrian,
>
> Could you please also update with the plan forward? What are the next steps?

Whatever people decide they'd like to do.

I think we've kept things stable and sane for quite a while. We can
easily create a new branch to push forward more obtrusive changes. You
just have to coordinate with the ath9k / ath9k_htc driver. :)



Adrian


From greearb at candelatech.com  Mon May 13 12:09:35 2013
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 13 May 2013 09:09:35 -0700
Subject: updates - sorry, been on holidays!
In-Reply-To: <CAJ-VmokGbkWiX3sNUMkE2Q-WYUZ6EE9KBrYurXY8r53gA9JM6A@mail.gmail.com>
References: <CAJ-VmokycXA651Ja++Gddn4WdUEXp-korajdY_2sO8Kq9XMChg@mail.gmail.com>
 <CAFSJ42YeCXmRyyvvLMfUYC6t9n0ccoQetc6nUdJTLeiSoackxA@mail.gmail.com>
 <CAJ-VmokGbkWiX3sNUMkE2Q-WYUZ6EE9KBrYurXY8r53gA9JM6A@mail.gmail.com>
Message-ID: <5191103F.6030100@candelatech.com>

On 05/13/2013 08:58 AM, Adrian Chadd wrote:
> On 13 May 2013 08:50, Eugene Krasnikov <k.eugene.e at gmail.com> wrote:
>> Hi Adrian,
>>
>> Could you please also update with the plan forward? What are the next steps?
>
> Whatever people decide they'd like to do.
>
> I think we've kept things stable and sane for quite a while. We can
> easily create a new branch to push forward more obtrusive changes. You
> just have to coordinate with the ath9k / ath9k_htc driver. :)

Any idea if the firmware can reliably support more VIFs than just 2?

Thanks,
Ben

>
>
>
> Adrian
>
> _______________________________________________
> ath9k_htc_fw mailing list
> ath9k_htc_fw at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath9k_htc_fw
>


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From adrian at freebsd.org  Mon May 13 12:10:30 2013
From: adrian at freebsd.org (Adrian Chadd)
Date: Mon, 13 May 2013 09:10:30 -0700
Subject: updates - sorry, been on holidays!
In-Reply-To: <5191103F.6030100@candelatech.com>
References: <CAJ-VmokycXA651Ja++Gddn4WdUEXp-korajdY_2sO8Kq9XMChg@mail.gmail.com>
 <CAFSJ42YeCXmRyyvvLMfUYC6t9n0ccoQetc6nUdJTLeiSoackxA@mail.gmail.com>
 <CAJ-VmokGbkWiX3sNUMkE2Q-WYUZ6EE9KBrYurXY8r53gA9JM6A@mail.gmail.com>
 <5191103F.6030100@candelatech.com>
Message-ID: <CAJ-VmonbOy+MYnqFArfDfGuG=ST8CZpuJiPhgtaNyVxRn_uXZA@mail.gmail.com>

On 13 May 2013 09:09, Ben Greear <greearb at candelatech.com> wrote:

> Any idea if the firmware can reliably support more VIFs than just 2?
>

No idea. It's mostly a RAM resource issue.



Adrian


From greearb at candelatech.com  Mon May 13 12:26:30 2013
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 13 May 2013 09:26:30 -0700
Subject: updates - sorry, been on holidays!
In-Reply-To: <CAJ-VmonbOy+MYnqFArfDfGuG=ST8CZpuJiPhgtaNyVxRn_uXZA@mail.gmail.com>
References: <CAJ-VmokycXA651Ja++Gddn4WdUEXp-korajdY_2sO8Kq9XMChg@mail.gmail.com>
 <CAFSJ42YeCXmRyyvvLMfUYC6t9n0ccoQetc6nUdJTLeiSoackxA@mail.gmail.com>
 <CAJ-VmokGbkWiX3sNUMkE2Q-WYUZ6EE9KBrYurXY8r53gA9JM6A@mail.gmail.com>
 <5191103F.6030100@candelatech.com>
 <CAJ-VmonbOy+MYnqFArfDfGuG=ST8CZpuJiPhgtaNyVxRn_uXZA@mail.gmail.com>
Message-ID: <51911436.7010509@candelatech.com>

On 05/13/2013 09:10 AM, Adrian Chadd wrote:
> On 13 May 2013 09:09, Ben Greear <greearb at candelatech.com> wrote:
>
>> Any idea if the firmware can reliably support more VIFs than just 2?
>>
>
> No idea. It's mostly a RAM resource issue.

Well, just in case someone is interested in working on this
or other features that make it better for my testing efforts
(such as making the NO-HT restriction I posted about a few days
ago work), please contact me off the list.

Most of my effort needs to go towards more fully-featured
NICs, but it's hard to resist the open-firmware...and the
little TP-LINK WN722N adapters I've been using are actually
quite nice!

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From linux at rempel-privat.de  Fri May 17 04:07:00 2013
From: linux at rempel-privat.de (Oleksij Rempel)
Date: Fri, 17 May 2013 10:07:00 +0200
Subject: [ath9k-devel] ath9k_htc: Target is unresponsive
In-Reply-To: <20130517060042.GA21663@sig21.net>
References: <20130515134258.GA9033@zenon.in.qult.net>
 <5194DEB3.2060407@rempel-privat.de>
 <20130516172030.GD21850@zenon.in.qult.net> <51951B90.70909@rempel-privat.de>
 <20130516185030.GB16833@zenon.in.qult.net>
 <20130516234857.GA17867@zenon.in.qult.net>
 <20130516234526.GH3795@alittletooquiet.net>
 <20130517060042.GA21663@sig21.net>
Message-ID: <5195E524.8000508@rempel-privat.de>

Am 17.05.2013 08:00, schrieb Johannes Stezenbach:
> On Thu, May 16, 2013 at 07:45:26PM -0400, Forest Bond wrote:
>> On Fri, May 17, 2013 at 01:48:57AM +0200, Ignacy Gawedzki wrote:
>>> On Thu, May 16, 2013 at 08:50:30PM +0200, thus spake Ignacy Gawedzki:
>>>> I'll try on yet another one and will tell you the results.
>>>
>>> Just tried on ICH7, same thing.  The easiest way to reproduce the bug is to
>>> boot into single user mode ("recovery mode" on Ubuntu), in order to prevent
>>> any NetworkManager or udev from interfering.  Then, without any attempt to up
>>> the interface, reboot the system by typing "reboot" in a root shell.
>>
>> FWIW, this has also been a problem for me on Ubuntu 12.04.  I can reproduce it
>> the same way.
>
> FWIW, I also met this problem after I added ath9k_htc
> to my initrd (via /etc/initramfs-tools/modules).
> So I removed it and the issue went away.  I first
> noticed it after resume from suspend-to-disk, but
> later found it doesn't work after warm reboot, too.
> The mainboard has Intel H77 chipset, the TL-WN722N is
> plugged into USB2.0 port.

OK, now i was able to reproduce it on ar9271.
In attachment is the log i grubbed form adapter.
Lines starting with ######### are my comments

-- 
Regards,
Oleksij
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ath9k_htc.log
Type: text/x-log
Size: 6370 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath9k_htc_fw/attachments/20130517/223692c5/attachment.bin>

From linux at rempel-privat.de  Fri May 17 04:31:28 2013
From: linux at rempel-privat.de (Oleksij Rempel)
Date: Fri, 17 May 2013 10:31:28 +0200
Subject: [ath9k-devel] ath9k_htc: Target is unresponsive
In-Reply-To: <20130517081507.GA9673@zenon.in.qult.net>
References: <20130515134258.GA9033@zenon.in.qult.net>
 <5194DEB3.2060407@rempel-privat.de>
 <20130516172030.GD21850@zenon.in.qult.net> <51951B90.70909@rempel-privat.de>
 <20130516185030.GB16833@zenon.in.qult.net>
 <20130516234857.GA17867@zenon.in.qult.net>
 <20130516234526.GH3795@alittletooquiet.net>
 <20130517060042.GA21663@sig21.net> <5195E524.8000508@rempel-privat.de>
 <20130517081507.GA9673@zenon.in.qult.net>
Message-ID: <5195EAE0.7040403@rempel-privat.de>

Am 17.05.2013 10:15, schrieb Ignacy Gawedzki:
> On Fri, May 17, 2013 at 10:07:00AM +0200, thus spake Oleksij Rempel:
>> OK, now i was able to reproduce it on ar9271.
>
> Ah, good, but what did you do wrong previously then?

Nothing. I needed to start single user mode first, and reboot the system 
to et this error.

>
>> In attachment is the log i grubbed form adapter.
>> Lines starting with ######### are my comments
>
> At least we can already diagnose a problem with A_PRINTF. :/
>
> Do these logs speak to anyone?
>

Here are some explanations:
"ASIC-ROM_1.8" - is start of boot loader on device. It should go 
immediately after adapter got power.
"8. download" - at this stage bootloader is ready to receive firmware.
"[Tgt running" - firmware was downloaded and running.
"!USB suspend" - means usb suspend was initiated
And that is probably our problem.

-- 
Regards,
Oleksij


From k.eugene.e at gmail.com  Fri May 17 05:33:53 2013
From: k.eugene.e at gmail.com (Eugene Krasnikov)
Date: Fri, 17 May 2013 11:33:53 +0200
Subject: [ath9k-devel] ath9k_htc: Target is unresponsive
In-Reply-To: <5195EAE0.7040403@rempel-privat.de>
References: <20130515134258.GA9033@zenon.in.qult.net>
 <5194DEB3.2060407@rempel-privat.de>
 <20130516172030.GD21850@zenon.in.qult.net>
 <51951B90.70909@rempel-privat.de>
 <20130516185030.GB16833@zenon.in.qult.net>
 <20130516234857.GA17867@zenon.in.qult.net>
 <20130516234526.GH3795@alittletooquiet.net>
 <20130517060042.GA21663@sig21.net>
 <5195E524.8000508@rempel-privat.de>
 <20130517081507.GA9673@zenon.in.qult.net>
 <5195EAE0.7040403@rempel-privat.de>
Message-ID: <CAFSJ42a3Ap1HmtpnMQp=RJeY5UED=ESrR-s--fFR=_3MJCJ=8Q@mail.gmail.com>

Did anybody tried to force the usb to go to suspend? If something like
this "echo suspend | sudo tee /sys/bus/usb/devices/usb3/power/level"
will help to reproduce this issue?

2013/5/17 Oleksij Rempel <linux at rempel-privat.de>:
> Am 17.05.2013 10:15, schrieb Ignacy Gawedzki:
>
>> On Fri, May 17, 2013 at 10:07:00AM +0200, thus spake Oleksij Rempel:
>>>
>>> OK, now i was able to reproduce it on ar9271.
>>
>>
>> Ah, good, but what did you do wrong previously then?
>
>
> Nothing. I needed to start single user mode first, and reboot the system to
> et this error.
>
>
>>
>>> In attachment is the log i grubbed form adapter.
>>> Lines starting with ######### are my comments
>>
>>
>> At least we can already diagnose a problem with A_PRINTF. :/
>>
>> Do these logs speak to anyone?
>>
>
> Here are some explanations:
> "ASIC-ROM_1.8" - is start of boot loader on device. It should go immediately
> after adapter got power.
> "8. download" - at this stage bootloader is ready to receive firmware.
> "[Tgt running" - firmware was downloaded and running.
> "!USB suspend" - means usb suspend was initiated
> And that is probably our problem.
>
> --
> Regards,
> Oleksij



-- 
Best regards,
Eugene


From i at lri.fr  Fri May 17 06:40:47 2013
From: i at lri.fr (Ignacy Gawedzki)
Date: Fri, 17 May 2013 12:40:47 +0200
Subject: [ath9k-devel] ath9k_htc: Target is unresponsive
In-Reply-To: <20130517103034.GA13060@zenon.in.qult.net>
References: <51951B90.70909@rempel-privat.de>
 <20130516185030.GB16833@zenon.in.qult.net>
 <20130516234857.GA17867@zenon.in.qult.net>
 <20130516234526.GH3795@alittletooquiet.net>
 <20130517060042.GA21663@sig21.net>
 <5195E524.8000508@rempel-privat.de>
 <20130517081507.GA9673@zenon.in.qult.net>
 <5195EAE0.7040403@rempel-privat.de>
 <CAFSJ42a3Ap1HmtpnMQp=RJeY5UED=ESrR-s--fFR=_3MJCJ=8Q@mail.gmail.com>
 <20130517103034.GA13060@zenon.in.qult.net>
Message-ID: <20130517104047.GA14150@zenon.in.qult.net>

On Fri, May 17, 2013 at 12:30:34PM +0200, thus spake Ignacy Gawedzki:
> On Fri, May 17, 2013 at 11:33:53AM +0200, thus spake Eugene Krasnikov:
> > Did anybody tried to force the usb to go to suspend? If something like
> > this "echo suspend | sudo tee /sys/bus/usb/devices/usb3/power/level"
> > will help to reproduce this issue?
> 
> This way of forcing suspend is apparently deprecated and doesn't work in my
> case.  I tried to set power/control to auto, but it has no apparent effect on
> anything. :(

Okay, I did manage to make it fail.  In single-user mode (to prevent any
daemon from interfering), I plugged the dongle, set power/control to "auto"
and after a few seconds unloaded/reloaded the ath9k_htc module.  This made the
target unresponsive.  If I do the same without setting power/control to "auto"
(it is "on" by default), then unloading/reloading the module doesn't make the
device unresponsive.

BTW, Oleksij, just out of curiosity, how did you manage to solder those UART
pins?

-- 
I have not lost my mind, it's backed up on disk somewhere.


From linux at rempel-privat.de  Fri May 17 06:48:53 2013
From: linux at rempel-privat.de (Oleksij Rempel)
Date: Fri, 17 May 2013 12:48:53 +0200
Subject: [ath9k-devel] ath9k_htc: Target is unresponsive
In-Reply-To: <20130517104047.GA14150@zenon.in.qult.net>
References: <51951B90.70909@rempel-privat.de>
 <20130516185030.GB16833@zenon.in.qult.net>
 <20130516234857.GA17867@zenon.in.qult.net>
 <20130516234526.GH3795@alittletooquiet.net>
 <20130517060042.GA21663@sig21.net> <5195E524.8000508@rempel-privat.de>
 <20130517081507.GA9673@zenon.in.qult.net> <5195EAE0.7040403@rempel-privat.de>
 <CAFSJ42a3Ap1HmtpnMQp=RJeY5UED=ESrR-s--fFR=_3MJCJ=8Q@mail.gmail.com>
 <20130517103034.GA13060@zenon.in.qult.net>
 <20130517104047.GA14150@zenon.in.qult.net>
Message-ID: <51960B15.8030001@rempel-privat.de>

Am 17.05.2013 12:40, schrieb Ignacy Gawedzki:
> On Fri, May 17, 2013 at 12:30:34PM +0200, thus spake Ignacy Gawedzki:
>> On Fri, May 17, 2013 at 11:33:53AM +0200, thus spake Eugene Krasnikov:
>>> Did anybody tried to force the usb to go to suspend? If something like
>>> this "echo suspend | sudo tee /sys/bus/usb/devices/usb3/power/level"
>>> will help to reproduce this issue?
>>
>> This way of forcing suspend is apparently deprecated and doesn't work in my
>> case.  I tried to set power/control to auto, but it has no apparent effect on
>> anything. :(
>
> Okay, I did manage to make it fail.  In single-user mode (to prevent any
> daemon from interfering), I plugged the dongle, set power/control to "auto"
> and after a few seconds unloaded/reloaded the ath9k_htc module.  This made the
> target unresponsive.  If I do the same without setting power/control to "auto"
> (it is "on" by default), then unloading/reloading the module doesn't make the
> device unresponsive.
>
> BTW, Oleksij, just out of curiosity, how did you manage to solder those UART
> pins?
>

Here an example of soldered pins, it is ar7010 device. I attached here 
jtag pins.
https://plus.google.com/u/0/102032716864870215256/posts/hZoEq8bo3zk

here is a workaround for this issue, please test it:
https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend


-- 
Regards,
Oleksij


From i at lri.fr  Fri May 17 07:22:43 2013
From: i at lri.fr (Ignacy Gawedzki)
Date: Fri, 17 May 2013 13:22:43 +0200
Subject: [ath9k-devel] ath9k_htc: Target is unresponsive
In-Reply-To: <51960B15.8030001@rempel-privat.de>
References: <20130516234857.GA17867@zenon.in.qult.net>
 <20130516234526.GH3795@alittletooquiet.net>
 <20130517060042.GA21663@sig21.net>
 <5195E524.8000508@rempel-privat.de>
 <20130517081507.GA9673@zenon.in.qult.net>
 <5195EAE0.7040403@rempel-privat.de>
 <CAFSJ42a3Ap1HmtpnMQp=RJeY5UED=ESrR-s--fFR=_3MJCJ=8Q@mail.gmail.com>
 <20130517103034.GA13060@zenon.in.qult.net>
 <20130517104047.GA14150@zenon.in.qult.net>
 <51960B15.8030001@rempel-privat.de>
Message-ID: <20130517112243.GA15539@zenon.in.qult.net>

On Fri, May 17, 2013 at 12:48:53PM +0200, thus spake Oleksij Rempel:
> Here an example of soldered pins, it is ar7010 device. I attached
> here jtag pins.
> https://plus.google.com/u/0/102032716864870215256/posts/hZoEq8bo3zk

Wow, my soldering iron has too broad a tip for that precision work. :/

> here is a workaround for this issue, please test it:
> https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend

It seems to work just right on the PC.  I'll test on the RPi and let you know.

Big thanks!

-- 
:wq!


From i at lri.fr  Fri May 17 07:41:35 2013
From: i at lri.fr (Ignacy Gawedzki)
Date: Fri, 17 May 2013 13:41:35 +0200
Subject: [ath9k-devel] ath9k_htc: Target is unresponsive
In-Reply-To: <20130517112243.GA15539@zenon.in.qult.net>
References: <20130516234526.GH3795@alittletooquiet.net>
 <20130517060042.GA21663@sig21.net>
 <5195E524.8000508@rempel-privat.de>
 <20130517081507.GA9673@zenon.in.qult.net>
 <5195EAE0.7040403@rempel-privat.de>
 <CAFSJ42a3Ap1HmtpnMQp=RJeY5UED=ESrR-s--fFR=_3MJCJ=8Q@mail.gmail.com>
 <20130517103034.GA13060@zenon.in.qult.net>
 <20130517104047.GA14150@zenon.in.qult.net>
 <51960B15.8030001@rempel-privat.de>
 <20130517112243.GA15539@zenon.in.qult.net>
Message-ID: <20130517114135.GA16784@zenon.in.qult.net>

On Fri, May 17, 2013 at 01:22:43PM +0200, thus spake Ignacy Gawedzki:
> On Fri, May 17, 2013 at 12:48:53PM +0200, thus spake Oleksij Rempel:
> > Here an example of soldered pins, it is ar7010 device. I attached
> > here jtag pins.
> > https://plus.google.com/u/0/102032716864870215256/posts/hZoEq8bo3zk
> 
> Wow, my soldering iron has too broad a tip for that precision work. :/
> 
> > here is a workaround for this issue, please test it:
> > https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend
> 
> It seems to work just right on the PC.  I'll test on the RPi and let you know.

Works on the RPi as well!  Are there any implications for this being a
workaround and not a proper fix?

-- 
Sex on TV doesn't hurt....unless you fall off.


From linux at rempel-privat.de  Fri May 17 08:00:25 2013
From: linux at rempel-privat.de (Oleksij Rempel)
Date: Fri, 17 May 2013 14:00:25 +0200
Subject: [ath9k-devel] ath9k_htc: Target is unresponsive
In-Reply-To: <20130517114135.GA16784@zenon.in.qult.net>
References: <20130516234526.GH3795@alittletooquiet.net>
 <20130517060042.GA21663@sig21.net> <5195E524.8000508@rempel-privat.de>
 <20130517081507.GA9673@zenon.in.qult.net> <5195EAE0.7040403@rempel-privat.de>
 <CAFSJ42a3Ap1HmtpnMQp=RJeY5UED=ESrR-s--fFR=_3MJCJ=8Q@mail.gmail.com>
 <20130517103034.GA13060@zenon.in.qult.net>
 <20130517104047.GA14150@zenon.in.qult.net>
 <51960B15.8030001@rempel-privat.de>
 <20130517112243.GA15539@zenon.in.qult.net>
 <20130517114135.GA16784@zenon.in.qult.net>
Message-ID: <51961BD9.6050300@rempel-privat.de>

Am 17.05.2013 13:41, schrieb Ignacy Gawedzki:
> On Fri, May 17, 2013 at 01:22:43PM +0200, thus spake Ignacy Gawedzki:
>> On Fri, May 17, 2013 at 12:48:53PM +0200, thus spake Oleksij Rempel:
>>> Here an example of soldered pins, it is ar7010 device. I attached
>>> here jtag pins.
>>> https://plus.google.com/u/0/102032716864870215256/posts/hZoEq8bo3zk
>>
>> Wow, my soldering iron has too broad a tip for that precision work. :/
>>
>>> here is a workaround for this issue, please test it:
>>> https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend
>>
>> It seems to work just right on the PC.  I'll test on the RPi and let you know.
>
> Works on the RPi as well!  Are there any implications for this being a
> workaround and not a proper fix?

Yes, i do not know what i did. I will need to find out, what it actually 
should do.


-- 
Regards,
Oleksij


From adrian at freebsd.org  Fri May 17 11:37:22 2013
From: adrian at freebsd.org (Adrian Chadd)
Date: Fri, 17 May 2013 08:37:22 -0700
Subject: [ath9k-devel] ath9k_htc: Target is unresponsive
In-Reply-To: <51961BD9.6050300@rempel-privat.de>
References: <20130516234526.GH3795@alittletooquiet.net>
 <20130517060042.GA21663@sig21.net>
 <5195E524.8000508@rempel-privat.de>
 <20130517081507.GA9673@zenon.in.qult.net>
 <5195EAE0.7040403@rempel-privat.de>
 <CAFSJ42a3Ap1HmtpnMQp=RJeY5UED=ESrR-s--fFR=_3MJCJ=8Q@mail.gmail.com>
 <20130517103034.GA13060@zenon.in.qult.net>
 <20130517104047.GA14150@zenon.in.qult.net>
 <51960B15.8030001@rempel-privat.de>
 <20130517112243.GA15539@zenon.in.qult.net>
 <20130517114135.GA16784@zenon.in.qult.net>
 <51961BD9.6050300@rempel-privat.de>
Message-ID: <CAJ-Vmo=X3n0UY62RHzVSpi+XUTYeNNdjLYY1rr1o6Ds1gK6E4Q@mail.gmail.com>

On 17 May 2013 05:00, Oleksij Rempel <linux at rempel-privat.de> wrote:

>>>> here is a workaround for this issue, please test it:
>>>> https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend
>>>
>>> It seems to work just right on the PC.  I'll test on the RPi and let you know.
>>
>> Works on the RPi as well!  Are there any implications for this being a
>> workaround and not a proper fix?
>
> Yes, i do not know what i did. I will need to find out, what it actually
> should do.

... hm, is this reset type not working? Is this the whole "reset
through watchdog" versus "reset through reset" thing you talked about
a couple weeks ago?



Adrian


From linux at rempel-privat.de  Fri May 17 14:51:16 2013
From: linux at rempel-privat.de (Oleksij Rempel)
Date: Fri, 17 May 2013 20:51:16 +0200
Subject: [ath9k-devel] ath9k_htc: Target is unresponsive
In-Reply-To: <CAJ-Vmo=X3n0UY62RHzVSpi+XUTYeNNdjLYY1rr1o6Ds1gK6E4Q@mail.gmail.com>
References: <20130516234526.GH3795@alittletooquiet.net>
 <20130517060042.GA21663@sig21.net> <5195E524.8000508@rempel-privat.de>
 <20130517081507.GA9673@zenon.in.qult.net> <5195EAE0.7040403@rempel-privat.de>
 <CAFSJ42a3Ap1HmtpnMQp=RJeY5UED=ESrR-s--fFR=_3MJCJ=8Q@mail.gmail.com>
 <20130517103034.GA13060@zenon.in.qult.net>
 <20130517104047.GA14150@zenon.in.qult.net>
 <51960B15.8030001@rempel-privat.de>
 <20130517112243.GA15539@zenon.in.qult.net>
 <20130517114135.GA16784@zenon.in.qult.net>
 <51961BD9.6050300@rempel-privat.de>
 <CAJ-Vmo=X3n0UY62RHzVSpi+XUTYeNNdjLYY1rr1o6Ds1gK6E4Q@mail.gmail.com>
Message-ID: <51967C24.1010508@rempel-privat.de>

Am 17.05.2013 17:37, schrieb Adrian Chadd:
> On 17 May 2013 05:00, Oleksij Rempel <linux at rempel-privat.de> wrote:
>
>>>>> here is a workaround for this issue, please test it:
>>>>> https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend
>>>>
>>>> It seems to work just right on the PC.  I'll test on the RPi and let you know.
>>>
>>> Works on the RPi as well!  Are there any implications for this being a
>>> workaround and not a proper fix?
>>
>> Yes, i do not know what i did. I will need to find out, what it actually
>> should do.
>
> ... hm, is this reset type not working? Is this the whole "reset
> through watchdog" versus "reset through reset" thing you talked about
> a couple weeks ago?

No, it is different issue, at least at different path.
I did some more test and i'll try now to reflect all collected informations:
- Only ar9271 devices are affected. ar7010 seems to be fine.
- the issue is in:
target_firmware/magpie_fw_dev/target/hif/k2_fw_usb_api.c:
in _fw_usb_suspend_reboot()

this function is called from two points:
- _fw_usbfifo_recv_command(), this one is triggered if host go to supend
- _fw_usb_fw_task(), this function is called on different events, 
including reset, some cases if suspend? and resume? last was never 
called. I'll need to check how exactly this part is working.

So,  _fw_usb_suspend_reboot() should theoretically prepare adapter for 
suspend, to reduce power consumption. But there are fallowing problems 
with this function:
- some hosts will completely power down this device. Absolutely no power 
is consumed and all preparations made by this function are lost (cald 
reset).
- some hosts keep usb port powered to be able to charge some device. It 
is done only on laptops/pcs connected to power supply (i have one of 
this, so i was able to check it). In this case we go to some undefined 
state, and probably prepared to receive firmware.  In this state device 
use about 40mA.
- in all cases linux will do reset on resume. So all side effects 
produced by _fw_usb_suspend_reboot() are reseted. This is why it is so 
hard to reproduce this case.

The problem what we now have is passed from _fw_usb_fw_task(), in this 
case adapter will restart to boot loader and got ready to receive 
firmware. But it looks like usb descriptor in this case is incomplete:

here is brocken descriptor:
Bus 003 Device 002: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n
Device Descriptor:
   bLength                18
   bDescriptorType         1
   bcdUSB               2.00
   bDeviceClass          255 Vendor Specific Class
   bDeviceSubClass       255 Vendor Specific Subclass
   bDeviceProtocol       255 Vendor Specific Protocol
   bMaxPacketSize0        64
   idVendor           0x0cf3 Atheros Communications, Inc.
   idProduct          0x9271 AR9271 802.11n
   bcdDevice            1.08
   iManufacturer          16
   iProduct               32
   iSerial                48
   bNumConfigurations      1
---end---


here is ok descriptor:

Bus 003 Device 003: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n
Device Descriptor:
   bLength                18
   bDescriptorType         1
   bcdUSB               2.00
   bDeviceClass          255 Vendor Specific Class
   bDeviceSubClass       255 Vendor Specific Subclass
   bDeviceProtocol       255 Vendor Specific Protocol
   bMaxPacketSize0        64
   idVendor           0x0cf3 Atheros Communications, Inc.
   idProduct          0x9271 AR9271 802.11n
   bcdDevice            1.08
   iManufacturer          16 ATHEROS
   iProduct               32 UB91C
   iSerial                48 12345
   bNumConfigurations      1
   Configuration Descriptor:
     bLength                 9
     bDescriptorType         2
     wTotalLength           60
     bNumInterfaces          1
     bConfigurationValue     1
     iConfiguration          0
     bmAttributes         0x80
       (Bus Powered)
     MaxPower              500mA
--- and some more --------


after i disabled this function... see my workaround patch. I got 
fallowing process. Host send suspend command.... no changes was made, 
(currently i do not know what should we send as response), host trying 
to send it some more times and the send reset. After this, adapter is 
rebooting and firmware is uploaded... so it comes to normal working state.

There is no way to support WoW here. So, there is no need to have some 
sort of reduced power state. I assume, we can remove most part of 
suspend sequence from firmware. And replace it with some correct 
response to the host that every thing is ok, or that we do not support 
this bit.
-- 
Regards,
Oleksij


From i at lri.fr  Fri May 17 04:15:07 2013
From: i at lri.fr (Ignacy Gawedzki)
Date: Fri, 17 May 2013 10:15:07 +0200
Subject: [ath9k-devel] ath9k_htc: Target is unresponsive
In-Reply-To: <5195E524.8000508@rempel-privat.de>
References: <20130515134258.GA9033@zenon.in.qult.net>
 <5194DEB3.2060407@rempel-privat.de>
 <20130516172030.GD21850@zenon.in.qult.net>
 <51951B90.70909@rempel-privat.de>
 <20130516185030.GB16833@zenon.in.qult.net>
 <20130516234857.GA17867@zenon.in.qult.net>
 <20130516234526.GH3795@alittletooquiet.net>
 <20130517060042.GA21663@sig21.net>
 <5195E524.8000508@rempel-privat.de>
Message-ID: <20130517081507.GA9673@zenon.in.qult.net>

On Fri, May 17, 2013 at 10:07:00AM +0200, thus spake Oleksij Rempel:
> OK, now i was able to reproduce it on ar9271.

Ah, good, but what did you do wrong previously then?

> In attachment is the log i grubbed form adapter.
> Lines starting with ######### are my comments

At least we can already diagnose a problem with A_PRINTF. :/

Do these logs speak to anyone?

-- 
/* This is not a comment */


From i at lri.fr  Fri May 17 06:30:34 2013
From: i at lri.fr (Ignacy Gawedzki)
Date: Fri, 17 May 2013 12:30:34 +0200
Subject: [ath9k-devel] ath9k_htc: Target is unresponsive
In-Reply-To: <CAFSJ42a3Ap1HmtpnMQp=RJeY5UED=ESrR-s--fFR=_3MJCJ=8Q@mail.gmail.com>
References: <20130516172030.GD21850@zenon.in.qult.net>
 <51951B90.70909@rempel-privat.de>
 <20130516185030.GB16833@zenon.in.qult.net>
 <20130516234857.GA17867@zenon.in.qult.net>
 <20130516234526.GH3795@alittletooquiet.net>
 <20130517060042.GA21663@sig21.net>
 <5195E524.8000508@rempel-privat.de>
 <20130517081507.GA9673@zenon.in.qult.net>
 <5195EAE0.7040403@rempel-privat.de>
 <CAFSJ42a3Ap1HmtpnMQp=RJeY5UED=ESrR-s--fFR=_3MJCJ=8Q@mail.gmail.com>
Message-ID: <20130517103034.GA13060@zenon.in.qult.net>

On Fri, May 17, 2013 at 11:33:53AM +0200, thus spake Eugene Krasnikov:
> Did anybody tried to force the usb to go to suspend? If something like
> this "echo suspend | sudo tee /sys/bus/usb/devices/usb3/power/level"
> will help to reproduce this issue?

This way of forcing suspend is apparently deprecated and doesn't work in my
case.  I tried to set power/control to auto, but it has no apparent effect on
anything. :(

-- 
I drive too fast to worry about cholesterol.


