[PATCH atubs-fw 0/4] ATUSB firmware changes towards a 0.2 release

[PATCH atubs-fw 0/4] ATUSB firmware changes towards a 0.2 release

[Stefan Schmidt]

Hello.

Nothing to be appliad to the kernel but rather the atusb firmware repo. Just
sending it here as it is releated to the mainline driver and the device users
are reading here.

These are the four patches I consider we need to have a working 0.2 release.
The revert might be only needed for my qemu setup with USB passthrough, but
without it I'm not able to get the device to show up in qemu. Thoughts
appreciated.

Using RX_AACK_ON sounds like a good idea as we loose nothing but work also work
well with nodes using ARET.

Bumping to version 0.2 and adding the need magic to add a valid DFU suffix to
the firmware file. I will followup with a mail attaching the binary I'm using
right now and I consider the final 0.2 if everyone agrees with these patches.

Stefan Schmidt (4):
  Revert "atusb/fw/usb/: enable MCU reset on USB bus reset after config
    selection"
  atusb/fw: Use RX_AACK_ON instead of RX_ON in the firmware.
  atusb/fw: Add build system support for adding a DFU suffix to the fw
    file
  atusb/fw: Bump minor version to mark first public release.

 atusb/fw/Makefile            | 17 +++++++++++++----
 atusb/fw/include/atusb/ep0.h |  3 ++-
 atusb/fw/mac.c               |  6 +++---
 atusb/fw/usb/atu2.c          |  7 +------
 atusb/fw/usb/usb.c           |  1 -
 atusb/fw/usb/usb.h           |  1 -
 6 files changed, 19 insertions(+), 16 deletions(-)

regards
Stefan Schmidt

-- 
2.1.0

[PATCH atubs-fw 1/4] Revert "atusb/fw/usb/: enable MCU reset on USB bus reset after config selection"

[Stefan Schmidt]

This reverts commit 9b2696b8488dbc39b0fdcdefdfad775913cb6e2d.

With this patch ATUSB resets constantly when I use it in QEMU with USB
poassthrough.

Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
---
 atusb/fw/usb/atu2.c | 7 +------
 atusb/fw/usb/usb.c  | 1 -
 atusb/fw/usb/usb.h  | 1 -
 3 files changed, 1 insertion(+), 8 deletions(-)

diff --git a/atusb/fw/usb/atu2.c b/atusb/fw/usb/atu2.c
index 409b8e0..e030bfa 100644
--- a/atusb/fw/usb/atu2.c
+++ b/atusb/fw/usb/atu2.c
@@ -247,12 +247,6 @@ void usb_reset(void)
 }
 
 
-void usb_enable_bus_reset(void)
-{
-	UDCON |= 1 << RSTCPU;		/* reset CPU on bus reset */
-}
-
-
 void usb_init(void)
 {
 	USBCON |= 1 << FRZCLK;		/* freeze the clock */
@@ -269,6 +263,7 @@ void usb_init(void)
 
 	UDCON &= ~(1 << DETACH);	/* attach the pull-up */
 	UDIEN = 1 << EORSTE;		/* enable device interrupts  */
+//	UDCON |= 1 << RSTCPU;		/* reset CPU on bus reset */
 
 	ep_init();
 }
diff --git a/atusb/fw/usb/usb.c b/atusb/fw/usb/usb.c
index 20b4d5f..2a2f720 100644
--- a/atusb/fw/usb/usb.c
+++ b/atusb/fw/usb/usb.c
@@ -119,7 +119,6 @@ bool handle_setup(const struct setup_request *setup)
 	case TO_DEVICE(SET_CONFIGURATION):
 		if (setup->wValue != config_descriptor[5])
 			return 0;
-		usb_enable_bus_reset();
 		break;
 
 	/*
diff --git a/atusb/fw/usb/usb.h b/atusb/fw/usb/usb.h
index 32d8ad7..6428ccd 100644
--- a/atusb/fw/usb/usb.h
+++ b/atusb/fw/usb/usb.h
@@ -182,7 +182,6 @@ bool handle_setup(const struct setup_request *setup);
 void set_addr(uint8_t addr);
 void usb_ep_change(struct ep_descr *ep);
 void usb_reset(void);
-void usb_enable_bus_reset(void);
 void usb_init(void);
 
 #endif /* !USB_H */
-- 
2.1.0

Re: [PATCH atubs-fw 1/4] Revert "atusb/fw/usb/: enable MCU reset on USB bus reset after config selection"

[Alexander Aring]

