USB peripheral boot support on a Linux PC

Folks who have CSST know the capability of OMAP doing something known as a peripheral boot mode support over USB and UART. on Linux, well.. looks like no one(at least to my knowledge) has done the same thing.. So, today, in the middle of cooking some kadai chicken and some chicken kebobs, i played around and got thru to give a proof of concept code( http://www.geocities.com/crecmca98/Linux/omap_linux_peripheral_boot.tgz):

1) “Hacking” to get the vendor id and product id:

I dont own a Catc or a usb monitor.. so just plugged in the board to my laptop and dumped the syslog ;)

$ cat /var/log/syslog

Mar 16 15:26:23 coyote NetworkManager: [1205699183.236191] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_451_d009_N/A').

Voila!! 3430 is nothin but,

VendorId = 0x0451

DeviceID = 0xD009

2) Trigger an external program to download image:

Would you believe it, last time i was working in the kernel, hotplug was still working.. it seems that greg and others made hotplug obsolete! damn.. i have been out of kernel development for too long.. :(.

Anyways, I will need to create a scenario where on connection, the device will need to trigger some mechanism to initiate the downloads. I need to give some image fast as I see the following(putting couple of info points at probe and disconnect):

Mar 16 15:26:23 coyote kernel: [161173.293707] /home/nmenon/Src/Omap-Linux-Per/omap_peripheral.c: probe

Mar 16 15:26:23 coyote kernel: [161173.593413] usb 5-3: USB disconnect, address 15

Mar 16 15:26:23 coyote kernel: [161173.593534] /home/nmenon/Src/Omap-Linux-Per/omap_peripheral.c: discon

that is around 300ms to do everything and get out.. else we will get chopped in b/w. :(.

Looking at the same thru udevmonitor:

udevmonitor: throws out the messages that the system feels when I plug in/disconnect a device

udevmonitor will print the received events for the device connection and disconnect events:

nmenon@coyote:/etc/udev/rules.d$ sudo udevmonitor --env

udevmonitor will print the received events for:

UDEV the event which udev sends out after rule processing

UEVENT the kernel uevent

UEVENT[1205699933.731375] add /devices/pci0000:00/0000:00:1a.7/usb5/5-3 (usb)

ACTION=add

DEVPATH=/devices/pci0000:00/0000:00:1a.7/usb5/5-3

SUBSYSTEM=usb

SEQNUM=2954

MAJOR=189

MINOR=527

DEVTYPE=usb_device

PHYSDEVBUS=usb

DEVICE=/proc/bus/usb/005/016

PRODUCT=451/d009/0

TYPE=255/255/255

BUSNUM=005

DEVNUM=016

in short, the technique in the code link given above is based on the following:
install a driver which will provide read/write and usbdevfs entries,
use udev rules to detect a plug in event, and route the message accross to a second script
the second script will check for a config file and get the second file name from it, send the same to a perl script which will break it down to usb sized writes to the driver's fop write function.. bingo.. our image is going straight to SRAM.. (depends on the load address which i hacked into the perl script.. u can modify the same if you like)...


Not a tooo convinent a method + not portable to Windows, but has anyone considered libUSB ?
that might be interesting to try some day...