Stefan Schmidt | 4 May 16:48 2010

[PATCH 1/5] ieee802154/cc2420: Fix packet length value.

This is an addition to the last fix for adding the length byte. With hardware
FCS enabled we are obliged to set the length including the 2 bytes for the
FCS. Our skb does only have the len for the data it contains so we need to
adjust it for the length byte.

Signed-off-by: Stefan Schmidt <stefan@...>
---
 drivers/ieee802154/cc2420.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/ieee802154/cc2420.c b/drivers/ieee802154/cc2420.c
index fd072ce..3cc2724 100644
--- a/drivers/ieee802154/cc2420.c
+++ b/drivers/ieee802154/cc2420.c
 <at>  <at>  -213,6 +213,8  <at>  <at>  static int
 cc2420_write_txfifo(struct cc2420_local *lp, u8 *data, u8 len)
 {
 	int status;
+	/* Length byte must include FCS even if calculated in hardware */
+	int len_byte = len + 2;
 	struct spi_message msg;
 	struct spi_transfer xfer_head = {
 		.len		= 1,
 <at>  <at>  -221,7 +223,7  <at>  <at>  cc2420_write_txfifo(struct cc2420_local *lp, u8 *data, u8 len)
 	};
 	struct spi_transfer xfer_len = {
 		.len		= 1,
-		.tx_buf		= &len,
+		.tx_buf		= &len_byte,
 	};
(Continue reading)

Stefan Schmidt | 4 May 16:48 2010

[PATCH 2/5] ieee802154/cc2420: Send only the real packet into the stack.

With hardware FCS enabled the chip replaces the FCS bytes with a correlation
value, a FCS flag and the rssi value.

We need to make sure that both bytes are getting clipped before sending them
into the stack as functions checking for the length will fail otherwise.

Signed-off-by: Stefan Schmidt <stefan@...>
---
 drivers/ieee802154/cc2420.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/ieee802154/cc2420.c b/drivers/ieee802154/cc2420.c
index 3cc2724..f8fab59 100644
--- a/drivers/ieee802154/cc2420.c
+++ b/drivers/ieee802154/cc2420.c
 <at>  <at>  -367,8 +367,9  <at>  <at>  static int cc2420_rx(struct cc2420_local *lp)
 		return -EINVAL;
 	}

-	skb_trim(skb, len-1); /* We do not put CRC and Corr into
-							the frame, but remain rssi value */
+	/* Clip last two bytes. When using hardware FCS they get replaced with
+	 * correlation value, FCS flag and RSSI value */
+	skb_trim(skb, len-2);

 	ieee802154_rx_irqsafe(lp->dev, skb, lqi);

--

-- 
1.7.1

(Continue reading)

Stefan Schmidt | 4 May 16:48 2010

[PATCH 4/5] HACK: ieee802154/cc2420: Avoid gpio_request for fifop.

When gpio_request()'ing the fifop GPIO we get back an -EBUSY. It seems to be
related to fifop being 0 and the gpiolib may have some special handling for 0.
As this is "only" a resource allocation call which does not do anything with the
GPIO we are still able to use it correctly without it and it works as expected.

However this needs to be worked out completely and a real fix is needed.
---
 drivers/ieee802154/cc2420.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/ieee802154/cc2420.c b/drivers/ieee802154/cc2420.c
index 983800f..7839ddb 100644
--- a/drivers/ieee802154/cc2420.c
+++ b/drivers/ieee802154/cc2420.c
 <at>  <at>  -588,10 +588,12  <at>  <at>  static int __devinit cc2420_probe(struct spi_device *spi)
 	ret = gpio_request(lp->pdata->cca, "cca");
 	if (ret)
 		goto err_free_gpio_fifo;
+#if 0
 	/* This is causing problems as fifop is gpio 0 ? */
 	ret = gpio_request(lp->pdata->fifop, "fifop");
 	if (ret)
 		goto err_free_gpio_cca;
+#endif
 	ret = gpio_request(lp->pdata->sfd, "sfd");
 	if (ret)
 		goto err_free_gpio_fifop;
 <at>  <at>  -700,8 +702,8  <at>  <at>  err_free_gpio_sfd:
 	gpio_free(lp->pdata->sfd);
 err_free_gpio_fifop:
