Re: libusb usb_interrupt_read hangs under FreeBSD
On 4/3/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: On Tuesday 03 April 2007 13:27, Xiaofan Chen wrote: I was redirected to this list as per the suggestion from the libusb mailing list. It will be greatly appreciated that someone can suggest how to debug this problem? With the new USB stack installed, do like this: sysctl hw.usb.debug=15 Then run you program. Then get all the lines with ugen() in the debug output. sysctl hw.usb.debug=0 --HPS Thanks for the fast reply. ===[mcuee] ~/Desktop/build/mypk2 # sudo sysctl hw.usb.debug=15 Password: hw.usb.debug: 0 - 15 ===[mcuee] ~/Desktop/build/mypk2 # sudo python testpk2.py usb_set_debug: Setting debugging level to 255 (on) usb_os_find_busses: Found /dev/usb0 usb_os_find_busses: Found /dev/usb1 usb_os_find_busses: Found /dev/usb2 usb_os_find_devices: Found /dev/ugen0 on /dev/usb1 usb_control_msg: 128 6 512 0 0xbfbfe2e8 8 1000 usb_control_msg: 128 6 512 0 0x81222c0 41 1000 skipped 1 class/vendor specific interface descriptors usb_control_msg: 128 6 513 0 0xbfbfe2e8 8 1000 usb_control_msg: 128 6 513 0 0x8116900 32 1000 setConfiguration params: configuration: 1 set Configuration 1 claimInterface params: interfaceNumber: 0 claim Interface 0 Turing power on by USB interrupt write interruptWrite params: endpoint: 1 timeout: 1000 interruptWrite buffer param: 56 31 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a Sending version command by USB interrupt write interruptWrite params: endpoint: 1 timeout: 1000 interruptWrite buffer param: 76 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a Getting version command by USB interrupt read interruptRead params: endpoint: 1 size: 64 timeout: 1000 ^CUSB error: error reading from interrupt endpoint /dev/ugen0.1: Interrupted system call Traceback (most recent call last): File testpk2.py, line 43, in ? r=dh.interruptRead(1,64,1000) usb_os_close: closing endpoint 4 ===[mcuee] ~ # dmesg | grep ugen ugen0: Microchip Technology Inc. PICkit 2 Microcontroller Programmer, class 0/0, rev 2.00/0.01, addr 126 ugenopen: flag=1, mode=8192 ugenioctl: cmd=40125569 ugenclose: flag=1, mode=8192 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenclose: flag=3, mode=8192 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045565 ugen_set_config: configno 1, sc=0xc31ad800 ugenclose: flag=0, mode=0 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045572 ugenwrite: ugenwrite: transferred 64 bytes ugenioctl: cmd=80045572 ugenwrite: ugenwrite: transferred 64 bytes ugenioctl: cmd=80045572 ugenioctl: cmd=80045571 ugenread: ugen_open_pipe_read: interrupt open done ugenclose: flag=3, mode=8192 ugenclose: flag=3, mode=8192 Regards, Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libusb usb_interrupt_read hangs under FreeBSD
On 4/4/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: On Wednesday 04 April 2007 01:55, Xiaofan Chen wrote: On 4/3/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: Hi, I think that your device is broken, and goes bad when it receives a clear-stall request for the interrupt pipe. That is not very uncommon. Could you be more clearer? I'd like to communicate this problem to the firmware developer of PICKit 2 inside Microchip. Thanks. The chip does not handle a clear-stall request on the control pipe to clear-stall on the interrupt pipe. The result is that the interrupt pipe stops, or at least all buffers are cleared. I could be more detailed, but I think the developers will understand what I mean. Thanks. I will talk to the Micrpchip PICKit 2 developers. Hopefully they will be able to fix the firmware. From the dmesg output, I can see the portion that shows what you say. ugenioctl: cmd=80045572 ugenioctl: cmd=80045571 ugenread: usbd_get_pipe: udev=0xc3168800 iface_index=0 address=0x1 type=0x3 dir=0x80 index=0 usbd_get_pipe: udev=0xc3168800 iface_index=0 address=0x0 type=0x0 dir=0xff index=0 usbd_mem_alloc_sub: 0xe6aa, 4096 bytes, phys=0x3e85 usbd_get_pipe: udev=0xc3168800 iface_index=0 address=0x1 type=0x3 dir=0x80 index=0 usbd_get_pipe: udev=0xc3168800 iface_index=0 address=0x0 type=0x0 dir=0xff index=0 usbd_start_hardware: xfer=0xc3085420, pipe=0xc3168894 len=64 dir=in usbd_dump_pipe: pipe=0xc3168894 edesc=0xc31746db isoc_next=0 toggle_next=0 bEndpointAddress=0x81 usbd_dump_queue: pipe=0xc3168894 usbd_start_hardware: xfer=0xc3085528, pipe=0xc3168800 len=8 dir=out usbd_dump_pipe: pipe=0xc3168800 edesc=0xc3168a3d isoc_next=0 toggle_next=0 bEndpointAddress=0x00 usbd_dump_queue: pipe=0xc3168800 ugen_open_pipe_read: interrupt open done usbd_transfer_done: xfer=0xc3085528 pipe=0xc3168800 status=0 actlen=8 usbd_clearstall_callback: xfer=0xc3085528 usbd_start_hardware: xfer=0xc3085420, pipe=0xc3168894 len=64 dir=in usbd_dump_pipe: pipe=0xc3168894 edesc=0xc31746db isoc_next=0 toggle_next=0 bEndpointAddress=0x81 usbd_dump_queue: pipe=0xc3168894 usb_event_thread: woke up usb_discover: usbd_transfer_done: xfer=0xc3085420 pipe=0xc3168894 status=20 actlen=0 usbd_start_hardware: xfer=0xc3085420, pipe=0xc3168894 len=64 dir=in usbd_dump_pipe: pipe=0xc3168894 edesc=0xc31746db isoc_next=0 toggle_next=0 bEndpointAddress=0x81 usbd_dump_queue: pipe=0xc3168894 usbd_start_hardware: xfer=0xc3085528, pipe=0xc3168800 len=8 dir=out usbd_dump_pipe: pipe=0xc3168800 edesc=0xc3168a3d isoc_next=0 toggle_next=0 bEndpointAddress=0x00 usbd_dump_queue: pipe=0xc3168800 usbd_transfer_done: xfer=0xc3085528 pipe=0xc3168800 status=0 actlen=8 usbd_clearstall_callback: xfer=0xc3085528 usbd_start_hardware: xfer=0xc3085420, pipe=0xc3168894 len=64 dir=in usbd_dump_pipe: pipe=0xc3168894 edesc=0xc31746db isoc_next=0 toggle_next=0 bEndpointAddress=0x81 usbd_dump_queue: pipe=0xc3168894 usb_event_thread: woke up ... ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libusb usb_interrupt_read hangs under FreeBSD
On 4/4/07, Hans Petter Selasky [EMAIL PROTECTED] wrote:
On Wednesday 04 April 2007 01:55, Xiaofan Chen wrote:
On 4/3/07, Hans Petter Selasky [EMAIL PROTECTED] wrote:
Hi,
I think that your device is broken, and goes bad when it receives a
clear-stall request for the interrupt pipe. That is not very uncommon.
Could you be more clearer? I'd like to communicate this problem
to the firmware developer of PICKit 2 inside Microchip. Thanks.
The chip does not handle a clear-stall request on the control pipe to
clear-stall on the interrupt pipe. The result is that the interrupt pipe
stops, or at least all buffers are cleared.
I could be more detailed, but I think the developers will understand what I
mean.
Sorry to dig out this again. I read a bit more on the firmware source code
and I found the following. Seems a bit dubious. The USB controller used
is Microchip 18F2550.
Any comments? Thanks in advance.
/**
* Function:void USBStallHandler(void)
*
* PreCondition:A STALL packet is sent to the host by the SIE.
*
* Input: None
*
* Output: None
*
* Side Effects:None
*
* Overview:The STALLIF is set anytime the SIE sends out a STALL
* packet regardless of which endpoint causes it.
* A Setup transaction overrides the STALL function. A stalled
* endpoint stops stalling once it receives a setup packet.
* In this case, the SIE will accepts the Setup packet and
* set the TRNIF flag to notify the firmware. STALL function
* for that particular endpoint pipe will be automatically
* disabled (direction specific).
*
* There are a few reasons for an endpoint to be stalled.
* 1. When a non-supported USB request is received.
* Example: GET_DESCRIPTOR(DEVICE_QUALIFIER)
* 2. When an endpoint is currently halted.
* 3. When the device class specifies that an endpoint must
* stall in response to a specific event.
* Example: Mass Storage Device Class
* If the CBW is not valid, the device shall
* STALL the Bulk-In pipe.
* See USB Mass Storage Class Bulk-only Transport
* Specification for more details.
*
* Note:UEPn.EPSTALL can be scanned to see which endpoint causes
* the stall event.
* If
*/
void USBStallHandler(void)
{
/*
* Does not really have to do anything here,
* even for the control endpoint.
* All BDs of Endpoint 0 are owned by SIE right now,
* but once a Setup Transaction is received, the ownership
* for EP0_OUT will be returned to CPU.
* When the Setup Transaction is serviced, the ownership
* for EP0_IN will then be forced back to CPU by firmware.
*
* NOTE: Above description is not quite true at this point.
* It seems the SIE never returns the UOWN bit to CPU,
* and a TRNIF is never generated upon successful
* reception of a SETUP transaction.
* Firmware work-around is implemented below.
*/
if(UEP0bits.EPSTALL == 1)
{
USBPrepareForNextSetupTrf();// Firmware Work-Around
UEP0bits.EPSTALL = 0;
}
UIRbits.STALLIF = 0;
}//end USBStallHandler
/**
* Function:void USBPrepareForNextSetupTrf(void)
*
* PreCondition:None
*
* Input: None
*
* Output: None
*
* Side Effects:None
*
* Overview:The routine forces EP0 OUT to be ready for a new Setup
* transaction, and forces EP0 IN to be owned by CPU.
*
* Note:None
*/
void USBPrepareForNextSetupTrf(void)
{
ctrl_trf_state = WAIT_SETUP;// See usbctrltrf.h
ep0Bo.Cnt = EP0_BUFF_SIZE; // Defined in usbcfg.h
ep0Bo.ADR = (byte*)SetupPkt;
ep0Bo.Stat._byte = _USIE|_DAT0|_DTSEN; // EP0 buff dsc init, see usbmmap.h
ep0Bi.Stat._byte = _UCPU; // EP0 IN buffer initialization
}//end USBPrepareForNextSetupTrf
/** EOF usbctrltrf.c */
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libusb usb_interrupt_read hangs under FreeBSD
On 7/8/07, Xiaofan Chen [EMAIL PROTECTED] wrote: On 7/8/07, M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Xiaofan Chen [EMAIL PROTECTED] writes: : On 7/5/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: : The chip does not handle a clear-stall request on the control pipe to : clear-stall on the interrupt pipe. The result is that the interrupt : pipe stops, or at least all buffers are cleared. : : : The following is part of the usb firmware from Micrcohip. I never learned the details, but a client of mine was able to get fixes from Microchip for their product. The exact problem was that endpoint stall clearing didn't work for these devices and it was a firmware bug. Thanks a lot for the info. I ran the old USBCheck Version 5.10 with PICKit 2 and find out that it is true that PICKit 2 failed to respond to a clear STALL feature request for endpoint 0 (IN and OUT) even though it successfuly responded to the clear STALL request for endpoint 1 (IN and OUT). So I think this is a potential bug with the Microchip USB firmware framework. According to a reply from Microchip Forum: There is a slight ambiguity in the USB spec concerning 'clear stall feature'. Endpoint 0 canot stall a request, so a request to unstall endpoint 0 is completely redundant. I recall that the required response is not clearly defined. Personally, I just accept the request and acknowledge it, but there is no real action to be taken. I guess other software writers have chosen a different path. Why FreeBSD sends out the clear stall feature request for PICKit 2? The following is the reply from Microchip Forum poster Pacer. The Setup transaction cannot be stalled. However to indicate that the device doesn't understand the request it may stall the data or status stage of a control transfer. This is a 'protocol' stall, unique to control pipes, so doesn't need to be unstalled with a 'clear feature'. Therefore it must be a 'protocol stall' and FreeBSD does not need to send a clear feature request for the endpoint 0 to PICkit 2. Am I right? ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libusb usb_interrupt_read hangs under FreeBSD
On 7/9/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: Perhaps what happens is that the *pDst.bRam = _UCPU; command clears the FIFO contents of the USB interrupt endpoint in addition to clearing the stall!? If the sequence is like this: Write to interrupt endpoint. Reply command is written to FIFO. Clear interrupt endpoint stall. There is no data to read, because the FIFO has been emptied as a part of the stall command. Xiaofan Chen: Could you check the datasheet for the chip that is used, what the stall command actually does? I need to look further but what you mentioned seem to make sense. *pDst.bRam = _UCPU seems to clear the buffer. The following are the definitions for for the Buffer Descriptor Status Register. /* Buffer Descriptor Status Register Initialization Parameters */ #define _BSTALL 0x04//Buffer Stall enable #define _DTSEN 0x08//Data Toggle Synch enable #define _INCDIS 0x10//Address increment disable #define _KEN0x20//SIE keeps buff descriptors enable #define _DAT0 0x00//DATA0 packet expected next #define _DAT1 0x40//DATA1 packet expected next #define _DTSMASK0x40//DTS Mask #define _USIE 0x80//SIE owns buffer #define _UCPU 0x00//CPU owns buffer FYI: Datasheet of PIC18F2550 USB MCU: http://ww1.microchip.com/downloads/en/DeviceDoc/39632D.pdf bit 7 UOWN: USB Own bit(1) 0 = The microcontroller core owns the BD and its corresponding buffer 1 = SIE owns the BD and its corresponding buffer Note: This bit must be initialized by the user to the desired value prior to enabling the USB module. bit 6 DTS: Data Toggle Synchronization bit(2) 1 = Data 1 packet 0 = Data 0 packet Note: This bit is ignored unless DTSEN = 1 bit 5 KEN: BD Keep Enable bit 1 = USB will keep the BD indefinitely once UOWN is set (required for SPP endpoint configuration) 0 = USB will hand back the BD once a token has been processed bit 4 INCDIS: Address Increment Disable bit 1 = Address increment disabled (required for SPP endpoint configuration) 0 = Address increment enabled bit 3 DTSEN: Data Toggle Synchronization Enable bit 1 = Data toggle synchronization is enabled; data packets with incorrect Sync value will be ignored except for a SETUP transaction, which is accepted even if the data toggle bits do not match 0 = No data toggle synchronization is performed bit 2 BSTALL: Buffer Stall Enable bit 1 = Buffer stall enabled; STALL handshake issued if a token is received that would use the BD in the given location (UOWN bit remains set, BD value is unchanged) 0 = Buffer stall disabled bit 1-0 BC9:BC8: Byte Count 9 and 8 bits The byte count bits represent the number of bytes that will be transmitted for an IN token or received during an OUT token. Together with BC7:0, the valid byte counts are 0-1023. What Warner mentioned before might also be correct. On 7/8/07, M. Warner Losh [EMAIL PROTECTED] wrote: : I never learned the details, but a client of mine was able to get : fixes from Microchip for their product. The exact problem was that : endpoint stall clearing didn't work for these devices and it was a : firmware bug. I need to look it up, but I believe that a clear endpoint stall also resets the toggle, and that was the bug that was tracked down. FYI: the Firmware source code for PICkit 2, an HID device is here. http://ww1.microchip.com/downloads/en/DeviceDoc/FirmwareV2.10.00.zip I am still in the process of understanding the firmware so I may misunderstand something. But I will try to dig further. Regards, Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with libusb on FreeBSD?
On 7/9/07, Pierre-Luc Drouin [EMAIL PROTECTED] wrote: I have looked through the GPSBabel code and it looks like it is failing at the very first call of usb_bulk_write() when the initialization packet is sent to the device. Is this a known bug with libusb on FreeBSD 6.2? Maybe you can try the new USB stack by Hans. I've problems to get PICkit 2 working under the original USB stack with libusb. With Hans's new USB stack, it is working on FreeBSD 6.2. Regards, Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libusb usb_interrupt_read hangs under FreeBSD
On 7/9/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: Perhaps what happens is that the *pDst.bRam = _UCPU; command clears the FIFO contents of the USB interrupt endpoint in addition to clearing the stall!? If the sequence is like this: Write to interrupt endpoint. Reply command is written to FIFO. Clear interrupt endpoint stall. There is no data to read, because the FIFO has been emptied as a part of the stall command. Xiaofan Chen: Could you check the datasheet for the chip that is used, what the stall command actually does? Sorry that I have three more questions: 1) What is the correct method to correctly respond to clear halt feature request in the firmware so that it can still recover from the stall? 2) For the host, how does it know that the buffer data is still correct if the buffer is not cleared? 2) What cause the stall to happen in the first place? Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libusb usb_interrupt_read hangs under FreeBSD
On 7/15/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: 2) For the host, how does it know that the buffer data is still correct if the buffer is not cleared? Clear stall should only clear the data toggle! You need a second control command to reset the buffers and/or the protocol! 2) What cause the stall to happen in the first place? It is either a wrong data-toggle bit or a protocol error. The device can send stall at any time! Thanks a lot for the detailed explanation. If it is a protocol error for the control endpoint 0 (EP0), the host will not need to send a clear stall feature request to EP0. Even if it is sent (shall we consider it a bug of the USB stack if that is the case?), the current PICkit 2 firmware will filter out it and ignore it. So I think we can narrow it down to the wrong data-toggle bit. I will dig further. I'd like to convince the PICKit 2 firmware developer that something is wrong even though it is now working under FreeBSD. Could we see the reason for the stall from the following USB log? ===[mcuee] ~ # dmesg | grep ugen ugen0: Microchip Technology Inc. PICkit 2 Microcontroller Programmer, class 0/0, rev 2.00/0.01, addr 126 ugenopen: flag=1, mode=8192 ugenioctl: cmd=40125569 ugenclose: flag=1, mode=8192 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenclose: flag=3, mode=8192 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045565 ugen_set_config: configno 1, sc=0xc31ad800 ugenclose: flag=0, mode=0 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045572 ugenwrite: ugenwrite: transferred 64 bytes ugenioctl: cmd=80045572 ugenwrite: ugenwrite: transferred 64 bytes ugenioctl: cmd=80045572 ugenioctl: cmd=80045571 ugenread: ugen_open_pipe_read: interrupt open done ugenclose: flag=3, mode=8192 ugenclose: flag=3, mode=8192 On 7/8/07, M. Warner Losh [EMAIL PROTECTED] wrote: : Why FreeBSD sends out the clear stall feature request for PICKit 2? : : Therefore it must be a 'protocol stall' and FreeBSD does not need to : send a clear feature request for the endpoint 0 to PICkit 2. I need to look it up, but I believe that a clear endpoint stall also resets the toggle, and that was the bug that was tracked down. Remind me when is this clear endpoint stall sent? In 7.x we don't send one on pipe open unless the device is quirked to require one. On RELENG_6, at least as of today, we never send one on the open. I am using the alternative stack from Hans and 6.2 Stable version. So maybe there is a difference here. Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to talk to a USB Device
On 8/10/07, Robert Cousins [EMAIL PROTECTED] wrote: Hello: I've got several USB devices which I'd like to talk to from a program. They are Phigets -- a servo controller, an RFID reader, etc. Could someone please give me a hint as to the best starting point for learning how to use libusb and the associated facilities? I've been lurking for a while on this list and haven't seen/heard what I think I need to know. You might want to look at libhid/libphidgets. http://libhid.alioth.debian.org/ http://libphidgets.alioth.debian.org/ Take note that you have to disable uhid and use ugen. Regards, Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libusb usb_interrupt_read hangs under FreeBSD
On 7/9/07, M. Warner Losh [EMAIL PROTECTED] wrote: I need to look it up, but I believe that a clear endpoint stall also resets the toggle, and that was the bug that was tracked down. Remind me when is this clear endpoint stall sent? In 7.x we don't send one on pipe open unless the device is quirked to require one. On RELENG_6, at least as of today, we never send one on the open. I believe we have tracked down the bug with the HID firmware in PICkit 2 and I am waiting for the confirmwation from Microchip. You are exactly right! Thanks. http://forum.microchip.com/tm.aspx?m=275422mpage=2 HID framework does not reinitialize data toggle to DATA0 after ClearFeature on IN endpoint. Regards, Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snd_uaudio with libusb ?
On 9/29/07, Chuck T. [EMAIL PROTECTED] wrote: I have a Linux application that talks to an USB audio dongle that I'm trying to port to FreeBSD. I have no problem with the audio portion, but I'm also trying to use libusb to access the GPIO bits on the chip. What is the Linux application? How does the Linux work with the audio and GPIO working at the same time? As far as I know, Linux in libusb needs to unbind the kernel driver using the non-portable usb_detach_kernel_driver_np function in order to have access to the usb device --to set the configuration and claim the interface. I think your device is a USB composite USB device with two interfaces (one for USB audio and the other for GPIO). How do you control the GPIO under Linux (by control transfer or interrupt/bulk transfer)? If the Linux application indeed works at the same time as the USB audio, then Linux does bind different driver to different interfaces (one for the usb audio interface and no driver for the GPIO interface). Ok I am now under FreeBSD and the following is the output from a USB composite device (audio and genric). I have the firmware burnt but I have not built the full USB soundcard. http://home.comcast.net/~armag1234/soundcard.html ===[mcuee] ~/Desktop/build/pyusb-0.4.1/samples # sudo ./usbenum.py Device: /dev/ugen0 Device class: 0 Device sub class: 0 Device protocol: 0 Max packet size: 8 idVendor: 4660 idProduct: 15 Device Version: 00.00 Configuration: 1 Total length: 133 selfPowered: 0 remoteWakeup: 0 maxPower: 200 Interface: 0 Alternate Setting: 0 Interface class: 1 Interface sub class: 1 Interface protocol: 0 Interface: 1 Alternate Setting: 0 Interface class: 1 Interface sub class: 2 Interface protocol: 0 Alternate Setting: 1 Interface class: 1 Interface sub class: 2 Interface protocol: 0 Endpoint: 0x2 Type: 1 Max packet size: 96 Interval: 2 Interface: 2 Alternate Setting: 0 Interface class: 0 Interface sub class: 0 Interface protocol: 0 Endpoint: 0x1 Type: 3 Max packet size: 64 Interval: 1 Endpoint: 0x81 Type: 3 Max packet size: 64 Interval: 1 ===[mcuee] ~ # sudo ls -la /dev/ugen* crw-r--r-- 1 root operator0, 118 Sep 29 09:18 /dev/ugen0 crw-r--r-- 1 root operator0, 117 Sep 29 09:18 /dev/ugen0.1 So it seems that ugen only binds the first interface for this USB composite device. Not so sure if there is a method to bind the other interfaces. I am also not so sure if libusb will work in this case. I am not that experienced with FreeBSD USB. Sorry no real help here. A bit strange that this USB soundcard is not recognized under FreeBSD. I am using an old version of HPS USB stack. Xiaofan http://mcuee.blogspot.com ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snd_uaudio with libusb ?
On 9/29/07, Chuck T. [EMAIL PROTECTED] wrote: I think your device is a USB composite USB device with two interfaces (one for USB audio and the other for GPIO). How do you control the GPIO under Linux (by control transfer or interrupt/bulk transfer)? If the Linux application indeed works at the same time as the USB audio, then Linux does bind different driver to different interfaces (one for the usb audio interface and no driver for the GPIO interface). I talk to the GPIO bits via vendor specific requests to the control pipe. I do a usb_open() when my application loads and never close it. When I need to set a GPIO bit I use usb_control_msg(). I've never looked under the covers to see why it works, but it does. So this works under Linux but not FreeBSD. Maybe this is just a limitation of libusb under FreeBSD. Anyway, it is said that libusb is just a thin wrapper on top of USB. You may want to use the lower level api instead. I confess I do not know further (like how to bind ugen to individual interfaces and use IOCTL to perform usb transfer). But if post some codes, others may be able to help you. Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snd_uaudio with libusb ?
On 9/29/07, Chuck T. [EMAIL PROTECTED] wrote:
if(dev != NULL) {
if((udev = usb_open(dev)) != NULL) {
Ret = 0;
}
Hmm, you do not set USB configurations. I know this might
be good for Linux but this will not work under Windows.
Not so sure about FreeBSD.
I have tested some codes under Linux/Windows and
I will do the tests for FreeBSD. I already tested pk2
and Piklab for PICkit 2 under FreeBSD with the help
from people here. I always set configurations and
calim interfaces (interrupt transfer for PICKit 2 -- HID device).
http://forum.microchip.com/tm.aspx?m=106426
Not so sure about control transfer. I think you do not
need to claim the interface.
Regards,
Xiaofan
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]
VID parser problem with usbdevs
Somehow the vendor ID is parsed wrongly. 0x04d8 is for Microchip technology. ===[mcuee] ~/Desktop/build/fsusb/fsusb-0.1.11-2 # sudo usbdevs -v Controller /dev/usb1: addr 126: full speed, power 100 mA, config 1, product 0x000b(0x000b), I-Tuner Networks(0x04d8), rev 0.00 port 4 addr 126: full speed, power 100 mA, config 1, product 0x000b(0x000b), I-Tuner Networks(0x04d8), rev 0.00 ===[mcuee] ~/Desktop/build/fsusb/fsusb-0.1.11-2 # uname -a FreeBSD FreeBsd62.Mshome 6.2-STABLE FreeBSD 6.2-STABLE #2: Thu Oct 11 19:50:55 SGT 2007 [EMAIL PROTECTED]:/home/obj/home/src/sys/USBDEBUG i386 I am running kernel 6.2-STABLE with the latest SVN version of HPS Stack. Regards, Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
PICDEM FS USB Bootloader under FreeBSD
I am trying to get the PICDEM FS USB demo board working under FreeBSD. There are two libusb based application for it which work under Linux and Windows. I am now trying to get the bootloader working first. It is not working. Possibly this is again a firmware bug related issue but I would like to get it working either by patching the kernel code or by fixing the firmware. I am running the latest SVN version of HPS stack and the latest FreeBSD 6.2 Stable version. http://www.internetking.org/fsusb (original under Linux) http://forum.microchip.com/tm.aspx?m=106426 (minor patch by me) ===[mcuee] ~ # uname -a FreeBSD FreeBsd62.Mshome 6.2-STABLE FreeBSD 6.2-STABLE #2: Thu Oct 11 19:50:55 SGT 2007 [EMAIL PROTECTED]:/home/obj/home/src/sys/USBDEBUG i386 ===[mcuee] ~/Desktop/build/fsusb/fsusb-0.1.11-2 # dmesg | grep ugen ugen0: I-Tuner Networks product 0x000b, class 0/0, rev 2.00/0.00, addr 126 ugen1: Microchip Technology Inc. PICkit 2 Microcontroller Programmer, class 0/0, rev 2.00/0.01, addr 125 ===[mcuee] ~/Desktop/build/fsusb/fsusb-0.1.11-2 # sudo sysctl hw.usb.debug=15 hw.usb.debug: 0 - 15 ===[mcuee] ~/Desktop/build/fsusb/fsusb-0.1.11-2 # sudo ./fsusb --read test.hex usb_set_debug: Setting debugging level to 255 (on) Locating USB Microchip(tm) PICDEM-FS USB(tm) (vendor 0x04d8/product 0x000b) usb_os_find_busses: Found /dev/usb0 usb_os_find_busses: Found /dev/usb1 usb_os_find_busses: Found /dev/usb2 usb_os_find_devices: Found /dev/ugen1 on /dev/usb1 usb_os_find_devices: Found /dev/ugen0 on /dev/usb1 usb_control_msg: 128 6 512 0 0xbfbfe828 8 1000 USB error: error sending control message: Input/output error Unable to get descriptor (-5) usb_control_msg: 128 6 512 0 0xbfbfe828 8 1000 usb_control_msg: 128 6 512 0 0x8052080 41 1000 skipped 1 class/vendor specific interface descriptors usb_control_msg: 128 6 513 0 0xbfbfe828 8 1000 usb_control_msg: 128 6 513 0 0x804d100 32 1000 Found USB PICDEM-FS USB as device '/dev/ugen0' on USB bus /dev/usb1 USB error: error writing to bulk endpoint /dev/ugen0.1: Input/output error usb_bulk_write: Input/output error Fatal error rjl_request_version(): USB write failed ===[mcuee] ~/Desktop/build/fsusb/fsusb-0.1.11-2 # dmesg | grep ugen ugen0: I-Tuner Networks product 0x000b, class 0/0, rev 2.00/0.00, addr 126 ugen1: Microchip Technology Inc. PICkit 2 Microcontroller Programmer, class 0/0, rev 2.00/0.01, addr 125 ugenopen: flag=1, mode=8192 ugenioctl: cmd=40125569 ugenclose: flag=1, mode=8192 ugenopen: flag=1, mode=8192 ugenioctl: cmd=40125569 ugenclose: flag=1, mode=8192 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenclose: flag=3, mode=8192 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenclose: flag=3, mode=8192 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045565 ugen_set_config: configno 1, sc=0xc35cd000 ugenclose: flag=0, mode=0 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045572 ugenwrite: ugenwrite: transferred 5 bytes ugen_write_clear_stall_callback: sce=0xc35cd084: stall cleared ugen_default_write_callback: waking 0xc35cd084 ugenclose: flag=3, mode=8192 ugenclose: flag=3, mode=8192 Regards, Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
PICkit 2 again with HPS stack
I have updated the kernel and the new HPD stack and now PICkit 2 is again not working. I have updated the firmware based on the newly released Microchip stack and I thought I solved the data toggle problem by changing a line as suggested by Leo Bodnar. http://forum.microchip.com/tm.aspx?m=275422mpage=2 Apparent there is still a problem with the clear feature request. Enclosed is the running log. Since the file ugen.c is now changed, I dare not to apply the old patches provided by Hans. FreeBSD FreeBsd62.Mshome 6.2-STABLE FreeBSD 6.2-STABLE #2: Thu Oct 11 19:50:55 SGT 2007 [EMAIL PROTECTED]:/home/obj/home/src/sys/USBDEBUG i386 ===[mcuee] ~/Desktop/build/pk2-2.04 # sudo sysctl hw.usb.debug=15 Password: hw.usb.debug: 0 - 15 ===[mcuee] ~/Desktop/build/pk2-2.04 # sudo ./pk2 --on PK2 version 2.04 - 2006/12/17 ./pk2 --on usb_set_debug: Setting debugging level to 255 (on) Locating USB Microchip PICkit2 (vendor 0x04d8/product 0x0033) usb_os_find_busses: Found /dev/usb0 usb_os_find_busses: Found /dev/usb1 usb_os_find_busses: Found /dev/usb2 usb_os_find_devices: Found /dev/ugen0 on /dev/usb1 usb_control_msg: 128 6 512 0 0xbfbfe7e8 8 1000 usb_control_msg: 128 6 512 0 0x806b080 41 1000 skipped 1 class/vendor specific interface descriptors usb_control_msg: 128 6 513 0 0xbfbfe7e8 8 1000 usb_control_msg: 128 6 513 0 0x8066100 32 1000 Found USB PICkit as device '/dev/ugen0' on USB bus /dev/usb1 Setting USB configuration is okay. Claiming USB interface is okay. Sending GETVERSION command using interrupt transfer. USB 76 Receiving PICkit VERSION information using interrupt transfer. USB error: error reading from interrupt endpoint /dev/ugen0.1: Resource temporarily unavailable Fatal error USB read did not return 64 bytes ===[mcuee] ~/Desktop/build/pk2-2.04 # dmesg | grep ugen ugen0: Microchip Technology Inc. PICkit 2 Microcontroller Programmer, class 0/0, rev 2.00/0.01, addr 126 ugenopen: flag=1, mode=8192 ugenioctl: cmd=40125569 ugenclose: flag=1, mode=8192 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenclose: flag=3, mode=8192 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045565 ugen_set_config: configno 1, sc=0xc31bf000 ugenclose: flag=0, mode=0 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045572 ugenwrite: ugenwrite: transferred 64 bytes ugen_write_clear_stall_callback: sce=0xc31bf084: stall cleared ugen_default_write_callback: waking 0xc31bf084 ugenioctl: cmd=80045572 ugenioctl: cmd=80045571 ugenread: ugen_open_pipe_read: interrupt open done ugen_read_clear_stall_callback: sce=0xc31bf084: stall cleared ugenclose: flag=3, mode=8192 ugenclose: flag=3, mode=8192 ===[mcuee] ~/Desktop/build/pyusb-0.4.1/samples # sudo usbdevs -v Controller /dev/usb0: addr 127: full speed, self powered, config 1, OHCI root hub(0x), nVidia(0x), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered Controller /dev/usb1: addr 126: full speed, power 100 mA, config 1, PICkit 2 Microcontroller Programmer(0x0033), Microchip Technology Inc.(0x04d8), rev 0.01 addr 127: full speed, self powered, config 1, OHCI root hub(0x), nVidia(0x), rev 1.00 port 1 powered port 2 addr 126: full speed, power 100 mA, config 1, PICkit 2 Microcontroller Programmer(0x0033), Microchip Technology Inc.(0x04d8), rev 0.01 port 3 powered port 4 powered Controller /dev/usb2: addr 127: high speed, self powered, config 1, EHCI root hub(0x), nVidia(0x), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered port 7 powered port 8 powered Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PICDEM FS USB Bootloader under FreeBSD
On 10/13/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: I think that the write STALLED. You can check this by turning on debugging on the OHCI controller by: systctl hw.usb.ohci.debug=15 Replace ohci by ehci or uhci if you are using such controllers. Strange today reading seems to work. I will check other functionality later. This bootloader device uses bulk transfer. ===[mcuee] ~/Desktop/build/fsusb/fsusb-0.1.11-2 # sudo ./fsusb --read test3.hex usb_set_debug: Setting debugging level to 255 (on) Locating USB Microchip(tm) PICDEM-FS USB(tm) (vendor 0x04d8/product 0x000b) usb_os_find_busses: Found /dev/usb0 usb_os_find_busses: Found /dev/usb1 usb_os_find_busses: Found /dev/usb2 usb_os_find_devices: Found /dev/ugen0 on /dev/usb1 usb_control_msg: 128 6 512 0 0xbfbfe828 8 1000 usb_control_msg: 128 6 512 0 0x804d0e0 32 1000 Found USB PICDEM-FS USB as device '/dev/ugen0' on USB bus /dev/usb1 Communication established. Onboard firmware version is 1.0 Finished reading More info about the bootloader device: ===[mcuee] /usr/ports/sysutils/usbutil # sudo usbgen -f ugen0 -v -D Dumping all descriptors DEVICE descriptor: bLength=18 bDescriptorType=1 bcdUSB=2.00 bDeviceClass=0 bDeviceSubClass=0 bDeviceProtocol=0 bMaxPacketSize=8 idVendor=0x04d8 idProduct=0x000b bcdDevice=0 iManufacturer=0 iProduct=0 iSerialNumber=0 bNumConfigurations=1 Current configuration is number 1 CONFIGURATION descriptor index 0: bLength=9 bDescriptorType=2 wTotalLength=32 bNumInterface=1 bConfigurationValue=1 iConfiguration=0 bmAttributes=80 bMaxPower=100 mA INTERFACE descriptor index 0, alt index 0: bLength=9 bDescriptorType=4 bInterfaceNumber=0 bAlternateSetting=0 bNumEndpoints=2 bInterfaceClass=0 bInterfaceSubClass=0 bInterfaceProtocol=0 iInterface=0 ENDPOINT descriptor index 0: bLength=7 bDescriptorType=5 bEndpointAddress=1-out bmAttributes=2 wMaxPacketSize=64 bInterval=0 ENDPOINT descriptor index 1: bLength=7 bDescriptorType=5 bEndpointAddress=1-in bmAttributes=2 wMaxPacketSize=64 bInterval=0 Do you have any USB protocol analyser by hand so that you can trace the USB cable ? Not yet. I am only doing this as a USB hobbyist. Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PICkit 2 again with HPS stack
On 10/13/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: Resource temporarily unavailable maps to EAGAIN according to man errno. From what I can see from the log you have provided this means that the msleep() call in ugenread timed out. What timeout have you programmed in your PICkit ? It is 1000ms. I change it to 1ms but this does not help. Can you set the debugging value to 15 using the PICkit ? Alternativly: sysctl hw.usb.debug=15 ===[mcuee] ~/Desktop/build/pk2-2.04 # sudo sysctl hw.usb.debug=15 hw.usb.debug: 15 - 15 ===[mcuee] ~/Desktop/build/pk2-2.04 # sudo ./pk2 --on PK2 version 2.04 - 2006/12/17 ./pk2 --on usb_set_debug: Setting debugging level to 255 (on) Locating USB Microchip PICkit2 (vendor 0x04d8/product 0x0033) usb_os_find_busses: Found /dev/usb0 usb_os_find_busses: Found /dev/usb1 usb_os_find_busses: Found /dev/usb2 usb_os_find_devices: Found /dev/ugen1 on /dev/usb1 usb_os_find_devices: Found /dev/ugen0 on /dev/usb1 usb_control_msg: 128 6 512 0 0xbfbfe7e8 8 1000 usb_control_msg: 128 6 512 0 0x8066120 32 1000 usb_control_msg: 128 6 512 0 0xbfbfe7e8 8 1000 usb_control_msg: 128 6 512 0 0x806c0c0 41 1000 skipped 1 class/vendor specific interface descriptors usb_control_msg: 128 6 513 0 0xbfbfe7e8 8 1000 usb_control_msg: 128 6 513 0 0x8066160 32 1000 Found USB PICkit as device '/dev/ugen1' on USB bus /dev/usb1 Setting USB configuration is okay. Claiming USB interface is okay. Sending GETVERSION command using interrupt transfer. USB 76 Receiving PICkit VERSION information using interrupt transfer. USB error: error reading from interrupt endpoint /dev/ugen1.1: Resource temporarily unavailable Fatal error USB read did not return 64 bytes ===[mcuee] ~/Desktop/build/pk2-2.04 # dmesg | grep ugen ugenopen: flag=1, mode=8192 ugenioctl: cmd=40125569 ugenclose: flag=1, mode=8192 ugenopen: flag=1, mode=8192 ugenioctl: cmd=40125569 ugenclose: flag=1, mode=8192 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenclose: flag=3, mode=8192 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenclose: flag=3, mode=8192 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045565 ugen_set_config: configno 1, sc=0xc35c7000 ugenclose: flag=0, mode=0 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045572 ugenwrite: ugenwrite: transferred 64 bytes ugen_write_clear_stall_callback: sce=0xc35c7084: stall cleared ugen_default_write_callback: waking 0xc35c7084 ugenioctl: cmd=80045572 ugenioctl: cmd=80045571 ugenread: ugen_open_pipe_read: interrupt open done ugen_read_clear_stall_callback: sce=0xc35c7084: stall cleared ugenclose: flag=3, mode=8192 ugenclose: flag=3, mode=8192 To Hans: The full dmesg log will be sent to you per email. Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
PICDEM FS USB Demo under FreeBSD with HPS Stack
Today I checked the Demo mode of PICDEM FS USB demo board. it does not work either. Again this uses interrupt transfer. ===[mcuee] ~/Desktop/build/pyusb-0.4.1/samples # sudo ./usbenum.py Device: /dev/ugen0 Device class: 0 Device sub class: 0 Device protocol: 0 Max packet size: 8 idVendor: 1240 idProduct: 12 Device Version: 00.00 Configuration: 1 Total length: 32 selfPowered: 0 remoteWakeup: 0 maxPower: 200 Interface: 0 Alternate Setting: 0 Interface class: 0 Interface sub class: 0 Interface protocol: 0 Endpoint: 0x1 Type: 3 Max packet size: 64 Interval: 32 Endpoint: 0x81 Type: 3 Max packet size: 64 Interval: 32 ===[mcuee] ~/Desktop/build/fsusb/Demo # sudo ./fsusb_demo Password: Locating Microchip(tm) PICDEM(tm) FS USB Demo Board (vendor 0x04d8/product 0x000c) usb_set_debug: Setting debugging level to 255 (on) setting USB debug on by adding usb_set_debug(255) usb_os_find_busses: Found /dev/usb0 usb_os_find_busses: Found /dev/usb1 usb_os_find_busses: Found /dev/usb2 usb_os_find_devices: Found /dev/ugen1 on /dev/usb1 usb_os_find_devices: Found /dev/ugen0 on /dev/usb1 usb_control_msg: 128 6 512 0 0xbfbfe888 8 1000 usb_control_msg: 128 6 512 0 0x804b100 32 1000 usb_control_msg: 128 6 512 0 0xbfbfe888 8 1000 usb_control_msg: 128 6 512 0 0x80500c0 41 1000 skipped 1 class/vendor specific interface descriptors usb_control_msg: 128 6 513 0 0xbfbfe888 8 1000 usb_control_msg: 128 6 513 0 0x804b140 32 1000 Found USB PICDEM FS USB Demo Board as device '/dev/ugen0' on USB bus /dev/usb1 Communication established. USB error: error reading from bulk endpoint /dev/ugen0.1: Resource temporarily unavailable usb PICDEM FS USB read: Resource temporarily unavailable Fatal error USB read failed ===[mcuee] ~/Desktop/build/fsusb/Demo # dmesg | grep ugen ugenopen: flag=1, mode=8192 ugenioctl: cmd=40125569 ugenclose: flag=1, mode=8192 ugenopen: flag=1, mode=8192 ugenioctl: cmd=40125569 ugenclose: flag=1, mode=8192 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenclose: flag=3, mode=8192 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenioctl: cmd=80045572 ugenioctl: cmd=c018556f ugenclose: flag=3, mode=8192 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045565 ugen_set_config: configno 1, sc=0xc3a72000 ugenclose: flag=0, mode=0 ugenopen: flag=3, mode=8192 ugenioctl: cmd=80045572 ugenwrite: ugenwrite: transferred 2 bytes ugen_write_clear_stall_callback: sce=0xc3a72084: stall cleared ugen_default_write_callback: waking 0xc3a72084 ugenioctl: cmd=80045572 ugenioctl: cmd=80045571 ugenread: ugen_open_pipe_read: interrupt open done ugen_read_clear_stall_callback: sce=0xc3a72084: stall cleared ugenclose: flag=3, mode=8192 ugenclose: flag=3, mode=8192 Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PICkit 2 again with HPS stack
On 10/13/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: What timeout have you programmed in your PICkit ? It is 1000ms. I change it to 1ms but this does not help. Do you see that the code is waiting 10 seconds for the timeout ? I think so. The program stops quite a while before quit. Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PICDEM FS USB Demo under FreeBSD with HPS Stack
On 10/13/07, Xiaofan Chen [EMAIL PROTECTED] wrote: Oops, the original code is using bulk transfer. I changed it to interrupt transfer but the error is the same. ===[mcuee] ~/Desktop/build/fsusb/Demo # sudo ./fsusb_demo Locating Microchip(tm) PICDEM(tm) FS USB Demo Board (vendor 0x04d8/product 0x000c) usb_set_debug: Setting debugging level to 255 (on) setting USB debug on by adding usb_set_debug(255) usb_os_find_busses: Found /dev/usb0 usb_os_find_busses: Found /dev/usb1 usb_os_find_busses: Found /dev/usb2 usb_os_find_devices: Found /dev/ugen0 on /dev/usb1 usb_control_msg: 128 6 512 0 0xbfbfe858 8 1000 usb_control_msg: 128 6 512 0 0x804b0e0 32 1000 Found USB PICDEM FS USB Demo Board as device '/dev/ugen0' on USB bus /dev/usb1 Communication established. USB error: error reading from interrupt endpoint /dev/ugen0.1: Resource temporarily unavailable usb PICDEM FS USB read: Resource temporarily unavailable Fatal error USB read failed So I go back to the old kernel and it actually works. ===[mcuee] ~/Desktop/build/fsusb/Demo # sudo ./fsusb_demo Password: Locating Microchip(tm) PICDEM(tm) FS USB Demo Board (vendor 0x04d8/product 0x000c) usb_set_debug: Setting debugging level to 255 (on) setting USB debug on by adding usb_set_debug(255) usb_os_find_busses: Found /dev/usb0 usb_os_find_busses: Found /dev/usb1 usb_os_find_busses: Found /dev/usb2 usb_os_find_devices: Found /dev/ugen1 on /dev/usb1 usb_os_find_devices: Found /dev/ugen0 on /dev/usb1 usb_control_msg: 128 6 512 0 0xbfbfe868 8 1000 usb_control_msg: 128 6 512 0 0x804b100 32 1000 usb_control_msg: 128 6 512 0 0xbfbfe868 8 1000 usb_control_msg: 128 6 512 0 0x8052080 41 1000 skipped 1 class/vendor specific interface descriptors usb_control_msg: 128 6 513 0 0xbfbfe868 8 1000 usb_control_msg: 128 6 513 0 0x804b160 32 1000 Found USB PICDEM FS USB Demo Board as device '/dev/ugen0' on USB bus /dev/usb1 Communication established. answer was correct! Onboard firmware version is 1.0 fsusb_demo: Software for PICDEM Full Speed USB demo board fsusb_demo --ledon n, n=3 or 4: ON LED D3 or D4 fsusb_demo --ledff n, n=3 or 4: Off LED D3 or D4 fsusb_demo --readtemp: read out temperature fsusb_demo --readpot: read out poti value fsusb_demo --reset: to reset the PICDEM FS USB demo board ===[mcuee] ~/Desktop/build/fsusb/Demo # sudo ./fsusb_demo --readpot Locating Microchip(tm) PICDEM(tm) FS USB Demo Board (vendor 0x04d8/product 0x000c) usb_set_debug: Setting debugging level to 255 (on) setting USB debug on by adding usb_set_debug(255) usb_os_find_busses: Found /dev/usb0 usb_os_find_busses: Found /dev/usb1 usb_os_find_busses: Found /dev/usb2 usb_os_find_devices: Found /dev/ugen1 on /dev/usb1 usb_os_find_devices: Found /dev/ugen0 on /dev/usb1 usb_control_msg: 128 6 512 0 0xbfbfe848 8 1000 usb_control_msg: 128 6 512 0 0x804b100 32 1000 usb_control_msg: 128 6 512 0 0xbfbfe848 8 1000 usb_control_msg: 128 6 512 0 0x8052080 41 1000 skipped 1 class/vendor specific interface descriptors usb_control_msg: 128 6 513 0 0xbfbfe848 8 1000 usb_control_msg: 128 6 513 0 0x804b160 32 1000 Found USB PICDEM FS USB Demo Board as device '/dev/ugen0' on USB bus /dev/usb1 Communication established. answer was correct! Onboard firmware version is 1.0 Potentiometer now reads 263 usb_os_close: closing endpoint 4 FreeBSD FreeBsd62.Mshome 6.2-STABLE FreeBSD 6.2-STABLE #1: Wed Apr 4 07:47:03 SGT 2007 [EMAIL PROTECTED]:/home/obj/home/src/sys/USBDEBUG i386 Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PICkit 2 again with HPS stack
On 10/16/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: On Saturday 13 October 2007, Xiaofan Chen wrote: On 10/13/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: Resource temporarily unavailable maps to EAGAIN according to man errno. From what I can see from the log you have provided this means that the msleep() call in ugenread timed out. What timeout have you programmed in your PICkit ? It is 1000ms. I change it to 1ms but this does not help. Do you see this timeout ? Does the code actually wait 10 seconds ? I think so. In the file ugen.c in the function ugen_open_pipe_read() you will find a case UE_INTERRUPT:. Some lines further down you will find: /* first transfer clears stall */ sce-read_stall = 1; This you can set to 0. Then recompile and install the ugen module and/or kernel. Does your USB hardware work now ? Yes with the changes, PICkit 2 is happy again under Linux. ===[mcuee] ~/Desktop/build/mypk2 # sudo python testpk2.py set Configuration 1 claim Interface 0 Turing power on by USB interrupt write Sending version command by USB interrupt write Getting version command by USB interrupt read (2, 10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) Thanks a lot. So it seems there is still a bug in the firmware. Maybe two. The first one caused the stall (why?). The second one is still related to dealing with clear stall feature request. Right? Regards, Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PICDEM FS USB Demo under FreeBSD with HPS Stack
On 10/13/07, Xiaofan Chen [EMAIL PROTECTED] wrote: Today I checked the Demo mode of PICDEM FS USB demo board. it does not work either. Again this uses interrupt transfer. This is with the latest HPS USB stack and 6.2 Stable. On 10/16/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: On Saturday 13 October 2007, Xiaofan Chen wrote: On 10/13/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: In the file ugen.c in the function ugen_open_pipe_read() you will find a case UE_INTERRUPT:. Some lines further down you will find: /* first transfer clears stall */ sce-read_stall = 1; This you can set to 0. Then recompile and install the ugen module and/or kernel. Does your USB hardware work now ? This also solved the problem with PICDEM FS USB demo board. Thanks! ===[mcuee] ~/Desktop/build/fsusb/Demo # sudo ./fsusb_demo --readpot Locating Microchip(tm) PICDEM(tm) FS USB Demo Board (vendor 0x04d8/product 0x000c) usb_set_debug: Setting debugging level to 255 (on) setting USB debug on by adding usb_set_debug(255) usb_os_find_busses: Found /dev/usb0 usb_os_find_busses: Found /dev/usb1 usb_os_find_busses: Found /dev/usb2 usb_os_find_devices: Found /dev/ugen1 on /dev/usb1 usb_os_find_devices: Found /dev/ugen0 on /dev/usb1 usb_control_msg: 128 6 512 0 0xbfbfe9a8 8 1000 usb_control_msg: 128 6 512 0 0x8051040 41 1000 skipped 1 class/vendor specific interface descriptors usb_control_msg: 128 6 513 0 0xbfbfe9a8 8 1000 usb_control_msg: 128 6 513 0 0x804b120 32 1000 usb_control_msg: 128 6 512 0 0xbfbfe9a8 8 1000 usb_control_msg: 128 6 512 0 0x804b160 32 1000 Found USB PICDEM FS USB Demo Board as device '/dev/ugen1' on USB bus /dev/usb1 Communication established. answer was correct! Onboard firmware version is 1.0 Potentiometer now reads 263 usb_os_close: closing endpoint 4 Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PICDEM FS USB Bootloader under FreeBSD
On 10/13/07, Xiaofan Chen [EMAIL PROTECTED] wrote: On 10/13/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: I think that the write STALLED. You can check this by turning on debugging on the OHCI controller by: systctl hw.usb.ohci.debug=15 Replace ohci by ehci or uhci if you are using such controllers. Strange today reading seems to work. I will check other functionality later. This bootloader device uses bulk transfer. So this is the last one I want to make to work under FreeBSD right now. Unfortunately verifying and writing are still not working. Reading is working. The bootloader firmware uses a cut-down version of the USB firmware framework. Maybe it is even buggier. ===[mcuee] ~/Desktop/build/fsusb/fsusb-0.1.11-2 # sudo ./fsusb newdemo.hex usb_set_debug: Setting debugging level to 255 (on) Locating USB Microchip(tm) PICDEM-FS USB(tm) (vendor 0x04d8/product 0x000b) usb_os_find_busses: Found /dev/usb0 usb_os_find_busses: Found /dev/usb1 usb_os_find_busses: Found /dev/usb2 usb_os_find_devices: Found /dev/ugen0 on /dev/usb1 usb_control_msg: 128 6 512 0 0xbfbfe988 8 1000 usb_control_msg: 128 6 512 0 0x804d0e0 32 1000 Found USB PICDEM-FS USB as device '/dev/ugen0' on USB bus /dev/usb1 Communication established. Onboard firmware version is 1.0 ^C CTRL-C since it hanges here. ===[mcuee] ~/Desktop # dmesg ... ohci_root_ctrl_task_td: type=0x80 request=0x06 wLen=0x0002 wValue=0x0301 wIndex=0x0001 ohci_device_done: xfer=0xc41a9a20, pipe=0xc3053100 length=10 error=0 ohci_device_done: xfer=0xc41a9a20, pipe=0xc3053100 length=10 error=5 ohci_root_ctrl_task_td: type=0x80 request=0x06 wLen=0x000e wValue=0x0301 wIndex=0x0001 ohci_device_done: xfer=0xc41aa420, pipe=0xc3053100 length=22 error=0 ohci_device_done: xfer=0xc41aa420, pipe=0xc3053100 length=22 error=5 ohci_root_ctrl_task_td: type=0x80 request=0x06 wLen=0x0002 wValue=0x0302 wIndex=0x0001 ohci_device_done: xfer=0xc41a9820, pipe=0xc3053100 length=10 error=0 ohci_device_done: xfer=0xc41a9820, pipe=0xc3053100 length=10 error=5 ohci_root_ctrl_task_td: type=0x80 request=0x06 wLen=0x001c wValue=0x0302 wIndex=0x0001 ohci_device_done: xfer=0xc41a9c20, pipe=0xc3053100 length=36 error=0 ohci_device_done: xfer=0xc41a9c20, pipe=0xc3053100 length=36 error=5 ohci_root_ctrl_task_td: type=0x80 request=0x06 wLen=0x0002 wValue=0x0301 wIndex=0x0001 ohci_device_done: xfer=0xc3cdaa20, pipe=0xc3054900 length=10 error=0 ohci_device_done: xfer=0xc3cdaa20, pipe=0xc3054900 length=10 error=5 ohci_root_ctrl_task_td: type=0x80 request=0x06 wLen=0x000e wValue=0x0301 wIndex=0x0001 ohci_device_done: xfer=0xc41a9e20, pipe=0xc3054900 length=22 error=0 ohci_device_done: xfer=0xc41a9e20, pipe=0xc3054900 length=22 error=5 ohci_root_ctrl_task_td: type=0x80 request=0x06 wLen=0x0002 wValue=0x0302 wIndex=0x0001 ohci_device_done: xfer=0xc41a9420, pipe=0xc3054900 length=10 error=0 ohci_device_done: xfer=0xc41a9420, pipe=0xc3054900 length=10 error=5 ohci_root_ctrl_task_td: type=0x80 request=0x06 wLen=0x001c wValue=0x0302 wIndex=0x0001 ohci_device_done: xfer=0xc41a9020, pipe=0xc3054900 length=36 error=0 ohci_device_done: xfer=0xc41a9020, pipe=0xc3054900 length=36 error=5 ohci_setup_standard_chain: addr=126 endpt=0 len=16 speed=2 ohci_setup_standard_chain: nexttog=1; data before transfer: TD(0xe6a8b080) at 0x3eb13080: -TOG0 delay=7 ec=0 cc=15 cbp=0x3eb13000 next=0x3eb13060 be=0x3eb13007 TD(0xe6a8b060) at 0x3eb13060: -R-IN-TOG1 delay=7 ec=0 cc=15 cbp=0x3eb13008 next=0x3eb13040 be=0x3eb1300f TD(0xe6a8b040) at 0x3eb13040: -OUT-TOG1 delay=1 ec=0 cc=15 cbp=0x next=0x be=0x _ohci_append_qh: 0xe6a8b0a0 to 0xc3007100 ohci_check_transfer: xfer=0xc3cd9c20 checking transfer ohci_non_isoc_done: xfer=0xc3cd9c20 pipe=0xc41a2900 transfer done TD(0xe6a8b080) at 0x3eb13080: -TOG1 delay=7 ec=0 cc=0 cbp=0x next=0x be=0x3eb13007 ohci_non_isoc_done: len=8 ohci_non_isoc_done: len=8 ohci_non_isoc_done: len=0 ohci_non_isoc_done: actlen=16 ohci_device_done: xfer=0xc3cd9c20, pipe=0xc41a2900 length=16 error=0 _ohci_remove_qh: 0xe6a8b0a0 from 0xe6a8b0a0 ohci_device_done: xfer=0xc3cd9c20, pipe=0xc41a2900 length=16 error=5 _ohci_remove_qh: 0xe6a8b0a0 from 0xc3007100 ohci_setup_standard_chain: addr=126 endpt=0 len=40 speed=2 ohci_setup_standard_chain: nexttog=1; data before transfer: TD(0xe6a8b0a0) at 0x3eb130a0: -TOG0 delay=7 ec=0 cc=15 cbp=0x3eb13000 next=0x3eb13080 be=0x3eb13007 TD(0xe6a8b080) at 0x3eb13080: -R-IN-TOG1 delay=7 ec=0 cc=15 cbp=0x3eb13008 next=0x3eb13060 be=0x3eb13027 TD(0xe6a8b060) at 0x3eb13060: -OUT-TOG1 delay=1 ec=0 cc=15 cbp=0x next=0x be=0x _ohci_append_qh: 0xe6a8b0c0 to 0xc3007100 ohci_check_transfer: xfer=0xc41a9220 checking transfer ohci_non_isoc_done: xfer=0xc41a9220 pipe=0xc41a2900 transfer done TD(0xe6a8b0a0) at 0x3eb130a0: -TOG1 delay=7 ec=0 cc=0 cbp=0x next=0x be=0x3eb13007 ohci_non_isoc_done: len=8 ohci_non_isoc_done: len=32 ohci_non_isoc_done: len=0 ohci_non_isoc_done: actlen=40 ohci_device_done: xfer
Re: PICkit 2 again with HPS stack
On 10/17/07, Hans Petter Selasky [EMAIL PROTECTED] wrote:
Thanks a lot. So it seems there is still a bug in the firmware. Maybe two.
The first one caused the stall (why?). The second one is still related to
dealing with clear stall feature reques
I think that the clear-stall command will flush the FIFO of the interrupt
endpoint.
Is it possible that you can open the interrupt endpoint which is a
file, /dev/ugenX.X, before sending the version command ? So that we
don't end up clearing the stall after sending the command, but before.
PICkit 2 applications I am testing now are all using libusb. I have
not really looked into the libusb FreeBSD codes (I am not good
at programming) but I will try.
I have the following codes from a FreeBSD user. He is trying not to
use libusb. I will try to add his codes to see if it helps.
static void check_device_id(void)
{
usb_device_descriptor_t udd;
ioctl(fdpk2, USB_GET_DEVICE_DESC, udd);
if (udd.idVendor != vidMicrochip || udd.idProduct != pidPICkit2)
die(device isn't a PICkit2);
}
void pk2open(char *devname)
{
printf(pk2open =\n);
fdpk2 = open(devname, O_RDWR);
if (fdpk2 0)
die_errno(open failed);
check_device_id();
printf(pk2open =\n);
}
static char *pk2dev = /dev/ugen0.1;
int main(int argc, char **argv)
{
pk2open(pk2dev);
...
}
Regards,
Xiaofan
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]
OpenUSB for FreeBSD?
OpenUSB's API is now rather stable and they have the front end and Linux/Solaris backend basically done. It is a fork of libusb-1.0 development branch since that branch is dormant for a while. The aim is to be thread safe and supports assync I/O and isochronous transfer where libusb-0.1 may have problems. Is it possible for some people here to implement a backend (based on ugen?) for FreeBSD? OpeUSB webpage: http://openusb.sourceforge.net/ http://openusb.sourceforge.net/documents/guide/index.html Or maybe at least improve the current libusb-0.1.x implemenation for FreeBSD. By the way, the latest CVS version of usbutils (lsusb) supports FreeBSD and it is rather a nice tool. Xiaofan http://mcuee.blogspot.com ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenUSB for FreeBSD?
On 11/12/07, Henrik Brix Andersen [EMAIL PROTECTED] wrote: Is it possible for some people here to implement a backend (based on ugen?) for FreeBSD? Interesting - definitely something I will take a look at. Thank you for the pointer. Or maybe at least improve the current libusb-0.1.x implemenation for FreeBSD. Yeah, I was looking at backporting some of the features from libusb CVS HEAD to libusb-0.1 on FreeBSD a while back and improving FreeBSD compatability as well for an application, I work on - but we ended up making FreeBSD specific work-arounds in the application instead. Could you be a bit more specific? I know there are some missing calls in FreeBSD. And I have problems with libusb interrupt write with the default kernel (hangs). It is documented here. http://lists.freebsd.org/pipermail/freebsd-usb/2007-November/004128.html But I am not so sure if it is a libusb problem or the kernel USB driver problem. The HPS stack seems to be better in this aspect and I got some libusb application ported from Linux/Windows to FreeBSD thanks to the help from Hans. The current stable version of libusb certainly makes a lot to wish for on FreeBSD. Seems to be quite true. Regards, Xiaofan http://mcuee.blogspot.com ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenUSB for FreeBSD?
On Nov 17, 2007 4:38 PM, Hans Petter Selasky [EMAIL PROTECTED] wrote: Could you be a bit more specific? I know there are some missing calls in FreeBSD. And I have problems with libusb interrupt write with the default kernel (hangs). It is documented here. http://lists.freebsd.org/pipermail/freebsd-usb/2007-November/004128.html But I am not so sure if it is a libusb problem or the kernel USB driver problem. The problem about clear stall on the interrupt endpoint is a pure device problem. Your USB device must re-queue any lost interrupt packets after clear stall! Sorry but that problem does not occur using the HPS stack but the stock FreeBSD 7 Current kernel (actually in FreeBSD 6.1 and 6.2 as well last time I tried it). Under HPS stack, it works. And I remember that Warner said that the Current kernel does not clear stall. Quote from http://lists.freebsd.org/pipermail/freebsd-usb/2007-July/003751.html Warner Losh wrote: Remind me when is this clear endpoint stall sent? In 7.x we don't send one on pipe open unless the device is quirked to require one. On RELENG_6, at least as of today, we never send one on the open. Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenUSB for FreeBSD?
On Nov 17, 2007 7:31 PM, Hans Petter Selasky [EMAIL PROTECTED] wrote: On Saturday 17 November 2007, Xiaofan Chen wrote: On Nov 17, 2007 4:38 PM, Hans Petter Selasky [EMAIL PROTECTED] wrote: Could you be a bit more specific? I know there are some missing calls in FreeBSD. And I have problems with libusb interrupt write with the default kernel (hangs). It is documented here. http://lists.freebsd.org/pipermail/freebsd-usb/2007-November/004128.htm l But I am not so sure if it is a libusb problem or the kernel USB driver problem. The problem about clear stall on the interrupt endpoint is a pure device problem. Your USB device must re-queue any lost interrupt packets after clear stall! Sorry but that problem does not occur using the HPS stack but the stock FreeBSD 7 Current kernel (actually in FreeBSD 6.1 and 6.2 as well last time I tried it). Under HPS stack, it works. And I remember that Warner said that the Current kernel does not clear stall. Quote from http://lists.freebsd.org/pipermail/freebsd-usb/2007-July/003751.html Warner Losh wrote: Remind me when is this clear endpoint stall sent? In 7.x we don't send one on pipe open unless the device is quirked to require one. On RELENG_6, at least as of today, we never send one on the open. Ok, but is that with or without that patch I sent you for Ugen ? I need the single line patch for ugen. I understand that the firmware may still have the bug dealing with clear endpoint stall. It is documented here: http://mcuee.blogspot.com/2007/11/pk2cmd-ported-to-linux.html Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BlackBerry (Re: using libusb)
On Jan 10, 2008 2:34 AM, Hans Petter Selasky [EMAIL PROTECTED] wrote: On Wednesday 09 January 2008, Mikhail Teterin wrote: We really need the low-level (ugen?) interfaces available for all USB-devices -- even those, which are /also/ handled by higher-level interfaces (like ulpt, uscan, umass). As things stand, the higher-level ones are greedy and will prevent ugen from appearing, even if one wanted to. Yes, you are completely right. And this is not very far away from happening. I've wanted to do this for a long time, but have found no time yet. My plan is to extend /dev/usbX so that it becomes a so-called clonable device. When you open up /dev/usb0.2.3 for example, you open up the device having index 2 on USB bus 0 and endpoint 3. This will need some modifications in libusb. Ugen will still be there, but I plan to move the functionality over to usb.c. Accessing endpoints will then work regardless of what drivers are hooked on. I am a non-programmer (I only know a bit of C) and not a USB expert. But I like libusb and use it with some USB devices. If you can get this done for FreeBSD, it will be wonderful. On the Linux libusb front, there are two new things going on. One is that the new libusb maintainer will be Daniel Drake and he will use his fpusb as the base for libusb 1.0 and get rid of the old 1.0 code. The 0.1 branch may also get some fixes. http://www.nabble.com/libusb-future-to14571903.html http://reactivated.net/fprint/wiki/Fpusb The other development is OpenUSB (under Solaris and Linux) mainly sponsored by Sun. http://openusb.sourceforge.net/wiki/index.php/Main_Page So you might look into these two. Some open problems that needs to be resolved: Should we allow parallell access to USB interfaces? Do you mean thread safe access and/or assynchronous I/O? You might want to check out OpenUSB. And what about rights management? From what I know, it seems devfs rule works fine under FreeBSD. http://mcuee.blogspot.com/2007/11/setting-up-permissions-for-usb-ports-to.html (my blog post). Under Linux, the old one is using hotplug, now udev rules or HAL. Regards, Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PICkit 2 again with HPS stack
On Thu, Apr 24, 2008 at 10:59 PM, Xiaofan Chen [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] /var/crash]# ls -la total 508352 drwxr-x--- 2 root wheel512 Apr 24 22:07 . drwxr-xr-x 25 root wheel512 Apr 25 06:07 .. -rw-r--r-- 1 root wheel 2 Apr 24 22:07 bounds -rw--- 1 root wheel444 Mar 30 16:19 info.0 -rw--- 1 root wheel445 Mar 30 16:52 info.1 -rw--- 1 root wheel446 Apr 24 21:58 info.2 -rw--- 1 root wheel446 Apr 24 22:07 info.3 -rw-r--r-- 1 root wheel 5 Feb 25 01:53 minfree -rw--- 1 root wheel 61952000 Mar 30 16:19 vmcore.0 -rw--- 1 root wheel 175443968 Mar 30 16:52 vmcore.1 -rw--- 1 root wheel 168951808 Apr 24 21:59 vmcore.2 -rw--- 1 root wheel 163037184 Apr 24 22:07 vmcore.3 [EMAIL PROTECTED] /var/crash]# cat info.3 Dump header from device /dev/ad4s4b Architecture: i386 Architecture Version: 2 Dump Length: 163037184B (155 MB) Blocksize: 512 Dumptime: Thu Apr 24 22:04:54 2008 Hostname: freebsd7.MSHOME.net Magic: FreeBSD Kernel Dump Version String: FreeBSD 7.0-RELEASE #1: Sun Mar 30 16:29:52 SGT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/custom Panic String: page fault Dump Parity: 2907024719 Bounds: 3 Dump Status: good All the 4 crashes are caused by this problem. It used to run fine with the 7.0-Beta1/2/3 kernel and the HPS stack. http://mcuee.blogspot.com/2007/11/pk2cmd-ported-to-linux.html How should I attack this problem? More information here (by following the steps of the following URL: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html). freebsd7# kgdb kernel.debug /var/crash/vmcore.3 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd. Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor read, page not present instruction pointer = 0x20:0xc077f155 stack pointer = 0x28:0xe6c19a48 frame pointer = 0x28:0xe6c19a64 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 1140 (pk2) trap number = 12 panic: page fault cpuid = 0 Uptime: 7m27s Physical memory: 1011 MB Dumping 155 MB: 140 124 108 92 76 60 44 28 12 #0 doadump () at pcpu.h:195 195 __asm __volatile(movl %%fs:0,%0 : =r (td)); (kgdb) list *0xc077f155 0xc077f155 is in turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:835). 830 831 /* 832 * Transfer the blocked list to the pending list. 833 */ 834 mtx_lock_spin(td_contested_lock); 835 TAILQ_CONCAT(ts-ts_pending, ts-ts_blocked[queue], td_lockq); 836 mtx_unlock_spin(td_contested_lock); 837 838 /* 839 * Give a turnstile to each thread. The last thread gets (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc074ddc7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc074e089 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0a53c9c in trap_fatal (frame=0xe6c19a08, eva=24) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0a545ff in trap (frame=0xe6c19a08) at /usr/src/sys/i386/i386/trap.c:280 #5 0xc0a3b20b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc077f155 in turnstile_broadcast (ts=0x0, queue=0) at /usr/src/sys/kern/subr_turnstile.c:835 #7 0xc0741712 in _mtx_unlock_sleep (m=0xc0bf3710, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:605 #8 0xc098cb7f in usbd_do_request_flags (udev=0xc40bc800, mtx=0xc0bf3710, req=0xe6c19afc, data=0xe6c19b63, flags=0, actlen=0x0, timeout=5000) at /usr/src/sys/dev/usb/usb_transfer.c:3952 #9 0xc0981371 in usbreq_get_desc (udev=0xc40bc800, mtx=0xc0bf3710, desc=0xe6c19b63, min_len=9, max_len=9, id=0, type=2 '\002', index=0 '\0', retries=0 '\0') at /usr/src/sys/dev/usb/usb_requests.c:202 #10 0xc0981585 in usbreq_get_config_desc (udev=0xc40bc800, mtx=0xc0bf3710, d=0xe6c19b63, conf_index=Variable conf_index is not available. ) at /usr/src/sys/dev/usb/usb_requests.c:367 #11 0xc09849a4 in usbd_set_config_no (udev=0xc40bc800, no=2 '\002', msg=1 '\001') at /usr/src/sys/dev/usb/usb_subr.c:1028 #12 0xc06be879
Re: PICkit 2 again with HPS stack
On Thu, Apr 24, 2008 at 11:21 PM, Hans Petter Selasky [EMAIL PROTECTED] wrote: I have fixed some issues where the Giant lock was not locked when calling into the USB stack recently. What version are you at? A stack backtrace from the panic would also be nice. Make sure that everything is built clean. [EMAIL PROTECTED] /usr/home/mcuee/Desktop/usb/i4b]$ svn info Path: . URL: svn://svn.turbocat.net/i4b Repository Root: svn://svn.turbocat.net/i4b Repository UUID: 4429bdba-5c01-0410-9f4f-ee3375ed255f Revision: 651 Node Kind: directory Schedule: normal Last Changed Author: hselasky Last Changed Rev: 651 Last Changed Date: 2008-03-29 20:04:10 +0800 (Sat, 29 Mar 2008) I will update to see if the later code fixed this problem. The backtrace is enclosed in the previous post. The other libusb based program fsusb_demo still works fine. (discussed last time in the thread: http://lists.freebsd.org/pipermail/freebsd-usb/2007-October/004087.html). [EMAIL PROTECTED] /usr/home/mcuee/Desktop/build/fsusb]$ ./fsusb_demo --readpot Locating Microchip(tm) PICDEM(tm) FS USB Demo Board (vendor 0x04d8/product 0x000c) usb_set_debug: Setting debugging level to 255 (on) setting USB debug on by adding usb_set_debug(255) usb_os_find_busses: Found /dev/usb0 usb_os_find_busses: Found /dev/usb1 usb_os_find_busses: can't open /dev/usb2: Permission denied usb_os_find_devices: Found /dev/ugen0 on /dev/usb0 usb_control_msg: 128 6 512 0 0xbfbfe964 8 1000 usb_control_msg: 128 6 512 0 0x2820c070 41 1000 skipped 1 class/vendor specific interface descriptors usb_control_msg: 128 6 513 0 0xbfbfe964 8 1000 usb_control_msg: 128 6 513 0 0x2820a080 32 1000 usb_os_find_devices: Found /dev/ugen1 on /dev/usb1 usb_control_msg: 128 6 512 0 0xbfbfe964 8 1000 usb_control_msg: 128 6 512 0 0x2820a0c0 32 1000 Found USB PICDEM FS USB Demo Board as device '/dev/ugen1' on USB bus /dev/usb1 Communication established. answer was correct! Onboard firmware version is 1.20 Potentiometer now reads 650 usb_os_close: closing endpoint 4 Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PICDEM FS USB Bootloader under FreeBSD
On Tue, Oct 16, 2007 at 9:34 PM, Xiaofan Chen [EMAIL PROTECTED] wrote: On 10/13/07, Xiaofan Chen [EMAIL PROTECTED] wrote: On 10/13/07, Hans Petter Selasky [EMAIL PROTECTED] wrote: I think that the write STALLED. You can check this by turning on debugging on the OHCI controller by: systctl hw.usb.ohci.debug=15 Replace ohci by ehci or uhci if you are using such controllers. Strange today reading seems to work. I will check other functionality later. This bootloader device uses bulk transfer. So this is the last one I want to make to work under FreeBSD right now. Unfortunately verifying and writing are still not working. Reading is working. The bootloader firmware uses a cut-down version of the USB firmware framework. Maybe it is even buggier. This does not work either with 7.0-Release and the HPS USB stack. I will update to the latest SVN version of the HPS stack and see if the situation will improve. The bootlaoder does work under Linux (as well as Windows) fine with libusb (libusb-win32). [EMAIL PROTECTED] ~/Desktop/build/fsusb/fsusb-0.1.11-2]$ sudo ./fsusb --verify demo.hex Locating USB Microchip(tm) PICDEM-FS USB(tm) (vendor 0x04d8/product 0x000b) Found USB PICDEM-FS USB as device '/dev/ugen1' on USB bus /dev/usb1 Communication established. Onboard firmware version is 1.0 ^C [EMAIL PROTECTED] ~/Desktop/build/fsusb/fsusb-0.1.11-2]$ dmesg ... ohci_setup_standard_chain: addr=2 endpt=0 sumlen=16 speed=2 ohci_setup_standard_chain: nexttog=1; data before transfer: TD(0xc40fab00) at 0x0173db00: -TOG0 delay=7 ec=0 cc=15 cbp=0x014fd120 next=0x0173d200 be=0x014fd127 TD(0xc40fa200) at 0x0173d200: -R-IN-TOG1 delay=7 ec=0 cc=15 cbp=0x014fd128 next=0x0173d280 be=0x014fd12f TD(0xc40fa280) at 0x0173d280: -OUT-TOG1 delay=1 ec=0 cc=15 cbp=0x next=0x be=0x _ohci_append_qh: 0xc40fab80 to 0xc4057580 ohci_check_transfer: xfer=0xc40bc050 checking transfer ohci_non_isoc_done: xfer=0xc40bc050 pipe=0xc40bc9b0 transfer done TD(0xc40fab00) at 0x0173db00: -TOG1 delay=7 ec=0 cc=0 cbp=0x next=0x be=0x014fd127 ohci_device_done: xfer=0xc40bc050, pipe=0xc40bc9b0, error=0 _ohci_remove_qh: 0xc40fab80 from 0xc40fab80 ohci_setup_standard_chain: addr=2 endpt=0 sumlen=49 speed=2 ohci_setup_standard_chain: nexttog=1; data before transfer: TD(0xc40fa700) at 0x0173d700: -TOG0 delay=7 ec=0 cc=15 cbp=0x014fd120 next=0x0173d680 be=0x014fd127 TD(0xc40fa680) at 0x0173d680: -R-IN-TOG1 delay=7 ec=0 cc=15 cbp=0x014fd128 next=0x0173d600 be=0x014fd150 TD(0xc40fa600) at 0x0173d600: -OUT-TOG1 delay=1 ec=0 cc=15 cbp=0x next=0x be=0x _ohci_append_qh: 0xc40fa780 to 0xc4057580 ohci_check_transfer: xfer=0xc40bc050 checking transfer ohci_non_isoc_done: xfer=0xc40bc050 pipe=0xc40bc9b0 transfer done TD(0xc40fa700) at 0x0173d700: -TOG1 delay=7 ec=0 cc=0 cbp=0x next=0x be=0x014fd127 ohci_device_done: xfer=0xc40bc050, pipe=0xc40bc9b0, error=0 _ohci_remove_qh: 0xc40fa780 from 0xc40fa780 ohci_setup_standard_chain: addr=2 endpt=0 sumlen=16 speed=2 ohci_setup_standard_chain: nexttog=1; data before transfer: TD(0xc40fab00) at 0x0173db00: -TOG0 delay=7 ec=0 cc=15 cbp=0x014fd120 next=0x0173d200 be=0x014fd127 TD(0xc40fa200) at 0x0173d200: -R-IN-TOG1 delay=7 ec=0 cc=15 cbp=0x014fd128 next=0x0173d280 be=0x014fd12f TD(0xc40fa280) at 0x0173d280: -OUT-TOG1 delay=1 ec=0 cc=15 cbp=0x next=0x be=0x _ohci_append_qh: 0xc40fab80 to 0xc4057580 ohci_check_transfer: xfer=0xc40bc050 checking transfer ohci_non_isoc_done: xfer=0xc40bc050 pipe=0xc40bc9b0 transfer done TD(0xc40fab00) at 0x0173db00: -TOG1 delay=7 ec=0 cc=0 cbp=0x next=0x be=0x014fd127 ohci_device_done: xfer=0xc40bc050, pipe=0xc40bc9b0, error=0 _ohci_remove_qh: 0xc40fab80 from 0xc40fab80 ohci_setup_standard_chain: addr=2 endpt=0 sumlen=40 speed=2 ohci_setup_standard_chain: nexttog=1; data before transfer: TD(0xc40fa700) at 0x0173d700: -TOG0 delay=7 ec=0 cc=15 cbp=0x014fd120 next=0x0173d680 be=0x014fd127 TD(0xc40fa680) at 0x0173d680: -R-IN-TOG1 delay=7 ec=0 cc=15 cbp=0x014fd128 next=0x0173d600 be=0x014fd147 TD(0xc40fa600) at 0x0173d600: -OUT-TOG1 delay=1 ec=0 cc=15 cbp=0x next=0x be=0x _ohci_append_qh: 0xc40fa780 to 0xc4057580 ohci_check_transfer: xfer=0xc40bc050 checking transfer ohci_non_isoc_done: xfer=0xc40bc050 pipe=0xc40bc9b0 transfer done TD(0xc40fa700) at 0x0173d700: -TOG1 delay=7 ec=0 cc=0 cbp=0x next=0x be=0x014fd127 ohci_device_done: xfer=0xc40bc050, pipe=0xc40bc9b0, error=0 _ohci_remove_qh: 0xc40fa780 from 0xc40fa780 ohci_setup_standard_chain: addr=2 endpt=0 sumlen=16 speed=2 ohci_setup_standard_chain: nexttog=1; data before transfer: TD(0xc4daec00) at 0x098cac00: -TOG0 delay=7 ec=0 cc=15 cbp=0x06d0c120 next=0x098cab80 be=0x06d0c127 TD(0xc4daeb80) at 0x098cab80: -R-IN-TOG1 delay=7 ec=0 cc=15 cbp=0x06d0c128 next=0x098cab00 be=0x06d0c12f TD(0xc4daeb00) at 0x098cab00: -OUT-TOG1 delay=1 ec=0 cc=15 cbp=0x
Re: PICkit 2 again with HPS stack
On Fri, Apr 25, 2008 at 7:34 AM, Xiaofan Chen [EMAIL PROTECTED] wrote: On Thu, Apr 24, 2008 at 11:57 PM, Hans Petter Selasky [EMAIL PROTECTED] wrote: The problem should at least be fixed in revision 711. The problem has existed for a while after I made some changes to the usbd_do_request_flags routine. The problem is that the required mutex is not locked when doing the set config call. Thanks I will try this out and report back. With revision 711, PICkit 2 again works happily under FreeBSD. [EMAIL PROTECTED] ~/Desktop/build/pk2cmd/pk2cmdLinux-0.8]$ ./pk2cmd -?V Executable Version:1.01.00 (Linux/Mac port 0.8) Device File Version: 1.42.00 OS Firmware Version: 2.30.01 Operation Succeeded [EMAIL PROTECTED] ~/Desktop/build/pk2cmd/pk2cmdLinux-0.8]$ ./pk2cmd -PPIC16F690 -Y -F16f690.hex PICkit 2 Verify Report 25-4-2008, 21:42:18 Device Type: PIC16F690 Verify Succeeded. Operation Succeeded Thanks for the great support! Now I will need to try out some other USB device under 7.0-Release with the HPS stack. Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
USB Mass Storage Device with HPS Stack
I've got a free USB flash disk from National Semiconductor. It may be the so-called U3 device since it comes up as a CDROM and a removable USB drive. The removable USB drive part works fine. But I am not able to mount the CD part which contains some datasheets from National Semiconductor. Any tips on this? umass0: USB Mass Storage, class 0/0, rev 2.00/2.00, addr 2 on usb2 umass0: SCSI over Bulk-Only; quirks = 0x umass0:0:0:-1: Attached to scbus0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: NATIONAL FLASH DISK 2.00 Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 477MB (976896 512 byte sectors: 64H 32S/T 477C) cd0 at umass-sim0 bus 0 target 0 lun 1 cd0: NATIONAL FLASH DISK 2.00 Removable CD-ROM SCSI-2 device cd0: 40.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present GEOM_LABEL: Label for provider da0s1 is msdosfs/NATIONAL. [EMAIL PROTECTED] /media]$ sudo mount_msdosfs /dev/da0s1 /media/usbdisk1 [EMAIL PROTECTED] /media]$ ls -la /media/usbdisk1 total 18 drwxr-xr-x 1 root wheel 16384 Dec 31 1979 . drwxr-xr-x 11 root wheel512 Apr 25 22:16 .. [EMAIL PROTECTED] /media]$ sudo mount_cd9660 /dev/cd0 /media/usbcd mount_cd9660: /dev/cd0: Invalid argument Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PICDEM FS USB Bootloader under FreeBSD
On Sat, Apr 26, 2008 at 5:54 AM, Hans Petter Selasky [EMAIL PROTECTED] wrote: On Friday 25 April 2008, Xiaofan Chen wrote: This does not work either with 7.0-Release and the HPS USB stack. I will update to the latest SVN version of the HPS stack and see if the situation will improve. The bootlaoder does work under Linux (as well as Windows) fine with libusb (libusb-win32). I think it is a fault of your USB device. But at the same time I think that we can do a better job working around faulty USB devices. The most likely cause of the problem is that your USB device does not requeue data on what in your case is endpoint 1 when it receives the clear-stall for endpoint 1. That is what I suspect. Where was the firmware for your device again? This is from the popular PICDEM FS USB demo board firmware from Microchip. It is very popular among hobbyists as well as many customers because of low cost, free C18 C compiler (no code size limit, but only optimization limit), free samples, DIP package USB chips, lots of examples and good support from Microchip. Microchip USB info: http://www.microchip.com/usb Others and I have identified various firmware bugs in the free USB stack Microchip offers. They have also corrected quite some of them. Reference: http://forum.microchip.com/tm.aspx?m=275422 I will see if the latest V2.1 stack has fixed this issue. I think it has not. I think you have pinpointed the potential bugs in the stall handling code. The question is then why you want to clear stall in the first transfer. sidetrack When an USB device is broken or it has no driver: First you e-mail the manufacturer and complain. Then you e-mail usb.org and complain. Then you call your government and complain. Anything I forgot ? If one has the access to the firmware, try to fix it. ;-) In this case, since I have access to the firmware codes and I am quite familiar with it, I will try to fix the firmware. I can totally understand your point as a USB developer for alternative OS like Linux and FreeBSD. Still you can see a lot of Linux USB efforts are to support quirky USB device. It is not that fun, but it is quite important if you care the user experience. A good example from Linux USB; http://kerneltrap.org/mailarchive/linux-kernel/2007/9/13/259148 It turns out that USB devices suck when it comes to power management issues :(. So maybe it is also true that USB devices suck when it comes to handling clear stall feature request. Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PICDEM FS USB Bootloader under FreeBSD
On Sat, Apr 26, 2008 at 12:46 PM, Xiaofan Chen [EMAIL PROTECTED] wrote: On Sat, Apr 26, 2008 at 11:50 AM, Xiaofan Chen [EMAIL PROTECTED] wrote: 2) Patch /sys/dev/usb/ugen.c Change all lines looking like the following, that are not in a function named xxx_callback: sce-read_stall = 1; sce-write_stall = 1; Into: sce-read_stall = 0; sce-write_stall = 0; Recompile ugen an try again. Maybe this is a stupid question but how do I compile ugen only and not the whole kernel? Normally I will use the following command with this modifications. [EMAIL PROTECTED] /usr/src]# make buildkernel installkernel KERNCONF=custom -DNOCLEAN -DNO_CLEAN -DNO_KERNELDEPEND But with major updates I will just use make buildkernel installkernel KERNCONF=custom I will try this out and report back. This does not help. On the other hand, reading the hex file works. It worked with the same change for PICkit 2 actually. [EMAIL PROTECTED] /usr/home/mcuee/Desktop/build/fsusb/fsusb-0.1.11-2]$ ./fsusb --read demo1.hex Locating USB Microchip(tm) PICDEM-FS USB(tm) (vendor 0x04d8/product 0x000b) Found USB PICDEM-FS USB as device '/dev/ugen1' on USB bus /dev/usb1 Communication established. Onboard firmware version is 1.0 Finished reading [EMAIL PROTECTED] /usr/home/mcuee/Desktop/build/fsusb/fsusb-0.1.11-2]$ sudo sysctl hw.usb.debug=1 [EMAIL PROTECTED] /usr/home/mcuee/Desktop/build/fsusb/fsusb-0.1.11-2]$ ./fsusb --read demo2.hex Locating USB Microchip(tm) PICDEM-FS USB(tm) (vendor 0x04d8/product 0x000b) Found USB PICDEM-FS USB as device '/dev/ugen1' on USB bus /dev/usb1 Communication established. Onboard firmware version is 1.0 Finished reading dmesg output is truncated. But here is a short version from /var/log/messages: Apr 26 13:00:58 freebsd7 sudo:mcuee : TTY=ttyp1 ; PWD=/usr/home/mcuee/Desktop/build/fsusb/fsusb-0.1.11-2 ; USER=root ; COMMAND=/sbin/sysctl hw.usb.debug=1 Apr 26 13:01:11 freebsd7 kernel: usbd_start_hardware: xfer=0xc4272070, pipe=0xc40bc9b0, nframes=2, dir=read Apr 26 13:01:11 freebsd7 kernel: usbd_dump_pipe: pipe=0xc40bc9b0 edesc=0xc40bcc7d isoc_next=0 toggle_next=0 bEndpointAddress=0x00 Apr 26 13:01:11 freebsd7 kernel: usbd_dump_queue: pipe=0xc40bc9b0 Apr 26 13:01:11 freebsd7 kernel: usbd_start_hardware: xfer=0xc4272070, pipe=0xc40bc9b0, nframes=2, dir=read Apr 26 13:01:11 freebsd7 kernel: usbd_dump_pipe: pipe=0xc40bc9b0 edesc=0xc40bcc7d isoc_next=0 toggle_next=0 bEndpointAddress=0x00 Apr 26 13:01:11 freebsd7 kernel: usbd_dump_queue: pipe=0xc40bc9b0 Apr 26 13:01:11 freebsd7 kernel: usbd_start_hardware: xfer=0xc4272070, pipe=0xc40bc9b0, nframes=2, dir=read Apr 26 13:01:11 freebsd7 kernel: usbd_dump_pipe: pipe=0xc40bc9b0 edesc=0xc40bcc7d isoc_next=0 toggle_next=0 bEndpointAddress=0x00 Apr 26 13:01:11 freebsd7 kernel: usbd_dump_queue: pipe=0xc40bc9b0 Apr 26 13:01:11 freebsd7 kernel: usbd_start_hardware: xfer=0xc4272070, pipe=0xc40bc9b0, nframes=2, dir=read Apr 26 13:01:11 freebsd7 kernel: usbd_dump_pipe: pipe=0xc40bc9b0 edesc=0xc40bcc7d isoc_next=0 toggle_next=0 bEndpointAddress=0x00 Apr 26 13:01:11 freebsd7 kernel: usbd_dump_queue: pipe=0xc40bc9b0 Apr 26 13:01:11 freebsd7 kernel: usbd_start_hardware: xfer=0xc46d9070, pipe=0xc4e6e9b0, nframes=2, dir=read Apr 26 13:01:11 freebsd7 kernel: usbd_dump_pipe: pipe=0xc4e6e9b0 edesc=0xc4e6ec7d isoc_next=0 toggle_next=0 bEndpointAddress=0x00 Apr 26 13:01:11 freebsd7 kernel: usbd_dump_queue: pipe=0xc4e6e9b0 Apr 26 13:01:11 freebsd7 kernel: usbd_start_hardware: xfer=0xc46d9070, pipe=0xc4e6e9b0, nframes=2, dir=read Apr 26 13:01:11 freebsd7 kernel: usbd_dump_pipe: pipe=0xc4e6e9b0 edesc=0xc4e6ec7d isoc_next=0 toggle_next=0 bEndpointAddress=0x00 Apr 26 13:01:11 freebsd7 kernel: usbd_dump_queue: pipe=0xc4e6e9b0 Apr 26 13:01:11 freebsd7 kernel: usbd_start_hardware: xfer=0xc4f05070, pipe=0xc4e6e9c4, nframes=1, dir=write Apr 26 13:01:11 freebsd7 kernel: usbd_dump_pipe: pipe=0xc4e6e9c4 edesc=0xc40cb232 isoc_next=0 toggle_next=0 bEndpointAddress=0x01 Apr 26 13:01:11 freebsd7 kernel: usbd_dump_queue: pipe=0xc4e6e9c4 Apr 26 13:01:11 freebsd7 kernel: usbd_start_hardware: xfer=0xc4f16070, pipe=0xc4e6e9d8, nframes=1, dir=read Apr 26 13:01:11 freebsd7 kernel: usbd_dump_pipe: pipe=0xc4e6e9d8 edesc=0xc40cb239 isoc_next=0 toggle_next=0 bEndpointAddress=0x81 Apr 26 13:01:11 freebsd7 kernel: usbd_dump_queue: pipe=0xc4e6e9d8 Apr 26 13:01:11 freebsd7 kernel: usbd_start_hardware: xfer=0xc4f05070, pipe=0xc4e6e9c4, nframes=1, dir=write Apr 26 13:01:11 freebsd7 kernel: usbd_dump_pipe: pipe=0xc4e6e9c4 edesc=0xc40cb232 isoc_next=0 toggle_next=1 bEndpointAddress=0x01 Apr 26 13:01:11 freebsd7 kernel: usbd_dump_queue: pipe=0xc4e6e9c4 Apr 26 13:01:11 freebsd7 kernel: usbd_start_hardware: xfer=0xc4f16070, pipe=0xc4e6e9d8, nframes=1, dir=read Apr 26 13:01:11 freebsd7 kernel: usbd_dump_pipe: pipe=0xc4e6e9d8 edesc=0xc40cb239 isoc_next=0 toggle_next=1 bEndpointAddress=0x81 Apr 26 13:01:11
Re: USB Mass Storage Device with HPS Stack
On Sat, Apr 26, 2008 at 5:49 AM, Hans Petter Selasky [EMAIL PROTECTED] wrote: On Friday 25 April 2008, Xiaofan Chen wrote: I've got a free USB flash disk from National Semiconductor. It may be the so-called U3 device since it comes up as a CDROM and a removable USB drive. The removable USB drive part works fine. But I am not able to mount the CD part which contains some datasheets from National Semiconductor. Any tips on this? Since I have some other mass storage device and it seems the latest HPS stack works fine with the normal ones (Kingston Data Traveler 256MB, IMation 1GB Flash Drive and Nokia 6280 with 1GB MicroSD card in storage mode) but not the strange ones like a 23040 Bytes PIC18F2550 USB mass storage device. 1) 23040B PIC18F2550 device (using internal Flash as the storage) http://sourceforge.net/projects/pic18fusb http://forum.microchip.com/tm.aspx?m=164912 dmesg: umass1: I-Tuner Networks product 0x0004, class 0/0, rev 2.00/0.00, addr 3 on usb0 umass1: SCSI over Bulk-Only; quirks = 0x umass1: Get Max Lun not supported (USBD_ERR_SHORT_XFER) umass1:1:1:-1: Attached to scbus1 da1 at umass-sim1 bus 1 target 0 lun 0 da1: Didlet MSD\\000\\030\\030\\030\\030\\030\\030\\030\\030\\030\\030 1\\000 == Removable Direct Access SCSI-4 device da1: 1.000MB/s transfers da1: 0MB (49 512 byte sectors: 64H 32S/T 0C) (da1:umass-sim1:1:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 [EMAIL PROTECTED] ~]$ sudo mount_msdosfs /dev/da1 /media/usbdisk2 mount_msdosfs: /dev/da1: : Input/output error And Nokia 6280 in default mode will crash FreeBSD just as it crashes Linux last time. The computer immediately freezes and I have to hit the reset button. It did not work last time under my XP SP2 but later Nokia host software seems to solve the issue. It did not work under Linux either with the USB storage mode. http://www.mail-archive.com/[EMAIL PROTECTED]/msg17810.html Later it seems to me that 2GB MicroSD card is the problem and I have replaced it with a 1GB card and it works better. With default mode, last time Linux will crash as well but it seems the problem has been solved. http://bugzilla.kernel.org/show_bug.cgi?id=7201 Strangely I could not find any crash log this time. It happened to me yesterday with the Kingston Data Traveler 256MB but today it works fine with revision 711 HPS stack. Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB Mass Storage Device with HPS Stack
On Sat, Apr 26, 2008 at 3:19 PM, Xiaofan Chen [EMAIL PROTECTED] wrote: Since I have some other mass storage device and it seems the latest HPS stack works fine with the normal ones (Kingston Data Traveler 256MB, IMation 1GB Flash Drive and Nokia 6280 with 1GB MicroSD card in storage mode) but not the strange ones like a 23040 Bytes PIC18F2550 USB mass storage device. 1) 23040B PIC18F2550 device (using internal Flash as the storage) http://sourceforge.net/projects/pic18fusb http://forum.microchip.com/tm.aspx?m=164912 dmesg: umass1: I-Tuner Networks product 0x0004, class 0/0, rev 2.00/0.00, addr 3 on usb0 umass1: SCSI over Bulk-Only; quirks = 0x umass1: Get Max Lun not supported (USBD_ERR_SHORT_XFER) umass1:1:1:-1: Attached to scbus1 da1 at umass-sim1 bus 1 target 0 lun 0 da1: Didlet MSD\\000\\030\\030\\030\\030\\030\\030\\030\\030\\030\\030 1\\000 == Removable Direct Access SCSI-4 device da1: 1.000MB/s transfers da1: 0MB (49 512 byte sectors: 64H 32S/T 0C) (da1:umass-sim1:1:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 [EMAIL PROTECTED] ~]$ sudo mount_msdosfs /dev/da1 /media/usbdisk2 mount_msdosfs: /dev/da1: : Input/output error Forget about this one. It does not work under the latest Ubuntu 8.04 either. It also hangs NetBSD 4.0. So I think the firmware is not really working. Yeah, it works under Windows. ;-) Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PICDEM FS USB Bootloader under FreeBSD
On Mon, Apr 28, 2008 at 4:37 PM, Hans Petter Selasky [EMAIL PROTECTED] wrote: Maybe this is a stupid question but how do I compile ugen only and not the whole kernel? You can get ugen alone by using loading the ugen module: kldload ugen kldunload ugen I know this one. Actually my question is how to build ugen module only without rebuild the full kernel. Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB CDC-ACM device under FreeBSD and HPS stack
On Mon, Apr 28, 2008 at 4:52 PM, Hans Petter Selasky [EMAIL PROTECTED] wrote: I found it: Edit /sys/dev/usb/ucycom.c and change: --- src/sys/dev/usb/ucycom.c(revision 711) +++ src/sys/dev/usb/ucycom.c(working copy) @@ -167,8 +167,8 @@ }; DRIVER_MODULE(ucycom, uhub, ucycom_driver, ucycom_devclass, usbd_driver_load, 0); -MODULE_VERSION(ucycom, 1); MODULE_DEPEND(ucycom, usb, 1, 1, 1); +MODULE_DEPEND(ucycom, ucom, UCOM_MINVER, UCOM_PREFVER, UCOM_MAXVER); Then recompile the ucycom module. Thanks, this works for ucycom. I also just learned how to build the module only thanks to the help from a list member: cd /sys/modules/ucycom (or ugen); make; make install. But as I said, ucycom is actually not what I wanted. I'd like to use Silabs CP210x (which is only supported by 8-Current) and generic cdc-acm. For example, even if I load ucom and umodem, the generic CDC device (LPC-P2148 example from http://jcwren.com/arm/) still show up as ugen device. [EMAIL PROTECTED] ~]$ sudo kldload ucom [EMAIL PROTECTED] ~]$ sudo kldload umodem [EMAIL PROTECTED] ~]$ dmesg ugen2: LPCUSB USBSerial, class 2/0, rev 2.00/1.00, addr 3 on usb0 The same steps seem to work under NetBSD 4.0. The Silicon Labs CP2101 device I have seems to work under NetBSD 4.0 as well. But PICkit 2 and PICDEM FS USB demo work under FreeBSD 7.0-Release and HPS USB stack Revision 711 but not NetBSD 4.0 (libusb related problem). So I might want to try out the HPS stack with NetBSD 4.0 but I am too new to NetBSD. Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB Mass Storage Device with HPS Stack
On Mon, Apr 28, 2008 at 4:35 PM, Hans Petter Selasky [EMAIL PROTECTED] wrote: Then try to mount again. You can also try loading ata-usb instead of umass. ata-usb will query the disk size regularly. Hmm, I do not see any thing similar to ata-usb module in the kernel and I can not load ata-usb. Do you have: /sys/modules/ata/atausb ? Hmm yes I have the module. [EMAIL PROTECTED] /sys/modules/ata/atausb]$ sudo make [EMAIL PROTECTED] /sys/modules/ata/atausb]$ sudo make install install -o root -g wheel -m 555 atausb.ko /boot/kernel kldxref /boot/kernel [EMAIL PROTECTED] /sys/modules/ata/atausb]$ sudo kldload atausb After plugging in the USB disk, I got the following: [EMAIL PROTECTED] ~]$ dmesg umass0: USB Mass Storage, class 0/0, rev 2.00/2.00, addr 2 on usb2 umass0: SCSI over Bulk-Only; quirks = 0x umass0:0:0:-1: Attached to scbus0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: NATIONAL FLASH DISK 2.00 Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 477MB (976896 512 byte sectors: 64H 32S/T 477C) cd0 at umass-sim0 bus 0 target 0 lun 1 cd0: NATIONAL FLASH DISK 2.00 Removable CD-ROM SCSI-2 device cd0: 40.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present GEOM_LABEL: Label for provider da0s1 is msdosfs/NATIONAL. [EMAIL PROTECTED] ~]$ sudo cat /dev/null /dev/cd0 bash: /dev/cd0: Permission denied [EMAIL PROTECTED] ~]$ su - freebsd7# bash [EMAIL PROTECTED] ~]# cat /dev/null /dev/cd0 [EMAIL PROTECTED] ~]# mount_cd9660 /dev/cd0 /media/usbcd mount_cd9660: /dev/cd0: Invalid argument [EMAIL PROTECTED] ~]# kldunload umass kldunload: can't find file umass So it seems that umass is still claiming the device. How do I unload umass without rebuilding the kernel? Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB Mass Storage Device with HPS Stack
On Tue, Apr 29, 2008 at 3:01 PM, Hans Petter Selasky [EMAIL PROTECTED] wrote: If umass is in the kernel you need to rebuild. Else you kldunload umass. I managed to crash the system again when playing with kldload umass and kldunload umass. But maybe the backtrace does not make much sense, to me anyway. [EMAIL PROTECTED] /var/crash]# cat info.4 Dump header from device /dev/ad4s4b Architecture: i386 Architecture Version: 2 Dump Length: 152387584B (145 MB) Blocksize: 512 Dumptime: Tue Apr 29 20:34:58 2008 Hostname: freebsd7.MSHOME.net Magic: FreeBSD Kernel Dump Version String: FreeBSD 7.0-RELEASE #2: Tue Apr 29 19:47:40 SGT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/custom Panic String: page fault Dump Parity: 3612086858 Bounds: 4 Dump Status: good [EMAIL PROTECTED] /usr/obj/usr/src/sys/custom]# kgdb kernel.debug /var/crash/vmcore.4 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd. Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x8 fault code = supervisor write, page not present instruction pointer = 0x20:0xc4fcb2f5 stack pointer = 0x28:0xe6fdfbf4 frame pointer = 0x28:0xe6fdfc10 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1376 (USB interrupt threa) trap number = 12 panic: page fault cpuid = 0 Uptime: 44m1s Physical memory: 1011 MB Dumping 145 MB: 130 114 98 82 66 50 34 18 2 #0 doadump () at pcpu.h:195 195 __asm __volatile(movl %%fs:0,%0 : =r (td)); (kgdb) list *0xc4fcb2f5 No source file for address 0xc4fcb2f5. (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc0739ac7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0739d89 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0a3fb4c in trap_fatal (frame=0xe6fdfbb4, eva=8) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0a3fdb0 in trap_pfault (frame=0xe6fdfbb4, usermode=0, eva=8) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0a40732 in trap (frame=0xe6fdfbb4) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0a270bb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc4fcb2f5 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) quit Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB Mass Storage Device with HPS Stack
On Tue, Apr 29, 2008 at 7:59 PM, Xiaofan Chen [EMAIL PROTECTED] wrote: One more MP3 player which works under Windows XP and Linux but not FreeBSD 7.0-Release with HPS stack. [EMAIL PROTECTED] ~]# dmesg ... umass1: vendor 0x10d6 USB 2.0(HS) Flash Disk, class 0/0, rev 2.00/1.00, addr 3 on usb2 umass1: 8070i (ATAPI) over Bulk-Only; quirks = 0x umass1:1:1:-1: Attached to scbus1 da1 at umass-sim1 bus 1 target 0 lun 0 da1: USB 2.0 (HS) Flash Disk 1.00 Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: 1946MB (3987121 512 byte sectors: 255H 63S/T 248C) (da1:umass-sim1:1:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 [EMAIL PROTECTED] ~]# usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, OHCI root HUB(0x), nVidia(0x), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, OHCI root HUB(0x), nVidia(0x), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered Controller /dev/usb2: addr 1: high speed, self powered, config 1, EHCI root HUB(0x), nVidia(0x), rev 1.00 port 1 addr 3: high speed, power 500 mA, config 1, USB 2.0(HS) Flash Disk(0x1101), vendor 0x10d6(0x10d6), rev 1.00 port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered port 7 powered port 8 addr 2: high speed, power 100 mA, config 1, Mass Storage(0x2002), USB(0x178c), rev 2.00 port 1 addr 1 is the MP3 player, a cheap iPOD Nano clone (look-alike). port 8 addr 2 is the National Semiconductor USB Mass Storage device which has a read-only CDROM partition. Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB Mass Storage Device with HPS Stack
On Wed, Apr 30, 2008 at 3:59 AM, Hans Petter Selasky [EMAIL PROTECTED] wrote: Maybe you can get my USB stack working on your PIC board? It now supports the Device Side aswell as the host side! See usbd_handle_request in: http://www.selasky.org/hans_petter/isdn4bsd/sources/src/sys/dev/usb/usb_transfer.c Mass storage driver: http://www.selasky.org/hans_petter/isdn4bsd/sources/src/sys/dev/usb/ustorage_fs.c The PIC18F4550 is a lowly 8-bit MCU (12MIPS, 32KB Flash, 2KB SRAM including USB RAM). So maybe it is too low to run your USB stack's device side. What is the minimum requirement to run your USB stack's device side? XIaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB CDC-ACM device under FreeBSD and HPS stack
On Wed, Apr 30, 2008 at 3:45 AM, Hans Petter Selasky [EMAIL PROTECTED] wrote: As for the generic CDC-ACM device (the Olimex LPC-P2148), I do not know how to load the necessary kernel module to get it work as a usb-serial device. Under Linux, there is a generic cdc-acm device support. kldload umodem I tried that and nothing happens. [EMAIL PROTECTED] ~]# kldload umodem [EMAIL PROTECTED] ~]# kldstat Id Refs AddressSize Name 1 18 0xc040 90568c kernel 21 0xc0d06000 6f88 snd_ich.ko 32 0xc0d0d000 4a5acsound.ko 41 0xc0d58000 6a32cacpi.ko 51 0xc4492000 22000linux.ko 61 0xc46f7000 21000radeon.ko 71 0xc4718000 f000 drm.ko 101 0xc4d9a000 4000 umodem.ko 111 0xc4d9f000 4000 ucom.ko [EMAIL PROTECTED] ~]# dmesg (nothing happens). [EMAIL PROTECTED] ~]# kldload ugen [EMAIL PROTECTED] ~]# dmesg ugen0: vendor 0x10d6 USB 2.0(HS) Flash Disk, class 0/0, rev 2.00/1.00, addr 2 on usb2 ugen1: LPCUSB USBSerial, class 2/0, rev 2.00/1.00, addr 3 on usb0 [EMAIL PROTECTED] ~]# lsusb -vvv Bus /dev/usb0 Device /dev/ugen1: ID :0005 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x idProduct 0x0005 bcdDevice1.00 iManufacturer 1 LPCUSB iProduct2 USBSerial iSerial 3 DEADC0DE bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 67 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 CDC Header: bcdCDC 1.10 CDC Call Management: bmCapabilities 0x01 call management bDataInterface 1 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Union: bMasterInterface0 bSlaveInterface 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 can't get device qualifier: Input/output error can't get debug descriptor: Input/output error Device Status: 0x (Bus Powered) Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB CDC-ACM device under FreeBSD and HPS stack
On Thu, May 1, 2008 at 12:33 AM, Hans Petter Selasky [EMAIL PROTECTED] wrote: Hi, Edit /sys/dev/usb/ugensa.c and add the VID+PID to the ugensa_devs structure. Recompile the ugensa module (/sys/module/ugensa) and load it. Thanks. Again there is an error. ugensa0: LPCUSB USBSerial, class 2/0, rev 2.00/1.00, addr 3 on usb0 ugensa0: No interfaces! device_attach: ugensa0 attach returned 6 ugensa0: LPCUSB USBSerial, class 2/0, rev 2.00/1.00, addr 3 on usb0 ugensa0: No interfaces! device_attach: ugensa0 attach returned 6 Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB Mass Storage Device with HPS Stack
On Thu, May 1, 2008 at 12:30 AM, Hans Petter Selasky [EMAIL PROTECTED] wrote: Try and find out. I know that many structures can be optimized for minimal memory usage. Currently I reserve space for 128 USB devices and 32 endpoints and interfaces. If you reduce those numbers then you will save a lot of memory. I am a bit confused now. So your USB stack now can be used for Device side which does not require FreeBSD OS support. Is this true? I thought your device side stack is like Linux Gadget which runs some kind of Linux and then act as an usb function device (slave) to a USB host. I am getting two new USB development boards from Microchip, PIC24 16bit and PIC32 32 bit (MIPS based) USB, both with OTG, both will not be able to run FreeBSD or Linux or even uClinux due to memory constraint. I have the Olimex LPC-P2148 (ARM7 based) as well which could not run FreeBSD/Linux either. Do you think any of them can run your stack's device side? What is your test platform for your stack's device side? Does it run FreeBSD? Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB CDC-ACM device under FreeBSD and HPS stack
On Sat, Apr 26, 2008 at 4:16 PM, Xiaofan Chen [EMAIL PROTECTED] wrote: CP210x seems to be only supported by 8-Current. But maybe this can be ported to the HPS stack. Actually it is supported by the HPS stack with uslcom. I just found it today. [EMAIL PROTECTED] ~]# dmesg uslcom0: Silicon Labs U-Light, class 0/0, rev 1.10/1.00, addr 3 on usb1 [EMAIL PROTECTED] ~]# ls -la /dev/ttyU* crw--- 1 root wheel0, 127 May 1 11:44 /dev/ttyU0 crw--- 1 root wheel0, 128 May 1 11:44 /dev/ttyU0.init crw--- 1 root wheel0, 129 May 1 11:44 /dev/ttyU0.lock Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: final usb question
On 6/9/08, Hans Petter Selasky [EMAIL PROTECTED] wrote: There will soon be a utility that can do this, so that you can run: usbconfig -u ugen0 -c 1 for example to select configuration index 1 for your device. Please note that there will be one ugen device for every USB device present in the future! And I'm in the future :-) That would be great. In that case, you might want to look at the new libusb-1.0 and ported it to FreeBSD. The new libusb-1.0 supports isochronous transfer and asynchronous I/O. Right now it only works under Linux. It is under beta now but the API should be mostly stable alreay. http://www.reactivated.net/weblog/archives/2008/05/libusb-10-enters-beta/ http://libusb.sourceforge.net/api-1.0/ Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: may I commit this small umodem patch ?
On Sat, Jul 5, 2008 at 5:39 AM, Luigi Rizzo [EMAIL PROTECTED] wrote: What about flow control? Is flow control required for these devices? the ones I am talking about don't implement any form of flow control. I suppose they would otherwise match the previous check. They are many of this device and they do not have flow control. I got two of them right here. One is for NXP LPC-P2148 and the other is using Microchip PIC18F USB PICs. Last time it was discussed here. http://lists.freebsd.org/pipermail/freebsd-usb/2008-April/004907.html I've tried the lpcusb based generic CDC-ACM device under Linux/Windows/NetBSD successfully but not FreeBSD. Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: apcupsd port regression from 7x. to 8.x
On Fri, May 7, 2010 at 9:27 PM, Bernd Walter ti...@cicely7.cicely.de wrote: I am guessing the program would need to be re-written to use v1.0 ? Thanks for the feedback and help as always! I recently converted own code to 1.0 API, just to get negative feedback from Debian users, since they only offer libusb 0.1 packages for anything but bleeding edge development versions. I assume because of this the old API will still be around for some time. Hmm, that is a bit strange. But you are right Debian/Ubuntu still have libusb-0.1 and libusb-1.0. Other Linux distros move to libusb-1.0 and libusb-0.1-compat since libusb-0.1 is no longer maintained by the developers and the bug reports are treated as won't fix. http://www.libusb.org/report/1 -- Xiaofan (part of the libusb-win32 admin team) ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: apcupsd port regression from 7x. to 8.x
On Fri, May 7, 2010 at 9:52 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Fri, May 7, 2010 at 4:40 AM, Hans Petter Selasky hsela...@c2i.net wrote: The FreeBSD LibUSB v0.1 reports the wrong number of busses and devices. I can fix this. I've made a small patch, but it won't fix your issue :-( http://p4web.freebsd.org/@@177865?ac=10 I am not so sure if this is related to the bugs of pyusb here. http://sourceforge.net/mailarchive/forum.php?thread_name=w2ua276da401004190609t9f26a872qa0c0217e91c39180%40mail.gmail.comforum_name=pyusb-users No the patch does not help. I think it is not a problem of libusb under FreeBSD, but rather the bug with pyusb. If possible, please give pyusb a try. Thanks. I have not updated to 8-stable to be able to catch up with the libusb changes in FreeBSD. The later changes of libusb under FreeBSD does not seem to be compatible with 8-Release. -- Xiaofan http://mcuee.blogspot.com ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Ioctl 0x7601 on /dev/video0 - `linux' in kernel
On Fri, Jun 11, 2010 at 2:43 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: I have linuxulator in the kernel (option COMPAT_LINUX), however, so, I thought, it is supposed to just work... But it does not. Is anyone successful getting skype with video on FreeBSD? If that would work, it will be a perfect world. ;-) I would not think that the Linux emulation is good for USB hardware. -- Xiaofan http://mcuee.blogspot.com ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Recommendations for programming HID in FreeBSD 9
On Fri, Jun 1, 2012 at 9:45 PM, Engineering e...@athyriogames.com wrote: I had been researching libusb for a while, but their webpage says it is not recommended for HID devices and to use HIDAPI, which does not seem to be on BSD. HIDAPI does work under FreeBSD using libusb (1.0 API) as the backend. https://github.com/signal11/hidapi/commit/74440e2dbbba80b4abcc4304ddae9e484231b72d https://github.com/signal11/hidapi/tree/master/libusb -- Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/173666: [USB, LIBUSB] usb_reset() behavior different between GNU/Linux and FreeBSD
On Sat, Nov 17, 2012 at 8:19 PM, Hans Petter Selasky hsela...@c2i.net wrote:
On Friday 16 November 2012 23:47:29 Wojciech A. Koszek wrote:
Number: 173666
Category: usb
Synopsis: [USB, LIBUSB] usb_reset() behavior different between
GNU/Linux and FreeBSD Confidential: no
Severity: non-critical
Priority: low
Responsible:freebsd-usb
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Fri Nov 16 22:50:00 UTC 2012
Closed-Date:
Last-Modified:
Originator: Wojciech A. Koszek
Release:9.0-RELEASE
Organization:
FreeBSD
Environment:
FreeBSD seu 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC
2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
Description:
I have a driver written for libusb, which works fine under GNU/Linux and
libusb. Device:
gen0.2: JSB283 Relay Module J-Works,Inc at usbus0, cfg=0 md=HOST spd=LOW
(1.5Mbps) pwr=ON
(I used USB sniffer to uncover traffic based on what Windows was doing)
Under Linux usb_reset()+usb_set_configuration() calls works fine. Under
FreeBSD I have to disable calling usb_reset(), otherwise
usb_set_configuration() fails with I/O error.
According to:
http://libusb.sourceforge.net/doc/function.usbreset.html
What you describe is the expected behaviour.
The above document is really meant for libusb-0.1 but the
behavior of libusb-compat's usb_reset() is different since
it is based on libusb-1.0's libusb_reset_device.
http://git.libusb.org/?p=libusb-compat-0.1.git;a=blob;f=libusb/core.c
743 API_EXPORTED int usb_reset(usb_dev_handle *dev)
744 {
745 usbi_dbg();
746 return compat_err(libusb_reset_device(dev-handle));
747 }
For libusb-1.0 under Linux and Mac OS X, usually
libusb_reset_device will not cause enumeration.
Reference:
http://libusb.6.n5.nabble.com/PATCH-make-libusb-reset-force-re-enumeration-on-Mac-td4499375.html
http://libusb.sourceforge.net/api-1.0/group__dev.html#ga7321bd8dc28e9a20b411bf18e6d0e9aa
int libusb_reset_device ( libusb_device_handle * dev )
Perform a USB port reset to reinitialize a device.
The system will attempt to restore the previous configuration and
alternate settings after the reset has completed.
If the reset fails, the descriptors change, or the previous state
cannot be restored, the device will appear to be disconnected
and reconnected. This means that the device handle is no longer
valid (you should close it) and rediscover the device. A return code
of LIBUSB_ERROR_NOT_FOUND indicates when this is the case.
This is a blocking function which usually incurs a noticeable delay.
Parameters:
deva handle of the device to reset
Returns:
0 on success
LIBUSB_ERROR_NOT_FOUND if re-enumeration is required, or if the
device has been disconnected
another LIBUSB_ERROR code on other failure
--
Xiaofan
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/173666: [USB, LIBUSB] usb_reset() behavior different between GNU/Linux and FreeBSD
On Fri, Dec 21, 2012 at 3:38 PM, Hans Petter Selasky hsela...@c2i.net wrote:
If you look in the old libusb-0.1 code you'll see something different I think.
Could you check that?
Not much differences in reality. I believe it is a document bug for the
libusb-0.1.
Both old libusb-0.1 code and libusb-1.0 use the same IOCTL under Linux
and the behavior should be similar.
Please refer to the following code listing and take note even though
the name of the IOCTL is different but they are the same if you
look at the defines.
On the other hand, libusb-win32's usb_reset will cause re-enumeration.
From libusb-0.1.12 source (linux.c)
int usb_reset(usb_dev_handle *dev)
{
int ret;
ret = ioctl(dev-fd, IOCTL_USB_RESET, NULL);
if (ret)
USB_ERROR_STR(-errno, could not reset: %s, strerror(errno));
return 0;
}
From libusb.org libusb.git (libusb-1.0) souce:
static int op_reset_device(struct libusb_device_handle *handle)
{
int fd = _device_handle_priv(handle)-fd;
int i, r, ret = 0;
/* Doing a device reset will cause the usbfs driver to get unbound
from any interfaces it is bound to. By voluntarily unbinding
the usbfs driver ourself, we stop the kernel from rebinding
the interface after reset (which would end up with the interface
getting bound to the in kernel driver if any). */
for (i = 0; i USB_MAXINTERFACES; i++) {
if (handle-claimed_interfaces (1L i)) {
op_release_interface(handle, i);
}
}
usbi_mutex_lock(handle-lock);
r = ioctl(fd, IOCTL_USBFS_RESET, NULL);
if (r) {
if (errno == ENODEV) {
ret = LIBUSB_ERROR_NOT_FOUND;
goto out;
}
usbi_err(HANDLE_CTX(handle),
reset failed error %d errno %d, r, errno);
ret = LIBUSB_ERROR_OTHER;
goto out;
}
/* And re-claim any interfaces which were claimed before the reset */
for (i = 0; i USB_MAXINTERFACES; i++) {
if (handle-claimed_interfaces (1L i)) {
r = op_claim_interface(handle, i);
if (r) {
usbi_warn(HANDLE_CTX(handle),
failed to re-claim interface %d after
reset, i);
handle-claimed_interfaces = ~(1L i);
}
}
}
out:
usbi_mutex_unlock(handle-lock);
return ret;
}
--
Xiaofan
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/173666: [USB, LIBUSB] usb_reset() behavior different between GNU/Linux and FreeBSD
On Sun, Dec 23, 2012 at 5:40 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Saturday 22 December 2012 11:17:15 Xiaofan Chen wrote: On Fri, Dec 21, 2012 at 3:38 PM, Hans Petter Selasky hsela...@c2i.net wrote: If you look in the old libusb-0.1 code you'll see something different I think. Could you check that? Not much differences in reality. I believe it is a document bug for the libusb-0.1. Both old libusb-0.1 code and libusb-1.0 use the same IOCTL under Linux and the behavior should be similar. Please refer to the following code listing and take note even though the name of the IOCTL is different but they are the same if you look at the defines. Can you create a thread for this at the libusb lists? Okay. -- Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/173666: [USB, LIBUSB] usb_reset() behavior different between GNU/Linux and FreeBSD
On Mon, Dec 24, 2012 at 9:17 AM, Xiaofan Chen xiaof...@gmail.com wrote: On Sun, Dec 23, 2012 at 5:40 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Saturday 22 December 2012 11:17:15 Xiaofan Chen wrote: On Fri, Dec 21, 2012 at 3:38 PM, Hans Petter Selasky hsela...@c2i.net wrote: If you look in the old libusb-0.1 code you'll see something different I think. Could you check that? Not much differences in reality. I believe it is a document bug for the libusb-0.1. Both old libusb-0.1 code and libusb-1.0 use the same IOCTL under Linux and the behavior should be similar. Please refer to the following code listing and take note even though the name of the IOCTL is different but they are the same if you look at the defines. Can you create a thread for this at the libusb lists? Okay. There is no reply in that thread. But in another thread, Alan Stern confirms that Linux libusb reset will not cause re-enumeation. Ref: http://libusb.6.n5.nabble.com/USB-device-works-in-linux-but-not-in-OSX-tp5711092p5711132.html The detailed Linux behavior is as following as explained by Alan Stern. http://libusb.6.n5.nabble.com/USB-device-works-in-linux-but-not-in-OSX-tp5711092p5711148.html It is not that pretty in this case since different OS may behave differently. Summary here: http://libusb.6.n5.nabble.com/USB-device-works-in-linux-but-not-in-OSX-tp5711092p5711139.html -- Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: argyllcms and usb (0.1 and 1.0)
On Thu, Feb 21, 2013 at 1:04 AM, Hans Petter Selasky hsela...@c2i.net wrote: USE_LIBUSB1 should be set, and -lusb must be used as linker flag, not - lusb-1.0 like under linux. In FreeBSD -lusb is a multi-API library, including v0.1, v1.0 and v2.0. Header files are in /usr/include Maybe it is good to have a pkg-config pc file for libusb-0.1 and libusb-1.0 wrapper to point to the correct -lusb flag. Reference: http://freebsd.1045724.n5.nabble.com/libusb-config-missing-td4055538.html Or maybe it is good to have symbolic link to libusb-1.0.so. -- Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: argyllcms and usb (0.1 and 1.0)
On Fri, Feb 22, 2013 at 4:15 PM, Boris Samorodov b...@passap.ru wrote: USE_LIBUSB1 should be set, and -lusb must be used as linker flag, not - lusb-1.0 like under linux. After a deeper look at the code I realised that actually the called LIBUSB1 is a USB-1.0 with some changes. The author call it USB-1.0A. And this specific code is used at Linux and Windows drivers. And this code dosn't compile at FreeBSD. So I proceed with USB-0.1. It should not really matter. The USB-1.0A mod is more aimed under Windows (to support libusb0.sys) and a bit of mod for older Linux libusb-1.0.8. The API is still libusb-1.0 API. And of course the code does not compile for FreeBSD, in fact, libusb-1.0 and libusbx will not compile for FreeBSD since FreeBSD has its own libusb-1.0 API implementation (wrap around libusb20). libusb-1.0 and libusbx do have experimental support of OpenBSD and NetBSD which is based on ugen driver. The linker flag actually is -lusb. In FreeBSD -lusb is a multi-API library, including v0.1, v1.0 and v2.0. Header files are in /usr/include Thanks, it was helpfull. With some changes at the code I managed to build argyllcms-1.4.0. -- Xiaofan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
