Home » Windows»Updating Your Emulex HBA Firmware

Recently, I've had to update the firmware on the HBAs of various servers, in preparation for a SAN migration. These are some notes I've taken along the way.


Nobody wants to logon to 4,000 servers and point/click their way through upgrades, least of all me.

To help with this, I've used the "elxflash.exe" utility, which is included in the Emulex Online Utilities package.

Download the file, and unzip it. You'll find one x86 and one x64 version of the utility in there. Each of these has a subdirectory called "firmware" ,and another one called "boot". You need to populate these directories with the relevant firmware images for your HBAs. These are also available from Emulex, to download. For example, the LightPulse LPe11000 requires a file called "ZD282A4.ALL" to be present in the firmware subdirectory. A listing of most HBA models and the required firmware and bootcode files, is in the "fwmatrix.txt" file. This file is used by the elxflash utility to determine which firmware image to install (or which firmware image to download to the HBA, in Emulex parlance).

Unattended HBAggage

Sorry for the poor wordplay. I haven't had much coffee yet today.
You don't want to have to logon to every server and run the elxflash utility manually, do you? No. Having taken the trouble to populate your firmware directory, you want to be able to just run the damned thing and have it do its stuff. This is where the batch file LCREFLSH.BAT comes in handy. This file contains several example command lines that you can use to upgrade/downgrade your firmware. Each of these calls elxflash.exe with different arguments. Simply uncomment (REM) the line you want, and run the batch file. Or create your own, perhaps adding a /LOG=logfile.log argument.

There are two ways in which the elxflash.exe utility can determine which firmware image to apply. By default, it will look in the fwmatrix.txt file (which should be placed in the same directory as the elxflash.exe utility. If you specify the /AUTO switch on the command line, it will ignore the fwmatrix.txt file, and just look straight at the firmware subdirectory. This needs to be a subdirectory of wherever elxflash.exe is located.

Let's say we want to use the fwmatrix.txt file. We need to make sure that we have the right model and firmware image in the file, and that the file exists in the firmware subdirectory. Then, we would run a command ELXFLASH /FF. But as we're looking to script this, we probably want the output logged to a file, rather than sent to stdout, where your automation solution might or might not retain it. So we'll change that command line to ELXFLASH /FF /LOG=%TEMP%\hba-fw.log. This gives us:

C:\HBA>elxflash /ff /log=%TEMP%\hbafw.log

Mon Jul 29 15:17:57 2013
HBA=LPe11000, Port Type=FC, WWN=10:00:00:00:FF:88:BE:B8,
Update=Firmware, Image=ZD282A4.ALL, New=282A4, Old=272A2, Status=Preview

Mon Jul 29 15:17:57 2013
HBA=LPe11000, Port Type=FC, WWN=10:00:00:00:FF:88:EB:9F,
Update=Firmware, Image=ZD282A4.ALL, New=282A4, Old=272A2, Status=Preview

elxflash.exe: All required firmware downloads succeeded - Return Code=0

- which is written to the log file, as well as stdout.

To test this without making changes, you can use the /PREVIEW switch, as well as the other switches - in fact, you may have noticed that the elxflash output above was actually run in this mode (showing Status=Preview). If you want the elxflash.exe utility to detect the firmware it's supposed to be using, instead of relying on the fwmatrix.txt file, you just add the /AUTO switch. So, if we wanted to discover (as opposed to look up in the fwmatrix file) the HBA and firmware image, and we wanted to test this without making any changes, the command line would be: elxflash /ff /auto /preview /log=%TEMP%\hbafw.log.

So put that command in the LCREFLSH.BAT file, and make sure the others are REM'd out, and you can zip up the package, deploy it wherever it needs to go, unzip and execute LCREFLSH.BAT - and you should have some updated HBAs to use.