Re: USB stack / configuration 0
On Thursday 08 January 2004 07:01, Bernd wrote:
Im mostly worried about having more than a single device with address 0.
You can't do this as long as another device gets initialized.
Therefor I thought disabling/enabling the port would be better, but I'm
wrong as the result is be the same.
With the changes I have made, it is only possible to let the USB stack reset
the device from the ATTACH routine of a driver. This should garantee that
there is only one device with addr==0 , since the probe attach routines are
only called from one process.
For my device driver I have made a small change to the USB Stack and I
have introduced the return code USB_ATTACH_NEED_RESET for drivers to
tell the USB Stack thee device needs to be re-enumerated. The stack then
automatically re-assigns the device it's address, and re-probes for
drivers. This way even two seperate drivers could be made : one with the
firmware and one with the real driver.
Is anyone interrested in a patch maybe?
Sounds interesting.
Have a look at the patch attached to this mail.
My idea is to let a driver upload the firmware from it's ATTACH routine and
after that return with USB_ATTACH_NEED_RESET. Since some devices really
require a reset to be sent to it and others only need to be re-configured,
the USB stack doesn't send the reset itself. The ATTACH function is
responsible for sending the reset to the device.
After getting the NEED_RESET response, the USB stack assumes the device is
ready and listening at addr==0 again. The stack re-reads the device
descriptor, sets the address again and tries another round of attaching
drivers. We give up after 5 rounds of NEED_RESET.
If anyone knows a more elegant way to achieve the same functionality, I'm open
to ideas :)
grtz,
Daandiff -ur usb.org/usb_port.h usb/usb_port.h
--- usb.org/usb_port.h Wed Oct 2 09:44:20 2002
+++ usb/usb_port.h Wed Jan 7 20:26:55 2004
@@ -435,6 +435,7 @@
/* Returns from attach */
#define USB_ATTACH_ERROR_RETURN return ENXIO
#define USB_ATTACH_SUCCESS_RETURN return 0
+#define USB_ATTACH_NEED_RESET return EAGAIN
#define USB_ATTACH_SETUP \
sc-sc_dev = self; \
diff -ur usb.org/usb_subr.c usb/usb_subr.c
--- usb.org/usb_subr.c Wed Jan 15 00:07:43 2003
+++ usb/usb_subr.c Wed Jan 7 22:50:20 2004
@@ -86,6 +86,9 @@
Static int usbd_print(void *aux, const char *pnp);
Static int usbd_submatch(device_ptr_t, void *, void *);
#endif
+Static usbd_status usbd_new_device2(device_ptr_t parent, usbd_bus_handle bus,
+ int depth, int speed, int port,
+ struct usbd_port *up);
Static void usbd_free_iface_data(usbd_device_handle dev, int ifcno);
Static void usbd_kill_pipe(usbd_pipe_handle);
Static usbd_status usbd_probe_and_attach(device_ptr_t parent,
@@ -131,6 +134,7 @@
SHORT_XFER,
STALLED,
INTERRUPTED,
+ NEED_RESET,
XXX,
};
@@ -888,6 +892,14 @@
uaa.ifaceno = ifaces[i]-idesc-bInterfaceNumber;
dv = USB_DO_ATTACH(dev, bdev, parent, uaa, usbd_print,
usbd_submatch);
+
+ if (dev-address == USB_START_ADDR) {
+#if defined(__FreeBSD__)
+device_delete_child(parent, bdev);
+#endif
+return (USBD_NEED_RESET);
+ }
+
if (dv != NULL) {
dev-subdevs[found++] = dv;
dev-subdevs[found] = 0;
@@ -958,7 +970,7 @@
* and attach a driver.
*/
usbd_status
-usbd_new_device(device_ptr_t parent, usbd_bus_handle bus, int depth,
+usbd_new_device2(device_ptr_t parent, usbd_bus_handle bus, int depth,
int speed, int port, struct usbd_port *up)
{
usbd_device_handle dev;
@@ -1099,6 +,12 @@
err = usbd_probe_and_attach(parent, dev, port, addr);
if (err) {
+ if (err == USBD_NEED_RESET) {
+ DPRINTFN(1,(usbd_new_device: device needs reset\n));
+ /* must set address back to what it was */
+ dev-address = addr;
+ }
+
usbd_remove_device(dev, up);
return (err);
}
@@ -1106,6 +1124,27 @@
usbd_add_dev_event(USB_EVENT_DEVICE_ATTACH, dev);
return (USBD_NORMAL_COMPLETION);
+}
+
+usbd_status
+usbd_new_device(device_ptr_t parent, usbd_bus_handle bus, int depth,
+ int speed, int ports, struct usbd_port *up)
+{
+ int retry = 0;
+ usbd_status err;
+
+ err = usbd_new_device2(parent, bus, depth, speed, ports, up);
+ while ((err == USBD_NEED_RESET) (retry++ 5)) {
+ DPRINTFN(1,(usb_new_device: re-enumerating device\n));
+ err = usbd_new_device2(parent, bus, depth, speed, ports, up);
+ }
+
+ if (retry == 5) {
+ DPRINTFN(1,(usb_new_device: giving up after 5 tries...\n));
+ return (USBD_NOT_CONFIGURED);
+ }
+
+ return err;
}
usbd_status
diff -ur usb.org/usbdi.h usb/usbdi.h
--- usb.org/usbdi.h Mon May 6 20:23:36 2002
+++ usb/usbdi.h Wed Jan 7 21:45:11 2004
@@ -66,6 +66,7 @@
USBD_SHORT_XFER, /* 16 */
USBD_STALLED, /* 17 */
USBD_INTERRUPTED, /* 18 */
+ USBD_NEED_RESET, /* 19 */
USBD_ERROR_MAX /* must be last */
} usbd_status;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send
Re: USB stack / configuration 0
On Wednesday 07 January 2004 17:08, Bernd Walter wrote: I don't think it IS a dumb device, there is a USB spec called DFU which covers it and the hosts job is to do the reenumeration. Sparing a transistor to offload the work to the host were its also way more complex to do is dump. If this is part of the Spec, then the spec is dump too. Err yes, this IS USB we're talking about here :) usbd_reset_port should do from the USB point of view, but this doesn't trigger Free BSD to do a reconfiguration of the device, which is required after reset. Maybe the following will do instead: usbd_clear_port_feature(dev, port, UHF_PORT_ENABLE) delay(USB_PORT_POWERUP_DELAY); usbd_set_port_feature(dev, port, UHF_PORT_ENABLE) dev and port is that from the hub. Except that would remove power to the port I think.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB stack / configuration 0
On Wed, Jan 07, 2004 at 05:34:05PM +1030, Daniel O'Connor wrote: On Wednesday 07 January 2004 17:08, Bernd Walter wrote: I don't think it IS a dumb device, there is a USB spec called DFU which covers it and the hosts job is to do the reenumeration. Sparing a transistor to offload the work to the host were its also way more complex to do is dump. If this is part of the Spec, then the spec is dump too. Err yes, this IS USB we're talking about here :) Reead your spec - it's not part of USB itself. umass, ulpt, etc are extensions. It is even that a mass storage device doesn't have to honour umass specification to get the USB compliance logo :( usbd_reset_port should do from the USB point of view, but this doesn't trigger Free BSD to do a reconfiguration of the device, which is required after reset. Maybe the following will do instead: usbd_clear_port_feature(dev, port, UHF_PORT_ENABLE) delay(USB_PORT_POWERUP_DELAY); usbd_set_port_feature(dev, port, UHF_PORT_ENABLE) dev and port is that from the hub. Except that would remove power to the port I think.. AFAIK power is independend, but I'm not 100% shure. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB stack / configuration 0
On Wednesday 07 January 2004 09:07, Bernd Walter wrote: On Wed, Jan 07, 2004 at 05:34:05PM +1030, Daniel O'Connor wrote: On Wednesday 07 January 2004 17:08, Bernd Walter wrote: I don't think it IS a dumb device, there is a USB spec called DFU which covers it and the hosts job is to do the reenumeration. Sparing a transistor to offload the work to the host were its also way more complex to do is dump. If this is part of the Spec, then the spec is dump too. Err yes, this IS USB we're talking about here :) Reead your spec - it's not part of USB itself. As long as there are a lot of usefull devices that use the DFU spec, to me it seems no more than logicle to implement it in FreeBSD, no matter how dumb the system may sound :) usbd_reset_port should do from the USB point of view, but this doesn't trigger Free BSD to do a reconfiguration of the device, which is required after reset. Maybe the following will do instead: usbd_clear_port_feature(dev, port, UHF_PORT_ENABLE) delay(USB_PORT_POWERUP_DELAY); usbd_set_port_feature(dev, port, UHF_PORT_ENABLE) dev and port is that from the hub. Except that would remove power to the port I think.. AFAIK power is independend, but I'm not 100% shure. I have written a driver for Atmel USB WLAN adapters for FreeBSD recently (and still am). The device also needs it's firmware to be uploaded via the DFU interface. The first time the device is plugged in, an internal ROM mask is mapped into code-space of the processor which provides it with only a very basic USB stack that can do enumeration and DFU. Via DFU the host uploads the firmware into RAM. At the end of the upload the host asks the device to manifest the firmware. For the device this means having to switch the ROM image with the RAM image which is impossible while running in the specific processor. Thus the processor tells it's core to map RAM into code-space and resets itself. After that the device will apear again with address = 0. The host then needs to set the address, re-read the device descriptor (it has changes, the device now offers endpoints etc), attach a driver. Btw, a reset can be sent down to a usb device from within a driver with this line of code : usb_port_status_t stat; usbd_reset_port(sc-atuwi_udev-myhub, sc-atuwi_udev-powersrc-portno, stat); For my device driver I have made a small change to the USB Stack and I have introduced the return code USB_ATTACH_NEED_RESET for drivers to tell the USB Stack thee device needs to be re-enumerated. The stack then automatically re-assigns the device it's address, and re-probes for drivers. This way even two seperate drivers could be made : one with the firmware and one with the real driver. Is anyone interrested in a patch maybe? btw2: I have submitted a couple of patches in 2003 (one of witch is almost a year old at this moment), but none of the got comments / commited. Is anyone really working on USB code development / debugging lately? I want to see ALL USB devices working with FreeBSD and am willing to devote my spare-time to achieving this. grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB stack / configuration 0
On Wednesday 07 January 2004 18:37, Bernd Walter wrote: If this is part of the Spec, then the spec is dump too. Err yes, this IS USB we're talking about here :) Reead your spec - it's not part of USB itself. umass, ulpt, etc are extensions. It is even that a mass storage device doesn't have to honour umass specification to get the USB compliance logo :( shrugs I have a sharp axe you can split hairs with if you like. umass/ulpt/dfu/etc are all things that make USB useful, so support is good :) Maybe the following will do instead: usbd_clear_port_feature(dev, port, UHF_PORT_ENABLE) delay(USB_PORT_POWERUP_DELAY); usbd_set_port_feature(dev, port, UHF_PORT_ENABLE) dev and port is that from the hub. Except that would remove power to the port I think.. AFAIK power is independend, but I'm not 100% shure. I'll see how it goes :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB stack / configuration 0
On Wednesday 07 January 2004 20:34, Daan Vreeken [PA4DAN] wrote: Reead your spec - it's not part of USB itself. As long as there are a lot of usefull devices that use the DFU spec, to me it seems no more than logicle to implement it in FreeBSD, no matter how dumb the system may sound :) Yeah.. well there are plenty of dumb things about USB :) AFAIK power is independend, but I'm not 100% shure. I have written a driver for Atmel USB WLAN adapters for FreeBSD recently (and still am). The device also needs it's firmware to be uploaded via the DFU interface. The first time the device is plugged in, an internal ROM mask is mapped into code-space of the processor which provides it with only a very basic USB stack that can do enumeration and DFU. Via DFU the host uploads the firmware into RAM. At the end of the upload the host asks the device to manifest the firmware. For the device this means having to switch the ROM image with the RAM image which is impossible while running in the specific processor. Thus the processor tells it's core to map RAM into code-space and resets itself. After that the device will apear again with address = 0. The host then needs to set the address, re-read the device descriptor (it has changes, the device now offers endpoints etc), attach a driver. Interesting way of making it :) The device I have uses a Ti chip which has USB primitives and powers up with DFU only support, and then needs a reset to start executing the new code from RAM. Btw, a reset can be sent down to a usb device from within a driver with this line of code : usb_port_status_t stat; usbd_reset_port(sc-atuwi_udev-myhub, sc-atuwi_udev-powersrc-portno, stat); For my device driver I have made a small change to the USB Stack and I have introduced the return code USB_ATTACH_NEED_RESET for drivers to tell the USB Stack thee device needs to be re-enumerated. The stack then automatically re-assigns the device it's address, and re-probes for drivers. This way even two seperate drivers could be made : one with the firmware and one with the real driver. Is anyone interrested in a patch maybe? Ooh yes please :) btw2: I have submitted a couple of patches in 2003 (one of witch is almost a year old at this moment), but none of the got comments / commited. Is anyone really working on USB code development / debugging lately? I want to see ALL USB devices working with FreeBSD and am willing to devote my spare-time to achieving this. I thought Josef Karthauser [EMAIL PROTECTED] was doing some USB work, but I am not certain. I can test some stuff - I have a variety of USB 1 and 2 hardware (USB1 scanner, USB2 card reader, USB1 Pocket PC cradle *hiss* :), mouse, USB2 HD enclosure, USB1 printer and dongle..) I updated by laptop to 5.x recently so that should make this more relevant :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB stack / configuration 0
On Wed, Jan 07, 2004 at 11:04:37AM +0100, Daan Vreeken [PA4DAN] wrote: For the device this means having to switch the ROM image with the RAM image which is impossible while running in the specific processor. Thus the processor tells it's core to map RAM into code-space and resets itself. After that the device will apear again with address = 0. The host then needs to set the address, re-read the device descriptor (it has changes, the device now offers endpoints etc), attach a driver. Btw, a reset can be sent down to a usb device from within a driver with this line of code : usb_port_status_t stat; usbd_reset_port(sc-atuwi_udev-myhub, sc-atuwi_udev-powersrc-portno, stat); Im mostly worried about having more than a single device with address 0. You can't do this as long as another device gets initialized. Therefor I thought disabling/enabling the port would be better, but I'm wrong as the result is be the same. For my device driver I have made a small change to the USB Stack and I have introduced the return code USB_ATTACH_NEED_RESET for drivers to tell the USB Stack thee device needs to be re-enumerated. The stack then automatically re-assigns the device it's address, and re-probes for drivers. This way even two seperate drivers could be made : one with the firmware and one with the real driver. Is anyone interrested in a patch maybe? Sounds interesting. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB stack / configuration 0
On Tuesday 06 January 2004 18:47, Bernd Walter wrote: When setting a USB device to configuration number USB_UNCONFIG_NO (i.e. 0), the device goes into an unconfigured state with an invalid dev-cdesc. How does one then leave this unconfigured state and reconfigure the device to accept configuration changes? (all USB_SET_CONFIG changes are currently refused after going into configuration 0 - I'm not sure if this is the desired behaviour or a bug) I have to read the docs first bevor making a qualified comment about this. I'm not 100% sure if this applies, but.. There are certainly situations where you want to reenumerate the USB devices, for example there are a number of devices which have no real firmware - they expect to be programmed by the PC then reset and reenumerated after being plugged in. I have such a device (M-Audio Mobile Pre USB) and I have modified USB audio code which works except that you need to manually reset the device without removing power (which is done by partially removing and then reinserting the USB connector). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB stack / configuration 0
On Wed, Jan 07, 2004 at 04:05:15PM +1030, Daniel O'Connor wrote: On Tuesday 06 January 2004 18:47, Bernd Walter wrote: When setting a USB device to configuration number USB_UNCONFIG_NO (i.e. 0), the device goes into an unconfigured state with an invalid dev-cdesc. How does one then leave this unconfigured state and reconfigure the device to accept configuration changes? (all USB_SET_CONFIG changes are currently refused after going into configuration 0 - I'm not sure if this is the desired behaviour or a bug) I have to read the docs first bevor making a qualified comment about this. I'm not 100% sure if this applies, but.. There are certainly situations where you want to reenumerate the USB devices, for example there are a number of devices which have no real firmware - they expect to be programmed by the PC then reset and reenumerated after being plugged in. Different story. I have such a device (M-Audio Mobile Pre USB) and I have modified USB audio code which works except that you need to manually reset the device without removing power (which is done by partially removing and then reinserting the USB connector). Bad device - it would have been so easy add an single transitor to do this automaticaly. Nevertheless USB_UNCONFIG_NO can't help you here. What you need to do is toggling the hub port if the device is to stupid to detach/reattach on his own. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB stack / configuration 0
On Wednesday 07 January 2004 16:35, Bernd Walter wrote: There are certainly situations where you want to reenumerate the USB devices, for example there are a number of devices which have no real firmware - they expect to be programmed by the PC then reset and reenumerated after being plugged in. Different story. Ahh well, I was hopeful :) I have such a device (M-Audio Mobile Pre USB) and I have modified USB audio code which works except that you need to manually reset the device without removing power (which is done by partially removing and then reinserting the USB connector). Bad device - it would have been so easy add an single transitor to do this automaticaly. Nevertheless USB_UNCONFIG_NO can't help you here. What you need to do is toggling the hub port if the device is to stupid to detach/reattach on his own. I don't think it IS a dumb device, there is a USB spec called DFU which covers it and the hosts job is to do the reenumeration. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB stack / configuration 0
On Wed, Jan 07, 2004 at 04:44:46PM +1030, Daniel O'Connor wrote: On Wednesday 07 January 2004 16:35, Bernd Walter wrote: Bad device - it would have been so easy add an single transitor to do this automaticaly. Nevertheless USB_UNCONFIG_NO can't help you here. What you need to do is toggling the hub port if the device is to stupid to detach/reattach on his own. I don't think it IS a dumb device, there is a USB spec called DFU which covers it and the hosts job is to do the reenumeration. Sparing a transistor to offload the work to the host were its also way more complex to do is dump. If this is part of the Spec, then the spec is dump too. usbd_reset_port should do from the USB point of view, but this doesn't trigger Free BSD to do a reconfiguration of the device, which is required after reset. Maybe the following will do instead: usbd_clear_port_feature(dev, port, UHF_PORT_ENABLE) delay(USB_PORT_POWERUP_DELAY); usbd_set_port_feature(dev, port, UHF_PORT_ENABLE) dev and port is that from the hub. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
USB stack / configuration 0
Hi I've just finished a patch to alleviate several panics in the ugen driver (related to devfs issues and setting a USB device's configuration to USB_UNCONFIG_NO). I'm about to submit to freebsd-current@, but I need to clarify something first. When setting a USB device to configuration number USB_UNCONFIG_NO (i.e. 0), the device goes into an unconfigured state with an invalid dev-cdesc. How does one then leave this unconfigured state and reconfigure the device to accept configuration changes? (all USB_SET_CONFIG changes are currently refused after going into configuration 0 - I'm not sure if this is the desired behaviour or a bug) All I can think of is unplugging/plugging the device back in. In which case, why would we want to let users set USB_UNCONFIG_NO in the first place? -- Cheers, Jay http://www.evilrealms.net/ - Systems Administrator Developer http://www.imperial.ac.uk/ - 3rd year CS student ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
