Re: Re: AT86RF212 based USB-Stick (HUL)

Re: Re: AT86RF212 based USB-Stick (HUL)

[Josef Filzmaier]

> Does it use the exact same MCU to drive the transceiver?

It uses the AT90USB1287 so yes, they are the same.

> How did you verify that it works nicely? You said there is no USB 
communication going on.

There actually *is* USB communication going on. I can see it when capturing 
usb traffic and also in dmesg. The atusb_{write,read}_{reg,subreg} functions are 
working. I can read out information like part_num, version_num and man_id_x 
perfectly fine.
Setting channel, tx_power, pan_id etc are all working (or at least the 
communication over USB is working fine)

However, i do believe that the firmware is not fully capable of handling the 
incoming USB traffic. I will describe my problem in more detail at the bottom.

> Did you actually change anything in the firmware at all? Keep in mind that 
the firmware also has some parts of the send and receive logic which might need 
adaption for the 212 as well.

The only thing i have done in the firmware is that i have changed the the NAME 
parameter in the makefile to:
NAME = rzusb

> Hmm, 4.9 is a bit older and might miss some fixes from the stack. Any chance 
you could run that with a newer kernel? Its a USB device which could give you 
a way quicker development env on a normal desktop or laptop machine.

For me it is important that it runs on the raspberry pi with linux 4.9, but 
for development using a laptop/desktop could help out a lot that's true. I'm 
already cross compiling that is also helping a lot.
Maybe i will try it with a more recent development version of the kernel soon, 
just to be sure.

> Do you have the link to the code somewhere? Also the dmesg output of the 
atusb driver when inserting the usb stick would be interesting to see.

I have pushed my modified changes to github [1]. 
All i have done is added the part_num of the at86rf212 (7) case to the 
driver's probe function. (With the same calls as in the at86rf230 driver) Also 
i added the missing set_lbt function because i could not set the interface up 
otherwise. After those modifications there were no errors reported when probing 
the driver.

The full dmesg output when inserting the stick can be found here [2].
I also included the output of tshark with usbmon here [3].

*Detailed Problem Description:*

At the end of the dmesg output you can see that the atusb_xmit function is 
called and it seems to be completing. This is the _only_ atusb_xmit function 
call ever. It does only happen one single time, and then it never occurs 
again, even when actively using the network interface*. This is what makes me 
think:
  - Either the problem is higher up in the network stack. I am currently 
investigating this possibility (looking how sockets work in the kernel)
  - Or the problem occurs after the usb_submit_urb() function.

I do not think that this problem is within the firmware, but i might be wrong.

In either case, the transceiver never transmits any rf data over the 
transmission medium.

* I also have tested this with the at86rf212 transceiver connected directly 
via spi and it is working perfectly. i.e. the driver's xmit function is called 
for every network call.

Thanks!

[1] https://github.com/joseffilzmaier/linux/commit/
d0624efcceb8aa0911178f586d9b82dde5471570
[2] https://pastebin.com/HhzWJvea
[3] https://pastebin.com/HYpEK7LR

-- 
Josef Filzmaier

Re: AT86RF212 based USB-Stick (HUL)

[Stefan Schmidt]

Hello.

On 08/03/2017 04:26 PM, Josef Filzmaier wrote:
>> Does it use the exact same MCU to drive the transceiver?
> 
> It uses the AT90USB1287 so yes, they are the same.

Great. That means we can indeed use the rzusb board logic from the 
firmware to setup USB and SPI, etc on the MCU side.
> 
>> How did you verify that it works nicely? You said there is no USB
> communication going on.
> 
> There actually *is* USB communication going on. I can see it when capturing
> usb traffic and also in dmesg. The atusb_{write,read}_{reg,subreg} functions are
> working. I can read out information like part_num, version_num and man_id_x
> perfectly fine.
> Setting channel, tx_power, pan_id etc are all working (or at least the
> communication over USB is working fine)

I have to say this is way better than I expected. :) Being able to read 
out registers and have the basic USB communication working is already a 
good step in the right direction.

> However, i do believe that the firmware is not fully capable of handling the
> incoming USB traffic. I will describe my problem in more detail at the bottom.
> 
>> Did you actually change anything in the firmware at all? Keep in mind that
> the firmware also has some parts of the send and receive logic which might need
> adaption for the 212 as well.
> 
> The only thing i have done in the firmware is that i have changed the the NAME
> parameter in the makefile to:
> NAME = rzusb

