I have ethernet driver experience but not wifi. I have a project to
add some features to the ar9170 that will require additions to the
firmware. I would appreciate pointers for docs etc. to get me started.
What is available for the ar9170 itself ?
How does the firmware and the linux driver communicate?
Is there an overview of the firmware - what is where ?
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 [email protected] http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
On 05/22/2010 09:34 PM, Christian Lamparter wrote:
>> I beleive the timer_init() routine in carlfw/src/timer.c can not be
>> called for more than one timer. Any subsequent call will clear the
>> interrupt and mode bits for the previous timer.
>>
> there's more than that.
> Take a look at the (timer<< 2) and so forth...
>
The control and interrupt registers are bitmasks.
When you set the bit for the current timer you are clearing all the
others.
> based on observation: Some timers(1-4) are *driven* by the cpu clock.
> Which is of course determined by the operation mode and phy band.
> As you know there are 7 (1 + 2 * 3) possible AHB/CPU clock settings:
> * 40MHz (refclock)
> * 20MHz (PSM, 5GHz)& 22MHz (PSM, 2.4GHz)
> * 40MHz (11an, 5GHz, HT20)& 44Mhz (11bgn, 2.4GHz, HT20)
> * 80MHz (11an, 5GHz, HT40)& 88MHz (11bgn, 2.4GHz, HT40)
>
Thanks I have been working alot more with the timers today.
TSF follows the docs and is 1us.
My docs say that CCR is 25ns and only 16 bit.
But your code and that of the original ar9710-fw has it as 2 16 bit
registers making 32bits.
I have verified that and verified that it is pretty close to 25ns.
in my system.
But the remainder of the timers seem to be much much slower. My dos
do not specify that they are tied to anything specific.
I tripped over the AHB/CPU clock in the code. I need to look much
more thoroughly at that, and I am going to need to work out exactly how
it effects the other timers. I need the fastest timer I can get for my
application.
Thanks alot.
i will pull 1.0.9.1 shortly
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 [email protected] http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
On Sunday 02 May 2010 13:14:59 David H. Lynch Jr. wrote:
> On 05/02/2010 03:47 AM, Benoit Papillault wrote:
> > Le 01/05/2010 22:45, Christian Lamparter a ?crit :
> >> On Saturday 01 May 2010 20:23:26 David H. Lynch Jr. wrote:
> >>> I think I can tell you what I am supposed add - I need to be able
> >>> to provide userspace apps with precise timing information for each
> >>> packet.
> >>> Since i am working on GPL'd code and the results are going to be
> >>> provided to third parties whatever I do is GPL'd too.
> >>
> >> if by precise timing you mean "exact mac time in TU/usecs when frame
> >> was received at the radio", then you might have a _problem_.
> >> You see, the firmware already receives fully packed frames from
> >> the MAC processor and only _forwards_ them all [as is] in
> >> one big DMA to the USB subsystem.
> >> (this is done in src/wlan.c handle_rx())
> >>
> >> So, unless the HW has a _magic_ flag to enable this capability...
> >> you are sort of screwed :-/.
> >
> > I would love this feature as well. I have a device to test if that can
> > help. I share the feeling of Christian however... but maybe your
> > documentation says something about a special flag.
> I am interested in round trip time as measured from some fixed point
> in the sending process to some fixed point in the packet acknowledgement.
> The more accurate the better. Preferably measured by events at the
> radio rather than on the linux side.
> I am interested in tx packets rather than rx packets.
ahh, well... there goes' benoit interest ;).
> If necessary I can measure the times myself as delta's from one
> event to another withing the SH2.
>
> I have not digested the docs I have thoroughly yet but a cursory
> review suggests a less than trivial project.
> I have not yet found a good high resolution clock inside the ar9170
> there are alot of clocks but they all seem to be 16bit. Probably that
> will make things harder.
TSF timer could be used for this. (see 802.11-2007, Section 11 et seq.)
It's a 2^64 bit timer with a 1us resolution and a accuracy _better_
or equal to +/- 0.01%.
The register address are at:
- 0x1c3514 (low, AR9170_MAC_REG_TSF_L, read only)
- 0x1c3518 (high, AR9170_MAC_REG_TSF_H, read only)
But it comes at a small price: this timer is sometimes
update & synchronized (802.11 11.1.3.4 and 11.1.4) in
station or ad-hoc mode. The exact details are hidden
inside MAC chip, but it should be possible to disable
both by selecting the monitor mode.
> I was expecting to have to make changes to the ar9170 firmware. I
> was expecting to have to devise some means of passing that information
> to the Linux driver and to the userspace application.
Well, then you have two more good reasons why to use carl9170:
* the ar9170usb driver and ar9170 firmware don't track tx frames.
carl9170 on the other hand does (every frame has a 8 bit "cookie").
This feature was necessary to generate an accurate tx transmission
feedback report for every individual frame for the driver.
* carl9170 has the ability to store additional per-frame data.
In fact, if you don't need to have a different retry rates
you could realloc the 3 * 32 bit "rr" (as in retry rate)
array in the carl9170_tx_superdesc and _carl9170_tx_superdesc
struct (see wlan.h) for your purposes (storage for your time values).
And if you fetched all the data, everything will be sent
with an ordinary tx status feedback report to the application
(add the timer fields into carl9170_tx_status and _carl9170_tx_status
struct - see fwcmd.h)
(* talked about this earlier, but you never know...
carlu _tool_ already provides a low-level HW driver for userspace.
This has the obvious advantage that you won't need to mess with
the kernel driver and network stacks.
The only work you'll have to do is: get the kernel code for
the MAC & PHY initialization and put it into carlu.
But the framework is already there so it's mostly copy + paste )
> I would be happy to do that in some fashion that conformed to an existing
> or future standard, but I was not anticipating a broad desire for what I am
> doing. Variable latencies are highly undesirable in this application,
> but the userspace application will be aggregating large amounts of
> information, if latencies in what is measured are constrained and the
> unit of time measurement is small enough everything will work.
> If it comes to that we switch to different hardware, but my project
> is bringing a concept that was demonstrated with an expensive SDR to an
> ar9170.
It's always nice to have some "added value" for cheap and generic devices.
e.g.: Atheros AR92xx chips can be used as among other stuff as a
full range spectrum analyzer.
Regards,
Chr
On Saturday 01 May 2010 20:23:26 David H. Lynch Jr. wrote:
> On 05/01/2010 01:19 PM, Christian Lamparter wrote:
> >
> > Well, for starters the ar9170 uses a ZyDas MAC (aka ZD1221)
> > and a AR900x PHY/Radio. Therefore the phy code and registers
> > are very similar to those #definitions you can find in ath9k.
> > And for the MAC code& registers you can look into zd1211rw,
> > or look into drivers/staging/otus (original vendor driver,
> > shares some code with their windows drivers)
> >
> > AFAICT, there are no technical documents about the AR9170
> > solution available w/o signing a NDA with Atheros
> > (probably because the devices are still produced and sold in high quantities?).
> >
> Thanks;
>
> I did just discover a reasonably good 150p spec. In what I received from
> my client. If I can I will share it. I am under an NDA, but the client also
> told me that they received no cooperation from atheros.
hmm, only 150 pages? That's sounds a bit thin, as a matter of
fact I know that the ath5k docs (rf+mac+eeprom) are at least
around 300-400 pages.
Well, we'll see. But just in case, we already have a small
library of hardware docs (but most from different vendors):
http://wireless.kernel.org/en/developers/Documentation/specs
and we would welcome such an addition ;-)
> >> What is available for the ar9170 itself ?
> >> How does the firmware and the linux driver communicate?
> >> Is there an overview of the firmware - what is where ?
> >>
> > not really, apart from the headers of the original firmware
> > and vendor drivers.
> >
> > But if you really need to implement some of your 'features'
> > (what are they, if I may ask?)
>
> I think I can tell you what I am supposed add - I need to be able
> to provide userspace apps with precise timing information for each packet.
> Since i am working on GPL'd code and the results are going to be
> provided to third parties whatever I do is GPL'd too.
if by precise timing you mean "exact mac time in TU/usecs when frame
was received at the radio", then you might have a _problem_.
You see, the firmware already receives fully packed frames from
the MAC processor and only _forwards_ them all [as is] in
one big DMA to the USB subsystem.
(this is done in src/wlan.c handle_rx())
So, unless the HW has a _magic_ flag to enable this capability...
you are sort of screwed :-/.
> Why gets into the NDA.
> Right now i have an NDA with a new client and though I am
> exercising care. But they seem fairly mellow. I am probably just being
> overly cautious.
k, understood.
On Wednesday 12 May 2010 00:02:03 David H. Lynch Jr. wrote:
> On 05/02/2010 08:52 AM, Christian Lamparter wrote:
> > Well, then you have two more good reasons why to use carl9170:
> > * carl9170 has the ability to store additional per-frame data.
> > In fact, if you don't need to have a different retry rates
> > you could realloc the 3 * 32 bit "rr" (as in retry rate)
> > array in the carl9170_tx_superdesc and _carl9170_tx_superdesc
> > struct (see wlan.h) for your purposes (storage for your time values).
> >
> > And if you fetched all the data, everything will be sent
> > with an ordinary tx status feedback report to the application
> > (add the timer fields into carl9170_tx_status and _carl9170_tx_status
> > struct - see fwcmd.h)
> cmd.h __check() tests for sizeof(carl9170_tx_status) != 2
> is there an assumption somewhere that carl9170_tx_status == 2 ?
good catch!
I have now replace some of those meaningless numerical values with
precalculated #defines *_SIZE.
This way, firmware and drivers can verify the structs sizes
and check whenever the compiler really did what it was supposed
to do.
Regards,
Chr
Le 01/05/2010 22:45, Christian Lamparter a ?crit :
> On Saturday 01 May 2010 20:23:26 David H. Lynch Jr. wrote:
>> I think I can tell you what I am supposed add - I need to be able
>> to provide userspace apps with precise timing information for each packet.
>> Since i am working on GPL'd code and the results are going to be
>> provided to third parties whatever I do is GPL'd too.
>
> if by precise timing you mean "exact mac time in TU/usecs when frame
> was received at the radio", then you might have a _problem_.
> You see, the firmware already receives fully packed frames from
> the MAC processor and only _forwards_ them all [as is] in
> one big DMA to the USB subsystem.
> (this is done in src/wlan.c handle_rx())
>
> So, unless the HW has a _magic_ flag to enable this capability...
> you are sort of screwed :-/.
I would love this feature as well. I have a device to test if that can
help. I share the feeling of Christian however... but maybe your
documentation says something about a special flag.
Regards,
Benoit
On Saturday 22 May 2010 21:13:50 David H. Lynch Jr. wrote:
>
> some items I have found while making my changes to the code.
patches are welcome :-D
> In firmware_source/carlfw/src/wlan.c you have aloop to read the TSF
> timer to make sure there is no roll over. According to the docs I have
> when TSF_LOW is read, TSF_HI is automatically concurrently copied to a
> temp register so that an immediate read of TSF_HI will get the value
> that was present when TSF_LO was read.
Thanks for that clarification. The code in question was actually a
adaptation from ar9170_op_get_tsf (patch author included in CC).
Since this is now settled, I made the necessary chances to the
kernel driver as well. (with a reference to your previous mail)
> I beleive the timer_init() routine in carlfw/src/timer.c can not be
> called for more than one timer. Any subsequent call will clear the
> interrupt and mode bits for the previous timer.
there's more than that.
Take a look at the (timer << 2) and so forth...
> I have not completely tracked these down, but the new config system
> must be missing some dependencies, because I can configure and build
> firmware that will not load.
> In carlfw/src/cmd.c the CARL9170_CMD_PSM case needs ifdef'd with
> CONFIG_CARL9170FW_PSM or it will not build with PSM disabled.
>
fixed.
Thanks for your comments. I've just released 1.0.9.1, which
contains fixes for all of your comments and some additional changes.
BTW:
> I have been playing with the assorted timers in the ar9170.
> My preliminary observations seem to be indicating that
> AR9170_TIMER_REG_TIMER0 might actually be running at 40mhz/25ns,
> But that all the other timers seem to be running far slower - i.e.
> maybe they are cascaded of the overflow on timer0.
>
> I have specifically looked at timer1-4 and tic_timer and clock_low
> and they all seem to be running very slow.
> The docs that I have imply but do not state that all these clocks
> are directly off the 25ns/40mhz superH clock.
> Have you had any experience with the clocks and their rates ?
based on observation: Some timers(1-4) are *driven* by the cpu clock.
Which is of course determined by the operation mode and phy band.
As you know there are 7 (1 + 2 * 3) possible AHB/CPU clock settings:
* 40MHz (refclock)
* 20MHz (PSM, 5GHz) & 22MHz (PSM, 2.4GHz)
* 40MHz (11an, 5GHz, HT20) & 44Mhz (11bgn, 2.4GHz, HT20)
* 80MHz (11an, 5GHz, HT40) & 88MHz (11bgn, 2.4GHz, HT40)
Regards,
Chr
On Wed, May 5, 2010 at 11:41 AM, David H. Lynch Jr. <[email protected]> wrote:
> I am trying to build a kernel using the carl9170 driver/firmware.
> I am not particular about what kernel or how so long as I can get it
> running.
>
> When I build out of the wireless-testing git tree (puled today)
> 2.6.34-rc6
> using my current systems .config I get a very quick error on boot about
> PCI bridge windows.
> googling the error indicates this is a know 2.6.34 problem and that there
> are fixes in other 2.6.34 trees.
> I have been unable to find the actual patches or I would just apply them
> to wireless-testing.
>
> Alternately, I tried to build out of the ubuntu-lucid git tree. 2.6.32
> again with my existing .config.
> I the carl9170 driver does not build. While I found patches at OpenWRT
> that are supposed to allow building carl9170 with 2.6.33 or less,
> the errors are unrelated to what is changed by those patches.
>
> I have also tried using linux-source-2.6.32 pulled from cannonical via
> apt for my install rather than the ubuntu-lucid git tree
> with similar results.
You can build the driver with compat-wireless so that way you can keep
your existing functional kernel and only backport the driver. We did
this way back when we first started doing development on ath9k and it
worked well.
Luis
On 05/02/2010 03:47 AM, Benoit Papillault wrote:
> Le 01/05/2010 22:45, Christian Lamparter a ?crit :
>> On Saturday 01 May 2010 20:23:26 David H. Lynch Jr. wrote:
>>> I think I can tell you what I am supposed add - I need to be able
>>> to provide userspace apps with precise timing information for each
>>> packet.
>>> Since i am working on GPL'd code and the results are going to be
>>> provided to third parties whatever I do is GPL'd too.
>>
>> if by precise timing you mean "exact mac time in TU/usecs when frame
>> was received at the radio", then you might have a _problem_.
>> You see, the firmware already receives fully packed frames from
>> the MAC processor and only _forwards_ them all [as is] in
>> one big DMA to the USB subsystem.
>> (this is done in src/wlan.c handle_rx())
>>
>> So, unless the HW has a _magic_ flag to enable this capability...
>> you are sort of screwed :-/.
>
> I would love this feature as well. I have a device to test if that can
> help. I share the feeling of Christian however... but maybe your
> documentation says something about a special flag.
I am interested in round trip time as measured from some fixed point
in the sending process to some fixed point in the packet acknowledgement.
The more accurate the better. Preferably measured by events at the
radio rather than on the linux side. I am interested in tx packets
rather than rx packets.
If necessary I can measure the times myself as delta's from one
event to another withing the SH2.
I have not digested the docs I have thoroughly yet but a cursory
review suggests a less than trivial project.
I have not yet found a good high resolution clock inside the ar9170
there are alot of clocks but they all seem to be 16bit. Probably that
will make things harder.
I was expecting to have to make changes to the ar9170 firmware. I
was expecting to have to devise some means of passing that information
to the Linux driver and to the userspace application. I would be happy
to do that in some fashion that conformed to an existing or future
standard, but I was not anticipating a broad desire for what I am
doing. Variable latencies are highly undesirable in this application,
but the userspace application will be aggregating large amounts of
information, if latencies in what is measured are constrained and the
unit of time measurement is small enough everything will work.
If it comes to that we switch to different hardware, but my project
is bringing a concept that was demonstrated with an expensive SDR to an
ar9170.
I am still coming up to speed on some aspects of Wireless - I am
not a complete noob, I have done ethernet drivers, and other very low
level work. I have also worked with non-802.11 wireless, and network
communications. But three days ago I had only cursory understanding of
how 802.11 works.
I already greatly appreciate your assistance.
>
> Regards,
> Benoit
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 [email protected] http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
some items I have found while making my changes to the code.
In firmware_source/carlfw/src/wlan.c you have aloop to read the TSF
timer to make sure there is no roll over. According to the docs I have
when TSF_LOW is read, TSF_HI is automatically concurrently copied to a
temp register so that an immediate read of TSF_HI will get the value
that was present when TSF_LO was read.
Presuming the docs are correct - and this feature is common in
multi-word timers you should be able to save some code.
Also with some complex casting or another pointer you can read directly
to your destination and save a memcpy()
I beleive the timer_init() routine in carlfw/src/timer.c can not be
called for more than one timer. Any subsequent call will clear the
interrupt and mode bits for the previous timer.
I have not completely tracked these down, but the new config system
must be missing some dependencies, because I can configure and build
firmware that will not load.
In carlfw/src/cmd.c the CARL9170_CMD_PSM case needs ifdef'd with
CONFIG_CARL9170FW_PSM or it will not build with PSM disabled.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 [email protected] http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies
toonumerous to list.
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction."
Albert Einstein
When I was attempting to push my ll_temac driver, I was told to use
dev_err(), dev_warn(), and dev_info() rather than printk(KERN_XXXX. I
beleive the ar9170 driver already in the kernel tree is doing that. I
beleive these I tend to create DBG(), ERR() and WARN() macros, because
during debugging I have been known to reroute the error handling through
a uart or some other debug port - kind of like you are printf'ing
through USB in the firmware. Putting it in a macro makes global changes
easier. Though I think heavy use of macros is now frowned on.
Just my .02
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 [email protected] http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
On 05/01/2010 01:19 PM, Christian Lamparter wrote:
>
> Well, for starters the ar9170 uses a ZyDas MAC (aka ZD1221)
> and a AR900x PHY/Radio. Therefore the phy code and registers
> are very similar to those #definitions you can find in ath9k.
> And for the MAC code& registers you can look into zd1211rw,
> or look into drivers/staging/otus (original vendor driver,
> shares some code with their windows drivers)
>
> AFAICT, there are no technical documents about the AR9170
> solution available w/o signing a NDA with Atheros
> (probably because the devices are still produced and sold in high quantities?).
>
Thanks;
I did just discover a reasonably good 150p spec. in what I
received from my client.
If I can I will share it. I am under an NDA, but the client
also told me that they received no cooperation from atheros.
>> What is available for the ar9170 itself ?
>> How does the firmware and the linux driver communicate?
>> Is there an overview of the firmware - what is where ?
>>
> not really, apart from the headers of the original firmware
> and vendor drivers.
>
> But if you really need to implement some of your 'features'
> (what are they, if I may ask?)
I think I can tell you what I am supposed add - I need to be able
to provide userspace apps with precise timing information for each packet.
Since i am working on GPL'd code and the results are going to be
provided to third parties whatever I do is GPL'd too.
Why gets into the NDA.
Right now i have an NDA with a new client and though I am
exercising care. But they seem fairly mellow. I am probably just being
overly cautious.
> into the firmware you could
> save some time by migrating to carl9170 code base:
> ( http://www.kernel.org/pub/linux/kernel/people/chr/carl9170/1.0.5
> + linville's wireless-testing.git )
>
The carl9170 code is the expected future of the ar9170 in Linux ?
If so that is where I want to be working.
> The advantages over the original firmware code (from a developers POV) are:
> * customizable/configurable fw
> + driver can auto detect all selected fw features
>
> * userspace testbench ( carlu ) for the usb subsystem
> (allows you to run usb stress-test, dump the device's eeprom content
> to stdout and of course: you can implement your own routines
> and test& develop without crashing the kernel)
>
> * all hardware& firmware interface definitions are all located
> in a single directory /include/shared/*.h
>
> version.h - carl9170 API/ABI version
> eeprom.h - eeprom layout
> phy.h - AR900x PHY/Radio definitions
> fwcmd.h - implemented firmware commands
> fwdesc.h - layout of the firmware descriptor (e.g. available/activated features)
> hw.h - ZD1221 MAC + (Faraday USB) definitions
> wlan.h - (part of hw.h& phy.h) contains all the information about
> tx& rx frame formats.
>
> * (tiny) printf + hexdump (obviously, you want those ;-) )
>
> * follows linux' kernel coding style :-D
>
Thanks alot.
I will look seriously at that.
While I want to keep the scope of what I am doing small, and as
narrowly confined as a I can,
it would be nice if atleast some of my work was useful beyond the
unique needs of my client.
> Regards,
> Chr
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 [email protected] http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
On Thursday, May 06, 2010 09:09:58 am Bjorn Helgaas wrote:
> On Wednesday, May 05, 2010 01:59:55 pm Christian Lamparter wrote:
> > On Wednesday 05 May 2010 20:41:26 David H. Lynch Jr. wrote:
> > > When I build out of the wireless-testing git tree (puled today)
> > > 2.6.34-rc6 using my current systems .config I get a very quick error
> > > on boot about PCI bridge windows.
> > > googling the error indicates this is a know 2.6.34 problem and that
> > > there are fixes in other 2.6.34 trees.
> > > I have been unable to find the actual patches or I would just apply
> > > them to wireless-testing.
>
> I made significant changes in the way we handle PCI bridge windows,
> and I'm eager to fix any issues in that area. But "very quick error
> on boot" doesn't give me any information to work with.
>
> Please attach your complete dmesg output, serial console log (with
> "ignore_loglevel"), digital photo of the error, or other specific
> details.
Ping! If there's a problem here, I want to fix it as soon as possible.
Do you have any more details? What error message did you google?
Thanks,
Bjorn
On Wednesday, May 05, 2010 01:59:55 pm Christian Lamparter wrote:
> On Wednesday 05 May 2010 20:41:26 David H. Lynch Jr. wrote:
> > When I build out of the wireless-testing git tree (puled today)
> > 2.6.34-rc6 using my current systems .config I get a very quick error
> > on boot about PCI bridge windows.
> > googling the error indicates this is a know 2.6.34 problem and that
> > there are fixes in other 2.6.34 trees.
> > I have been unable to find the actual patches or I would just apply
> > them to wireless-testing.
I made significant changes in the way we handle PCI bridge windows,
and I'm eager to fix any issues in that area. But "very quick error
on boot" doesn't give me any information to work with.
Please attach your complete dmesg output, serial console log (with
"ignore_loglevel"), digital photo of the error, or other specific
details.
Bjorn
On 05/02/2010 08:52 AM, Christian Lamparter wrote:
>
>
>> If necessary I can measure the times myself as delta's from one
>> event to another withing the SH2.
>>
>> I have not digested the docs I have thoroughly yet but a cursory
>> review suggests a less than trivial project.
>> I have not yet found a good high resolution clock inside the ar9170
>> there are alot of clocks but they all seem to be 16bit. Probably that
>> will make things harder.
>>
> TSF timer could be used for this. (see 802.11-2007, Section 11 et seq.)
> It's a 2^64 bit timer with a 1us resolution and a accuracy _better_
> or equal to +/- 0.01%.
>
> The register address are at:
> - 0x1c3514 (low, AR9170_MAC_REG_TSF_L, read only)
> - 0x1c3518 (high, AR9170_MAC_REG_TSF_H, read only)
>
> But it comes at a small price: this timer is sometimes
> update& synchronized (802.11 11.1.3.4 and 11.1.4) in
> station or ad-hoc mode. The exact details are hidden
> inside MAC chip, but it should be possible to disable
> both by selecting the monitor mode.
>
I will have to look into that it might work.
I beleive this project is in ad-hoc mode,
but if the timer is not being altered between the transmission of a
packet and the receipt of its ACK I am fine,
the worst case would be that it is and delta T becomes artificially
smaller. One characteristic of my problem is that
almost all the error is positive delta T overly large.
>
>> I was expecting to have to make changes to the ar9170 firmware. I
>> was expecting to have to devise some means of passing that information
>> to the Linux driver and to the userspace application.
>>
> Well, then you have two more good reasons why to use carl9170:
>
> * the ar9170usb driver and ar9170 firmware don't track tx frames.
> carl9170 on the other hand does (every frame has a 8 bit "cookie").
> This feature was necessary to generate an accurate tx transmission
> feedback report for every individual frame for the driver.
>
That would be necescary in my application and I have started to work
with the carl9170 driver.
I built the toolchain compiler the firmware and I am building a
linux kernel right now.
> * carl9170 has the ability to store additional per-frame data.
> In fact, if you don't need to have a different retry rates
> you could realloc the 3 * 32 bit "rr" (as in retry rate)
> array in the carl9170_tx_superdesc and _carl9170_tx_superdesc
> struct (see wlan.h) for your purposes (storage for your time values).
>
> And if you fetched all the data, everything will be sent
> with an ordinary tx status feedback report to the application
> (add the timer fields into carl9170_tx_status and _carl9170_tx_status
> struct - see fwcmd.h)
>
I need a delta T between some fixed point during the send and some
fixed point during the ACK.
And the MAC address of the device I was sending to. The latter
already is obviously already known, I just have to tie to it.
>
> (* talked about this earlier, but you never know...
>
> carlu _tool_ already provides a low-level HW driver for userspace.
> This has the obvious advantage that you won't need to mess with
> the kernel driver and network stacks.
>
> The only work you'll have to do is: get the kernel code for
> the MAC& PHY initialization and put it into carlu.
> But the framework is already there so it's mostly copy + paste )
>
I beleive you are using DEBUGFS and that was already part of my spec.
Regardless, I am comfortable on the Linux driver side.
The closer I get to the Linux side the more comfortable I am.
Further though the actual timing of each send's delta T needs to be
as accurate and fine grained as possible,
everything else in this project is non-critical. Within reason it
is unimportant how long it takes to propigate data from the AR9170
through to userspace,
Clean and simple will take precedence over any other technical demands.
>> I would be happy to do that in some fashion that conformed to an existing
>> or future standard, but I was not anticipating a broad desire for what I am
>> doing. Variable latencies are highly undesirable in this application,
>> but the userspace application will be aggregating large amounts of
>> information, if latencies in what is measured are constrained and the
>> unit of time measurement is small enough everything will work.
>> If it comes to that we switch to different hardware, but my project
>> is bringing a concept that was demonstrated with an expensive SDR to an
>> ar9170.
>>
> It's always nice to have some "added value" for cheap and generic devices.
> e.g.: Atheros AR92xx chips can be used as among other stuff as a
> full range spectrum analyzer.
>
And my ability to get consulting work is strongly effected by the
extent I can contribute to Linux.
References, and lists of skills and qualifications on my web site
are dwarfed by
Dave Lynch, DLA Systems <[email protected]> appearing inside the
kernel tree.
I love this work. I love working for myself, I want to continue to
do so.
I would contribute as I can regardless, but self interest helps.
> Regards,
> Chr
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 [email protected] http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
I need to track a new value for each tx frame only in the firmware.
It appears I should be adding it to carl9170_tx_superdesc. But that
structure seems to be used on both the Linux and firmware side, and I
have not been able to successfully add to it without breaking something
elsewhere either in the firmware or Linux driver or between them.
Alternately I can create a private array to hold my data, but then I
need to be able to find items in it using a carl9170_tx_superframe
pointer. I am gathering that the cookie and queue number constitute a
unique identifier, but that seems like alot of work to avoid adding a
u16 to carl9170_tx_superdesc.
Any other ideas about tracking a u16 value for each tx frame only on
the firmware side without substantial complexity ?
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 [email protected] http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies
toonumerous to list.
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction."
Albert Einstein
On 05/02/2010 08:52 AM, Christian Lamparter wrote:
> Well, then you have two more good reasons why to use carl9170:
> * carl9170 has the ability to store additional per-frame data.
> In fact, if you don't need to have a different retry rates
> you could realloc the 3 * 32 bit "rr" (as in retry rate)
> array in the carl9170_tx_superdesc and _carl9170_tx_superdesc
> struct (see wlan.h) for your purposes (storage for your time values).
>
> And if you fetched all the data, everything will be sent
> with an ordinary tx status feedback report to the application
> (add the timer fields into carl9170_tx_status and _carl9170_tx_status
> struct - see fwcmd.h)
cmd.h __check() tests for sizeof(carl9170_tx_status) != 2
is there an assumption somewhere that carl9170_tx_status == 2 ?
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 [email protected] http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
On Sat, May 1, 2010 at 11:23 AM, David H. Lynch Jr. <[email protected]> wrote:
> On 05/01/2010 01:19 PM, Christian Lamparter wrote:
>>
>> Well, for starters the ar9170 uses a ZyDas MAC (aka ZD1221)
>> and a AR900x PHY/Radio. Therefore the phy code and registers
>> are very similar to those #definitions you can find in ath9k.
>> And for the MAC code& registers you can look into zd1211rw,
>> or look into drivers/staging/otus (original vendor driver,
>> shares some code with their windows drivers)
>>
>> AFAICT, there are no technical documents about the AR9170
>> solution available w/o signing a NDA with Atheros
>> (probably because the devices are still produced and sold in high
>> quantities?).
>>
>
> Thanks;
> I did just discover a reasonably good 150p spec. in what I received
> from my client. If I can I will share it. I am under an NDA, but the client also told
> me that they received no cooperation from atheros.
You should be more specific. Atheros did GPL their ar9170 driver after
all, so it is in fact the first hardware vendor to ever have GPL'd
firmware for *any* device driver upstream. Releasing more docs takes
time, you are better off working directly with the upstream Atheros
developers than just subjectively claiming lack of cooperation.
Luis
On Wednesday 05 May 2010 20:41:26 David H. Lynch Jr. wrote:
> When I build out of the wireless-testing git tree (puled today)
> 2.6.34-rc6 using my current systems .config I get a very quick error
> on boot about PCI bridge windows.
> googling the error indicates this is a know 2.6.34 problem and that
> there are fixes in other 2.6.34 trees.
> I have been unable to find the actual patches or I would just apply
> them to wireless-testing.
so? If there is already a patch available, then the linux-pci people
have to know something about it. I'm sure they can help you out there.
Just describe your problem in detail (a extensive checklist is located in
your kernel's root directory "REPORTING-BUGS" file) as a reply to this mail.
I simply can't give you any support for problems I know nothing about.
So please, concentrate your questions around this particular device and
interaction with firmware and driver. But as I said in my previous mail,
you don't need a special kernel driver. *carlu* really is a userspace-only
application that can communicate with the device (through the use of
libusb) at the "lowest level". It may be even possible to port the code to
other platforms (FreeBSD & Mac OS X, Windows) with little effort.
Regards,
Chr
On Saturday 01 May 2010 12:19:11 David H. Lynch Jr. wrote:
> I have ethernet driver experience but not wifi. I have a project to
> add some features to the ar9170 that will require additions to the
> firmware. I would appreciate pointers for docs etc. to get me started.
Well, for starters the ar9170 uses a ZyDas MAC (aka ZD1221)
and a AR900x PHY/Radio. Therefore the phy code and registers
are very similar to those #definitions you can find in ath9k.
And for the MAC code & registers you can look into zd1211rw,
or look into drivers/staging/otus (original vendor driver,
shares some code with their windows drivers)
AFAICT, there are no technical documents about the AR9170
solution available w/o signing a NDA with Atheros
(probably because the devices are still produced and sold in high quantities?).
> What is available for the ar9170 itself ?
> How does the firmware and the linux driver communicate?
> Is there an overview of the firmware - what is where ?
not really, apart from the headers of the original firmware
and vendor drivers.
But if you really need to implement some of your 'features'
(what are they, if I may ask?) into the firmware you could
save some time by migrating to carl9170 code base:
( http://www.kernel.org/pub/linux/kernel/people/chr/carl9170/1.0.5
+ linville's wireless-testing.git )
The advantages over the original firmware code (from a developers POV) are:
* customizable/configurable fw
+ driver can auto detect all selected fw features
* userspace testbench ( carlu ) for the usb subsystem
(allows you to run usb stress-test, dump the device's eeprom content
to stdout and of course: you can implement your own routines
and test & develop without crashing the kernel)
* all hardware & firmware interface definitions are all located
in a single directory /include/shared/*.h
version.h - carl9170 API/ABI version
eeprom.h - eeprom layout
phy.h - AR900x PHY/Radio definitions
fwcmd.h - implemented firmware commands
fwdesc.h - layout of the firmware descriptor (e.g. available/activated features)
hw.h - ZD1221 MAC + (Faraday USB) definitions
wlan.h - (part of hw.h & phy.h) contains all the information about
tx & rx frame formats.
* (tiny) printf + hexdump (obviously, you want those ;-) )
* follows linux' kernel coding style :-D
Regards,
Chr
On 05/21/2010 06:55 PM, Christian Lamparter wrote:
> On Friday 21 May 2010 23:35:13 David H. Lynch Jr. wrote:
>
>> I need to track a new value for each tx frame only in the firmware.
>> It appears I should be adding it to carl9170_tx_superdesc.
>> But that structure seems to be used on both the Linux and firmware side,
>> and I have not been able to successfully add to it without breaking
>> something elsewhere either in the firmware or Linux driver or between them.
>>
> there are two superdesc structures:
> carl9170_tx_superdesc and _carl9170_tx_superdesc.
>
> This is due to the bit-field packing bug which is present
> in all GCC version prior to 4.4.
>
> Now, for the firmware we have a special toolchain and
> a BUILD_BUG check, so no problem is there.
>
> But kernel driver& userspace tools might be compiled by
> an older version.
>
> Therefore, if you want to introduce new fields, you have
> to update both structures accordingly.
>
> (And of course, always check that you're using your
> custom firmware and driver.)
>
For the moment I have found another way of resolving the issue.
I am not concerned that there are two versions of the structures
under Linux.
My problem was that it appears to add a field to the firmware I
must also add it to linux.
During a TX I am looking to track something in firmware, and then
return it to Linux.
If I have this correct the carl9170_tx_superframe is passed from
Linux to the firmware and the carl9170_tx_status is passed back to Linux.
I do not need the extra field in carl9170_tx_superframe in Linux. i
do need it at several different points prior to having a
carl9170_tx_status record, in the firmware. And then I need to return
the value to Linux in the carl9170_tx_status field.
I am gathering that whether I need or not that
carl9170_tx_superframe must match perfectly between Linux and the
firmware. And there is no other per packet data being managed in the
firmware.
My second problem is that even after adding it to both sides and
adjusting for all the alignment and other issues, I end up with
something that does not work.
I am being careful to keep the driver and firmware aligned. I
grasp that is an issue.
>
>> Alternately I can create a private array to hold my data, but then I
>> need to be able to find items in it using a carl9170_tx_superframe
>> pointer. I am gathering that the cookie and queue number constitute a
>> unique identifier, but that seems like alot of work to avoid adding a
>> u16 to carl9170_tx_superdesc.
>>
> It might not be visible at first glance, but carl9170_tx_superframe
> has two distinct header descriptors.
> * ar9170_tx_hwdesc
> * carl9170_tx_superdesc
>
> variables of those headers can not be mixed. This is because the
> layout of ar9170_tx_hwdesc is dictated by the hardware design.
>
> Therefore the queue number goes into ar9170_tx_hwdesc.mac.QoS,
> whereas the "cookie" is intended to be used by the firmware code.
> (In fact, carl9170_tx_superdesc is _hidden_ from the hardware POV)
>
>
>> Any other ideas about tracking a u16 value for each tx frame only on
>> the firmware side without substantial complexity ?
>>
> Erm, adding a single u16 is a bad idea. I'm pretty sure that the documents
> from your employer cover this subject in great detail since this is a
> well-known limitation.
>
Pardon my sensitivity, but I am a consultant. I have clients not
employers.
The parts of the AR9170 spec I have read do not address this, but I
have not read everything thoroughly.
My project deals almost exclusively with timing. And I am trying
not to touch things I do not need to.
> What you could try - on the other hand - u32.
> even if you don't need the extra 2 bytes that come with this
> bigger storage class.
>
I may need to do that anyway. 25ns * 65K is 1.6ms before
overflow, that is almost too short.
>
> BTW:
> Yes, the (CARL9170_TX_STATUS_NUM % 2) check can be safely disabled now.
> But let me run some experiments. Just to be on the safe side.
>
Thanks.
> Regards,
> Chr
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 [email protected] http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
firmware_ssource/include/config.h
tests CARL9170_TX_STATUS_NUM - the number of status entries in the
response to see if it is an even number.
Does the max number of status entries actually have to be even ?
I had to add a fill byte to tx_status to get an even result.
> BUILD_BUG_ON(CARL9170_TX_STATUS_NUM % 2 || !CARL9170_TX_STATUS_NUM);
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 [email protected] http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies
toonumerous to list.
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction."
Albert Einstein
I am trying to build a kernel using the carl9170 driver/firmware.
I am not particular about what kernel or how so long as I can get
it running.
When I build out of the wireless-testing git tree (puled today)
2.6.34-rc6
using my current systems .config I get a very quick error on boot
about PCI bridge windows.
googling the error indicates this is a know 2.6.34 problem and that
there are fixes in other 2.6.34 trees.
I have been unable to find the actual patches or I would just apply
them to wireless-testing.
Alternately, I tried to build out of the ubuntu-lucid git tree.
2.6.32 again with my existing .config.
I the carl9170 driver does not build. While I found patches at
OpenWRT that are supposed to allow building carl9170 with 2.6.33 or less,
the errors are unrelated to what is changed by those patches.
I have also tried using linux-source-2.6.32 pulled from cannonical
via apt for my install rather than the ubuntu-lucid git tree
with similar results.
On 05/02/2010 08:52 AM, Christian Lamparter wrote:
> On Sunday 02 May 2010 13:14:59 David H. Lynch Jr. wrote:
>
>> On 05/02/2010 03:47 AM, Benoit Papillault wrote:
>>
>>> Le 01/05/2010 22:45, Christian Lamparter a ?crit :
>>>
>>>> On Saturday 01 May 2010 20:23:26 David H. Lynch Jr. wrote:
>>>>
>>>>> I think I can tell you what I am supposed add - I need to be able
>>>>> to provide userspace apps with precise timing information for each
>>>>> packet.
>>>>> Since i am working on GPL'd code and the results are going to be
>>>>> provided to third parties whatever I do is GPL'd too.
>>>>>
>>>> if by precise timing you mean "exact mac time in TU/usecs when frame
>>>> was received at the radio", then you might have a _problem_.
>>>> You see, the firmware already receives fully packed frames from
>>>> the MAC processor and only _forwards_ them all [as is] in
>>>> one big DMA to the USB subsystem.
>>>> (this is done in src/wlan.c handle_rx())
>>>>
>>>> So, unless the HW has a _magic_ flag to enable this capability...
>>>> you are sort of screwed :-/.
>>>>
>>> I would love this feature as well. I have a device to test if that can
>>> help. I share the feeling of Christian however... but maybe your
>>> documentation says something about a special flag.
>>>
>> I am interested in round trip time as measured from some fixed point
>> in the sending process to some fixed point in the packet acknowledgement.
>> The more accurate the better. Preferably measured by events at the
>> radio rather than on the linux side.
>>
>
>> I am interested in tx packets rather than rx packets.
>>
> ahh, well... there goes' benoit interest ;).
>
>
>> If necessary I can measure the times myself as delta's from one
>> event to another withing the SH2.
>>
>> I have not digested the docs I have thoroughly yet but a cursory
>> review suggests a less than trivial project.
>> I have not yet found a good high resolution clock inside the ar9170
>> there are alot of clocks but they all seem to be 16bit. Probably that
>> will make things harder.
>>
> TSF timer could be used for this. (see 802.11-2007, Section 11 et seq.)
> It's a 2^64 bit timer with a 1us resolution and a accuracy _better_
> or equal to +/- 0.01%.
>
> The register address are at:
> - 0x1c3514 (low, AR9170_MAC_REG_TSF_L, read only)
> - 0x1c3518 (high, AR9170_MAC_REG_TSF_H, read only)
>
> But it comes at a small price: this timer is sometimes
> update& synchronized (802.11 11.1.3.4 and 11.1.4) in
> station or ad-hoc mode. The exact details are hidden
> inside MAC chip, but it should be possible to disable
> both by selecting the monitor mode.
>
>
>> I was expecting to have to make changes to the ar9170 firmware. I
>> was expecting to have to devise some means of passing that information
>> to the Linux driver and to the userspace application.
>>
> Well, then you have two more good reasons why to use carl9170:
>
> * the ar9170usb driver and ar9170 firmware don't track tx frames.
> carl9170 on the other hand does (every frame has a 8 bit "cookie").
> This feature was necessary to generate an accurate tx transmission
> feedback report for every individual frame for the driver.
>
> * carl9170 has the ability to store additional per-frame data.
> In fact, if you don't need to have a different retry rates
> you could realloc the 3 * 32 bit "rr" (as in retry rate)
> array in the carl9170_tx_superdesc and _carl9170_tx_superdesc
> struct (see wlan.h) for your purposes (storage for your time values).
>
> And if you fetched all the data, everything will be sent
> with an ordinary tx status feedback report to the application
> (add the timer fields into carl9170_tx_status and _carl9170_tx_status
> struct - see fwcmd.h)
>
> (* talked about this earlier, but you never know...
>
> carlu _tool_ already provides a low-level HW driver for userspace.
> This has the obvious advantage that you won't need to mess with
> the kernel driver and network stacks.
>
> The only work you'll have to do is: get the kernel code for
> the MAC& PHY initialization and put it into carlu.
> But the framework is already there so it's mostly copy + paste )
>
>
>> I would be happy to do that in some fashion that conformed to an existing
>> or future standard, but I was not anticipating a broad desire for what I am
>> doing. Variable latencies are highly undesirable in this application,
>> but the userspace application will be aggregating large amounts of
>> information, if latencies in what is measured are constrained and the
>> unit of time measurement is small enough everything will work.
>> If it comes to that we switch to different hardware, but my project
>> is bringing a concept that was demonstrated with an expensive SDR to an
>> ar9170.
>>
> It's always nice to have some "added value" for cheap and generic devices.
> e.g.: Atheros AR92xx chips can be used as among other stuff as a
> full range spectrum analyzer.
>
> Regards,
> Chr
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 [email protected] http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
On Friday 21 May 2010 23:35:13 David H. Lynch Jr. wrote:
> I need to track a new value for each tx frame only in the firmware.
> It appears I should be adding it to carl9170_tx_superdesc.
> But that structure seems to be used on both the Linux and firmware side,
> and I have not been able to successfully add to it without breaking
> something elsewhere either in the firmware or Linux driver or between them.
there are two superdesc structures:
carl9170_tx_superdesc and _carl9170_tx_superdesc.
This is due to the bit-field packing bug which is present
in all GCC version prior to 4.4.
Now, for the firmware we have a special toolchain and
a BUILD_BUG check, so no problem is there.
But kernel driver & userspace tools might be compiled by
an older version.
Therefore, if you want to introduce new fields, you have
to update both structures accordingly.
(And of course, always check that you're using your
custom firmware and driver.)
> Alternately I can create a private array to hold my data, but then I
> need to be able to find items in it using a carl9170_tx_superframe
> pointer. I am gathering that the cookie and queue number constitute a
> unique identifier, but that seems like alot of work to avoid adding a
> u16 to carl9170_tx_superdesc.
It might not be visible at first glance, but carl9170_tx_superframe
has two distinct header descriptors.
* ar9170_tx_hwdesc
* carl9170_tx_superdesc
variables of those headers can not be mixed. This is because the
layout of ar9170_tx_hwdesc is dictated by the hardware design.
Therefore the queue number goes into ar9170_tx_hwdesc.mac.QoS,
whereas the "cookie" is intended to be used by the firmware code.
(In fact, carl9170_tx_superdesc is _hidden_ from the hardware POV)
> Any other ideas about tracking a u16 value for each tx frame only on
> the firmware side without substantial complexity ?
Erm, adding a single u16 is a bad idea. I'm pretty sure that the documents
from your employer cover this subject in great detail since this is a
well-known limitation.
What you could try - on the other hand - u32.
even if you don't need the extra 2 bytes that come with this
bigger storage class.
BTW:
Yes, the (CARL9170_TX_STATUS_NUM % 2) check can be safely disabled now.
But let me run some experiments. Just to be on the safe side.
Regards,
Chr