Avocent Worldwide
Avocent
Product Finder
Support

ESP-4 MI Flash Components

Driver Name:
ESP-4 MI Flash Components
Version:
3.13
File Size:
1.38 MB
Post Date:
15-Oct-07
File Name:
esp4bootapp313.zip
(Click to Download)

Release Notes: ESP-4 MI Flash Components

This document provides installation instructions and release notes for the flash components within the Avocent ESP-4 products. Note that these download images cannot be used on standard, 10/100 or Multi-Interface-8 ESPs.

NOTE: When the ESP-4 MI serial hubs are shipped, all ports are initialized to RS-232.

Components

ESP-4 models:

  • esp4app.img, version 3.13 (embedded application image)
  • esp4boot.img, version 0.82 (embedded bootstrap image)

Models

The following ESP models are supported:

  1. ESP-4 (images: esp4app.img and esp4boot.img)
    • ESP-4 MI

Flash Image Preparation On Windows Systems

The following are the steps to prepare the images for installation on Windows systems:

  1. Download the archive file from the web-site.
  2. Unzip the archive file.
  3. If you are using the Equinox TFTP service, copy the flash images (.img files) to the c:\%WINDIR%\system32\drivers directory. This is the root TFTP directory used by the Equinox TFTP service.
  4. If you plan to use a TFTP service other than the Equinox provided service, then it will be necessary to manually copy the flash image files to the appropriate TFTP transfer directory.
  5. Ensure that the TFTP service is properly installed and enabled.
  6. After installation, the temporary directory and its contents may be removed.

Flash Image Preparation On Unix Systems

The following are the steps to prepare the images for installation on Unix systems:

  1. Download the archive file from the web-site.
  2. Unzip the archive file.
  3. Copy the flash images (.img files) to the /etc/eqnx directory.
  4. If the TFTP root directory is not “/”, copy the flash images (.img files) to TFTPROOT/etc/eqnx. Note that typically TFTPROOT = /tftpboot.
  5. Ensure that the TFTP service is properly installed and enabled. Refer to “Enabling TFTPD on Unix Systems” within this document.
  6. After installation, the images may be removed.

Updating ESP-4 MI Flash

The flash images within the ESP-2/4 can be updated by:

  1. using EquiView Plus (windows systems only).
  2. using espcfg utility (unix systems only).
  3. using the embedded administration utility within the ESP-4 MI.
  4. using the embedded web browser administration utility within the ESP-4 MI. (requires version 2.50 or later of the application image and 0.60 or later of the bootstrap image).
  5. socket administration API facility.

Flash Image Update Using Device Manager (Windows 2K and above)

  • Download the archive file from the web-site.
  • Unzip the archive file.
  • If you are using the Equinox TFTP service, copy the flash images (.img files) to the c:\%WINDIR%\system32\drivers directory. This is the root TFTP directory used by the Equinox TFTP service. Note you can use a different subdirectory if you wish. This is directory you will use in step 11 below.
  • Open up Device Manager.
  • Double click on the Avocent Ethernet Serial Provider.
  • Click on the ESP properpty page tab. Make sure this is the correct ESP by looking at the Unit ID which is the same as the MAC Address and the IP Address.
  • Click on Update Flash.
  • Type in the Community Name (usually “public”) then click Next.
  • In the ESP FLASH Update mode page, your will see the Version, Create Date and Create Time. You also see the Status of the Last Flash Update. The Status should be App: Last Application Flash image update successful. And Boot: Last Boot Flash image update successful.
  • Click on the Manual FLASH Update.
  • Click to Enable both the Bootstrap FLASH Update Parameters and the Application FLASH Update Parameters. Type in the Server IP Address, this is the address of where the image files are located. Type in the full pathname for the boot image and app image. This is the full pathname to where the images are located. Click Next.
  • Here you can type in 0 for the Days Hours Minutes and Seconds or just click Next. This means the Flash updates will begin immediately.
  • Now click Finish.
  • After the images have been transferred you can go back to the ESP FLASH Update and you should see the App: Last Application Flash image update successful and Boot: Last Boot Flash image update successful. You should see the new Version and the Create Date and Create Time change. The Create Date and Time are the Date and Time these images where built.

Flash Image Update Using Equiview Plus (Windows systems only)

  1. Install, or upgrade to EquiView Plus 5.5 or later.
  2. If necessary, discover the ESP-4 MI unit.
  3. Using EquiView Plus, click on “Module” and “Update FLASH”.
  4. Select “Update Bootstrap Image”, provide the IP address of the TFTP server system and the name of the new image file. Then click Update.
  5. Repeat step 4 using application image.
  6. Reboot the ESP-4 MI.