Based on this name we set the atmel MCU but we also set the transceiver 
right now. So far we only had two boards which made it easier to just do 
both in one step.

If you look at the tiny mac part of the firmware you will see that we 
adjust teh state handling based on the transceiver. I haven't checked 
but I think at least that parts needs to be adapted as the 212 and 230 
will be different for for the state handling (also see Alex's reply on this)

http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/atusb/fw/mac.c

>> Hmm, 4.9 is a bit older and might miss some fixes from the stack. Any chance
> you could run that with a newer kernel? Its a USB device which could give you
> a way quicker development env on a normal desktop or laptop machine.
> 
> For me it is important that it runs on the raspberry pi with linux 4.9, but
> for development using a laptop/desktop could help out a lot that's true. I'm
> already cross compiling that is also helping a lot.
> Maybe i will try it with a more recent development version of the kernel soon,
> just to be sure.

Sure, I understand that your final goal is the pi with this specific 
version. It just might be easier for you to have the development on a 
different system until its working and you can worry about backporting 
and deployment.

>> Do you have the link to the code somewhere? Also the dmesg output of the
> atusb driver when inserting the usb stick would be interesting to see.
> 
> I have pushed my modified changes to github [1].
> All i have done is added the part_num of the at86rf212 (7) case to the
> driver's probe function. (With the same calls as in the at86rf230 driver) Also
> i added the missing set_lbt function because i could not set the interface up
> otherwise. After those modifications there were no errors reported when probing
> the driver.

Its impressive that it needs so litle code to get some basic stuff 
working :) I'm looking forward to get this into shape and into mailine 
once it is all working.

Is there any source where I still would be able to buy/get one of these 
devices from? The main link indicates they are no longer available. I 
would love to add one to my collection. At the minimum to make sure I do 
not break it when I do a new firmware or driver updates.

> The full dmesg output when inserting the stick can be found here [2].
> I also included the output of tshark with usbmon here [3].

Thanks for the links. I will go through them over the next days. I bit 
busy right now. I wanted to get you at least the info in here to help 
you dig deeper. I hope to come to it over the next days and give you 
some more comments.

> *Detailed Problem Description:*
> 
> At the end of the dmesg output you can see that the atusb_xmit function is
> called and it seems to be completing. This is the _only_ atusb_xmit function
> call ever. It does only happen one single time, and then it never occurs
> again, even when actively using the network interface*. This is what makes me
> think:
>    - Either the problem is higher up in the network stack. I am currently
> investigating this possibility (looking how sockets work in the kernel)
>    - Or the problem occurs after the usb_submit_urb() function.

My guess here is that the first calls hits the firmware at due to the 
different state handling of 230 we use to drive the 212 the hardware and 
the fw/driver are no longer in sync and things break down. Its a guess 
only but one that should be followed at least.

> I do not think that this problem is within the firmware, but i might be wrong.

I think its a combination of fw and driver, but I might be wrong as well.

> In either case, the transceiver never transmits any rf data over the
> transmission medium.
> 
> * I also have tested this with the at86rf212 transceiver connected directly
> via spi and it is working perfectly. i.e. the driver's xmit function is called
> for every network call.

Good to know. Interesting that you prefer to use a usb dongle on the pi 
instead of a transceiver hooked up over SPI.

regards
Stefan Schmidt

Re: AT86RF212 based USB-Stick (HUL)

[Josef Filzmaier]

> If you look at the tiny mac part of the firmware you will see that we
> adjust teh state handling based on the transceiver. I haven't checked
> but I think at least that parts needs to be adapted as the 212 and 230
> will be different for for the state handling (also see Alex's reply on this)
> 
> http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/atus
> b/fw/mac.c

Thanks, i will check that out tomorrow.

> Is there any source where I still would be able to buy/get one of these
> devices from? The main link indicates they are no longer available. I
> would love to add one to my collection. At the minimum to make sure I do
> not break it when I do a new firmware or driver updates.

The company i work for still has quite a few of those sticks. I can send you 
one. You just have to tell me where i should send it to :)

> Good to know. Interesting that you prefer to use a usb dongle on the pi
> instead of a transceiver hooked up over SPI.

We are currently using this stick running contiki and its 6LoWPAN stack. The 
next iteration of our hardware will be using the transceiver directly via SPI. 
But we need backwards compatability with this stick - and ideally a unified 
interface to send and receive data via SPI and with the stick. By using the 
linux-wpan stack we are really close to achieve this in a proper way :) 

