Provided by: openipmi_2.0.33-1.1build3_amd64 bug

DESCRIPTION

       The  ipmi_sim  emulation  is set up using these commands.  They can be read from a command file, run from
       the command line, or executed inside the simulator after it is started.

       This may be a little confusing, but the network interfaces are configured by the  ipmi_lan  configuration
       file,  and  the  various management controllers, sensors, etc. are specified using this file.  Plus, this
       can be used to configure the simulator after it is up, set sensor values, inject events,  and  things  of
       that nature.

GENERAL COMMANDS

       Blank  lines and lines starting with `#' are ignored.  Long lines may be broken up by putting a 'ยด at the
       end of the line to be continued.

       quit   Exit the simulator

       include "file"
              Include the given file.

       define name "value"

              Define the given name as a variable with the given value.  This variable  may  be  used  later  by
              doing  $name.   This  cannot  be  used in quotes, but quotes may be broken up and the variable put
              between them.  For instance, if you say:

              define MCNUM "40"

              you can use it later as in

              mc_add $MCNUM 1 no-device-sdrs 00  00  00  0xc9  0x009000 0x0002

              or

              sensor_add $MCNUM 0 21 12 0x6f poll 1000 file "/sys/dev/sens1-"$MCNUM"-1"

       sleep time
              Pause the command interface for the given number of seconds.  This does not affect  the  execution
              of the simulator.

       debug options
              Set the debugging output.  Valid options are:

              msg Dump messages.

              raw Dump raw I/O

              Entering nothing turns of debugging.

       read_cmds filename
              Execute the commands in the given file.

MC COMMANDS

       mc_add IPMBAddress DeviceID HasDeviceSDRs DeviceRevision MajorFWRev MinorFWRev DeviceSupport
       ManufacturerID ProductID
              Add  an  MC  to the simulator.  All values are hexadecimal.  These are mostly values for the ``Get
              Device ID'' command, see the spec for details.  Note that the MC is not enabled after being added,
              you must add it.

              Note that some of these values control the capabilities of the MC.   For  instance,  HasDeviceSDRs
              sets whether device SDR repository commands will work.

              You may use has-device-sdrs or no-device-sdrs in the HasDeviceSDRs field.

       mc_add_fru_data mc-addr DeviceID FRUSize (data [byte1 [byte2 [...]]] | file offset filename)
              Set  the  FRU data for a given MC and device id.  Data may be supplied directly here, or it may be
              given as a file.  The offset is the start from the beginning of the file where the data is kept.

       mc_dump_fru_data mc-addr DeviceID
              Dump the FRU data for a given MC and device id.

       mc_delete mc-addr
              Remove the MC from the system.

       mc_disable mc-addr
              Disable the MC, but don't remove it.

       mc_enable mc-addr
              Enable the given MC.

       mc_setbmc mc-addr
              Set the BMC's address.

       mc_set_guid mc-addr guid
              Set the GUID value.  The guid may be a string (in quotes) or a hexadecimal string.

       sel_enable mc-addr max-entries flags
              Enable the System Event Log on the given MC.  The flags is a byte this is returned from the  ``Get
              SEL Info'' command; it controls various aspects of the SEL.  See the spec for details.

       sel_add mc-addr RecordType byte1 byte2 ... byte13
              Add an entry to the MC's SEL.

       main_sdr_add mc-addr byte1 [byte2 [...]]
              Add an entry to the main SDR of the MC.

       device_sdr_add mc-addr LUN byte1 [byte2 [...]]
              Add an entry to the device SDR of the MC.

SENSOR COMMANDS

       sensor_add mc-addr LUN sensor-num sensor-type event-reading-code [poll poll_rate poll_type
       poll_type_options] [event-only]

              Add a sensor to the given MC and LUN.  The type of sensor is set by the event reading code.

              If  poll  is  specified,  then  the  sensor  will  be polled for data.  Only the file poll type is
              currently supported.  The value is a number read from a file.  It has the following  options,  all
              optional:

              div=val  will  divide  the  read  value  by  the  given  number.   This is done after the multiply
              operation.

              mult=val will multiply the read value by the given number.  This is done after the subtraction.

              sub=val will subtract the value by the given number.  This is done after the mask.

              mask=val will mask (bitwise and) the value by the given number.

              base=value Specify the base of the value read from the file.  By default this is zero, meaning "C"
              conventions are used.

              initstate=value sets what the event state is initially  set  to.   This  is  useful  for  discrete
              sensors  with  bits  that  should normally be set to "1", like a presence bit, to keep the program
              from issuing an event every time the program starts.

              raw specifies that the data from the file is a raw value.  Only length bytes are read from offset.

              ascii specifies that the data from the file is in ASCII.  This is the default.  The  offset  value
              is used, but no the length.

              length=val  specifies  the  length  of the data to read from the file.  The maximum value is 4,and
              this is only used for raw data.

              depends=<mc_addr>,<lun>,<sensor_number>,<bit> specifies a discrete sensor bit that must be set  to
              1  for  the  sensor to be active.  Generally, you use the presence bit of a sensor to mark whether
              other sensors on the device are actually present.  Each of the other sensors  would  have  one  of
              these pointing to the presence bit.

              event-only specifies that the sensor will not be readable, it will only generate events (specified
              with a type 3 SDR).

       sensor_set_bit mc-addr LUN sensor-num bit-to-set bit-value generate-event
              Set  the  given  bit  to bit-value (0 or 1) for the sensor by bit number, either the threshold for
              analog or the discrete sensor bit.  If generate-event  is  non-zero  and  the  sensor  has  events
              enabled for that bit, then generate an event.

       sensor_set_bit_clr_rest mc-addr LUN sensor-num bit-to-set bit-value generate-event
              Like sensor_set_bit, but automatically clears all other bits.

       sensor_set_value mc-addr LUN sensor-num value generate-event
              Set the byte value for an analog sensor.  If the sensor exceeds a threshold, the sensor has events
              enabled, and generate-event is non-zero, then generate an event for the condition.

       sensor_set_hysteresis mc-addr LUN sensor-num support positive negative
              Set the hysteresis capabilities of the sensor.  It must be an analog sensor.  The support value is
              the  hysteresis  capability,  the  same  as  the  hysteresis support value in the sensor SDR.  The
              positive and negative hysteresis values are also set by this command.

              The support value may also be none, readable, settable, or fixed instead of the numbers.

       sensor_set_threshold mc-addr LUN sensor-num threshold-support threshold-enabled [value5 [value4 [...
       [value0]]]]

              Set the threshold support for a sensor.  It must be an analog sensor.  The threshold-support value
              is the same as the threshold access support value in the sensor SDR.  The threshold-enabled values
              is a string of ``0'' and  ``1''  characters  that  enable  the  6  corresponding  thresholds;  the
              rightmost  value  is  value  0,  the leftmost is value 5.  Optionally, the threshold values may be
              specified as their byte values.

              The threshold-support value may also be none, readable, settable, or fixed to make it a  bit  more
              readable.  The thresholds are:

              0 - lower non critical

              1 - lower critical

              2 - lower non recoverable

              3 - upper non critical

              4 - upper critical

              5 - upper non recoverable

       sensor_set_event_support mc-addr LUN sensor-num events-enable scanning event-support assert-support
       deassert-support assert-enabled deassert-enabled

              Set  the  event support of a sensor.  The events-enable will enable global events on the sensor if
              non-zero, otherwise they are disabled.  The scanning values set the scanning value for the sensor.
              The event-support value sets the event capabilities in  the  sensor,  this  is  the  same  as  the
              ``sensor  event  message control support'' value in the sensor SDR.  The assert-support, deassert-
              support, assert-enabled, and deassert-enabled are all  bitmasks  (a  string  of  ``0''  and  ``1''
              characters)  that set their corresponding sensor bit's capability to generate events (support) and
              whether it will generate events now (enabled).

              Note that all bitmasks have the rightmost digit as the zeroth bit, and the leftmost digit  as  the
              highest order bit.  Note that you must specify 15 bits here, even if you don't use all of them.

              Note  that  you  may use enable or disable in the events-enable field, and you may use scanning or
              no-scanning in the scanning field.

              For event-support, you may use per-state, entire-sensor, global or none instead of a number.

              For a threshold sensor, the values are:

              0
               - lower non-critical going low

              1
               - lower non-critical going high

              2
               - lower critical going low

              3
               - lower critical going high

              4
               - lower non-recoverable going low

              5
               - lower non-recoverable going high

              6
               - upper non-critical going low

              7
               - upper non-critical going high

              8
               - upper critical going low

              9
               - upper critical going high

              1
               - upper non-recoverable going low

              1
               - upper non-recoverable going high

              Note that the "lower going high" and "upper going low" values are not supported,  since  they  are
              simply stupid.

ATCA OEM COMMANDS

       These are for emulation of special ATCA capabilities.

       atca_enable
              The system is an ATCA system, enables the other ATCA capabilities.

              Note  that  you should do this *before* creating any MCs (this should really be first) because the
              MCs are set up a little differently for ATCA mode.  This causes the MCs to be able to handle PICMG
              commands properly, sets up 2 LEDs by default, and enables proper hot-swap handling, including  the
              blue LED.  By default the blue LED supports local control and the other LEDs do not and are red.

              In  ATCA  mode, to drive the hot-swap state machine, you should use sensor_set_bit_clr_rest to set
              the hot-swap state.

       atca_set_site hardware-address site-type site-number
              Sets the given values for an ATCA system, the values returned by the get address commands.

       mc_set_num_leds mc-addr count
              Set the number of ATCA LEDs the MC has.

       mc_set_power mc-addr power gen-event
              Set the ATCA power setting for the MC as its numeric value.  If gen-event is non-zero, generate an
              event for the change.

FILES

       /etc/ipmi/lan.conf

SEE ALSO

       ipmi_sim(1)

KNOWN PROBLEMS

       IPMI is unnecessarily complicated.  Hords of capabilities are not yet implemented.

AUTHOR

       Corey Minyard <cminyard@mvista.com>

OpenIPMI                                            06/26/12                                     ipmi_sim_cmd(5)