Updating Flash Images Using espcfg (Unix systems only)

  1. Invoke espcfg.
  2. select "Update flash".
  3. select the appropriate esp.
  4. select "Update flash"
  5. provide the SNMP Community password (usually "public")
  6. select bootstrap or application.
  7. provide server IP address if necessary (note that the IP address for the current host will usually be displayed).
  8. provide bootstrap/application location. refer to "Location of Flash Components on Unix Systems". As shipped, the names of the images would be:
    • /etc/eqnx/esp2app.img (application image for ESP-2)
    • /etc/eqnx/esp2boot.img (kernel and bootloader for ESP-2)
    • /etc/eqnx/esp4app.img (application image for ESP-4)
    • /etc/eqnx/esp4boot.img (kernel and bootloader for ESP-4)
  9. Reboot the ESP as directed.

Updating Flash Images Using Embedded Administration Utility

  1. telnet to the IP address of the ESP-4 MI.
  2. Enter administration password (or specify one if not already configured).
  3. From the Main Menu, select Server Configuration.
  4. From the Server Configuration Menu, select Flash Status and Update.
  5. Enter ‘y’ to update applicaton image.
  6. Enter the IP address of the TFTP server system and the name of the application image file. Refer to “Location of Flash Components on Unix Systems”. Then click “Apply”.
  7. Allow 30 seconds for the process to complete.
  8. Repeat steps 5,6 and 7 for the bootstrap image.
  9. From the Server Configuration Menu, select Reboot.

Updating Flash Images Using Embedded Web Browser Administration Utility

  1. Launch a browser to the IP address of the ESP-4 MI.
  2. Enter administration password (or specify one if not already configured).
  3. From the Main Menu, select the Flash option.
  4. Click the Update Bootstrap button.
  5. Enter the IP address of the TFTP server system and the name of the bootstrap image file. Refer to “Location of Flash Components on Unix Systems”. Then click “Apply”.
  6. Allow 30 seconds for the process to complete.
  7. Repeat steps 4,5 and 6 for the application image.
  8. Click on the “Reboot” button.

Updating Flash Images Using Socket Administation API

Contact Avocent Technical Support for the Socket Administration API protocol document.

Enabling TFTPD on Unix Systems

For a flash update to succeed, the tftp (trivial file transfer protocol) daemon must be enabled on the server where the downloadable images are located at. This process is documented below. Note that the process varies based on operating system type:

OpenServer, UnixWare and Aix

tftpd is invoked indirectly by the internet services daemon - inetd. The configuration file for inetd must be modified to enable tftpd.

  1. edit /etc/inetd.conf
  2. uncomment the line for tftpd
  3. locate the inetd process: ps -eaf | grep inetd
  4. send signal to inetd process: kill -s SIGHUP <inetd process>

Note that the tftpd daemon can run in non-secure or secure mode. Either one may be used, but secure mode is recommended. Secure mode is specified by the “-s” option when tftpd is invoked (i.e. in the file /etc/inetd.conf). In secure mode, the default tftpd root directory is /tftpboot. If this is changed, the download images installed in the /tftpboot directory will need to be moved to the tftpd root directory.

Linux

If not already done, the tftpd package must be installed on your system. On most systems that use RPMs, this is done by the tftp-server RPM. To verify that this package is installed:

rpm -q tftp-server

If not present, then it must be installed from your distribution set.

tftpd is invoked indirectly by the internet services daemon inetd or xinetd (xinetd has replaced the older inetd in most recent distribution sets). The configuration file for inetd or xinetd must be modified to enable tftpd.

Determine if your system is using inetd or xinetd:

  • if /etc/inetd.conf is present, then inetd is being used.
  • if /etc/xinetd.d directory exists, then xinetd is being used.
Configuring inetd for tftpd
  1. edit /etc/inetd.conf
  2. uncomment the line for tftpd
  3. locate the inetd process: ps -eaf | grep inetd
  4. send signal to inetd process: kill -s SIGHUP <inetd process>

 

Configuring xinetd for tftpd

  1. edit /etc/xinetd.d/tftp
  2. set these fields:
    • user = root
    • server_args = -s /tftpboot
    • disable = no
  3. locate the xinetd process: ps -eaf | grep xinetd
  4. send signal to xinetd process: kill -s SIGUSR2 <xinetd process>

Note that the tftpd daemon can run in non-secure or secure mode. Either one may be used, but secure mode is recommended. Secure mode is specified by the “-s” option when tftpd is invoked (i.e. in the file /etc/inetd.conf or /etc/xinetd.d/tftp). In secure mode, the default tftpd root directory is /tftpboot. If this is changed, the download images located in the /tftpboot directory will need to be moved to the tftpd root directory.

Testing TFTPD

It is always a good idea to verify that tftpd is running correctly before doing a flash update. The verification can be done as follows:

  1. tftp localhost (or name of local system)
  2. get etc/eqnx/espapp.img
  3. quit

If tftpd is configured correctly, this should transfer espapp.img to the local directory.

Location of Flash Components on Unix Systems

As installed, the flash components are located in /etc/eqnx and /tftpboot/etc/eqnx. How the location of the flash components are specified varies based on whether or not secure mode tftpd is used:

Secure-Mode

Files are accessed relative to the tftpd root directory (i.e. expected to be /tftpboot). Hence etc/eqnx/esp2app.img actually refers to /tftpboot/etc/eqnx/esp2app.img