-- 
Josef Filzmaier

Re: AT86RF212 based USB-Stick (HUL)

[Stefan Schmidt]

Hello.

On 08/03/2017 10:51 PM, Josef Filzmaier wrote:
>> If you look at the tiny mac part of the firmware you will see that we
>> adjust teh state handling based on the transceiver. I haven't checked
>> but I think at least that parts needs to be adapted as the 212 and 230
>> will be different for for the state handling (also see Alex's reply on this)
>>
>> http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/atus
>> b/fw/mac.c
> 
> Thanks, i will check that out tomorrow.

Let me know how it goes.

>> Is there any source where I still would be able to buy/get one of these
>> devices from? The main link indicates they are no longer available. I
>> would love to add one to my collection. At the minimum to make sure I do
>> not break it when I do a new firmware or driver updates.
> 
> The company i work for still has quite a few of those sticks. I can send you
> one. You just have to tell me where i should send it to :)

That would be great. I will send you my address directly.

If your company would be interested to produce some more and sell them I 
would expect there would be folks willing to get some. As a data point I 
can tell you that Sysmocom sold over 100 of the newly produced ATUSB so 
far and they are still going. With the initial sold 120 this shows there 
is a target market for such devices. Maybe not big enough for your 
company though. Just something to think about. :)

> 
>> Good to know. Interesting that you prefer to use a usb dongle on the pi
>> instead of a transceiver hooked up over SPI.
> 
> We are currently using this stick running contiki and its 6LoWPAN stack. The
> next iteration of our hardware will be using the transceiver directly via SPI.
> But we need backwards compatability with this stick - and ideally a unified
> interface to send and receive data via SPI and with the stick. By using the
> linux-wpan stack we are really close to achieve this in a proper way :)

I love to hear that. :)

regards
Stefan Schmidt

Re: AT86RF212 based USB-Stick (HUL)

[Josef Filzmaier]

Hello again :)

> Let me know how it goes.

I have made some progress regarding the busware hul stick support. I had two 
major problems:

1) The atusb_xmit function is only called *once* and then never again
2) Configuring page, channel and txpower did not work.

I think that i did fix 2) successfully. (Firmware Patch: [1], Kernel Patch: [2] 
(Please ignore the modified device tree)) I hopefully did not break 
compatability with rzusb and atusb, could you please verify that and give some 
comments on my code?

For 1) however, i still have some problems - and am seeking for some help.
The first time i try to send a frame i get roughly the following function 
calling sequence (bottom up):

atusb_xmit
ieee802154_tx
ieee802154_subif_start_xmit
dev_hard_start_xmit
sch_direct_xmit
__dev_xmit_skb
__dev_queue_xmit
...

However, the second time i try to send a frame i get the following sequence:

sch_direct_xmit
__dev_xmit_skb
__dev_queue_xmit
...

The reason for this is that !netif_xmit_frozen_or_stopped(txq) (see [3]) is 
false, so the dev_hard_start_xmit() function is never called.
It is returning false because the netdev_queue is in state 
QUEUE_STATE_DRV_XOFF.
As far as i can tell this state change happens in the ieee802154_tx() [4] 
method with the ieee802154_stop_queue(&local->hw) function call.

What could be wrong here? Do i have to call ieee802154_wake_queue() somewhere? 
Or where should the netdev_queue state be reset so that the queue state is 
back at 0 that new frames can be sent. Or am i missing something completely 
here?

> That would be great. I will send you my address directly.

I just realized that your email with the address was in my spam folder. I will 
send you one ASAP.

Regards,
Josef

[1] https://github.com/joseffilzmaier/ben-wpan/compare/busware-hul
[2] https://github.com/raspberrypi/linux/compare/
rpi-4.9.y...joseffilzmaier:atusb-busware-hul
[3] http://elixir.free-electrons.com/linux/v4.9.40/source/net/sched/
sch_generic.c#L181
[4] http://elixir.free-electrons.com/linux/v4.9.40/source/net/mac802154/
tx.c#L72

-- 
Josef Filzmaier

Re: AT86RF212 based USB-Stick (HUL)

[Josef Filzmaier]

Hello!

> 1) The atusb_xmit function is only called *once* and then never again

I just managed to fix this problem, too. I did configure the interrupt of the 
microcontroller in the firmware incorrectly. So i did never get an interrupt 
and the kernel was never informed that the frame was transmitted successfully 
(atusb_tx_done was missing) I will send you the link to an updated patch once 
i've tested it a bit more.

