From brucembeach at gmail.com  Tue Mar  1 20:21:32 2016
From: brucembeach at gmail.com (bruce m beach)
Date: Tue, 1 Mar 2016 20:21:32 -0800
Subject: remote talking to AR9271
Message-ID: <CAArymCnX7wO-R3_rPAeMXhPp1vg6t6On1pbvsaMs6zDBROwKCg@mail.gmail.com>

> Do not worry to match about "how". Just create patches on
> your personal branch.  Try to do one patch per issue,
> describe what you do and why in the patch and if you think
> "it's time", then do a pull request.

Well I did the first patch on a branch I have locally, that
was no problem, but with the pull request I'm stumped, I
click on the "new pull request" and just don't get anything
that I'm expecting like some kind of form to fill in. Maybe
my brain has turned to mush from doing reverse engineering
all winter. First trying to get the sound working on the
samsung chromebook, which I acomplished and now working on this
project. My own tree that I'm using is quite a bit different
than the one at:
https://github.com/qca/open-ath9k-htc-firmware.git.
What I have done is remove the whole cmake hierarchy
and replaced it with 1 makefile (120 lines), moved all the
c-files(with merging of some of them) into a single
directory with all the include files in a single
subdirectory. This simplifies things a lot. I still have a
some more things like fix up the include files more,
remove some of the protocol layers and rename a lot of the
variables (I've been making a K2 tree only)  but for a
change of pace for the next while I'm going to work on
getting an independent usb link from userland to some
independent code running in the xtensa, hopefully interupt
driven (no dma) to keep it simple as possible. The two
candidates are

1 endpoint 0
2 endpoints 5 and 6 since they are unused.

I'll already have the userland program running which
currently crashes the firmware, which is okay because what I
wanted to find out is if the kernel would somehow block the
opening of the usb file descriptor but apparently not.

Bruce


From linux at rempel-privat.de  Tue Mar  1 20:34:50 2016
From: linux at rempel-privat.de (Oleksij Rempel)
Date: Wed, 2 Mar 2016 05:34:50 +0100
Subject: remote talking to AR9271
In-Reply-To: <CAArymCnX7wO-R3_rPAeMXhPp1vg6t6On1pbvsaMs6zDBROwKCg@mail.gmail.com>
References: <CAArymCnX7wO-R3_rPAeMXhPp1vg6t6On1pbvsaMs6zDBROwKCg@mail.gmail.com>
Message-ID: <56D66D6A.8020008@rempel-privat.de>

Am 02.03.2016 um 05:21 schrieb bruce m beach:
>> Do not worry to match about "how". Just create patches on
>> your personal branch.  Try to do one patch per issue,
>> describe what you do and why in the patch and if you think
>> "it's time", then do a pull request.
> 
> Well I did the first patch on a branch I have locally, that
> was no problem, but with the pull request I'm stumped, I
> click on the "new pull request" and just don't get anything
> that I'm expecting like some kind of form to fill in. Maybe
> my brain has turned to mush from doing reverse engineering
> all winter. First trying to get the sound working on the
> samsung chromebook, which I acomplished and now working on this
> project. 

Usually it works as fallow. You go to
https://github.com/qca/open-ath9k-htc-firmware.git and create a fork
(see fork button). Then you working with your own copy of repository.
Create local branch with name "fixes" or what ever then use github
interface to choice new branch and choice button pull request.
On youtube there are lots of tutorial for that.

> My own tree that I'm using is quite a bit different
> than the one at:
> https://github.com/qca/open-ath9k-htc-firmware.git.
> What I have done is remove the whole cmake hierarchy
> and replaced it with 1 makefile (120 lines), moved all the
> c-files(with merging of some of them) into a single
> directory with all the include files in a single
> subdirectory. This simplifies things a lot. I still have a
> some more things like fix up the include files more,
> remove some of the protocol layers and rename a lot of the
> variables (I've been making a K2 tree only)  but for a
> change of pace for the next while I'm going to work on
> getting an independent usb link from userland to some
> independent code running in the xtensa, hopefully interupt
> driven (no dma) to keep it simple as possible. The two
> candidates are
> 
> 1 endpoint 0
> 2 endpoints 5 and 6 since they are unused.

It would be interesting if you will find out how to use EP5 and 6 :)
According to the code they can be used to manage priorities.

> I'll already have the userland program running which
> currently crashes the firmware, which is okay because what I
> wanted to find out is if the kernel would somehow block the
> opening of the usb file descriptor but apparently not.
> 
> Bruce
> 


-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/ath9k_htc_fw/attachments/20160302/c72e737e/attachment.sig>

From brucembeach at gmail.com  Wed Mar  2 20:24:04 2016
From: brucembeach at gmail.com (bruce m beach)
Date: Wed, 2 Mar 2016 20:24:04 -0800
Subject: remote talking to AR9271
Message-ID: <CAArymCkQD54Y22gX2GBw2XjFN1uaPahTY4H7MpLPsXiO+9zv4A@mail.gmail.com>

>> Usually it works as followw. You go to https://github.com ..

  Well I made a fork https ...._fixes. I assume that I can
make the changes locally, somehow push the tree back onto
githup and then I can make the pull request. I'll try that
tomorrow and eventually get it working.  I guess I should be
thinking of getting these big changes that I am makeing onto
github.

> It would be interesting if you will find out how to use EP5 and 6 :)
> According to the code they can be used to manage priorities.