(Continue reading)

Stefan Schmidt | 4 May 16:48 2010

[PATCH 5/5] [ARM]: mach/pxa: Add platform data for cc2420 driver.

Now that the cc2420 driver has landed mainline we could supply the GPIO setup
via platform data and remove them from the MFP table.

Signed-off-by: Stefan Schmidt <stefan@...>
---
 arch/arm/mach-pxa/imote2.c |   27 ++++++++++++++++++---------
 1 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-pxa/imote2.c b/arch/arm/mach-pxa/imote2.c
index 5b0862d..c99f04e 100644
--- a/arch/arm/mach-pxa/imote2.c
+++ b/arch/arm/mach-pxa/imote2.c
 <at>  <at>  -23,6 +23,7  <at>  <at> 
 #include <linux/i2c.h>
 #include <linux/mfd/da903x.h>
 #include <linux/sht15.h>
+#include <linux/spi/cc2420.h>

 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 <at>  <at>  -39,6 +40,13  <at>  <at> 
 #include "devices.h"
 #include "generic.h"

+#define GPIO_FIFOP	0
+#define GPIO_SFD	16
+#define GPIO_RESET	22
+#define GPIO_FIFO	114
+#define GPIO_VREG	115
+#define GPIO_CCA	116
(Continue reading)

Stefan Schmidt | 4 May 16:48 2010

[PATCH 3/5] ieee802154/cc2420: Fix some typos and wording

Most of it is trivial but should help to understand the debugging output
better.

Signed-off-by: Stefan Schmidt <stefan@...>
---
 drivers/ieee802154/cc2420.c |   15 ++++++++-------
 1 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/ieee802154/cc2420.c b/drivers/ieee802154/cc2420.c
index f8fab59..983800f 100644
--- a/drivers/ieee802154/cc2420.c
+++ b/drivers/ieee802154/cc2420.c
 <at>  <at>  -496,7 +496,7  <at>  <at>  static void cc2420_sfd_irqwork(struct work_struct *work)
 		= container_of(work, struct cc2420_local, sfd_irqwork);
 	unsigned long flags;

-	dev_dbg(&lp->spi->dev, "fifop interrupt received\n");
+	dev_dbg(&lp->spi->dev, "sfd interrupt received\n");

 	spin_lock_irqsave(&lp->lock, flags);
 	if (lp->is_tx) {
 <at>  <at>  -544,7 +544,7  <at>  <at>  static int cc2420_hw_init(struct cc2420_local *lp)
 		udelay(1);
 	} while (!(status & CC2420_STATUS_XOSC16M_STABLE));

-	dev_info(&lp->spi->dev, "oscillator succesfully brought up \n");
+	dev_info(&lp->spi->dev, "oscillator succesfully brought up\n");

 	return 0;
 error_ret:
(Continue reading)

Stefan Schmidt | 4 May 16:48 2010

Latest fixes for CC2420

Hello.

With these patches I'm finally able to  have a working 802.15.4 setup with two
imotes. One as coordinator and one as client. The packets sniffed on the air are
also looking good now in wireshark.

I would like to get the first three patches applied. The fourth is a hack to
work around the gpio_request problem and should not get applied. We need a real
fix for this. Still it is needed to get the driver through probing.

The last patch is only appended as reference. It will go to the arm list once
the mac802154 stack and the cc2420 driver hits mainline.

regards
Stefan Schmidt

------------------------------------------------------------------------------
agogolev | 5 May 15:35 2010
Picon

cc2420 linux driver status?

Hello everyone,
I asked a questiona month ago, but nobody answered me, so I'm asking again:
Does anyone have a linux driver for TI/Chipcon cc2420 radio?
Or may be somebody knows where to get the compilable source?

It looks like people are using it, but yet I couldn't figure out where to
download it.
--

-- 
Respectfully yours, Alexander E. Gogolev

------------------------------------------------------------------------------
Jonathan Cameron | 5 May 16:47 2010
Picon
Picon

Re: cc2420 linux driver status?