-- 
Josef Filzmaier

Re: AT86RF212 based USB-Stick (HUL)

[Stefan Schmidt]

Hello.

On 08/16/2017 05:33 PM, Josef Filzmaier wrote:
> Hello again :)
> 
>> Let me know how it goes.
> 
> I have made some progress regarding the busware hul stick support. I had two
> major problems:
> 
> 1) The atusb_xmit function is only called *once* and then never again

I will skip this part here as you already sent another mail stating it 
came back to using the wrong INT in the firmware.

> 2) Configuring page, channel and txpower did not work.
> 
> I think that i did fix 2) successfully. (Firmware Patch: [1], Kernel Patch: [2]
> (Please ignore the modified device tree)) I hopefully did not break
> compatability with rzusb and atusb, could you please verify that and give some
> comments on my code?

As a first step I will go and test your firmware changes only on the 
atusb and rzusb devices to make sure nothing breaks with the current 
mainline driver.

Testing it with the atusb driver changes applied is the next step.

As for review I can go through your changes on the github links and do 
some initial review there but the final patches and review to get 
applied to the tree need to come as git patches to this mailing list.

>> That would be great. I will send you my address directly.
> 
> I just realized that your email with the address was in my spam folder. I will
> send you one ASAP.

I actually had to send it to you twice because the mails from my company 
address will not get through to gmx.at. I think this is due to some odd 
configuration on our side. nothign I can fix myself but I can bring it 
up at least.

I also send you the address from my private mail (datenfreihafen.org). 
Did this one end up in your SPAM folder? That would be odd.

regards
Stefan Schmidt

Re: AT86RF212 based USB-Stick (HUL)

[Stefan Schmidt]

Hello.

On 08/17/2017 10:28 AM, Josef Filzmaier wrote:
> Hello!
> 
>> 1) The atusb_xmit function is only called *once* and then never again
> 
> I just managed to fix this problem, too. I did configure the interrupt of the
> microcontroller in the firmware incorrectly. So i did never get an interrupt
> and the kernel was never informed that the frame was transmitted successfully
> (atusb_tx_done was missing) I will send you the link to an updated patch once
> i've tested it a bit more.
> 

Great!

I see yo used TIMER1_CAPT_vect as rzusb does but it needed to be 
INT0_vect like we do on the ATUSB. Tricky little beast this firmware. :)

regards
Stefan Schmidt

Re: AT86RF212 based USB-Stick (HUL)

[Josef Filzmaier]

Hello!

First i want to thank you for taking your time to look at my code and all the 
useful comments. I will go through them step by step.

I have some general questions:

My thought was to squash all the commits into a single one once the code is in 
good enough shape. Do you prefer to keep the commit history?

I did debug the firmware over UART. I thought it might be a useful option to 
other developers (using the DEBUG flag) working on this firmware, but i can of 
course also remove my debug code completely if it is not needed?

> As for review I can go through your changes on the github links and do
> some initial review there but the final patches and review to get
> applied to the tree need to come as git patches to this mailing list.

I have seen the git send-email tutorial on the linux-wpan homepage (To change 
the homepage). Never used git send-email before but i guess this is how it 
should be done with the code as well, once the code is in good shape.

> I also send you the address from my private mail (datenfreihafen.org).
> Did this one end up in your SPAM folder? That would be odd.

It actually did. No clue why :)

-- 
Josef Filzmaier

Re: AT86RF212 based USB-Stick (HUL)

[Stefan Schmidt]

Hello.

On 08/17/2017 01:14 PM, Josef Filzmaier wrote:
> Hello!
> 
> First i want to thank you for taking your time to look at my code and all the
> useful comments. I will go through them step by step.

No problem. I'm very happy to see someone working on adding support for 
a new board to the firmware and driver. Glad to review and test it. 
Sometimes it just takes a few days to come to it.

> I have some general questions:
> 
> My thought was to squash all the commits into a single one once the code is in
> good enough shape. Do you prefer to keep the commit history?

In general I'm not so much interested in the commit history. The 
interest is more to have big changes split into a useful, always 
buildable and easy to review series of commits.

We also want to have new features and bug fixes as well as cleanups in 
separate commits. This all could sound a bit overloading when doing a 
first series of patches (also the git send mail thing I comment on 
below). I try to not be to pedantic but some things I really have.