On Wed, May 20, 2015 at 03:18:11PM +0200, Stefan Schmidt wrote:
> This reverts commit 9b2696b8488dbc39b0fdcdefdfad775913cb6e2d.
> 
> With this patch ATUSB resets constantly when I use it in QEMU with USB
> poassthrough.
> 
> Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

Acked-by: Alexander Aring <alex.aring@gmail.com>

Yea, atusb running now with qemu version behind 1.6.2 on my side :-)
I/We always had issues with newer qemu releases.

- Alex

Re: [PATCH atubs-fw 1/4] Revert "atusb/fw/usb/: enable MCU reset on USB bus reset after config selection"

[Stefan Schmidt]

Hello.

[resend as I dropped cc :(]

On 20/05/15 17:33, Alexander Aring wrote:
> On Wed, May 20, 2015 at 03:18:11PM +0200, Stefan Schmidt wrote:
>> This reverts commit 9b2696b8488dbc39b0fdcdefdfad775913cb6e2d.
>>
>> With this patch ATUSB resets constantly when I use it in QEMU with USB
>> poassthrough.
>>
>> Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
> Acked-by: Alexander Aring <alex.aring@gmail.com>
>
> Yea, atusb running now with qemu version behind 1.6.2 on my side :-)
> I/We always had issues with newer qemu releases.

Ah, so you worked around it with staying on an old qemu interesting.

Given that it fixes problems for you and me while I have not seen a 
downside yet I would like to keep this revert for the 0.2 release. We 
can investigate later what the culprit is as long as we have a stable 
setup now.

I run some longer tests with ping6 packets on various sizes and counts 
of 1000 or more. All of them looked good. Stable average rrt and packet 
loss in the range of 1-3%.

Werner, if you do not have any objections please apply these patches to 
the ben-wpan repo. Once that is done we need to think where we want to 
put the firmware file for now. I would think having it on the atusb side 
on qi-hardware would make sense. An alternative would be wpan.cakelabs.org.

I will also try to get in into linux-firmware over the next weeks one we 
are happy with what we have.

regards
Stefan Schmidt

[PATCH atubs-fw 2/4] atusb/fw: Use RX_AACK_ON instead of RX_ON in the firmware.

[Stefan Schmidt]

This allows to run the device in ARET networks as we handle the needed
automated ACK in hardware.

Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
---
 atusb/fw/mac.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/atusb/fw/mac.c b/atusb/fw/mac.c
index 2344b99..08ed00a 100644
--- a/atusb/fw/mac.c
+++ b/atusb/fw/mac.c
@@ -182,7 +182,7 @@ bool mac_rx(int on)
 	if (on) {
 		mac_irq = handle_irq;
 		reg_read(REG_IRQ_STATUS);
-		change_state(TRX_CMD_RX_ON);
+		change_state(TRX_CMD_RX_AACK_ON);
 	} else {
 		mac_irq = NULL;
 		change_state(TRX_CMD_FORCE_TRX_OFF);
@@ -232,9 +232,9 @@ static void do_tx(void *user)
 
 	/*
 	 * Wait until we reach BUSY_TX, so that we command the transition to
-	 * RX_ON which will be executed upon TX completion.
+	 * RX_AACK_ON which will be executed upon TX completion.
 	 */
-	change_state(TRX_CMD_RX_ON);
+	change_state(TRX_CMD_RX_AACK_ON);
 }
 
 
-- 
2.1.0

[PATCH atubs-fw 3/4] atusb/fw: Add build system support for adding a DFU suffix to the fw file

[Stefan Schmidt]

DFU files need to have a valid DFU suffix which provides information about the
USB vendor and product ID it should be used for as well as same basic CRC file
integrity checking. The dfu-suffix tool can add this and got added to dfu-utils
in 0.7.

With the Makefile changes we take the original atusb-bin file, make a copy and
add the DFU suffix it before flashing.

Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
---
 atusb/fw/Makefile | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/atusb/fw/Makefile b/atusb/fw/Makefile
index 653cc56..ecd8b04 100644
--- a/atusb/fw/Makefile
+++ b/atusb/fw/Makefile
@@ -28,7 +28,12 @@ OBJCOPY = $(AVR_PREFIX)objcopy
 #OBJDUMP = $(AVR_PREFIX)objdump
 SIZE = $(AVR_PREFIX)size
 
