Release Notes Inside Out Networks Edgeport Driver Package for Linux edgeport-0.5-1.src.rpm edgeport-0.5-1.tgz Tested Linux Distributions: Red Hat 9.0 Linux Kernels supported: 2.4.x (UP and SMP) 12/18/2005 CONTENTS Section Description 1 Introduction 2 Supported Products 3 Installation 4 Enhancements and Bug Fixes 5 Known Limitations 6 Ionmode Command 7 Usbserial Reserve Ports 8 Udev 9 Building Binary RPMs 10 History 1. INTRODUCTION This Inside Out Networks software package includes device drivers for the Edgeport USB products. It is currently supported on the following hardware platforms: o Standard i386/i486 and Pentium PC (x86 32bit) and is currently supported on the following Linux distributions: o Red Hat 9.0 Most likely this package will work on many other Linux distributions based on the 2.4.18 kernels and later, but this has not yet been tested. NOTE: Because of the rapid rate of releases from each respective vendor, the tested/supported list above quickly becomes out of date. This driver package has been tested and verified working for kernels up to and including version 2.4.26 from kernel.org. It is anticipated that this driver will work with vendor kernel releases of up to 2.4.26 and beyond, but this cannot be guaranteed because each respective vendor can, and does, add their own various changes and patches to the stock kernel.org kernel. These additional vendor patches can cause unforeseen incompatibilities with this driver. There are two drivers for the Edgeport devices. The io_edgeport driver is for the 930 based devices, and the io_ti driver is for the TI based devices. The io_edgeport driver has been included in the Linux kernel since early in the 2.4 series; the io_ti driver was added to the kernel in 2.4.20. However the drivers included with the kernel are not the most up to date. These drivers will not work in the 2.6 kernels. The 2.6 kernels do have versions of the Edgeport drivers; kernels 2.6.10 and later have the latest versions of the Edgeport drivers, essentially the same as the drivers described here, with the same features and supporting the same hardware. The sections below on reserve ports, the ionmode command, and RPMs do not apply to Linux 2.6, however. In place of reserve you can use udev in Linux 2.6 to assign device files to specific devices. See the Udev section for information on how to do this. Unfortunately, there is no ionmode command and Linux 2.6 does not currently support RS485 on the Edgeport 4s. Since the drivers are already included in the kernel, you do not need to install them; simply ensure that your kernel is configured with support for the Edgeport drivers. These drivers are available from http://www.brimson.com/downloads See www.brimson.com/downloads/README for a description of the files available. You will want to get the latest versions of these files: edgeport_release_notes--.txt edgeport--.src.rpm edgeport--.tgz Depending on your Linux distribution, you will need either the .src.rpm or the .tgz package, but not both. If you have questions or problems with these drivers please contact Inside Out Networks technical support, or Peter Berger, pberger@brimson.com, or Al Borchers, alborchers@steinerpoint.com. 2. SUPPORTED PRODUCTS Below is the list of all Edgeport models supported by the Linux drivers; this should be most all Edgeport models. The Linux drivers have not been thoroughly tested on all models, however. Please let us know of any problems. The vendor id of all supported devices is 0x1608. The product ids are give in the table below. Some devices actually appear as multiple devices--for example, the Edgeport 412 appears as a four port and an eight port device, or the Edgeport 4 (TI based) appears as two two port devices. The io_edgeport driver supports these products: Device Product ID -------------------------------------------------- 2 Port Devices Edgeport 2 0x0005 Edgeport 2i 0x0007 Edgeport 421 0x000C Edgeport 21 0x000D Edgeport 2 (DIN) 0x0010 4 Port Devices Edgeport 4 0x0001 Rapidport 4 0x0003 Edgeport 4t 0x0004 Edgeport 4i 0x0006 Edgeport 8 (dual cpu) 0x000E Edgeport 4 (DIN) 0x0011 Edgeport 22i 0x001A Edgeport 412 (4 port device) 0x0019 Edgeport Compatible 0x0013 MT4X56USB 0x1403 8 Port Devices Edgeport 8 0x000F Edgeport 16 (dual cpu) 0x0012 Edgeport 8i 0x0014 Edgeport 8r 0x0002 Edgeport 8rr 0x0008 Edgeport 412 (8 port device) 0x0018 The io_ti driver supports these products: Device Product ID -------------------------------------------------- 1 Port Devices Edgeport 1 0x0215 Edgeport 1 (3410 based) 0x0240 Edgeport 1i (3410 based) 0x0241 Watchport/P Proximity 0x0301 Watchport/M Motion 0x0302 Watchport/W Moisture 0x0303 Watchport/T Temperature 0x0304 Watchport/H Humidity 0x0305 Watchport Power 0x0306 Watchport Light 0x0307 Watchport Radiation 0x0308 Watchport/A Acceleration 0x0309 Watchport/D Distance 0x030A Watchport/D Proximity Distance 0x030B Plus Power HubPort 4CD 0x030C Plus Power PCI 0x030E 2-8 Port Devices Edgeport 2 0x0205 Edgeport 2c 0x021B Edgeport 2i 0x0207 Edgeport 421 0x020C Edgeport 21 0x020D Edgeport 42 0x0217 Edgeport 4 0x0201 Edgeport 4i 0x0206 Edgeport 22i 0x021A Edgeport 221c 0x021C Edgeport 22c 0x021D Edgeport 21c 0x021E Edgeport 4s 0x0242 Edgeport 8 0x0244 Edgeport 8s 0x0243 3. INSTALLATION The Edgeport drivers are distributed as a source RPM package and as a source TGZ package. Either can be used to install the drivers; though you must use the TGZ package if your Linux distribution does not have the RPM package manager. Install the Kernel Sources To build the Edgeport drivers you must have the matching kernel sources for your kernel. To verify that you have matching kernel sources, run "uname -r" to get the version of the running kernel. Then check for the directory /usr/src/linux-, /lib/modules//source, /lib/modules//build, or /usr/src/linux-, where STRIPPED_VERSION has the extra version information removed. If you do not find the correct kernel source directory, you must find and install the kernel sources from your distribution CDs or other media. Prepare the Kernel Sources This step may or may not be necessary, depending on how your Linux distribution installs the kernel sources. Log in as root and do the following: Command Explanation -------------------------------------------------------------- 1. cd /usr/src/linux- Change to the source directory. 2. make mrproper Clean up any old files. 3. Make a configuration file to match your running kernel. Use either... make oldconfig For Red Hat. --OR-- make cloneconfig For SUSE. For other distributions these same commands might work, or you might need to find a config file in /boot or in a configs directory, copy it to .config, and run "make oldconfig". 4. make dep Create the dependency and version files. Install the Edgeport Drivers from the Source RPM Package Follow this step if your distribution supports RPM packages; if not, follow the next step on installing from a TGZ package instead. You will need the Edgeport source RPM package for this step. The Introduction section above describes where to find the latest Edgeport source RPM. Log in as root and do the following: Command Explanation -------------------------------------------------------------- 1. rpmbuild --rebuild edgeport--.src.rpm Build the driver package for your kernel. 2. cd /usr/src/redhat/RPMS/i386 3. rpm -Uvh edgeport--.i386.rpm Install the driver package. Install the Edgeport Drivers from the Source TGZ Package Follow this step if your distribution does not support RPM packages; if it does support RPM, use the previous step instead. You will need the Edgeport source TGZ package for this step. The Introduction section above describes where to find the latest Edgeport source TGZ. Log in as root and do the following: Command Explanation -------------------------------------------------------------- 1. tar xvzf edgeport--.tgz Unpack the sources. 2. cd edgeport-- 3. ./configure Configure the sources for your system and kernel version. make Build the drivers. make install Install the drivers. Load the Edgeport Drivers You must unload any old versions of the drivers and load the new drivers in their place. The RPM and TGZ packages attempt to do this, but they cannot do it if any USB serial devices are in use. If any USB serial devices are in use, you must either reboot or explicitly unload and reload the drivers. The simplest way to unload the old drivers and load the new is to reboot. Alternatively, you can close all open serial ports on all USB serial devices, unplug the USB serial devices, and then as root run the command rmmod io_edgeport io_ti usbserial Then plug the USB serial devices back in and the newly installed drivers will be loaded. Uninstalling the Edgeport Drivers If you installed the Edgeport RPM package, you can uninstall it by logging in as root and running the command rpm -e edgeport-- If you installed the Edgeport TGZ package, you can uninstall it by logging in as root and running the commands cd edgeport-- (You will need to give a full or relative path to the unpacked source file directory.) make uninstall 4. ENHANCEMENTS and BUG FIXES General o Created RPM and TGZ packages. o Added support for 8r, 8rr, 412, 22i, 221c, 22c, 21c, 1i, Watchport/A, Watchport/D, Plus Power Port HP4CD, and Plus Power Port PCI. o Updated io_usbvend.h to the latest IO Networks file. o Added ifdefs for 2.4.18 and 2.4.19 kernels. Changes to usbserial Version 1.7a-ionetworks o Modified the locking flag so that usbserial remains compatible with existing USB serial drivers. This was necessary for the source RPM which does not rebuild all the USB serial drivers. Version 1.7-ionetworks o Added reserve ports to usbserial. o Added a flag to usbserial for drivers that do their own locking. o Log device serial number when serial ports are assigned. Changes to io_edgeport Version 2.6-ionetworks o Fixed locking problem with OHCI USB controller on 2.4.26. o Added low_level_locking flag and minimal locking. o Fixed oops on disconnect. Version 2.5-ionetworks o Removed parallel port from io_edgeport--the printer class driver handles the parallel port on the Edgeports. o Updated io_fw_down.h to the latest IO Networks firmware, 1.16.4. o Added support for mark and space parity in io_edgeport. o Added support for TCSETAW and TCSETSW ioctls in io_edgeport. Changes to io_ti Version 0.6a-ionetworks o Added support for the Edgeport/8 and Edgeport/8s. o Firmware version 4.80 for TI based Edgeports. Version 0.6-ionetworks o Fixed ENXIO errors by adding a semaphore to serialize all control transfers (2.4 kernels cannot queue control transfers). o Removed calls to usb_clear_halt in callbacks--these would cause an oops since usb_clear_halt sleeps and the callbacks are in interrupt time. o The Edgeport device now handles hardware flow control directly, rather than the driver explicitly setting/clearing the RTS line. This also fixes an ENXIO error. Version 0.5b-ionetworks o Retry on -ENXIO (-6) error on synchronous read commands. Version 0.5a-ionetworks o Retry on -ENXIO (-6) error on synchronous write commands. Version 0.5-ionetworks o Fixed software flow control on outgoing data. Version 0.4-ionetworks o Added recognition of 3410-based EP/1 in io_ti. o Added support for Edgeport 4s to io_ti. Default for all ports is RS232. Other modes can be set via ION_SETMODE/ION_GETMODE ioctls. o In io_ti ION_SETMODE, set non-zero bUartMode values only on Edgeport 4s. o Updated io_fw_down3.h to the latest IO Networks firmware, 4.10.0. o Added a write buffer to io_ti. o Added a semaphore to io_ti to protect num_ports_open to fix a race during simultaneous opens--two opens could both try to submit the interrupt urb, an error. o Added a separate write_buf_in_use flag rather than relying on urb->status != -EINPROGRESS in io_ti. o Freed memory on failed startup and on shutdown in io_ti. o Added retry on io_ti TISendVendorRequestSync to fix failures during simultaneous opens. o Added more error messages to io_ti. o Added io_ti TIWriteCommand to write a command to the control endpoint without sleeping. TIClearRts now calls TIWriteCommand rather then TIWriteCommandSync. Needed to fix an oops when using hardware flow control--TIClearRts is called on interrupt time, so it cannot sleep. o Added setting/clearing tty->hw_stopped in io_ti to get hardware flow control working. o Removed usb_unlink_urb(...read_urb) in io_ti throttle and usb_submit_urb(...read_urb) in unthrottle--not needed and seemed to cause problems. o Dropped UMP_MASK_UART_FLAGS_RTS_FLOW flag in io_ti. It prevented RTS from dropping and it did not seem to help with RTS/CTS flow control. o Skip I2C_DESC_TYPE_FIRMWARE_AUTO records in io_ti TiValidateI2cImage(). o Check for UMP5152 and UMP3410 in io_ti TiValidateI2cImage() and TiGetI2cTypeInBootMode(). o Moved ION_SETMODE and ION_GETMODE ioctl defs into io_ti.h. 5. KNOWN LIMITATIONS General o SMP support has not been tested. o When multiple Edgeport devices are connected, kernel 2.4.18 sometimes fails to boot. To avoid this problem, disconnect the devices during boot. This problem has not been seen on later kernels. Known Problems in io_edgeport o Data is occasionally lost or corrupted, even with flow control on. o At higher baud rates or when sending data on many ports, a bulk in callback can be lost and the driver will stop reading. All subsequent opens will fail. You must disconnect/reconnect the Edgeport to recover. o On certain kernels, rmmod of io_edgeport sometimes causes a segmentation fault. This happens even if all ports are closed and the device disconnected. o On the Red Hat 9.0 2.4.20-6 and 2.4.20-8 kernels, the kernel crashes when a port is opened and closed with kermit. Upgrade to the latest official Red Hat 9.0 kernel, 2.4.20-31.9. Known problems in io_ti o Data is occasionally lost or corrupted, even with flow control on. o If you close a port that is software flow controlled, the port is stuck in a flow controlled state when you reopen it. To clear this state, the port must be configured for software flow control and a control-Q must be sent. Disconnecting/reconnecting the Edgeport also clears the problem. o When you close a port that is hardware flow controlled the port is not flushed, and some of the flow controlled data will be read when you reopen the port. o Sometimes a port will stop sending data. You can still receive data on the port, but not send data from the port. After this happens, the close of the port seems to hang-- for example, minicom will not exit. Closing and reopening the port does not fix the problem; the Edgeport must be disconnected and reconnected. o The ports on an Edgeport 4 or 4s will be assigned to /dev/ttyUSBXX in different orders. To avoid this problem, use the usbserial reserve ports feature. 6. IONMODE COMMAND The Edgeport 4s can be set for RS-232, RS-422, or RS-485 operation using the ionmode or ionmode_menu commands. See the man pages for these commands for complete information. Run "man ionmode" and "man ionmode_menu". 7. USBSERIAL RESERVE PORTS The usbserial.c driver has been enhanced with a way to explicitly assign serial ports to USB serial devices. Before this enhancement, the ports were assigned based on the order the USB serial devices were enumerated, but this changed depending on when the devices were plugged in, or how the system was booted. Devices like the Edgeport 4/s were particularly troublesome, since they are really two two port devices and these two devices were enumerated in different orders, randomly changing the port assignments of the four ports on the device. The usbserial module now has a module parameter named "reserve_ports". This is an array of strings, one for each USB serial port, beginning at /dev/ttyUSB0 and continuing on up. The string is a pattern that reserves the port for a particular device by serial number, by vendor/product id, or by device path. Syntax Initially the strings NULL for all ports, and these NULL strings leave the port available for any device. The first character of the string determines the type of the pattern: S -- serial number V -- vendor/product id D -- device path ^ -- this port is available for a multiport device that matched the previous pattern - -- this port is not available for any device * -- this port is available for any device The rest of the string is interpreted according to the first character: Serial Number The serial number is an ASCII string that is matched against the serial number reported by the device. An "*" can be used at the beginning or end of this string as a wildcard to match the beginning or ending of any serial number. The serial number of the Edgeports can be found by connecting the Edgeport and running the command "lsusb -v". (The serial number printed on the label on the device may not be the complete USB serial number--a trailing "-0" or "-1" might need to be added to the printed serial number--so use lsusb to determine the complete serial number.) Vendor/Product ID The vendor/product ids are two hex numbers separated by a ":" or "/". Either number can be replaced by a "*" as a wildcard to match any vendor or product id. The vendor and product ids should not have "0x" at the beginning. The vendor and product ids are listed in the SUPPORTED PRODUCTS section above. Device Path The device path is a "/" separated path of decimal integers. The first integer is the bus number, the rest are the USB port numbers of sequence of hubs leading to the device. Any integer in the path can be replaced by a "*" as a wildcard to match any port. For example, a device path like "D1/2/3" means the device attached to the 3rd port on the hub attached to the 2nd port on the virtual hub on bus 1. When the Edgeport is connected, you can use "lsusb -t" to print out the bus and device numbers of the path to the Edgeport. You can also find the path to the Edgeport in the /var/log/messages file when the device is first connected. Be sure syslog is logging informational messages and look for the "new device connect" message to see the path. Specifying the Module Parameters The reserve_ports module parameter can be given on the insmod or modprobe command line, or it can be given in the /etc/modules.conf file, like this add options usbserial 'reserve_ports=V1608:242,S*-0,V1608:242,S*-1' Examples The three examples that follow all assign the first four USB serial ports, /dev/ttyUSB0 through /dev/ttyUSB3, to an Edgeport 4/s. add options usbserial 'reserve_ports=SA32399053-0,^,SA32399053-1,^' This example specifies the serial number of the device. The Edgeport 4/s looks like two different devices, one with a serial number ending in "-0" for the first two ports and another with serial number ending in "-1" for the second two serial ports. add options usbserial 'reserve_ports=D1/2/*/2,D1/2/*/2,D1/2/*/1,D1/2/*/1' This example specifies the device path for an Edgeport 4s attached to any port of a hub attached to the computer's 2nd USB port. Since the Edgeport 4/s looks like two devices behind a hub, the path to the Edgeport 4/s shows one extra port; USB port 2 is used for the first two ports, and USB port 1 is used for the second two ports. add options usbserial 'reserve_ports=V1608:242,S*-0,V1608:242,S*-1' This example specifies the vendor and product id and the trailing part of the serial number. Since Edgeport 4/s looks like two two port devices, the device with the first two ports must match two entries in the reserve_ports array; in this example that means the the vendor id must be 0x1608, the product id must be 0x0242, and the serial number must end in "-0". Which method should you use to specify the Edgeport in the reserve ports configuration: serial number, vendor/product id, or device path? Each has pros and cons. The serial number uniquely identifies a specific Edgeport; serial numbers will distinguish between multiple Edgeports of the same model; and the Edgeport can be plugged into any USB port. However, you must determine and configure each serial number separately and update the reserve ports configuration if you replace an Edgeport, even with an identical model plugged into the same USB port. The vendor/product id only specifies the Edgeport model; if you have only one device of any Edgeport model this works fine. You can even replace the Edgeport with the same model or plug the Edgeport into a different USB port without updating the reserve ports configuration. However, if you have two or more Edgeports of the same model, vendor/product ids cannot distinguish them. The device path assigns the USB serial ports according to which USB port the Edgeport is plugged into. As long as none of the USB connections are moved, you can replace an Edgeport without updating the configuration (even if you change to a different model Edgeport, as long as it has the same number of ports as before). However, if you add, remove, or re-arrange the hubs or plug any hub or Edgeport into a different USB port, you will have to update the reserve ports configuration. 8. UDEV The Edgeport drivers in the Linux 2.6 kernel do not support reserve ports; however, the udev system provides a way to explicitly assign device names to USB serial devices. Without udev, the ports are assigned based on the order the USB serial devices are enumerated, but this changes depending on when the devices are plugged in, or how the system is booted. Devices like the Edgeport 4/s and 8/s are particularly troublesome, since they are really multiple two port devices and these devices can be enumerated in different orders, randomly changing the port names of the ports on the device. For complete details on udev, see the udev man page or http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html It is easy to write udev rules to name single port devices; this is described in the above documents. Here we will describe how to give deterministic names to each port on Edgeport multiport devices. Note that devices supported by the io_edgeport driver can have 2, 4, or 8 ports per device and a single Edgeport might appear as multiple devices. Devices supported by the io_ti driver can have 1 or 2 ports per device and a single Edgeport might appear as multiple devices. You will probably want to create symlinks to names that are meaningful to your application, as well. You can also modify these udev rules to select specific devices or USB ports. A few examples are given below. The udev rules for Edgeports need to be put in a file in the /etc/udev/rules.d directory. For example, the file might be named /etc/udev/rules.d/11-edgeport.rules. Here are the basic rules for an Edgeport/4. BUS="usb" SYSFS{idVendor}="1608" SYSFS{idProduct}="0201" SYSFS{serial}="*-0" NAME="%k" SYMLINK="ttyEDGE4_0_%e" BUS="usb" SYSFS{idVendor}="1608" SYSFS{idProduct}="0201" SYSFS{serial}="*-1" NAME="%k" SYMLINK="ttyEDGE4_1_%e" The four ports on the first Edgeport/4 will be /dev/ttyEDGE4_0_ /dev/ttyEDGE4_0_1 /dev/ttyEDGE4_1_ /dev/ttyEDGE4_1_1 The four ports on the second Edgeport/4 will be /dev/ttyEDGE4_0_2 /dev/ttyEDGE4_0_3 /dev/ttyEDGE4_1_2 /dev/ttyEDGE4_1_3 And so on. You can create more meaningful names with symbolic links. These commands will create symbolic links for the first two Edgeport/4 devices so the ports are named ttyA1 through ttyA4 for the first device and ttyB1 through ttyB4 for the second device. These commands only need to be run once. ln -s /dev/ttyEDGE4_0_ /dev/ttyA1 ln -s /dev/ttyEDGE4_0_1 /dev/ttyA2 ln -s /dev/ttyEDGE4_1_ /dev/ttyA3 ln -s /dev/ttyEDGE4_1_1 /dev/ttyA4 ln -s /dev/ttyEDGE4_0_2 /dev/ttyB1 ln -s /dev/ttyEDGE4_0_3 /dev/ttyB2 ln -s /dev/ttyEDGE4_1_2 /dev/ttyB3 ln -s /dev/ttyEDGE4_1_3 /dev/ttyB4 Similar rules and links can be created for other Edgeport devices. Udev can be used to identify devices more specifically. For example, if you wanted an Edgeport/4 plugged into the first USB port to appear as /dev/ttyA1 through /dev/ttyA4 and Edgeport/4 plugged into the second USB port to appear as /dev/ttyB1 through /dev/ttyB4. The devices would be associated with these ports based only on the USB port they were plugged into. To do this, you could use the following rules and links. BUS="usb" SYSFS{idVendor}="1608" SYSFS{idProduct}="0201" SYSFS{serial}="*-0" PLACE="1" NAME="%k" SYMLINK="ttyEDGE4_A_0_%e" BUS="usb" SYSFS{idVendor}="1608" SYSFS{idProduct}="0201" SYSFS{serial}="*-1" PLACE="1" NAME="%k" SYMLINK="ttyEDGE4_A_1_%e" BUS="usb" SYSFS{idVendor}="1608" SYSFS{idProduct}="0201" SYSFS{serial}="*-0" PLACE="2" NAME="%k" SYMLINK="ttyEDGE4_B_0_%e" BUS="usb" SYSFS{idVendor}="1608" SYSFS{idProduct}="0201" SYSFS{serial}="*-1" PLACE="2" NAME="%k" SYMLINK="ttyEDGE4_B_1_%e" ln -s /dev/ttyEDGE4_A_0_ /dev/ttyA1 ln -s /dev/ttyEDGE4_A_0_1 /dev/ttyA2 ln -s /dev/ttyEDGE4_A_1_ /dev/ttyA3 ln -s /dev/ttyEDGE4_A_1_1 /dev/ttyA4 ln -s /dev/ttyEDGE4_B_0_ /dev/ttyB1 ln -s /dev/ttyEDGE4_B_0_1 /dev/ttyB2 ln -s /dev/ttyEDGE4_B_1_ /dev/ttyB3 ln -s /dev/ttyEDGE4_B_1_1 /dev/ttyB4 The PLACE rule can be used to select devices plugged into specific ports on specific hubs. See the udev man page for more information on using the PLACE rule. As another example, suppose you had an Edgeport/4 with serial number V11111111 that you wanted to appear as ttyA1 through ttyA4 and another Edgeport/4 with serial number V22222222 to appear as ttyB1 through ttyB4. The devices would be associated with these ports regardless of which USB port they were plugged into. To do this, you could use the following rules and the same links given above. BUS="usb" SYSFS{idVendor}="1608" SYSFS{idProduct}="0201" SYSFS{serial}="V11111111-0" NAME="%k" SYMLINK="ttyEDGE4_A_0_%e" BUS="usb" SYSFS{idVendor}="1608" SYSFS{idProduct}="0201" SYSFS{serial}="V11111111-1" NAME="%k" SYMLINK="ttyEDGE4_A_1_%e" BUS="usb" SYSFS{idVendor}="1608" SYSFS{idProduct}="0201" SYSFS{serial}="V22222222-0" NAME="%k" SYMLINK="ttyEDGE4_B_0_%e" BUS="usb" SYSFS{idVendor}="1608" SYSFS{idProduct}="0201" SYSFS{serial}="V22222222-1" NAME="%k" SYMLINK="ttyEDGE4_B_1_%e" Note that here we specify the exact serial numbers, which uniquely identify the devices. 9. BUILDING BINARY RPMS The command rpmbuild --rebuild edgeport--.src.rpm will create a binary RPM from the source RPM. Normally you will build and install the binary RPM on the same system with the same running kernel. Configure uses "uname" to query the currently running kernel to determine the platform, the kernel version, and whether is is an SMP kernel or not. This information is used to build the a binary RPM appropriate for the running kernel. However, it is possible to build a binary RPM for a kernel other than the running kernel by setting these environment variables: EDGEPORT_PLATFORM -- x86, x86_64, and so on EDGEPORT_KERNEL -- 2.4.26, 2.4.18-3, and so on EDGEPORT_SMP -- "no" or "yes" If these environment variables are not set, "uname" is used to determine the values from the running kernel. Note that changing the EDGEPORT_PLATFORM variable will _not_ enable cross compiling, so this variable is currently not very useful. For example, the command EDGEPORT_KERNEL=2.4.18-3 EDGEPORT_SMP=no rpmbuild --rebuild edgeport-0.1-1.src.rpm will build the binary RPM for 2.4.18-3 UP, even if the running kernel is different. 10. HISTORY Version 0.5-1 -- 12/18/05 io_edgeport version 2.6-ionetworks io_ti version 0.6a-ionetworks usbserial 1.7a-ionetworks Added support for the Edgeport/8 and Edgeport/8s. Firmware version 4.80 for TI based Edgeports. Release notes include a section on UDEV for Linux 2.6. Version 0.4-3 -- 7/30/04 io_edgeport version 2.6-ionetworks io_ti version 0.6-ionetworks usbserial 1.7a-ionetworks This version is also available in a TGZ package and the release notes have been updated to describe the TGZ package. Version 0.4-2 -- 7/29/04 io_edgeport version 2.6-ionetworks io_ti version 0.6-ionetworks usbserial 1.7a-ionetworks This version fixed problems when uninstalling the RPM package. Version 0.4-1 -- 7/25/04 io_edgeport version 2.6-ionetworks io_ti version 0.6-ionetworks usbserial 1.7a-ionetworks This version fixed the ENXIO errors in the io_ti driver. Version 0.3-3 -- 7/21/04 io_edgeport version 2.6-ionetworks io_ti version 0.5b-ionetworks usbserial 1.7a-ionetworks Version 0.3-2 -- 7/19/04 io_edgeport version 2.6-ionetworks io_ti version 0.5a-ionetworks usbserial 1.7a-ionetworks Version 0.3-1 -- 6/30/04 io_edgeport version 2.6-ionetworks io_ti version 0.5-ionetworks usbserial 1.7a-ionetworks This was the initial release of the Edgeport RPM package.