If I look over your changes a potential series would be:
0001: Update atusb header with hw board define to sync up with firmware
0002: Basic refactor of atusb to enable easy support for a new board 
(hw_name and chip_data changes for example) [This would need to be done 
for rzusb and atusb only and need to build and work without the last patch]
0003: Finally add support for hulusb with all remaining needed changes.

If it turns out that having 2 & 3 as split commits it to complicated and 
the merged patch is not really that big we can also go for a merged version.

If you are going to have some generic bug fixes in there they would need 
to be separated out into signle commits and put in the beginning of the 
series though.

> I did debug the firmware over UART. I thought it might be a useful option to
> other developers (using the DEBUG flag) working on this firmware, but i can of
> course also remove my debug code completely if it is not needed?

Good question. I can see the debugging functionality being useful during 
bringup, just not during the normal lifetime. I'm happy to get the 
uart.c and additional changes as a patch to the firmware as long as it 
is off by default and we do not have to many debug statements sprinkled 
all over the code. :)

>> As for review I can go through your changes on the github links and do
>> some initial review there but the final patches and review to get
>> applied to the tree need to come as git patches to this mailing list.
> 
> I have seen the git send-email tutorial on the linux-wpan homepage (To change
> the homepage). Never used git send-email before but i guess this is how it
> should be done with the code as well, once the code is in good shape.

Yes, git send mail to this list is the final step to get review and the 
patches applied in the end. It can be a bit steep for first time users.
If you have trouble asking here is fine but there should also be some 
good tips in the kernel Documentation folder or on the internet.

What I normally do is something like this:

git format-patch --subject-prefix="PATCH bluetooth-next" -s -3 
--cover-letter

git send-email --to=linux-wpan@vger.kernel.org --smtp-server=XXX 
--smtp-user="XXX --smtp-server-port=587 --smtp-encryption=tls 000*

It would take your latest three commits, adjust the subject prefix, make 
sure they are signed off and finally send them to the list through your 
smtp server.

>> I also send you the address from my private mail (datenfreihafen.org).
>> Did this one end up in your SPAM folder? That would be odd.
> 
> It actually did. No clue why :)

Odd, I did never really had trouble with my private address before. 
Thanks for letting me know.

regards
Stefan Schmidt

Re: AT86RF212 based USB-Stick (HUL)

[Josef Filzmaier]

Hi!

I did refactor both repositories. I think they should now be much more 
enjoyable to review ;) - I would however like you to have another quick look 
within my github repo before i git send-mail it to the mailing list.

I rebased the patch of the linux driver to the 4.13-rc5 source code so it 
should be much easier to mainline. It is only a single commit, i was not sure 
how i should separate the commits without having "dead code". I think the 
patch is small enough that one commit is still feasible. [1]

I did separate the firmware into two commits: One that enables debugging 
and one that introduces the new board (with refactoring). [2]

The changes were tested again on the raspberry pi with linux 4.13-rc5 and
both patches applied (Firmware and Kernel).

Today i finally sent you the Busware HUL dongle, so you should receive it
sometime next week.

Regards,
Josef

[1] https://github.com/joseffilzmaier/linux/compare/rpi-4.13.y...joseffilzmaier:atusb-busware-hul-4.13
[2] https://github.com/joseffilzmaier/ben-wpan/compare/busware-hul-final

-- 
Josef Filzmaier

Re: AT86RF212 based USB-Stick (HUL)

[Stefan Schmidt]

Hello.

On 08/18/2017 12:26 PM, Josef Filzmaier wrote:
> Hi!
> 
> I did refactor both repositories. I think they should now be much more
> enjoyable to review ;) - I would however like you to have another quick look
> within my github repo before i git send-mail it to the mailing list.
> 
> I rebased the patch of the linux driver to the 4.13-rc5 source code so it
> should be much easier to mainline. It is only a single commit, i was not sure
> how i should separate the commits without having "dead code". I think the
> patch is small enough that one commit is still feasible. [1]
> 
> I did separate the firmware into two commits: One that enables debugging
> and one that introduces the new board (with refactoring). [2]
> 
> The changes were tested again on the raspberry pi with linux 4.13-rc5 and
> both patches applied (Firmware and Kernel).
> 
> Today i finally sent you the Busware HUL dongle, so you should receive it
> sometime next week.
> 
> Regards,
> Josef
> 
> [1] https://github.com/joseffilzmaier/linux/compare/rpi-4.13.y...joseffilzmaier:atusb-busware-hul-4.13
> [2] https://github.com/joseffilzmaier/ben-wpan/compare/busware-hul-final