-USB_ID = 20b7:1540
+# BCD notion is 0xJJMM with JJ being major and MM being minor. Thus 0x0020 is
+# version 0.2 */
+USB_BCD_VERSION = 0020
+USB_VENDOR_ID = 20b7
+USB_PRODUCT_ID = 1540
+USB_ID = $(USB_VENDOR_ID):$(USB_PRODUCT_ID)
 
 OBJS = atusb.o board.o board_app.o sernum.o spi.o descr.o ep0.o \
        dfu_common.o usb.o app-atu2.o mac.o
@@ -80,6 +85,10 @@ boot.elf:	$(BOOT_OBJS)
 		$(BUILD) $(OBJCOPY) -j .text -j .data -O binary $< $@
 		@echo "build #`cat .version`, `ls -l $@`"
 
+%.dfu:		%.bin
+		cp $(NAME).bin $(NAME).dfu
+		dfu-suffix -a $(NAME).dfu -d 0x$(USB_BCD_VERSION) -p 0x$(USB_PRODUCT_ID) -v 0x$(USB_VENDOR_ID)
+
 %.hex:		%.elf
 		$(BUILD) $(OBJCOPY) -j .text -j .data -O ihex $< $@
 		@echo "Size: `$(SIZE) -A boot.hex | sed '/Total */s///p;d'` B"
@@ -87,7 +96,7 @@ boot.elf:	$(BOOT_OBJS)
 # ----- Cleanup ---------------------------------------------------------------
 
 clean:
-		rm -f $(NAME).bin $(NAME).elf
+		rm -f $(NAME).bin $(NAME).elf $(NAME).dfu
 		rm -f $(OBJS) $(OBJS:.o=.d)
 		rm -f boot.hex boot.elf
 		rm -f $(BOOT_OBJS) $(BOOT_OBJS:.o=.d)
@@ -177,8 +186,8 @@ prog-read:
 		ssh $(HOST) avrdude -F -p $(CHIP) -c nanonote_atusb \
 		  -U flash:r:mcu.bin:r
 
-dfu:		$(NAME).bin
-		dfu-util -d $(USB_ID) -D $(NAME).bin
+dfu:		$(NAME).dfu
+		dfu-util -d $(USB_ID) -D $(NAME).dfu
 
 update:		$(NAME).bin
 		-atrf-reset -a
-- 
2.1.0

Re: [PATCH atubs-fw 3/4] atusb/fw: Add build system support for adding a DFU suffix to the fw file

[Werner Almesberger]

Stefan Schmidt wrote:
> DFU files need to have a valid DFU suffix which provides information
> about the USB vendor and product ID

Aah, more bureaucracy ! :)

> +		dfu-suffix -a $(NAME).dfu -d 0x$(USB_BCD_VERSION) -p 0x$(USB_PRODUCT_ID) -v 0x$(USB_VENDOR_ID)

Would be nice to keep wc -L <= 80, though.

- Werner

Re: [PATCH atubs-fw 3/4] atusb/fw: Add build system support for adding a DFU suffix to the fw file

[Stefan Schmidt]

Hello.

On 20/05/15 18:31, Werner Almesberger wrote:
> Stefan Schmidt wrote:
>> DFU files need to have a valid DFU suffix which provides information
>> about the USB vendor and product ID
> Aah, more bureaucracy ! :)
>
Yup. :)

Good one is this case though. The suffix add a little crc protection and 
having the ID to make sure we flash it to the right device also sounds 
good to me :)

>> +		dfu-suffix -a $(NAME).dfu -d 0x$(USB_BCD_VERSION) -p 0x$(USB_PRODUCT_ID) -v 0x$(USB_VENDOR_ID)
> Would be nice to keep wc -L <= 80, though.

ok, will change this tomorrow and resend. Going afk now.

regards
Stefan Schmidt

Re: [PATCH atubs-fw 3/4] atusb/fw: Add build system support for adding a DFU suffix to the fw file

[Stefan Schmidt]

[-- Attachment #1: Type: text/plain, Size: 800 bytes --]

Hello.

On 20/05/15 18:39, Stefan Schmidt wrote:
> Hello.
>
> On 20/05/15 18:31, Werner Almesberger wrote:
>> Stefan Schmidt wrote:
>>> DFU files need to have a valid DFU suffix which provides information
>>> about the USB vendor and product ID
>> Aah, more bureaucracy ! :)
>>
> Yup. :)
>
> Good one is this case though. The suffix add a little crc protection
> and having the ID to make sure we flash it to the right device also
> sounds good to me :)
>
>>> +        dfu-suffix -a $(NAME).dfu -d 0x$(USB_BCD_VERSION) -p
>>> 0x$(USB_PRODUCT_ID) -v 0x$(USB_VENDOR_ID)
>> Would be nice to keep wc -L <= 80, though.
>
> ok, will change this tomorrow and resend. Going afk now.
>

Please find the updated patch attached. If you prefer me to resend the
whole series let me know.

regards
Stefan Schmidt


[-- Attachment #2: 0003-atusb-fw-Add-build-system-support-for-adding-a-DFU-s.patch --]
[-- Type: text/x-patch, Size: 2401 bytes --]

 From f910b79aa194f9e0115bea859ede9133421ecb52 Mon Sep 17 00:00:00 2001
From: Stefan Schmidt <stefan@datenfreihafen.org>
Date: Wed, 20 May 2015 11:56:15 +0200
Subject: [PATCH atusb-fw 3/4] atusb/fw: Add build system support for adding a
 DFU suffix to the fw file

DFU files need to have a valid DFU suffix which provides information about the
USB vendor and product ID it should be used for as well as same basic CRC file
integrity checking. The dfu-suffix tool can add this and got added to dfu-utils
in 0.7.

With the Makefile changes we take the original atusb-bin file, make a copy and
add the DFU suffix it before flashing.

Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
---
 atusb/fw/Makefile | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/atusb/fw/Makefile b/atusb/fw/Makefile
index 653cc56..086994a 100644
--- a/atusb/fw/Makefile
+++ b/atusb/fw/Makefile
@@ -28,7 +28,12 @@ OBJCOPY = $(AVR_PREFIX)objcopy
 #OBJDUMP = $(AVR_PREFIX)objdump
 SIZE = $(AVR_PREFIX)size
 
-USB_ID = 20b7:1540
+# BCD notion is 0xJJMM with JJ being major and MM being minor. Thus 0x0020 is
+# version 0.2 */
+USB_BCD_VERSION = 0020
+USB_VENDOR_ID = 20b7
+USB_PRODUCT_ID = 1540
+USB_ID = $(USB_VENDOR_ID):$(USB_PRODUCT_ID)
 
 OBJS = atusb.o board.o board_app.o sernum.o spi.o descr.o ep0.o \
        dfu_common.o usb.o app-atu2.o mac.o
@@ -80,6 +85,11 @@ boot.elf:	$(BOOT_OBJS)
 		$(BUILD) $(OBJCOPY) -j .text -j .data -O binary $< $@
 		@echo "build #`cat .version`, `ls -l $@`"
 
+%.dfu:		%.bin
+		cp $(NAME).bin $(NAME).dfu
+		dfu-suffix -a $(NAME).dfu -d 0x$(USB_BCD_VERSION) -p 0x$(USB_PRODUCT_ID) \
+		  -v 0x$(USB_VENDOR_ID)
+
 %.hex:		%.elf
 		$(BUILD) $(OBJCOPY) -j .text -j .data -O ihex $< $@
 		@echo "Size: `$(SIZE) -A boot.hex | sed '/Total */s///p;d'` B"
@@ -87,7 +97,7 @@ boot.elf:	$(BOOT_OBJS)
 # ----- Cleanup ---------------------------------------------------------------
 
 clean:
-		rm -f $(NAME).bin $(NAME).elf
+		rm -f $(NAME).bin $(NAME).elf $(NAME).dfu
 		rm -f $(OBJS) $(OBJS:.o=.d)
 		rm -f boot.hex boot.elf
 		rm -f $(BOOT_OBJS) $(BOOT_OBJS:.o=.d)
@@ -177,8 +187,8 @@ prog-read:
 		ssh $(HOST) avrdude -F -p $(CHIP) -c nanonote_atusb \
 		  -U flash:r:mcu.bin:r
 
-dfu:		$(NAME).bin
-		dfu-util -d $(USB_ID) -D $(NAME).bin
+dfu:		$(NAME).dfu
+		dfu-util -d $(USB_ID) -D $(NAME).dfu
 
 update:		$(NAME).bin
 		-atrf-reset -a
-- 
2.1.0

[PATCH atubs-fw 4/4] atusb/fw: Bump minor version to mark first public release.

[Stefan Schmidt]

With version 0.2 we made the first public release in binary form of the
firmware. This comes together with the merge of the ATUSB driver to the
mainline linux kernel.

Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
---
 atusb/fw/include/atusb/ep0.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/atusb/fw/include/atusb/ep0.h b/atusb/fw/include/atusb/ep0.h
index d21878f..8b0ab9a 100644
--- a/atusb/fw/include/atusb/ep0.h
+++ b/atusb/fw/include/atusb/ep0.h
@@ -22,10 +22,11 @@
  *
  * 0.0	initial release
  * 0.1  addition of ATUSB_TEST
+ * 0.2  First public release
  */
 
 #define EP0ATUSB_MAJOR	0	/* EP0 protocol, major revision */
-#define EP0ATUSB_MINOR	1	/* EP0 protocol, minor revision */
+#define EP0ATUSB_MINOR	2	/* EP0 protocol, minor revision */
 
 #define	HW_TYPE_100813	0	/* 2010-08-13 */
 #define	HW_TYPE_101216	1	/* 2010-12-16 */
-- 
2.1.0

Re: [PATCH atubs-fw 0/4] ATUSB firmware changes towards a 0.2 release

[Stefan Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

Hello.

On 20/05/15 15:18, Stefan Schmidt wrote:
> Hello.
>
> Nothing to be appliad to the kernel but rather the atusb firmware repo. Just
> sending it here as it is releated to the mainline driver and the device users
> are reading here.
>
> These are the four patches I consider we need to have a working 0.2 release.
> The revert might be only needed for my qemu setup with USB passthrough, but
> without it I'm not able to get the device to show up in qemu. Thoughts
> appreciated.
>
> Using RX_AACK_ON sounds like a good idea as we loose nothing but work also work
> well with nodes using ARET.
>
> Bumping to version 0.2 and adding the need magic to add a valid DFU suffix to
> the firmware file. I will followup with a mail attaching the binary I'm using
> right now and I consider the final 0.2 if everyone agrees with these patches.
>
Binary firmware image attached. Alexander, if you could give that a test
it would be appreciated.

Everyone else with a atusb please test as well if you have the time.

regards
Stefan Schmidt

[-- Attachment #2: atusb-0.2.dfu --]
[-- Type: application/octet-stream, Size: 5800 bytes --]

Re: [PATCH atubs-fw 0/4] ATUSB firmware changes towards a 0.2 release

[Stefan Schmidt]

Hello.

On 20/05/15 15:21, Stefan Schmidt wrote:
> Hello.
>
> On 20/05/15 15:18, Stefan Schmidt wrote:
>> Hello.
>>
>> Nothing to be appliad to the kernel but rather the atusb firmware repo. Just
>> sending it here as it is releated to the mainline driver and the device users
>> are reading here.
>>
>> These are the four patches I consider we need to have a working 0.2 release.
>> The revert might be only needed for my qemu setup with USB passthrough, but
>> without it I'm not able to get the device to show up in qemu. Thoughts
>> appreciated.
>>
>> Using RX_AACK_ON sounds like a good idea as we loose nothing but work also work
>> well with nodes using ARET.
>>
>> Bumping to version 0.2 and adding the need magic to add a valid DFU suffix to
>> the firmware file. I will followup with a mail attaching the binary I'm using
>> right now and I consider the final 0.2 if everyone agrees with these patches.
>>
> Binary firmware image attached. Alexander, if you could give that a test
> it would be appreciated.
>
> Everyone else with a atusb please test as well if you have the time.

The pending patches have been pushed and I tagged the atusb firmware 0.2 
release in git:
http://projects.qi-hardware.com/index.php/p/ben-wpan/source/changes/v0.2-atusb-fw/

The firmware binary should be available from the website soon. If you 
are eager you can get it here:
http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/web/releases/atusb-0.2.dfu

If anyone has patches for the firmware pending or upcoming please CC me. 
I should be able help reviewing, testing and pushing them.

regards
Stefan Schmidt

Re: [PATCH atubs-fw 0/4] ATUSB firmware changes towards a 0.2 release

[Alexander Aring]

On Thu, May 21, 2015 at 04:40:14PM +0200, Stefan Schmidt wrote:
> Hello.
> 
> On 20/05/15 15:21, Stefan Schmidt wrote:
> >Hello.
> >
> >On 20/05/15 15:18, Stefan Schmidt wrote:
> >>Hello.
> >>
> >>Nothing to be appliad to the kernel but rather the atusb firmware repo. Just
> >>sending it here as it is releated to the mainline driver and the device users
> >>are reading here.
> >>
> >>These are the four patches I consider we need to have a working 0.2 release.
> >>The revert might be only needed for my qemu setup with USB passthrough, but
> >>without it I'm not able to get the device to show up in qemu. Thoughts
> >>appreciated.
> >>
> >>Using RX_AACK_ON sounds like a good idea as we loose nothing but work also work
> >>well with nodes using ARET.
> >>
> >>Bumping to version 0.2 and adding the need magic to add a valid DFU suffix to
> >>the firmware file. I will followup with a mail attaching the binary I'm using
> >>right now and I consider the final 0.2 if everyone agrees with these patches.
> >>
> >Binary firmware image attached. Alexander, if you could give that a test
> >it would be appreciated.
> >
> >Everyone else with a atusb please test as well if you have the time.
> 
> The pending patches have been pushed and I tagged the atusb firmware 0.2
> release in git:
> http://projects.qi-hardware.com/index.php/p/ben-wpan/source/changes/v0.2-atusb-fw/
> 
> The firmware binary should be available from the website soon. If you are
> eager you can get it here:
> http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/web/releases/atusb-0.2.dfu
> 
> If anyone has patches for the firmware pending or upcoming please CC me. I
> should be able help reviewing, testing and pushing them.
> 

Maybe send patches to be maintainer of atusb driver? I could review
also some firmware things when it's related to talk the with the
at86rf231 transceiver.

- Alex

Re: [PATCH atubs-fw 0/4] ATUSB firmware changes towards a 0.2 release

[Stefan Schmidt]

Hello.

On 21/05/15 17:39, Alexander Aring wrote:
> On Thu, May 21, 2015 at 04:40:14PM +0200, Stefan Schmidt wrote:
>> Hello.
>>
>> On 20/05/15 15:21, Stefan Schmidt wrote:
>>> Hello.
>>>
>>> On 20/05/15 15:18, Stefan Schmidt wrote:
>>>> Hello.
>>>>
>>>> Nothing to be appliad to the kernel but rather the atusb firmware repo. Just
>>>> sending it here as it is releated to the mainline driver and the device users
>>>> are reading here.
>>>>
>>>> These are the four patches I consider we need to have a working 0.2 release.
>>>> The revert might be only needed for my qemu setup with USB passthrough, but
>>>> without it I'm not able to get the device to show up in qemu. Thoughts
>>>> appreciated.
>>>>
>>>> Using RX_AACK_ON sounds like a good idea as we loose nothing but work also work
>>>> well with nodes using ARET.
>>>>
>>>> Bumping to version 0.2 and adding the need magic to add a valid DFU suffix to
>>>> the firmware file. I will followup with a mail attaching the binary I'm using
>>>> right now and I consider the final 0.2 if everyone agrees with these patches.
>>>>
>>> Binary firmware image attached. Alexander, if you could give that a test
>>> it would be appreciated.
>>>
>>> Everyone else with a atusb please test as well if you have the time.
>> The pending patches have been pushed and I tagged the atusb firmware 0.2
>> release in git:
>> http://projects.qi-hardware.com/index.php/p/ben-wpan/source/changes/v0.2-atusb-fw/
>>
>> The firmware binary should be available from the website soon. If you are
>> eager you can get it here:
>> http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/web/releases/atusb-0.2.dfu
>>
>> If anyone has patches for the firmware pending or upcoming please CC me. I
>> should be able help reviewing, testing and pushing them.
>>
> Maybe send patches to be maintainer of atusb driver?
Guess I can do that if you want. I have some more patches coming but 
they are not ready yet. Mostly catch up with what the stack learned in 
the last months. Adding the hooks inside the driver. Things like 
.set_promiscuous_mode, .set_frame_retries, .set_txpower, etc.

I will add a maintainer patch at the end of this and will send it 
together with that series when ready.

> I could review
> also some firmware things when it's related to talk the with the
> at86rf231 transceiver.

Yeah, there are quite some bits from the at86rf231 driver which will be 
useful in the  firmware. Need to pick them up piece by piece.

regards
Stefan Schmidt

Re: [PATCH atubs-fw 0/4] ATUSB firmware changes towards a 0.2 release

[Alexander Aring]

Hi,

On Thu, May 21, 2015 at 06:39:06PM +0200, Stefan Schmidt wrote:
> Hello.
> 
> On 21/05/15 17:39, Alexander Aring wrote:
> >On Thu, May 21, 2015 at 04:40:14PM +0200, Stefan Schmidt wrote:
> >>Hello.
> >>
> >>On 20/05/15 15:21, Stefan Schmidt wrote:
> >>>Hello.
> >>>
> >>>On 20/05/15 15:18, Stefan Schmidt wrote:
> >>>>Hello.
> >>>>
> >>>>Nothing to be appliad to the kernel but rather the atusb firmware repo. Just
> >>>>sending it here as it is releated to the mainline driver and the device users
> >>>>are reading here.
> >>>>
> >>>>These are the four patches I consider we need to have a working 0.2 release.
> >>>>The revert might be only needed for my qemu setup with USB passthrough, but
> >>>>without it I'm not able to get the device to show up in qemu. Thoughts
> >>>>appreciated.
> >>>>
> >>>>Using RX_AACK_ON sounds like a good idea as we loose nothing but work also work
> >>>>well with nodes using ARET.
> >>>>
> >>>>Bumping to version 0.2 and adding the need magic to add a valid DFU suffix to
> >>>>the firmware file. I will followup with a mail attaching the binary I'm using
> >>>>right now and I consider the final 0.2 if everyone agrees with these patches.
> >>>>
> >>>Binary firmware image attached. Alexander, if you could give that a test
> >>>it would be appreciated.
> >>>
> >>>Everyone else with a atusb please test as well if you have the time.
> >>The pending patches have been pushed and I tagged the atusb firmware 0.2
> >>release in git:
> >>http://projects.qi-hardware.com/index.php/p/ben-wpan/source/changes/v0.2-atusb-fw/
> >>
> >>The firmware binary should be available from the website soon. If you are
> >>eager you can get it here:
> >>http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/web/releases/atusb-0.2.dfu
> >>
> >>If anyone has patches for the firmware pending or upcoming please CC me. I
> >>should be able help reviewing, testing and pushing them.
> >>
> >Maybe send patches to be maintainer of atusb driver?
> Guess I can do that if you want. I have some more patches coming but they
> are not ready yet. Mostly catch up with what the stack learned in the last
> months. Adding the hooks inside the driver. Things like
> .set_promiscuous_mode, .set_frame_retries, .set_txpower, etc.
> 

in case of set_frame_retries above 0 this is will be fun, because you
need to turn then into TX_ARET_ON instead TX_ON state. :-)

In case of promiscuous mode, if the PHR field (the len byte) is evaluated
you need to remember that the phy doesn't filter anything and then the len
could be above 127.

I introduced for this use case the ieee802154_is_valid_psdu_len
function. But depends if the firmware use this value before. It's a mess
when the len field is not correct then you can guess where the lqi byte is.
In case of at86rf231 we need to be sure that the len is not above the
MTU otherwise we have an invalid array dereference of the pdu payload.

I am sure you will care about all these things. :-)

- Alex

Re: [PATCH atubs-fw 0/4] ATUSB firmware changes towards a 0.2 release

[Alexander Aring]

On Thu, May 21, 2015 at 10:44:59PM +0200, Alexander Aring wrote:
> Hi,
> 
> On Thu, May 21, 2015 at 06:39:06PM +0200, Stefan Schmidt wrote:
> > Hello.
> > 
> > On 21/05/15 17:39, Alexander Aring wrote:
> > >On Thu, May 21, 2015 at 04:40:14PM +0200, Stefan Schmidt wrote:
> > >>Hello.
> > >>
> > >>On 20/05/15 15:21, Stefan Schmidt wrote:
> > >>>Hello.
> > >>>
> > >>>On 20/05/15 15:18, Stefan Schmidt wrote:
> > >>>>Hello.
> > >>>>
> > >>>>Nothing to be appliad to the kernel but rather the atusb firmware repo. Just
> > >>>>sending it here as it is releated to the mainline driver and the device users
> > >>>>are reading here.
> > >>>>
> > >>>>These are the four patches I consider we need to have a working 0.2 release.
> > >>>>The revert might be only needed for my qemu setup with USB passthrough, but
> > >>>>without it I'm not able to get the device to show up in qemu. Thoughts
> > >>>>appreciated.
> > >>>>
> > >>>>Using RX_AACK_ON sounds like a good idea as we loose nothing but work also work
> > >>>>well with nodes using ARET.
> > >>>>
> > >>>>Bumping to version 0.2 and adding the need magic to add a valid DFU suffix to
> > >>>>the firmware file. I will followup with a mail attaching the binary I'm using
> > >>>>right now and I consider the final 0.2 if everyone agrees with these patches.
> > >>>>
> > >>>Binary firmware image attached. Alexander, if you could give that a test
> > >>>it would be appreciated.
> > >>>
> > >>>Everyone else with a atusb please test as well if you have the time.
> > >>The pending patches have been pushed and I tagged the atusb firmware 0.2
> > >>release in git:
> > >>http://projects.qi-hardware.com/index.php/p/ben-wpan/source/changes/v0.2-atusb-fw/
> > >>
> > >>The firmware binary should be available from the website soon. If you are
> > >>eager you can get it here:
> > >>http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/web/releases/atusb-0.2.dfu
> > >>
> > >>If anyone has patches for the firmware pending or upcoming please CC me. I
> > >>should be able help reviewing, testing and pushing them.
> > >>
> > >Maybe send patches to be maintainer of atusb driver?
> > Guess I can do that if you want. I have some more patches coming but they
> > are not ready yet. Mostly catch up with what the stack learned in the last
> > months. Adding the hooks inside the driver. Things like
> > .set_promiscuous_mode, .set_frame_retries, .set_txpower, etc.
> > 
> 
> in case of set_frame_retries above 0 this is will be fun, because you

meant:

s/above/above or equal/

- Alex

Re: [PATCH atubs-fw 0/4] ATUSB firmware changes towards a 0.2 release

[Stefan Schmidt]

Hello.

On 21/05/15 22:45, Alexander Aring wrote:
> Hi,
>
> On Thu, May 21, 2015 at 06:39:06PM +0200, Stefan Schmidt wrote:
>> Hello.
>>
>> On 21/05/15 17:39, Alexander Aring wrote:
>>> On Thu, May 21, 2015 at 04:40:14PM +0200, Stefan Schmidt wrote:
>>>> Hello.
>>>>
>>>> On 20/05/15 15:21, Stefan Schmidt wrote:
>>>>> Hello.
>>>>>
>>>>> On 20/05/15 15:18, Stefan Schmidt wrote:
>>>>>> Hello.
>>>>>>
>>>>>> Nothing to be appliad to the kernel but rather the atusb firmware repo. Just
>>>>>> sending it here as it is releated to the mainline driver and the device users
>>>>>> are reading here.
>>>>>>
>>>>>> These are the four patches I consider we need to have a working 0.2 release.
>>>>>> The revert might be only needed for my qemu setup with USB passthrough, but
>>>>>> without it I'm not able to get the device to show up in qemu. Thoughts
>>>>>> appreciated.
>>>>>>
>>>>>> Using RX_AACK_ON sounds like a good idea as we loose nothing but work also work
>>>>>> well with nodes using ARET.
>>>>>>
>>>>>> Bumping to version 0.2 and adding the need magic to add a valid DFU suffix to
>>>>>> the firmware file. I will followup with a mail attaching the binary I'm using
>>>>>> right now and I consider the final 0.2 if everyone agrees with these patches.
>>>>>>
>>>>> Binary firmware image attached. Alexander, if you could give that a test
>>>>> it would be appreciated.
>>>>>
>>>>> Everyone else with a atusb please test as well if you have the time.
>>>> The pending patches have been pushed and I tagged the atusb firmware 0.2
>>>> release in git:
>>>> http://projects.qi-hardware.com/index.php/p/ben-wpan/source/changes/v0.2-atusb-fw/
>>>>
>>>> The firmware binary should be available from the website soon. If you are
>>>> eager you can get it here:
>>>> http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/web/releases/atusb-0.2.dfu
>>>>
>>>> If anyone has patches for the firmware pending or upcoming please CC me. I
>>>> should be able help reviewing, testing and pushing them.
>>>>
>>> Maybe send patches to be maintainer of atusb driver?
>> Guess I can do that if you want. I have some more patches coming but they
>> are not ready yet. Mostly catch up with what the stack learned in the last
>> months. Adding the hooks inside the driver. Things like
>> .set_promiscuous_mode, .set_frame_retries, .set_txpower, etc.
>>
> in case of set_frame_retries above 0 this is will be fun, because you
> need to turn then into TX_ARET_ON instead TX_ON state. :-)
>
> In case of promiscuous mode, if the PHR field (the len byte) is evaluated
> you need to remember that the phy doesn't filter anything and then the len
> could be above 127.
>
> I introduced for this use case the ieee802154_is_valid_psdu_len
> function. But depends if the firmware use this value before. It's a mess
> when the len field is not correct then you can guess where the lqi byte is.
> In case of at86rf231 we need to be sure that the len is not above the
> MTU otherwise we have an invalid array dereference of the pdu payload.
Yeah, some of the atusb improvements will need firmware support. I need 
to deal with this once I come to that parts. Most likely I will batch 
them all together to have only one new firmware release with all needed 
features. Be prepared that I will ask you some questions about your 
at86rf2xx driver changes. :)

> I am sure you will care about all these things. :-)

I hope so, but one can never be sure. :)

regards
Stefan Schmidt