Re: [linux-usb-devel] Large control write transfers / zero-length-packet at end
On Wed, Sep 20, 2006 at 06:28:15PM -0700, David Brownell wrote: On Wednesday 20 September 2006 10:58 am, Harald Welte wrote: When a control-out transfer takes, the host controller sends a SETUP packet followed by as many OUT/DATA packets as necessary to transfer the data, but no zero-length OUT/DATA. There is a zero-length IN packet to terminate the transfer (the status stage), but that's present regardless of the amount of data. This really solves my problem. One fundamental problem (at least given the SAM7 register set) remains: I have no indication to decide which of the data OUT packets was the last, and when the device should return the status stage IN packet. The at91_udc driver should work on those at91sam7 parts, and I think some uClinux folk have done just that. AT91SAM7 != AT91RM9200. I don't think anyone runs [uC]linux in devices with 64/128k flash and half that amount of RAM. And then, I need all those resources for the actual job, not an OS. So I'm developing everything from the bare hardware onwards. Actually, DFU is the only part missing. Yesterday I finally got the USB side of DFU working, thanks to Alan's comments. So once again thanks for all of your help, time to close the thread, issue resolved :) -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ We all know Linux is great...it does infinite loops in 5 seconds. -- Linus pgpwn2Snok886.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Large control write transfers / zero-length-packet at end
This really solves my problem. One fundamental problem (at least given the SAM7 register set) remains: I have no indication to decide which of the data OUT packets was the last, and when the device should return the status stage IN packet. The at91_udc driver should work on those at91sam7 parts, and I think some uClinux folk have done just that. AT91SAM7 != AT91RM9200. Certainly not, But the USB peripheral controller is the same, last I checked. The whole AT91 series uses the same controller designs, and if folk don't run uClinux on your particular part, they've done so on others. I don't think anyone runs [uC]linux in devices with 64/128k flash and half that amount of RAM. And then, I need all those resources for the actual job, not an OS. So I'm developing everything from the bare hardware onwards. Which is why I pointed you at working code, using the same controller, already solving that problem. - Dave - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Large control write transfers / zero-length-packet at end
Hi! I'm currently writing a USB device firmware for a Free Software / Free hardware project based on an AT91SAM7 (see http://www.openpcd.org/) In order to implement USB DFU (device firmware upgrade), I need support for big control out transfers (larger than the 8 byte control endpoint size). I suppose this is a rarely used feature, since most control transfers are used to read information from a device (control in transfers). When I use libusb / usbdevio on a 2.6.17.13 kernel to send a control out transfer of e.g. 256 bytes, then I expect it to create 32 usb data out packets of each 8 bytes size, plus one zero-length packet to terminate the transfer. I'm using usb_control_msg() to do the transfer. However, on the AT91SAM7 I only see the 32 usb data out packets, and no ZLP (zero-length-packet). Transfers of an non-modulo-eight size (e.g. 31 packets of 8 bytes, plus one four-byte packet) work perfectly fine, since in this case no ZLP is supposed to be at the end of the transfer. The host controller is UHCI in this case. Am I somehow assuming something wrong? Is there anything at all on the host software stack that controls the generation of a ZLP at the end of the transfer, or is this all done by the host controller? Any other ideas? -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ We all know Linux is great...it does infinite loops in 5 seconds. -- Linus pgpGdFq1Bk9sq.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Large control write transfers / zero-length-packet at end
On Wed, 20 Sep 2006, Harald Welte wrote: Hi! I'm currently writing a USB device firmware for a Free Software / Free hardware project based on an AT91SAM7 (see http://www.openpcd.org/) In order to implement USB DFU (device firmware upgrade), I need support for big control out transfers (larger than the 8 byte control endpoint size). I suppose this is a rarely used feature, since most control transfers are used to read information from a device (control in transfers). When I use libusb / usbdevio on a 2.6.17.13 kernel to send a control out transfer of e.g. 256 bytes, then I expect it to create 32 usb data out packets of each 8 bytes size, plus one zero-length packet to terminate the transfer. I'm using usb_control_msg() to do the transfer. However, on the AT91SAM7 I only see the 32 usb data out packets, and no ZLP (zero-length-packet). Transfers of an non-modulo-eight size (e.g. 31 packets of 8 bytes, plus one four-byte packet) work perfectly fine, since in this case no ZLP is supposed to be at the end of the transfer. The host controller is UHCI in this case. Am I somehow assuming something wrong? Is there anything at all on the host software stack that controls the generation of a ZLP at the end of the transfer, or is this all done by the host controller? Your assumption is wrong. When a control-out transfer takes, the host controller sends a SETUP packet followed by as many OUT/DATA packets as necessary to transfer the data, but no zero-length OUT/DATA. There is a zero-length IN packet to terminate the transfer (the status stage), but that's present regardless of the amount of data. The idea is that you don't need a zero-length packet to terminate the data stage of the transfer, since the status stage's IN packet will always mark the termination. For bulk-out transfers you can force an extra zero-length packet at the end (if the data size is 0 and divisible by the maxpacket length) by setting URB_ZERO_PACKET in urb-transfer_flags. That works only for bulk-out, not for control-out. Alan Stern - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Large control write transfers / zero-length-packet at end
Hi, Alan (still remember meeting you at OLS in one of the past years!) Your assumption is wrong. thanks for your quick response. When a control-out transfer takes, the host controller sends a SETUP packet followed by as many OUT/DATA packets as necessary to transfer the data, but no zero-length OUT/DATA. There is a zero-length IN packet to terminate the transfer (the status stage), but that's present regardless of the amount of data. This really solves my problem. One fundamental problem (at least given the SAM7 register set) remains: I have no indication to decide which of the data OUT packets was the last, and when the device should return the status stage IN packet. Since (at least in my application, don't know whether this is how it is supposed to work) the setup state states the length of the data, I simply use this as indication. Seems to work just fine now. I spent already more than one day at this problem ;( Thanks once again. Cheers, -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ We all know Linux is great...it does infinite loops in 5 seconds. -- Linus pgpjRPpAP3Dc4.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Large control write transfers / zero-length-packet at end
On Wed, 20 Sep 2006, Harald Welte wrote: Hi, Alan (still remember meeting you at OLS in one of the past years!) Hi! Your assumption is wrong. thanks for your quick response. When a control-out transfer takes, the host controller sends a SETUP packet followed by as many OUT/DATA packets as necessary to transfer the data, but no zero-length OUT/DATA. There is a zero-length IN packet to terminate the transfer (the status stage), but that's present regardless of the amount of data. This really solves my problem. One fundamental problem (at least given the SAM7 register set) remains: I have no indication to decide which of the data OUT packets was the last, and when the device should return the status stage IN packet. The IN packet is sent by the host to mark the end of the data stage. The device then is supposed to return a zero-length DATA1 packet, to acknowledge the end of the transfer. So the device knows the data is complete when it gets that IN packet. Since (at least in my application, don't know whether this is how it is supposed to work) the setup state states the length of the data, I simply use this as indication. Yes, that will work equally well. Seems to work just fine now. I spent already more than one day at this problem ;( Thanks once again. You're welcome. Alan Stern - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Large control write transfers / zero-length-packet at end
On Wednesday 20 September 2006 10:58 am, Harald Welte wrote: When a control-out transfer takes, the host controller sends a SETUP packet followed by as many OUT/DATA packets as necessary to transfer the data, but no zero-length OUT/DATA. There is a zero-length IN packet to terminate the transfer (the status stage), but that's present regardless of the amount of data. This really solves my problem. One fundamental problem (at least given the SAM7 register set) remains: I have no indication to decide which of the data OUT packets was the last, and when the device should return the status stage IN packet. The at91_udc driver should work on those at91sam7 parts, and I think some uClinux folk have done just that. As Alan commented, once you get the IN packet, you know no more OUT DATA segments will be arriving. Control transfers are always a bit convoluted to follow in the code, but that's how at91_udc does it ... - Dave - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