That sounds all good. I'm offline at the weekend but I will go over your 
github commit on Monday and test it out.

regards
Stefan Schmidt

Re: AT86RF212 based USB-Stick (HUL)

[Stefan Schmidt]

Hello.

On 08/18/2017 12:26 PM, Josef Filzmaier wrote:
> Hi!
> 
> I did refactor both repositories. I think they should now be much more
> enjoyable to review ;) - I would however like you to have another quick look
> within my github repo before i git send-mail it to the mailing list.

Will do that in a moment.

> I rebased the patch of the linux driver to the 4.13-rc5 source code so it
> should be much easier to mainline. It is only a single commit, i was not sure
> how i should separate the commits without having "dead code". I think the
> patch is small enough that one commit is still feasible. [1]

It looks ok to be in one commit. It also applies cleanly on net-next 
which I use for testing.

> I did separate the firmware into two commits: One that enables debugging
> and one that introduces the new board (with refactoring). [2]

Good.

> The changes were tested again on the raspberry pi with linux 4.13-rc5 and
> both patches applied (Firmware and Kernel).

I did some testing now and so far it all looks good. The combinations I 
tested so far are:
1) ATUSB mainline driver + firmware with your patch
2) ATUSB driver with your patch + mainline firmware version
3) ATUSB driver with your patch + firmware with your patch

No problems spotted so far. Good job! :)

I still need to dig out my rzusb hardware and test it there as well.

> Today i finally sent you the Busware HUL dongle, so you should receive it
> sometime next week.

It arrived, thanks a lot. How would I go about flashing it? I build the 
firmware already but I'm a bit unsure how the flashing would go. Do I 
need JTAG or SPI or can it be done with the Atmel DFU variant (I think 
the tool is called dfu-programmer)?

What would be the commandline for the flashing? Would be nice if we 
could document that for others.

regards
Stefan Schmidt

Re: AT86RF212 based USB-Stick (HUL)

[Josef Filzmaier]

Hello!

> You would re-send the updated patches with a v2 or similar in the 
> subject prefix.

I have corrected the firmware patch and sent it again with a v2 indicator.
The patch for the kernel is not affected and is now working fine for over a week on my system.

regards
Josef Filzmaier


-- 
Josef Filzmaier

Re: AT86RF212 based USB-Stick (HUL)

[Stefan Schmidt]

Hello.

On 09/04/2017 06:22 PM, Josef Filzmaier wrote:
> Hello
> 
>> That worked and I was able to flash the device and bring it up with the
>> patched driver. It showed up correctly as subHGz device in iwpan. I have
>> no other device to test against but I can trust you on this. Please go
>> ahead and send your final patches to the list so we can get them into
>> the firmware and kernel.
> 
> I have used git send-mail to do so. However, i have found a small bug within
> the firmware after i sent the patch. (Caused by moving code between commits)
> What is the procedure if i want to re-submit a patch(set) to the mailing list?

You would re-send the updated patches with a v2 or similar in the 
subject prefix.

> Also, how does the review process work?

I will have a look at your patches again, review the code, run them 
through some scripts and build testing here and give you feedback.
Once I am happy with them I will give you my Acked-By line in a reply 
for the kernel patch and it should get picked up in a git tree and find 
its way to Linus tree from there.

The firmware patch I will take directly into the corresponding git repo. 
And once I do a new release of the frimware I will generate the binaries 
and make sure they are updated in linux-firmware.

>> I only have one odd thing related to the flashing process. The device
>> you got me comes up in LUFA DFU bootloader mode with the green and red
>> led blinking alternately. In this mode I can use the flash command you
>> gave me above. After the flashing it will stay in this mode and I have
>> to issue a
>>
>> dfu-programmer at90usb1287 reset
>>
>> to get into the firmware/application. After that the device enumerates
>> and the atusb driver takes care of it.
>>
>> That would be all fine if it only would be the case for the initial
>> flashing. For me the device always comes up in the bootloader mode,
>> though. I have to issue the reset command (not the flashing) each time I
>> plug it in.
>>
>> Did I miss something here? Any trick to have the device boot the
>> firmware directly and only go into bootloader mode if the program button
>> on the back side is pressed?
> 
> We did apply a custom bootloader here because this is the behaviour we need
> in order to deliver updates.

Oh, that explains it. :) For my use case of testing the driver against 
the hardware I can deal with it. Having a bootloader available to be 
flashed which jumps directly into the firmware might be nice for others 
though.

