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...
