Hotplug and USB device removal
I'm building a USB flash programmer with an EZ-USB chip. So far, it works fine, I'm able to plug in the device and have the hotplug usb.agent script notice it and start my demon. All this demon does is set permissions for the usbdevfs file and create a link in /var/run to point to the device. Thusly, the application can access the device as a normal user.
However, I would also like to use the hotplug system to notice the removal of the device and *remove* my symbolic link. The scripts currently do not support USB remove. It looks like the kernel sends all the necessary messages, but the script just needs updating. Is anyone working on this?
Also, as you guessed, I have a program that loads the ez-usb device from user mode. It won't be much effort for me to polish up and make it available to the world (especially since it supports sdcc output) as a generic ez-usb loader, but there must be millions of them out there:-)
Signature · 11 lines
Steve Williams "The woods are lovely, dark and deep. [email protected] But I have promises to keep, [email protected] and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · Stephen Williams
Also, as you guessed, I have a program that loads the ez-usb device from user mode. It won't be much effort for me to polish up and make it available to the world (especially since it supports sdcc output) as a generic ez-usb loader, but there must be millions of them out there:-)
I would be keen to see this loader work with the ezusb_load_0-3.tar.gz module that Adam Richter put together (ftp://ftp.yggdrasil.com/private/adam/ezusb/). Ideally, the loader would be generalized to handle a range of different formats (automatically, if possible). I had planned to do some work in this area (sdcc toolchain, and support libs for EZUSB FX2), but I also have an original anchorchips EZUSB board to do some testing (and a port of the ezload code from the BSD community).
I still don't support removing the various firmware codes from the kernel without better reasons that have been presented to date, but I do support being _able_ to do it from user speace.
Brad
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines · Stephen Williams
Also, as you guessed, I have a program that loads the ez-usb device from user mode.
Quoted 2 lines · [email protected] said:
Ideally, the loader would be generalized to handle a range of different formats (automatically, if possible).
Well, My loader supports intel hex files that sdcc generates, and it also sets the permisions and creates a soft link if so requested. I've abstracted the loader a bit more so that it is easier to add support for other formats, i.e. S-Records and Adam's hacked format.
With this program, my hotplug script looks like this:
!/bin/sh
# This script is the part of the server that goes into the hotplug
# directory. It takes the parameters of the policy agent and makes # calls to the gflashd server.
case "$PRODUCT" in
547/2235/*)
exec /usr/sbin/gflashd -I /usr/share/gflash/aa55.ihx ;;
12c5/*/*)
exec /usr/sbin/gflashd -m 0666 -L/var/run/gflash.lnk ;;
esac
(This handles the renumeration by detecting the Cypress chip. I haven't programmed the eeprom on this device yet.)
My application, then, can just look for the /var/run/gflash.lnk symbolic link to show up, and that is the device appearing and ready.
The problem here is that the link persists even when the device is disconnected. The usb.agent script does not pass on remove events to interested scripts.
Signature · 11 lines
Steve Williams "The woods are lovely, dark and deep. [email protected] But I have promises to keep, [email protected] and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · Stephen Williams
The problem here is that the link persists even when the device is disconnected. The usb.agent script does not pass on remove events to interested scripts.
I just looked at the call_policy() code in usb.c, and it looks like the "remove" event is supported by the code. What are you seeing in the debug logs (assuming that you have debugging turned on)? In particular, are you seeing "In_interrupt" messsages in your logs?
Brad
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · Stephen Williams
Quoted 2 lines · Stephen Williams
Also, as you guessed, I have a program that loads the ez-usb device from user mode.
Quoted 8 lines
Quoted 2 lines · [email protected] said:
Ideally, the loader would be generalized to handle a range of different formats (automatically, if possible).
Well, My loader supports intel hex files that sdcc generates, and it also sets the permisions and creates a soft link if so requested. I've abstracted the loader a bit more so that it is easier to add support for other formats, i.e. S-Records and Adam's hacked format.
The Keil toolchain eventually ends up with Intel hex as well. I'd be keen to see this made available, and made to support the firmware format used by Adam. I'm a bit busy at the moment, although I do need a tool for the EZUSB FX2 chipset, so I'll have to find some time. I remember you said that you needed to clean it up first - I'd encourage you to do so. It'd be good to somehow harmonise on a single tool for all these ezusb firmware applications.
Brad
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 1 line · [email protected] said:
The Keil toolchain eventually ends up with Intel hex as well.
It can also make S-Records, if I recall correctly. Anyhow, it should work with what I have.
Adam's format includes not just the bytes and addresses, but the 0xa0 of the commands as well. I suspect he didn't quite understand the workings of the ez-usb chip (he said as much on the linux-usb-devel mailing list) so may have thought that it was information.
Quoted 1 line · [email protected] said:
I remember you said that you needed to clean it up first
Pretty much done. Here's a snapshot:
<ftp://icarus.com/pub/steve/gflashd.tgz>
At the moment it is part of my gflash product, but if it finds a different home I'll maintain it wherever it lives.
Signature · 11 lines
Steve Williams "The woods are lovely, dark and deep. [email protected] But I have promises to keep, [email protected] and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · [email protected] said:
I just looked at the
call_policy()code inusb.c, and it looks like the "remove" event is supported by the code. What are you seeing in the debug logs (assuming that you have debugging turned on)?
May 19 07:14:24 beeker /sbin/hotplug: invoke /etc/hotplug/usb.agent () May 19 07:14:24 beeker /etc/hotplug/usb.agent: USB remove event not supported
It is apparently just the usb.agent script that lacks the necessary support for USB remove events. Unless my copy is out of date already.
Signature · 11 lines
Steve Williams "The woods are lovely, dark and deep. [email protected] But I have promises to keep, [email protected] and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines
However, I would also like to use the hotplug system to notice the removal of the device and *remove* my symbolic link. The scripts currently do not support USB remove. It looks like the kernel sends all the necessary messages, but the script just needs updating. Is anyone working on this?
Not unless you're volunteering ... :)
Quoted 5 lines
Also, as you guessed, I have a program that loads the ez-usb device from user mode. It won't be much effort for me to polish up and make it available to the world (especially since it supports sdcc output) as a generic ez-usb loader, but there must be millions of them out there:-)
Well, I think that one which handles both the FX and FX2, and which is generically integrated with the USB hotplugging, would be far more interesting than the other millions-less-one !
(The FX2 download procedure seems to be the same as for the FX, but the register used to control reset after downloading firmware has a different address.)
- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · Stephen Williams
Adam's format includes not just the bytes and addresses, but the
0xa0of the commands as well. I suspect he didn't quite understand the workings of the ez-usb chip (he said as much on the linux-usb-devel mailing list) so may have thought that it was information.
The 0xa0 is needed for devices like the WhiteHEAT that first loads a special loader into the EZUSB device, and then loads extra firmware. It uses two different commands to get this to work. See the current drivers/usb/serial/whiteheat.c file to see how this works, and why it is necessary.
There is also a script in the drivers/usb/serial directory that takes Intel hex records and converts them to the format used by the current drivers (a .h file full of records.) That script can be modified to do some other kind of output if you wish.
thanks,
greg k-h
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines
[...] It looks like the kernel sends
all the necessary messages, but the script just needs updating. Is anyone working on this?
Quoted 1 line · [email protected] said:
Not unless you're volunteering ... :)
As long as I'm not stepping on toes, this is pertinent to my day job; so sure I'm volunteering. I just want to make sure that it can work, and that I'm not going to conflict with the work of others.
Quoted 3 lines · [email protected] said:
Well, I think that one which handles both the FX and FX2, and which is generically integrated with the USB hotplugging, would be far more interesting than the other millions-less-one !
The CPUCS at 0x7f92 is it for the FX. If the FX2 works differently, then some configuration is needed. You can't autodetect based on device id as they can (and should be) set by a 0xb4 or 0xb6 load from the EEPROM.
However, it's pretty trivial to have a ``-t fx'' and ``-t fx2'' switch that the hotplug scripts can invoke. I'd be happy to cooperate on this. Someone with an FX2 board can send me patches, that's fine.
I think it is better to use standard ihex and srecord files wherever possible, as they can be generated and manipulated by commonly available tools, free and commercial.
Signature · 11 lines
Steve Williams "The woods are lovely, dark and deep. [email protected] But I have promises to keep, [email protected] and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel