| FXLOAD(8) | Linux Programmer's Manual | FXLOAD(8) |
fxload - Firmware download to EZ-USB devices
fxload [ -v ] [ -l ] [ -D
devpath ] [ -I hexfile ] [ -t
type ] [ -c config ] [ -s
loader ]
fxload [ -D devpath ] [ -L link
] [ -m mode ]
fxload [ -V ]
fxload is a program which downloads firmware to USB devices based on AnchorChips EZ-USB, Cypress EZ-USB FX, or Cypress EZ-USB FX2/FX2LP microcontrollers. These have 8-bit 8051 cores with special extensions for USB I/O. The FX2 supports high speed USB 2.0 transfers (480 Mbit/sec) as well as full speed USB 1.1 transfers (12 Mbit/sec), while the earlier parts supports only full speed transfers. These controllers have several package options, and can be set up with external memory (on-chip memory is usually 8K or 16K), EEPROMs, and ROMs when device costs allow.
This uses "usbfs" (older name: "usbdevfs") to access devices, and issues vendor specific control requests to download and reset the EZ-USB devices. Normally, firmware will then "renumerate" by disconnecting from USB and then reconnecting as a new device. It then appears with new device descriptors and functionality, as provided by the firmware which has been downloaded.
To support some non-firmware applications, this can also set up symbolic links for those usbfs names. It can also change their access modes. Both of these can help simplify software applications that need to talk to USB devices using user mode drivers, don't want to run with privileges or to examine all of the existing USB devices, and which don't need more kernel drivers.
See the Linux-Hotplug web site for information about how to use fxload to download device firmware when hotplugging USB devices, using driver-specific scripts stored in the /etc/hotplug/usb directory.
At least one of the following options must be specified. Note that as usual with UNIX and Linux commands, the order of command option flags does not matter. You may use these in any order.
Note that when downloading firmware that renumerates, there's no point in changing the device permissions or creating a symbolic link.
By default, fxload assumes the device uses an EZ-USB or EZ-USB FX. It also assumes that the device in question has been specified by USB kernel hotplugging conventions, using the DEVICE environment variable to name a "usbfs" file that can be used to talk to the device.
This program implements one extension to the standard "hex file" format. Lines beginning with a "#" character are ignored, and may be used to hold copyright statements and other information. Other tools may not handle hexfiles using this extension.
At this writing, "usbfs" is a kernel configuration option. That means that device drivers relying on user mode firmware downloading may need to depend on that kernel configuration option. A less preferable alternative involves compiling the firmware into the kernel and managing downloads and renumeration there. This is less preferable in part because much device firmware is provided with GPL-incompatible licensing, and in part because storing such firmware firmware wastes kernel memory.
For EZ-USB family devices, the hardware's first stage loader (supporting the 0xA0 vendor request) can't write into external memory. Configurations that put firmware into external memory thus need a second stage loader. For typical "flat" memory architectures, a loader supporting the 0xA3 vendor request is used to write into that memory. Similarly, a second stage loader that supports the 0xA2 vendor request is needed when writing boot firmware into an I2C EEPROM. These 0xA2 and 0xA3 vendor commands are conventions defined by Cypress. Devices that use bank switching or similar mechanisms to stretch the 64KByte address space may need different approach to loading firmware.
Not all devices support EEPROM updates. Some EZ-USB based devices don't have an I2C EEPROM; many such EEPROMs are too small to store firmware; and some firmware can't be placed in bootable I2C EEPROMs.
Linux Hotplugging Project http://linux-hotplug.sourceforge.net/
| September 2008 |