[Samsung Galaxy Nexus] E:V:A:
Any success for the device driver? In the documents above, they say you should use the FTDI VCP (Virtual COM Port) drivers... But included in the package above, there is a driver in the ../usb_drv_windows directory, for exactly the TI driver you mentioned:

%USB_OMAP4460% = USB_Install, USB\VID_0451&PID_d010

For lazy reference:

[SIZE=2]-- Usage --

OMAPFlash Host is a command-line based application. It is currently available
for Windows XP only and will run in a Windows command shell. The application can
take commands directly from the command line or via a script file (a more useful
approach). The syntax for calling the tool is:

[B]omapflash [ <option> ] <command>[/B]

or, if a script file is used: omapflash @<file>

-- Options --

The tool has a number of options that can be used to control its overall
behavior.

[B]-com <port number> [/B]By default OMAPFlash will try to communicate with the
target platform using a USB serial link. This option will force OMAPFlash to
use a UART for serial communication and specify the host side COM-port to use.

-t <timeout> By default the timeout for communication on the serial link is 5
seconds. This option allows control of the timeout value by specifying another
timeout value in seconds.

[B]-p <platform>[/B] This option is required by OMAPFlash and specifies the platform
for which the download is to take place. The platform specified is a name tag
that allows OMAPFlash to identify the correct second loader to use. The tag
typically identifies the platform type and the memory used with the OMAP
device present on the platform (“e.g. SDP_MDDR_HYNIX_4G). The tag is used to
look up the second loader in a configuration file (omapflash2nd.txt) in
combination with an OMAP device identifier received from the platform during
peripheral boot.

[B]-omap <version> [/B]This option is required by OMAPFlash if a peripheral boot
sequence is used to transfer a second loader to a target platform. The option
specifies the OMAP generation used on the platform – without this option set,
OMAPFlash will be unable to determine how to correctly perform the peripheral
boot sequence necessary for transfer of the second loader to the platform. The
version number is a single digit integer (e.g. ‘3’ for an OMAP3xxx based
platform or ‘4’ for an OMAP4xxx based platform).

[B]-2[/B] This option controls whether OMAPFlash will try to use the ROM code
peripheral boot sequence to transfer a second loader to internal RAM before
doing anything else. This option will be required for most scenarios where
OMAPFlash is used but can be left out if OMAPFlash Host is interacting with a
second loader already running on a target platform.

[B]-v[/B] The ‘-v’ option controls whether OMAPFlash Host will run in verbose mode.
If set, more information will be shown during the execution of the flashing
sequence. Note that this option should be set in order to see the target
platform response to certain commands (e.g. ‘chips’).

-- Commands --

Commands are executed on the target platform. Any command is prefixed by the
keyword ‘command’ and anything following this keyword will be passed directly to
OMAPFlash Second by OMAPFlash Host without interpretation or modification.
Typically the ‘verbose’ option should be used with commands in order to ensure
that information returned from the platform will be shown on the console.

branch <device> <offset>
This command will cause OMAPFlash Second to make an
unconditional branch to a memory mapped address. The device will typically be
the SDRAM handled by the OMAP SDRAM controller in this case, and the offset
typically zero. The device ID must be one known by OMAPFlash Second and the
offset an integer within the address offset range valid for the device.

peek32 <address> Get the register value of the register with the given
address.

poke32 <address> <value> Modify the register at the given address to the given
value

peekpoke32 <address> <value> <mask> Modify the register at the given address
with the given value and mask

-- Flashing --

OMAPFlash Host is able to handle three basic procedures for accessing memory
devices through the OMAPFlash Second loader. These procedures are used to erase
memory devices, transfer a binary file to a device or upload the device content
to a binary file. In all cases, parameter values specifying sizes or offsets are
hexadecimal.

[B]chip_erase <device>[@offset] <size> [/B]
This procedure is used to erase the
content of a device, either for the whole device or for part of its address
range. The ‘device’ identifier is a string matching one of the devices
available on the platform as listed from the ‘chips’ command – in other words,
a device known to OMAPFlash Second for the particular platform used (SDRAM is
not a valid choice). If an ‘offset’ is used, the device erasure will start at
the offset specified. The offset will need to be compatible with the memory
structure of the device in question – e.g. if the device has a block size of
40000h bytes, the offset will need to be a multiple of the block size. The
‘size’ specifies the number of bytes to erase – a value of zero has the
special meaning of “to the end of the device”, either starting at offset zero
or at the specified ‘offset’ value, and can be used to erase the entire
device. Note that the typical erase functionality of a memory device is based
on the erasure of blocks of memory – it may not make sense to ask for erasure
of a size that is not a multiple of the block size of the device.

[B]chip_download <device>[@offset] <file> [/B]
In order to transfer a binary file to a
device on the platform this procedure is used. The ‘device’ identifier is a
string matching one of the devices available on the platform. If an ‘offset’
is specified the binary will be downloaded to the device starting at the
offset address specified. Using an offset should be done with some caution,
since the meaning of the offset value may be unclear for some device types
(e.g. for a NAND device the offset will be used without consideration of bad
blocks present in the memory space preceding the offset address). The file to
be downloaded is specified by the ‘file’ parameter and must be a raw image.

[B]chip_upload <device>[@offset] <size> <file> [/B]
In order to upload the content of
a memory device this procedure is used. The ‘device’ identifier is a string
matching one of the devices available on the platform. If an ‘offset’ is
specified content will be uploaded from the device starting at the offset
address specified. As for the ‘chip_download’ procedure the use of an offset
should be done with caution. The ‘size’ parameter specifies the number of
bytes to upload and the ‘file’ parameter the file to which the uploaded data
will be saved. Note that due to some limitations on the serial link, upload of
data will be considerably slower than download.
[/SIZE]