The leading "/" may or may not be specified (on Linux systems with tftp-server versions 0.16 and earlier, the leading "/" must not be specified).

Non-Secure Mode

Files are accessed relative to the "/" directory. Hence, /etc/eqnx/esp2app.img actually refers to the file by that name.

Generally, the leading "/" must always be specified.

Flash Update Failures

When a flash update failure occurs, it may not always be obvious what the problem was. The following steps may be used to diagnose the failure:

In addition, check the following:

  1. Verify that tftpd is configured properly.
  2. Make sure the proper pathname to the image file was specified (see "Location of Flash Images on Unix Systems").
  3. Check the tftp logfile if one exists. This log will indicate if a successful tftp connection was made and also if there were any abnormal operations.
  4. Verify that the versions of the new images are greater than the currently installed images.
  5. TFTP is an un-reliable transport mechanism using UDP. A busy network may result in lost packets which would cause the update to fail.

Changes in release 3.13 (application image)

  1. Fix to dhcp client to properly timeout before sending next set of BOOTP/DHCP requests. Previously, no timeout would occur on busy networks which would result in BOOTP/DHCP requests never being sent beyond initial set.
  2. Change to dhcp request timeout values to reduce the amount of time to acquire an IP address during the first 60 seconds of operation. The new "rules" regarding requests:
    • For the first 60 seconds, there is a 5 second timeout between request bundles. A request bundle contains 1 BOOTP and 3 DHCP requests (each 1 second apart).
    • After 60 seconds, the timeout increases by 7 seconds between each request bundle. A request bundle contains 1 BOOTP and 2 DHCP requests (each 1 second apart).
    • The maximum is 60 seconds between request bundles. At the maximum, a request bundle contains 1 BOOTP and 1 DHCP requests (each 1 second apart).
  3. Change to permanent debug level to that it is saved across reboots. This is used to configure to application logger - which is only accessible via the serial menu administration utility.
  4. Change to the TCP-based administration API so that login can be done with a zero-length password.
  5. Add support for TFTP push of firmware images in order to do flash updates. The application or bootstrap image may be pushed by a TFTP client. No other TFTP pushes will be accepted while the flash update process is in operation.

Changes in release 3.12b (application image)

  1. Fix to properly account for deltas. Firmware was changed to match drivers, such that delta messages do not count against the send window size.
  2. Change the manufacturing process for ESP-2 models (ESP-2 MI and ESP-2 OPTO). Different image files and downloaded for the different ESP-2 models.
  3. Change when setting the SNMP community name MIB variables midRCommName and midWCommName (enterprises.544.4.1.4 and enterprises.544.4.1.5). Setting either variable will also cause the other to be set.
  4. Increased SNMP maximum request size. Equiview Plus sends a single request with multiple OIDs in order to "poll" the ESP. On ESP-16 MI, this request was being refused because the total request size was too large. Equiview Plus would indicate this by displaying its "No Reply" field.
  5. Changed the internal loopback (used by Equiview Plus and ESP-View) so that the drain would timeout after completing / terminating the loopback. Without the timeout, the port would remain in use until ESP reset.
  6. Changed the internal loopback (used by Equiview Plus and ESP-View) so that the "transmitter" paced better with the "receiver" and also so that the "transmitter" correctly honored x-offs.

Changes in release 3.11 (application image) / 0.82 (bootstrap image)

  1. Fix for problem that might cause control signal state to not be properly reported.
  2. Increased number of concurrent servers from 8 to 16.
  3. Added Windows SETXON and SETXOFF support.
  4. Added control signal extension protocol messages.

Changes in release 3.10 (application image)

  1. Added Windows SETXON and SETXOFF support.
  2. Added control signal extension protocol messages.
  3. Fix to restore gateway route after changing network attributes.

Changes in release 3.08 (application image) / 0.81 (bootstrap image)

  1. Enhancements to ESP-View utility to add the ability to run loopback on all serial ports and also obtain the status of all ports.
  2. Changed the menus for the CLI administration utility. This affects all of the port configuration and status functions. After selecting a function, the port number must be selected to perform the operation on. In addition, there is an “all ports” option to perform the operation on all serial ports.
  3. Changed the menus for the web based administration utility. This affects all of the port configuration and status functions. After selecting a function, the port number must be selected to perform the operation on. In addition, there is an “all ports” option to perform the operation on all serial ports.
  4. Modifications to the manufacturing setup and diagnostics procedure.
  5. Various other modifications and fixes, mainly in the administration functions.

Changes in release 3.04 (application image) / 0.77 (bootstrap image)

  1. Added support for ESP-4 MI models.
  2. Added ESP-View utility for performing datascope, loopback and status operations. This utility is invoked through the web based administration utility.
  3. Added ability to configure network interface with regard to speed and duplex. Configured through administration utilities.
  4. Added ability to send port break to serial port. Invoked through administration utilities.
  5. Modifications to adhere to Avocent branding requirements.
  6. Various other modifications and fixes, mainly in the administration functions.