regards
Stefan Schmidt

Re: AT86RF212 based USB-Stick (HUL)

[Josef Filzmaier]

Hello

> That worked and I was able to flash the device and bring it up with the 
> patched driver. It showed up correctly as subHGz device in iwpan. I have 
> no other device to test against but I can trust you on this. Please go 
> ahead and send your final patches to the list so we can get them into 
> the firmware and kernel.

I have used git send-mail to do so. However, i have found a small bug within
the firmware after i sent the patch. (Caused by moving code between commits)
What is the procedure if i want to re-submit a patch(set) to the mailing list?

Also, how does the review process work?

> I only have one odd thing related to the flashing process. The device 
> you got me comes up in LUFA DFU bootloader mode with the green and red 
> led blinking alternately. In this mode I can use the flash command you 
> gave me above. After the flashing it will stay in this mode and I have 
> to issue a
> 
> dfu-programmer at90usb1287 reset
> 
> to get into the firmware/application. After that the device enumerates 
> and the atusb driver takes care of it.
> 
> That would be all fine if it only would be the case for the initial 
> flashing. For me the device always comes up in the bootloader mode, 
> though. I have to issue the reset command (not the flashing) each time I 
> plug it in.
> 
> Did I miss something here? Any trick to have the device boot the 
> firmware directly and only go into bootloader mode if the program button 
> on the back side is pressed?

We did apply a custom bootloader here because this is the behaviour we need
in order to deliver updates.

Greetings,
Josef


-- 
Josef Filzmaier

Re: AT86RF212 based USB-Stick (HUL)

[Stefan Schmidt]

Hello.

On 08/26/2017 11:44 PM, Josef Filzmaier wrote:
>     No problems spotted so far. Good job! :)
> 
> Very good :) I am currently on vacation but will be available again late 
> next week. I will then update my patches. Where can i find the net-next 
> repository?

I meant bluetooth-next here. Sorry for giving the wrong name. The repo 
can be found here:

https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/

> 
>     It arrived, thanks a lot. How would I go about flashing it? I build the
>     firmware already but I'm a bit unsure how the flashing would go. Do I
>     need JTAG or SPI or can it be done with the Atmel DFU variant (I think
>     the tool is called dfu-programmer)?
> 
>     What would be the commandline for the flashing? Would be nice if we
>     could document that for others.
> 
> I used the following commands which worked for me:

Thanks.

> 
> avr-objcopy -O ihex -R .signature -R .fuse -R .eeprom hulusb.elf hulusb.hex

We should integrate that into the Makefile when building for hulusb.

> dfu-programmer at90usb1287 flash hulusb.hex

That worked and I was able to flash the device and bring it up with the 
patched driver. It showed up correctly as subHGz device in iwpan. I have 
no other device to test against but I can trust you on this. Please go 
ahead and send your final patches to the list so we can get them into 
the firmware and kernel.

I only have one odd thing related to the flashing process. The device 
you got me comes up in LUFA DFU bootloader mode with the green and red 
led blinking alternately. In this mode I can use the flash command you 
gave me above. After the flashing it will stay in this mode and I have 
to issue a

dfu-programmer at90usb1287 reset

to get into the firmware/application. After that the device enumerates 
and the atusb driver takes care of it.

That would be all fine if it only would be the case for the initial 
flashing. For me the device always comes up in the bootloader mode, 
though. I have to issue the reset command (not the flashing) each time I 
plug it in.

Did I miss something here? Any trick to have the device boot the 
firmware directly and only go into bootloader mode if the program button 
on the back side is pressed?

regards
Stefan Schmidt

Re: AT86RF212 based USB-Stick (HUL)

[Alexander Aring]

Hi,

2017-08-03 2:59 GMT-04:00 Stefan Schmidt <stefan@osg.samsung.com>:
...
>
> To be honest I would first want to verify that your communication between
> the atusb driver and the firmware is actually working correctly.
>
> If you flashed a unmodified rzusb firmware on the device you would have to
> be very lucky that everything would just work out of the box. If this design
> uses the same MCU  it would help a lot (please confirm) but the state
> handling of the rx/tx logic inside the firmware might still be slightly
> different for the 212 compared top the 230/231. The actual 212 kernel driver
> might give some hints about that. I do not know off hand.
>

Please take care of Errata of at86rf212 [0]. The reset doesn't work
you need to change to TRX_OFF after reset... something like that. Not
sure if atusb firmware really does that.
But this is more just like that... set CLKM stuff etc. Simple see
workaround at [0].