After looking at it all day, it still looks reasonable. The
USB seems to be set up in ROM so parts of the USB would have
to be reconfigured in one of the init files in firmware, a
interupt handler set up, which would sit and wait for data
to come in. We'll see after a few weeks how it is going.
I assume that the only data sheet for the fusb200 that you
have is the same as I have: FUSB200_ProductBrief_v1_2.pdf?

Bruce

Ps what do you mean "According to the code they can be used
to manage priorities" ?


From adrian at freebsd.org  Thu Mar  3 09:16:24 2016
From: adrian at freebsd.org (Adrian Chadd)
Date: Thu, 3 Mar 2016 09:16:24 -0800
Subject: remote talking to AR9271
In-Reply-To: <CAArymCkQD54Y22gX2GBw2XjFN1uaPahTY4H7MpLPsXiO+9zv4A@mail.gmail.com>
References: <CAArymCkQD54Y22gX2GBw2XjFN1uaPahTY4H7MpLPsXiO+9zv4A@mail.gmail.com>
Message-ID: <CAJ-VmomRyvLdTHv0CbB0jQ8gNzseE=fGphV27vbbTzTmPHn-Tw@mail.gmail.com>

IIRC, the general idea behind those EPs was to do different levels of
traffic QoS, but nothing was ever implemented.

Just remember, if you add an EP, you have to service it, or the other
EPs don't make progress. :)


-a


From brucembeach at gmail.com  Thu Mar  3 20:21:30 2016
From: brucembeach at gmail.com (bruce m beach)
Date: Thu, 3 Mar 2016 20:21:30 -0800
Subject: remote talking to AR9271
Message-ID: <CAArymC=hE4a8_4PPG54hB3A_qkyVVibXtUr_Af7R8xao7X=Rhw@mail.gmail.com>

Hello Adrian

>> IIRC, the general idea behind those EPs was to do
>> different levels of traffic QoS, but nothing was ever
>> implemented.

>> Just remember, if you add an EP, you have to service it,
>> or the other EPs don't make progress. :)

Yes but right now I'm trying to do something much more
modest. It might help to see what I'm targeting. I see these
chips (in this case the AR9271) as extraordinarily usefull
building blocks. A few hours with a soldering iron and you
could make all sorts of useful and interesting devices other
than just shoving it in a computer and useing it get on a
net. But to do this I'll need a fairly deep understanding
for which I imagine will take about a year. Although after
all some people pay $30 to see a 2 hour movie, whereas here
for a mere 15 bucks theres a whole years worth of
enterainment.  If I find out things useful for everybody
else then so much the better.

Heres the particlar crack that I'm trying to drive a wedge
into. With the kernel driver and the firmware in place and
running I want to have a couple of new unused endpoints set
up (IN OUT ). Now from userland ( using libusb ) I want to
send a command, have the firmware respond by writing
something,anything to the host's IN buffer, go and get that
something,anything and then I'm done. All completely
independant of the kernel driver functioning with the
firmware. That is all.

If I can do this with any unused endpoint then I can do it
with endpoints 5 and 6, which would at least demonstrate
that they are working.

Bruce


From brucembeach at gmail.com  Mon Mar  7 20:14:02 2016
From: brucembeach at gmail.com (bruce m beach)
Date: Mon, 7 Mar 2016 20:14:02 -0800
Subject: remote talking to AR9271
Message-ID: <CAArymCn1mQU87CMddY_auPrnORog_FXLuhGY=X0fd=4Vv9axRA@mail.gmail.com>

Hello Oleksij

I'm progressing on getting a usb link to userland. In
app_start.c I have a function setup_ep(.... ) at the end of
the file just before wlan_task(), where you supply some
parameters and the ep that you want is set up. If the code
actually gets executed it at least doesn't crash the
firmware since I'm on the net right now with it. (I set up
endpoint 13). What I'm looking for is where the interrupt
source registers are processed. It looks like it takes place
in the rom, but that I can intercept the proccessing through

usb_api_k2_patch.c

Does this seem likely, and if so where would be the best
place to put a branch to my handler?

Bruce


