Hi
I tried SIMTrace with Gemalto java smart cards and it is working great.
Unfortunately I can’t run it on my shiny Mac OSX (Darwin Kernel Version 10.8.0), hosting Ubuntu in VMware. SIMtrace is flashed with the latest firmware (see http://lists.osmocom.org/pipermail/simtrace/2011-August/000109.html)
If I connect it to my mac the red light is flashing periodically. In the kernel log I see the following messages:
9/28/11 9:47:05 PM kernel USBF: 428978. 89 [0xadd3100] The IOUSBFamily was not able to enumerate a device. 9/28/11 9:47:06 PM kernel USBF: 428979.493 [0xadd3100] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in. It will keep retrying. (Port 4 of Hub at 0x6000000) 9/28/11 9:47:06 PM kernel USBF: 428979.493 [0xadd3100] The IOUSBFamily was not able to enumerate a device. 9/28/11 9:47:07 PM kernel USBF: 428980.898 [0xadd3100] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in. It will keep retrying. (Port 4 of Hub at 0x6000000) 9/28/11 9:47:07 PM kernel USBF: 428980.898 [0xadd3100] The IOUSBFamily was not able to enumerate a device. 9/28/11 9:47:09 PM kernel USBF: 428982.303 [0xadd3100] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in. It will keep retrying. (Port 4 of Hub at 0x6000000) ....
with logging enabled: 9/29/11 9:10:33 PM kernel USBF: 1466.294 AppleUSBOHCI[0x7679000]::MakeDevice error setting address. err=0xe00002ed device=0x96d3400 - releasing device 9/29/11 9:10:33 PM kernel USBF: 1466.294 **5** AppleUSBHubPort[0x77d5c00]::AddDeviceResetChangeHandler - Port 4 of Hub at 0x6000000, unable to set device 0 to address 0 - disabling port 9/29/11 9:10:33 PM kernel USBF: 1466.296 AppleUSBHubPort[0x77d5c00]::DetachDevice Port 4 of Hub at 0x6000000 being detached (_attachRetry = 0) 9/29/11 9:10:33 PM kernel USBF: 1466.296 [0x77d5c00] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in. It will keep retrying. (Port 4 of Hub at 0x6000000) 9/29/11 9:10:33 PM kernel USBF: 1466.296 AppleUSBHubPort[0x77d5c00]::DetachDevice - Port 4 of Hub at 0x6000000 - device has gone away 9/29/11 9:10:33 PM kernel USBF: 1466.296 [0x77d5c00] The IOUSBFamily was not able to enumerate a device. 9/29/11 9:10:34 PM kernel USBF: 1467.700 AppleUSBOHCI[0x7679000]::MakeDevice error setting address. err=0xe00002ed device=0x96d3400 - releasing device 9/29/11 9:10:34 PM kernel USBF: 1467.700 **5** AppleUSBHubPort[0x77d5c00]::AddDeviceResetChangeHandler - Port 4 of Hub at 0x6000000, unable to set device 0 to address 0 - disabling port 9/29/11 9:10:34 PM kernel USBF: 1467.702 AppleUSBHubPort[0x77d5c00]::DetachDevice Port 4 of Hub at 0x6000000 being detached (_attachRetry = 0) 9/29/11 9:10:34 PM kernel USBF: 1467.702 [0x77d5c00] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in. It will keep retrying. (Port 4 of Hub at 0x6000000) 9/29/11 9:10:34 PM kernel USBF: 1467.702 AppleUSBHubPort[0x77d5c00]::DetachDevice - Port 4 of Hub at 0x6000000 - device has gone away 9/29/11 9:10:34 PM kernel USBF: 1467.702 [0x77d5c00] The IOUSBFamily was not able to enumerate a device. 9/29/11 9:10:36 PM kernel USBF: 1469.107 AppleUSBOHCI[0x7679000]::MakeDevice error setting address. err=0xe00002ed device=0x96d3400 - releasing device 9/29/11 9:10:36 PM kernel USBF: 1469.107 **5** AppleUSBHubPort[0x77d5c00]::AddDeviceResetChangeHandler - Port 4 of Hub at 0x6000000, unable to set device 0 to address 0 - disabling port 9/29/11 9:10:36 PM kernel USBF: 1469.109 AppleUSBHubPort[0x77d5c00]::DetachDevice Port 4 of Hub at 0x6000000 being detached (_attachRetry = 0) 9/29/11 9:10:36 PM kernel USBF: 1469.109 [0x77d5c00] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in. It will keep retrying. (Port 4 of Hub at 0x6000000) 9/29/11 9:10:36 PM kernel USBF: 1469.109 AppleUSBHubPort[0x77d5c00]::DetachDevice - Port 4 of Hub at 0x6000000 - device has gone away 9/29/11 9:10:36 PM kernel USBF: 1469.109 [0x77d5c00] The IOUSBFamily was not able to enumerate a device. 9/29/11 9:10:37 PM kernel USBF: 1470.512 AppleUSBOHCI[0x7679000]::MakeDevice error setting address. err=0xe00002ed device=0x96d3400 - releasing device
Please find attached also the trace logs form USBProber and usbtracer.
Any ideas how this could be fixed?
Ben
On 10/03/2011 12:26 PM, Holger Hans Peter Freyther wrote:
just a blind guess, at the Camp we had one or two reports that the device does not properly enumerate on a USB 3.0 port. Could this apply?
FYI: I tried on a mac (lion) and I can confirm this issue. Will try to play wit that tomorrow.
Holger Hans Peter Freyther wrote:
On 10/03/2011 12:26 PM, Holger Hans Peter Freyther wrote:
just a blind guess, at the Camp we had one or two reports that the device does not properly enumerate on a USB 3.0 port. Could this apply?
FYI: I tried on a mac (lion) and I can confirm this issue. Will try to play wit that tomorrow.
Mac OS is really really strict about USB descriptors being correct, where both Windows and Linux are more lenient. But the error messages say the device would not even accept the address it was assigned, so there is some more fundamental problem with the USB firmware. :\
//Peter
On 10/03/2011 07:41 PM, Peter Stuge wrote:
Mac OS is really really strict about USB descriptors being correct, where both Windows and Linux are more lenient. But the error messages say the device would not even accept the address it was assigned, so there is some more fundamental problem with the USB firmware. :\
any debug hints? it will be my first real adventure into the USB land. Right now I would just play trial and error to see how far in the setup things go.
:)
Holger Hans Peter Freyther wrote:
Mac OS is really really strict about USB descriptors being correct, where both Windows and Linux are more lenient. But the error messages say the device would not even accept the address it was assigned, so there is some more fundamental problem with the USB firmware. :\
any debug hints? it will be my first real adventure into the USB land. Right now I would just play trial and error to see how far in the setup things go.
The device address being assigned by the PC is very very early in the USB enumeration (device discovery after plug-in) process, so something goes wrong pretty early.
I understood that the firmware is based on an example firmware from Atmel, so maybe look around their developer resources for any info about known problems with Mac OS.
I would probably add some serial output to the firmware in main() and in the USB interrupt handler, and try to see what differs between Mac OS and other systems during enumeration.
I recall Harald mentioned an interrupt storm in some circumstances, this could also cause the device address assignment to fail if it isn't fixed already.
//Peter
Hey,
I can confirm this problem on my fresh OS X 10.7 (Lion) installation.
The IRQ storm bug you're referring to was caused by TCK byte difference between T=1 and T=0 protocols and has been fixed in firmware 0.2 ( http://laforge.gnumonks.org/weblog/2011/08/16/). This however should not be related I guess as if you connect the simtrace without a phone and simcard attached to it, this bug should not trigger (correct me if i'm wrong).
to debugging: you can use a serial cable connected to the 2.5" jack (something like FTDI based one for osmocom motorola phones if you have one) - that's the debugging interface. I'm currently travelling and don't have my usb->serial cable with me so I will check back at home.
Cheers, Lukas
On Mon, Oct 3, 2011 at 8:29 PM, Peter Stuge peter@stuge.se wrote:
Holger Hans Peter Freyther wrote:
Mac OS is really really strict about USB descriptors being correct, where both Windows and Linux are more lenient. But the error messages say the device would not even accept the address it was assigned, so there is some more fundamental problem with the USB firmware. :\
any debug hints? it will be my first real adventure into the USB land. Right now I would just play trial and error to see how far in the setup things go.
The device address being assigned by the PC is very very early in the USB enumeration (device discovery after plug-in) process, so something goes wrong pretty early.
I understood that the firmware is based on an example firmware from Atmel, so maybe look around their developer resources for any info about known problems with Mac OS.
I would probably add some serial output to the firmware in main() and in the USB interrupt handler, and try to see what differs between Mac OS and other systems during enumeration.
I recall Harald mentioned an interrupt storm in some circumstances, this could also cause the device address assignment to fail if it isn't fixed already.
//Peter
I've managed to get the serial traces:
*Linux trace on latest firmware (works fine):*
(C) 2006-2011 by Harald Welte hwelte@hmw-consulting.de This software is FREE SOFTWARE licensed under GNU GPL Version 0.1.12-fa72 compiled 20110815-230016 by laforge@nataraja.de.gnumonks.org
DEBUG Interface: 0) Set Pull-up 1) Clear Pull-up 2) Toggle LED1 3) Toggle LED2 9) Reset RSTC_SR=0x00010200 Inititalizing usbcmd_gen_init udp_open(437): entering USART Initializing pio_irq_register(109): registering handler 0010777c for PIOA 7 ISO_SW Initializing pio_irq_register(109): registering handler 00107c00 for PIOA 8 pio_irq_register(109): registering handler 00107af4 for PIOA 30 USART Entering Rx Mode RST computed Fi(1) Di(1) ratio: 372 MODE: SNIFFER
main(76): entering main (idle) loop
*Mac OS X 10.7 Lion trace (repeats itself over and over and over (red led blinks every time it resets)):*
(C) 2006-2011 by Harald Welte hwelte@hmw-consulting.de This software is FREE SOFTWARE licensed under GNU GPL Version 0.1.12-fa72 compiled 20110815-230016 by laforge@nataraja.de.gnumonks.org
DEBUG Interface: 0) Set Pull-up 1) Clear Pull-up 2) Toggle LED1 3) Toggle LED2 9) Reset RSTC_SR=0x00010200 Inititalizing usbcmd_gen_init udp_open(437): entering USART Initializing pio_irq_register(109): registering handler 0010777c for PIOA 7 __pio_irq_demux(43): PIO_ISR_STATUS = 0xffffffff RST computed Fi(1) Di(1) ratio: 372 ISO_SW Initializing pio_irq_register(109): registering handler 00107c00 for PIOA 8 pio_irq_register(109): registering handler 00107af4 for PIOA 30 USART Entering Rx Mode RST computed Fi(1) Di(1) ratio: 372 MODE: SNIFFER
main(76): entering main (idle) loop
Problem is obviously somewhere in the beginning, Mac OS X trace has these 3 lines more than Linux: __pio_irq_demux(43): PIO_ISR_STATUS = 0xffffffff RST computed Fi(1) Di(1) ratio: 372
I honestly don't know what could be the problem here but perhaps this can lead someone to an idea :)
Lukas On Mon, Oct 3, 2011 at 9:47 PM, Lukas Kuzmiak lukash@backstep.net wrote:
Hey,
I can confirm this problem on my fresh OS X 10.7 (Lion) installation.
The IRQ storm bug you're referring to was caused by TCK byte difference between T=1 and T=0 protocols and has been fixed in firmware 0.2 ( http://laforge.gnumonks.org/weblog/2011/08/16/). This however should not be related I guess as if you connect the simtrace without a phone and simcard attached to it, this bug should not trigger (correct me if i'm wrong).
to debugging: you can use a serial cable connected to the 2.5" jack (something like FTDI based one for osmocom motorola phones if you have one)
- that's the debugging interface. I'm currently travelling and don't have my
usb->serial cable with me so I will check back at home.
Cheers, Lukas
On Mon, Oct 3, 2011 at 8:29 PM, Peter Stuge peter@stuge.se wrote:
Holger Hans Peter Freyther wrote:
Mac OS is really really strict about USB descriptors being correct, where both Windows and Linux are more lenient. But the error messages say the device would not even accept the address it was assigned, so there is some more fundamental problem with the USB firmware. :\
any debug hints? it will be my first real adventure into the USB land. Right now I would just play trial and error to see how far in the setup things go.
The device address being assigned by the PC is very very early in the USB enumeration (device discovery after plug-in) process, so something goes wrong pretty early.
I understood that the firmware is based on an example firmware from Atmel, so maybe look around their developer resources for any info about known problems with Mac OS.
I would probably add some serial output to the firmware in main() and in the USB interrupt handler, and try to see what differs between Mac OS and other systems during enumeration.
I recall Harald mentioned an interrupt storm in some circumstances, this could also cause the device address assignment to fail if it isn't fixed already.
//Peter
On 10/03/2011 08:29 PM, Peter Stuge wrote:
I recall Harald mentioned an interrupt storm in some circumstances, this could also cause the device address assignment to fail if it isn't fixed already.
This was related to the UART code, but yes looking at the serial output i see:
RSTC_SR=0x00010200
SRCMP: 1 == Software reset in progress RSTTYP: 2 == Watchdog reset
so it is stuck somewhere. time to get a USBJtag adapter.. :)
On 10/04/2011 11:44 AM, Holger Hans Peter Freyther wrote:
SRCMP: 1 == Software reset in progress RSTTYP: 2 == Watchdog reset
so it is stuck somewhere. time to get a USBJtag adapter.. :)
Hi, I am lacking USB and AT7SAM knowledge here. I made the debug output synchronous and managed to get here:
udp_irq(imr=0x1200, isr=0x0300, state=5): RXSUSP RXRSM END udp_irq(imr=0x1200, isr=0x1000, state=5): ENDBUSRES END udp_irq(imr=0x1203, isr=0x0801, state=5): EP0INT(Control) CSR=0x88804 len=8 bmRequestType=0x80 DATA_IN=1 dfu_state = 0 GET_DESCRIPTOR(wValue=0x0100, wIndex=0x0000) OUT
So this means that we at least get a USB request to get our descriptor, and asking for USB_DT_DEVICE.
The call is made to:
udp_ep0_send_data((const char *) &dev_descriptor, MIN(sizeof(dev_descriptor), wLength));
and it is getting stuck in:
udp_ep0_send_zlp(void) { AT91PS_UDP pUdp = AT91C_BASE_UDP; pUdp->UDP_CSR[0] |= AT91C_UDP_TXPKTRDY; while (!(pUdp->UDP_CSR[0] & AT91C_UDP_TXCOMP)) ; ^^^^ sending never completes
Anyone has a guess? I am going to start to read the Atmel docs now.
On 10/03/2011 08:17 PM, Holger Hans Peter Freyther wrote:
any debug hints? it will be my first real adventure into the USB land. Right now I would just play trial and error to see how far in the setup things go.
I have a first hypothesis/guess... I think we transmit debug messages on EP3 before the device is configured.
Hello Holger,
On Tue, 04 Oct 2011 12:48:58 +0200, "Holger Hans Peter Freyther" holger@freyther.de wrote:
Anyone has a guess? I am going to start to read the Atmel docs now.
I don't have time to debug this issue, but a USB Analyzer trace clearly shows that the SET ADDRESS command goes wrong.
My guess: The only difference between the Windows and MacOS X trace is a USB Reset between the GET DESCRIPTOR and SET ADDRESS command on Windows, the Reset is not there on MacOS X (don't know what Linux does). So I would look if "upcd.state" is USB_STATE_DEFAULT, if not STD_SET_ADDRESS won't do anything. From my understanding "upcd.state" is set to USB_STATE_DEFAULT on a USB Reset, so it might not be initialized properly.
Best regards, Dieter
On 10/04/2011 01:34 PM, Dieter Spaar wrote:
Hello Holger,
I don't have time to debug this issue, but a USB Analyzer trace clearly shows that the SET ADDRESS command goes wrong.
I thought harald had fixed the issues your USB Analyzer complained about?
My guess: The only difference between the Windows and MacOS X trace is a USB Reset between the GET DESCRIPTOR and SET ADDRESS command on Windows, the Reset is not there on MacOS X (don't know what Linux does).
yes, the firmware 'stalls' in:
while (!(pUdp->UDP_CSR[0] & AT91C_UDP_TXPKTRDY))
for sending a zero length packet... (which is after/part of the GET DESCRIPTOR) response. I think it is from an interrupt handler and maybe we need to check if the transfer has been canceled?
look if "upcd.state" is USB_STATE_DEFAULT, if not STD_SET_ADDRESS won't do anything. From my understanding "upcd.state" is set to USB_STATE_DEFAULT on a USB Reset, so it might not be initialized properly.
will do, but I think we are stuck in the interrupt handler.
Hello Holger,
On Tue, 04 Oct 2011 14:37:09 +0200, "Holger Hans Peter Freyther" holger@freyther.de wrote:
I thought harald had fixed the issues your USB Analyzer complained about?
This was a completly different issue, it was not related to the USB behaviour on MacOS X.
for sending a zero length packet... (which is after/part of the GET DESCRIPTOR) response. I think it is from an interrupt handler and maybe we need to check if the transfer has been canceled?
The GET DESCRIPTOR request is working fine including the response from the device, the problem is that there is no repsonse on the SET ADDRESS request.
will do, but I think we are stuck in the interrupt handler.
As a quick check I would just remove the test for the state when handling SET ADDRESS and see if this helps.
Best regards, Dieter
On 10/04/2011 02:46 PM, Dieter Spaar wrote:
Hello Holger,
for sending a zero length packet... (which is after/part of the GET DESCRIPTOR) response. I think it is from an interrupt handler and maybe we need to check if the transfer has been canceled?
The GET DESCRIPTOR request is working fine including the response from the device, the problem is that there is no repsonse on the SET ADDRESS request.
will do, but I think we are stuck in the interrupt handler.
As a quick check I would just remove the test for the state when handling SET ADDRESS and see if this helps.
Hi Dieter,
I am not using JTAG to debug so my view i have might be limited. I have put DEBUG_UNBUFFERD in the codepath. So from the messages I print to the serial. With my current information I would claim the firmware does not see the SET ADDRESS (i assume the zpl method needs to check the ISR of the UDP)
frame 0> udp_ep0_send_zlp frame 1> udp_ep0_send_data frame 2> udp_ep0_handler frame 3> udp_irq
Please don't feel urged to look into it, I quite enjoy learning about USB this way. :)
On 10/04/2011 02:58 PM, Holger Hans Peter Freyther wrote:
frame 0> udp_ep0_send_zlp frame 1> udp_ep0_send_data frame 2> udp_ep0_handler frame 3> udp_irq
Okay, I 'reverted' fe88b83e80df8be0351ff38ee6a77b855b0cd0a9 that added sending a ZPL for every thing length % 8 == 0 and the device started to work on OSX. I assume we will need to look at the USB spec. :)
On 10/04/2011 03:23 PM, Holger Hans Peter Freyther wrote:
On 10/04/2011 02:58 PM, Holger Hans Peter Freyther wrote:
Okay, I 'reverted' fe88b83e80df8be0351ff38ee6a77b855b0cd0a9 that added sending a ZPL for every thing length % 8 == 0 and the device started to work on OSX. I assume we will need to look at the USB spec. :)
I have uploaded alternative firmware for OSX[1] and the 'diff' to revert the above commit. I have to read when to and when not to send a ZPL.
[1] http://bb.osmocom.org/trac/attachment/wiki/SIMtrace/Firmware/
Well done! I'll try it out in the evening and let you know, I think as it's known where the problem is now it won't be hard to find out if there's a mistake with ZPL and how to fix it to have one FW :)
Lukas
On Tue, Oct 4, 2011 at 4:12 PM, Holger Hans Peter Freyther < holger@freyther.de> wrote:
On 10/04/2011 03:23 PM, Holger Hans Peter Freyther wrote:
On 10/04/2011 02:58 PM, Holger Hans Peter Freyther wrote:
Okay, I 'reverted' fe88b83e80df8be0351ff38ee6a77b855b0cd0a9 that added sending
a ZPL
for every thing length % 8 == 0 and the device started to work on OSX. I assume we will need to look at the USB spec. :)
I have uploaded alternative firmware for OSX[1] and the 'diff' to revert the above commit. I have to read when to and when not to send a ZPL.
[1] http://bb.osmocom.org/trac/attachment/wiki/SIMtrace/Firmware/
Where is the firmware hosted btw ? The link on the SIMtrace/Firmware page is broken ...
[1] http://bb.osmocom.org/trac/attachment/wiki/SIMtrace/Firmware/
Cheers,
Sylvain
On 10/04/2011 04:43 PM, Sylvain Munaut wrote:
Where is the firmware hosted btw ? The link on the SIMtrace/Firmware page is broken ...
$ git clone git://git.gnumonks.org/openpcd.git
gitdaemon runs, gitweb on gnumonks does not show it though. I mailed harald about it (asking for sam7 utils as well).
holger
On Tue, Oct 04, 2011 at 04:54:47PM +0200, Holger Hans Peter Freyther wrote:
On 10/04/2011 04:43 PM, Sylvain Munaut wrote:
Where is the firmware hosted btw ? The link on the SIMtrace/Firmware page is broken ...
$ git clone git://git.gnumonks.org/openpcd.git
gitdaemon runs, gitweb on gnumonks does not show it though. I mailed harald about it (asking for sam7 utils as well).
the gitweb is up and running again. I have no sam7utils repository, sorry.
On 10/06/2011 09:54 AM, Harald Welte wrote:
the gitweb is up and running again. I have no sam7utils repository, sorry.
Hi,
do you think it makes sense to create one? It took me some time to figure out that it doesn't even connect to the device (or be able to have posix and usb backend in the same binary). I don't know the story about this utility, but IIRC I downloaded a tarball from openocd?
holger
Hi Holger,
On Thu, Oct 06, 2011 at 10:04:22AM +0200, Holger Hans Peter Freyther wrote:
do you think it makes sense to create one? It took me some time to figure out that it doesn't even connect to the device (or be able to have posix and usb backend in the same binary). I don't know the story about this utility, but IIRC I downloaded a tarball from openocd?
I think the most current version of the tool (or an equivalent tool) is distributed by Atmel itself, somewhere hidden deep in their download links for the AT91SAM7-EK product. There are even two versions of it, one that uses the raw USB device (via libusb) and one that uses the ttyUSB* device generated by the kernel serial driver for the sam-ba bootloader usb device.
Creating a git repo would probably make sense only if we actually had some changes/patcehs to that utility.
Regards, Harald
On 10/08/2011 10:41 AM, Harald Welte wrote:
Hi Holger,
Creating a git repo would probably make sense only if we actually had some changes/patcehs to that utility.
I have a printf in case the device fails to open, and I would build both (posix, libusbb) backends into the same binary. It took me some minutes to figure out that -l /dev/ttyACM0 was just ignored.
holger
Hello Holger,
On Tue, 04 Oct 2011 14:58:49 +0200, "Holger Hans Peter Freyther" holger@freyther.de wrote:
I am not using JTAG to debug so my view i have might be limited. I have put DEBUG_UNBUFFERD in the codepath. So from the messages I print to the serial.
I don't recommend debugging USB issues with JTAG anyway because it might chance the behaviour of the device.
With my current information I would claim the firmware does not see the SET ADDRESS (i assume the zpl method needs to check the ISR of the UDP)
frame 0> udp_ep0_send_zlp frame 1> udp_ep0_send_data frame 2> udp_ep0_handler frame 3> udp_irq
I can only judge from the trace and using the prebuilt firmware v0.2.2, in this case the GET DESCRIPTOR request is completed, the SET ADDRESS request comes in, is ACKed and no response from the device is sent back when the IN packet from the host arrives.
Have you tried to modify the SET ADDRESS handling already ?
Please don't feel urged to look into it, I quite enjoy learning about USB this way. :)
I don't have a working setup here for building the simtrace firmware, so far I only used prebuilt version. So I can't do much and I currently don't have the time to go through the process of creating the build-environment.
Best regards, Dieter
Hello Holger,
On Tue, 04 Oct 2011 16:12:42 +0200, "Holger Hans Peter Freyther" holger@freyther.de wrote:
I have uploaded alternative firmware for OSX[1] and the 'diff' to revert the above commit. I have to read when to and when not to send a ZPL.
Have a look at the requested size from the host, only when the host requests more data than available, the ZLP is needed (if the size sent is an exact multiple of the endpoint size). In my traces I can see that Windows request 64 bytes for the first GET DESCRIPTOR which is only 8 bytes long (so a ZPL should be sent). MacOS X requests 8 bytes, so no ZLP is needed.
I still believe there is another issue which will cause problems if a USB Reset is missing between the first GET DESCRIPTOR and the SET ADDRESS request, which I could observe here with my MacOS X installation (an older one from a year ago).
Best regards, Dieter
On 10/04/2011 04:43 PM, Dieter Spaar wrote:
Have a look at the requested size from the host, only when the host requests more data than available, the ZLP is needed (if the size sent is an exact multiple of the endpoint size).
ahhh. maybe I find something in the USB 2.0 specification about that part now. Thanks for your input!
Hello Holger,
On Tue, 04 Oct 2011 16:49:37 +0200, "Holger Hans Peter Freyther" holger@freyther.de wrote:
ahhh. maybe I find something in the USB 2.0 specification about that part now. Thanks for your input!
"8.5.3.2 Variable-length Data Stage"
Best regards, Dieter
Holger Hans Peter Freyther wrote:
I 'reverted' fe88b83e80df8be0351ff38ee6a77b855b0cd0a9 that added sending a ZPL for every thing length % 8 == 0 and the device started to work on OSX. I assume we will need to look at the USB spec. :)
I think that commit is mostly correct, it just overlooks the condition of total data length == requested length, in which case I think no zlp should be sent. Also, hard coding 8 as packet size is not awesome, the value used by the host for this is bMaxPacketSize0 in the device descriptor. (See 9.6.1) At least a define would be good, full-speed devices can choose value here.
The same commit also exists earlier in the branch as 8cc090e310545f7858558f74116f707318daf682 with no merges in between. I'm not sure what happened there.
Holger Hans Peter Freyther wrote:
"8.5.3.2 Variable-length Data Stage"
and 9.4.3 Get Descriptor.
What is a Control Pipe?
USB spec and Windows like to refer to pipes, I think it's a bit redundant, transfers to and from endpoints is good enough imo. :)
//Peter
Peter Stuge wrote:
I 'reverted' fe88b83e80df8be0351ff38ee6a77b855b0cd0a9
I think that commit is mostly correct, it just overlooks the condition of total data length == requested length, in which case I think no zlp should be sent.
Make that total data length >= requested length
//Peter
On 10/04/2011 07:54 PM, Peter Stuge wrote:
Holger Hans Peter Freyther wrote:
I 'reverted' fe88b83e80df8be0351ff38ee6a77b855b0cd0a9 that added sending a ZPL for every thing length % 8 == 0 and the device started to work on OSX. I assume we will need to look at the USB spec. :)
I think that commit is mostly correct, it just overlooks the condition of total data length == requested length, in which case I think no zlp should be sent. Also, hard coding 8 as packet size is not awesome, the value used by the host for this is bMaxPacketSize0 in the device descriptor. (See 9.6.1) At least a define would be good, full-speed devices can choose value here.
So 8.5.3.2 demands that if data.length is an exact multiple of wMaxPacketSize we need to send the ZPL.
And 9.4.3 The wLength field specifies the number of bytes to return. If the descriptor is longer than the wLength field, only the initial bytes of the descriptor are returned. If the descriptor is shorter than the wLength field, the device indicates the end of the control transfer by sending a short packet when further data is requested. A short packet is defined as a packet shorter than the maximum payload size or a zero length data packet (refer to Chapter 5).
How to put this together? I will try to tomorrow.
So as Peter points out we should not send a ZPL if we sent wLength byte but it also happens to be a multiple of wMaxPacketSize?
Holger Hans Peter Freyther wrote:
So 8.5.3.2 demands that if data.length is an exact multiple of wMaxPacketSize we need to send the ZPL.
It seems that this refers to control pipes other than the one involving endpoint 0, which is often refered to as the default control pipe. (It is mandatory by spec and endpoint 0 does not have an endpoint descriptor, so there is no wMaxPacketSize for endpoint 0. (See 9.6.6)
For endpoint 0 this is instead stored in bMaxPacketSize0 in the device descriptor.
Also, is data.length the length of the requested data, or is it the length that was requested? Note the difference. The requested data is e.g. the device descriptor. A device descriptor is always 18 bytes. (See 9.6.1)
And 9.4.3 The wLength field specifies the number of bytes to return. If the descriptor is longer than the wLength field, only the initial bytes of the descriptor are returned.
This is the case we hit on Mac OS. Since the requested data is longer (18) than the requested length (8) we must send no ZLP, only the first 8 bytes.
Mac OS should follow up with another request for more data.
If the descriptor is shorter than the wLength field, the device indicates the end of the control transfer by sending a short packet when further data is requested.
This case is what we hit on Windows, where 64 bytes are requested.
A short packet is defined as a packet shorter than the maximum payload size or a zero length data packet (refer to Chapter 5).
So for Windows we must also not send ZLP, because 18 bytes is already shorter than 64. Returning 18 bytes is sufficient to say that no more data is coming.
How to put this together? I will try to tomorrow.
So as Peter points out we should not send a ZPL if we sent wLength byte but it also happens to be a multiple of wMaxPacketSize?
Compare length of the descriptor with requested number of bytes. Only when more bytes are requested than the descriptor is long *and* when the descriptor is a multiple of the max packet size (bMaxPacketSize0 for ep0, wMaxPacketSize for the ep in the ep descriptor) then send ZLP.
//Peter
Hello Holger,
On Tue, 04 Oct 2011 17:25:01 +0200, "Holger Hans Peter Freyther" holger@freyther.de wrote:
and 9.4.3 Get Descriptor.
Its the same rule, all the standard device requests are Control Transfers as described in 8.5.3.
What is a Control Pipe? The 'reserved bandwidth/window' for a control request?
Shall I repeat "Terms and Abbreviations" from the specification ;-) ?
Control Pipe: Same as a message pipe.
Message Pipe: A bi-directional pipe that transfers data using a request/data/status paradigm. The data has an imposed structure that allows requests to be reliably identified and communicated
Think about the Control Pipe as the mechanism which transports the Control Transfers and a such the standard device requests. You can also put your own requests there (vendor specific requests).
Best regards, Dieter
Hello Holger,
On Tue, 04 Oct 2011 20:17:00 +0200, "Holger Hans Peter Freyther" holger@freyther.de wrote:
So 8.5.3.2 demands that if data.length is an exact multiple of wMaxPacketSize we need to send the ZPL.
But only if less data than requested are sent ("A control pipe may have a variable-length data phase in which the host requests more data than is contained").
Its the same rule for GET DESCRIPTOR, no difference.
Best regards, Dieter
-
Dieter Spaar -
Harald Welte -
Holger Hans Peter Freyther -
Lukas Kuzmiak -
Myonium -
Peter Stuge -
Sylvain Munaut