- Alex

[0] http://www.atmel.com/images/doc8168.pdf

Re: AT86RF212 based USB-Stick (HUL)

[Stefan Schmidt]

Hello.

On 08/02/2017 06:00 PM, Josef Filzmaier wrote:
> Hello everyone!
> 
> Disclaimer: I am new to kernel driver development
> 
> I'm trying to get the BUSWARE HUL stick [1] to work using the atusb driver.

Interesting. First time I see this device. Pity its now longr available. 
It would be nice to play around with the RF212 version of the atmel chips.

> I know this is not officially supported, but this stick is very similar to the
> rzusb stick which is stated work experimentally on the linux-wpan website.

Does it use the exact same MCU to drive the transceiver?

> I flashed the stick with the atben firmware using dfu-programmer and it seems to
> be working quite nicely.

How did you verify that it works nicely? You said there is no USB 
communication going on.

Did you actually change anything in the firmware at all? Keep in mind 
that the firmware also has some parts of the send and receive logic 
which might need adaption for the 212 as well.

> I'm on Kernel 4.9 lts with arm architecture (raspberry pi b+)

Hmm, 4.9 is a bit older and might miss some fixes from the stack. Any 
chance you could run that with a newer kernel? Its a USB device which 
could give you a way quicker development env on a normal desktop or 
laptop machine.

> I have modified the atusb driver to support the at86rf212 chip (inspired by the
> at86rf230 driver). It seems to be working just fine.

Do you have the link to the code somewhere? Also the dmesg output of the 
atusb driver when inserting the usb stick would be interesting to see.

  I can configure the stick
> as i like with the iwpan tool, so the configuration over usb seems to be
> working. Also, i can see the wpan0 interface and can create a lowpan interface
> on top of it (as described on the lowpan website).

This mostly depends on how you changed the atusb driver code. Its the 
driver who sets up the device and that makes it visible to the userspace 
tools.

> However, using the lowpan interface has no effect. No data gets sent over USB.
> I am able to capture the traffic using tshark, but the data never arrives at the
> atusb driver's atusb_xmit() function.
> 
> My idea currently is to put printk statements within the kernel to detect
> where the data gets lost. I can capture the data with wireshark so i should be
> able to find my calls somewhere in the kernel code.
> 
> Do you have any suggestions as to where i should start my debugging adventure?
> I cannot seem to find where a socket call is initiated and how it is propageted
> down to the driver level.

To be honest I would first want to verify that your communication 
between the atusb driver and the firmware is actually working correctly.

If you flashed a unmodified rzusb firmware on the device you would have 
to be very lucky that everything would just work out of the box. If this 
design uses the same MCU  it would help a lot (please confirm) but the 
state handling of the rx/tx logic inside the firmware might still be 
slightly different for the 212 compared top the 230/231. The actual 212 
kernel driver might give some hints about that. I do not know off hand.

regards
Stefan Schmidt

AT86RF212 based USB-Stick (HUL)

[Josef Filzmaier]

Hello everyone!

Disclaimer: I am new to kernel driver development

I'm trying to get the BUSWARE HUL stick [1] to work using the atusb driver.
I know this is not officially supported, but this stick is very similar to the 
rzusb stick which is stated work experimentally on the linux-wpan website.

I flashed the stick with the atben firmware using dfu-programmer and it seems to 
be working quite nicely.

I'm on Kernel 4.9 lts with arm architecture (raspberry pi b+)

I have modified the atusb driver to support the at86rf212 chip (inspired by the 
at86rf230 driver). It seems to be working just fine. I can configure the stick 
as i like with the iwpan tool, so the configuration over usb seems to be 
working. Also, i can see the wpan0 interface and can create a lowpan interface 
on top of it (as described on the lowpan website).

However, using the lowpan interface has no effect. No data gets sent over USB. 
I am able to capture the traffic using tshark, but the data never arrives at the 
atusb driver's atusb_xmit() function.

My idea currently is to put printk statements within the kernel to detect 
where the data gets lost. I can capture the data with wireshark so i should be 
able to find my calls somewhere in the kernel code.

Do you have any suggestions as to where i should start my debugging adventure? 
I cannot seem to find where a socket call is initiated and how it is propageted 
down to the driver level.

Any help welcome!

[1] http://www.busware.de/tiki-index.php?page=RF212USB

-- 
Josef Filzmaier