On 05/05/10 14:35, agogolev wrote:
> Hello everyone,
> I asked a questiona month ago, but nobody answered me, so I'm asking again:
> Does anyone have a linux driver for TI/Chipcon cc2420 radio?
> Or may be somebody knows where to get the compilable source?
> 
> It looks like people are using it, but yet I couldn't figure out where to
> download it.

As per Stefan Schmidt's email to this list yesterday, he has it working.

Apply his latest patch set to a clone of the linux-zigbee kernel git tree,

browse it at:

http://linux-zigbee.git.sourceforge.net/git/gitweb.cgi?p=linux-zigbee/kernel;a=summary

or

git clone  git://linux-zigbee.git.sourceforge.net/gitroot/linux-zigbee/kernel

Then take a look at the devel branch.

------------------------------------------------------------------------------
Xue Liu | 5 May 17:08 2010
Picon

Re: [PATCH 1/5] ieee802154/cc2420: Fix packet length value.

Hi, Stefan

2010/5/4 Stefan Schmidt <stefan <at> datenfreihafen.org>
This is an addition to the last fix for adding the length byte. With hardware
FCS enabled we are obliged to set the length including the 2 bytes for the
FCS. Our skb does only have the len for the data it contains so we need to
adjust it for the length byte.

I still don`t know why I must add 2 bytes for the FCS. I read cc2420 datasheet again.
In Page 38, it said:
"In transmit mode the FCS is appended at the correct position defined by the length
filed. The FCS is not written to the TXFIFO, but stored in a separate 16-bit register."

I think FCS should automatically add to MPDU by cc2420. 

Could you help me out? Thx

xue liu

 
Signed-off-by: Stefan Schmidt <stefan-OrPQZGeq07wqhVmZOOOmNx2eb7JE58TQ@public.gmane.org>
---
 drivers/ieee802154/cc2420.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/ieee802154/cc2420.c b/drivers/ieee802154/cc2420.c
index fd072ce..3cc2724 100644
--- a/drivers/ieee802154/cc2420.c
+++ b/drivers/ieee802154/cc2420.c
<at> <at> -213,6 +213,8 <at> <at> static int
 cc2420_write_txfifo(struct cc2420_local *lp, u8 *data, u8 len)
 {
       int status;
+       /* Length byte must include FCS even if calculated in hardware */
+       int len_byte = len + 2;
       struct spi_message msg;
       struct spi_transfer xfer_head = {
               .len            = 1,
<at> <at> -221,7 +223,7 <at> <at> cc2420_write_txfifo(struct cc2420_local *lp, u8 *data, u8 len)
       };
       struct spi_transfer xfer_len = {
               .len            = 1,
-               .tx_buf         = &len,
+               .tx_buf         = &len_byte,
       };
       struct spi_transfer xfer_buf = {
               .len            = len,
--
1.7.1


------------------------------------------------------------------------------
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel

------------------------------------------------------------------------------
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@...
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Xue Liu | 5 May 17:24 2010
Picon

Re: Latest fixes for CC2420

Hi, Stefan


Thanks a lot for you patches. I will test on my imote2 tomorrow.
But I still have some questions.
1. Is OpenEmbedded supporting imote2 now? With Jonathan`s help, I used OE to make a working filesystem for cc2420 develpment. But I did not update it for a long time.

2. How to cross compile zigbee user tools. I mean "configure" don`t have options to include path of zibgee linux source.

3. What "sniffer" or device do you use to corporate with wireshark?



2010/5/4 Stefan Schmidt <stefan-OrPQZGeq07wqhVmZOOOmNx2eb7JE58TQ@public.gmane.org>
Hello.

With these patches I'm finally able to  have a working 802.15.4 setup with two
imotes. One as coordinator and one as client. The packets sniffed on the air are
also looking good now in wireshark.

I would like to get the first three patches applied. The fourth is a hack to
work around the gpio_request problem and should not get applied. We need a real
fix for this. Still it is needed to get the driver through probing.

The last patch is only appended as reference. It will go to the arm list once
the mac802154 stack and the cc2420 driver hits mainline.

regards
Stefan Schmidt

------------------------------------------------------------------------------
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel

------------------------------------------------------------------------------
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@...
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel

Gmane