Artesyn ATCA-9405-Installation and Use

Chapter 8

Intelligent Peripheral Management Controller

8.1

Overview

The ATCA-9405 provides an intelligent hardware management system, as defined in the

AdvancedTCA® Base Specification (PICMG® 3.0; AMC.0). This system incorporates two IPMI controllers:





An Intelligent Platform Management Controller (IPMC) based on the BMR-H8S-AMCc® reference design from Pigeon Point Systems.

A Module Management Controller (MMC) residing at the RTM based on the BMR-AVR-

AMCm® reference design from Pigeon Point Systems.

Pigeon Point Systems IPM Sentry products are consistent with all current PICMG specifications as well as IPMI v1.5 compliant with specific 2.0 extensions.

8.2

Functional Overview

The ATCA-9405 implements all the standard Intelligent Platform Management Interface (IPMI) commands and provides hardware interfaces for other system management features such as

Hot Swap control, LED control, power control, and temperature and voltage monitoring. The

IPMC also supports a Keyboard Controller Style (KCS) based host interface for direct payload to

IPMI communication.

The ATCA-9405 provides the following features:

 HPM.1 firmware upgrades and crisis recovery





IPMI messaging

IPMI channels and sessions









Sensor Data Records and SDR Repository

FRU Inventory

Sensors

POST







Asynchronous Event Notification

U-boot Boot Configuration Parameter

Payload Boot Bank Selection

ATCA-9405 Installation and Use (6806800M71F) 109














Serial Line Selection

Built-in Terminal Server

Settable Graceful Shutdown Timeout

IPMI Hardware Watchdog Timer

Fail-safe

Local System Event Log (SEL)

The IPMC at the front board actslike a carrier IPMC. It retrieves the sensor information of the

MMC and creates an SDR repository that provides direct access to all sensors within the system. The IPMC is implemented as the managed FRU #0 and the MMC as FRU #1. All commands which are directed to the MMC are bridged by the IPMC.

The P2020 communicates with the IPMC using the Keyboard Controller Style (KCS) interface of the H8S. The FRU inventory, SEL events, and the SDR information is stored in external I2C

EEPROMS. This enables post-mortem analysis, when the system processor is disabled.

IPMB buffers on both the IPMB-0 busses are used to isolate a faulty IPMB bus from the backplane.

IPMC can access the registers within the FPGA and the Power CPLD via SPI bus. This enhances the capabilities of the IPMC. The FPGA is used to monitor the CPU status, the Payload reset cause, and to control the boot bank selection. The Power CPLD controls the enabling and monitoring of power good signals from all on-board power converters.

The functional block diagram of the ATCA-9405 IPMC/MMC system is shown in Figure 8-1 on page 111 .

110 ATCA-9405 Installation and Use (6806800M71F)


Figure 8-1 ATCA-9405 IPMC Block Diagram



8.3

Firmware Architecture

The IPMC and MMC firmware basically consists of three major parts:

 Boot loader





Hardware Abstraction Layer (HAL)

Application Layer

The boot loader maintains redundant copies of the firmware in flash. Each time the IPMI firmware is upgraded, a redundant copy of the current IPMI firmware is made in flash.

The Hardware Abstraction Layer (HAL) initializes H8S/ATMEL and makes all preparations necessary for running code written in C. The time management facility of the HAL provides a means for measuring time and detecting timeout conditions. The device drivers are responsible for implementing high-level interfaces to the hardware.

The Application layer is implemented as a multi threaded application. The main thread reads incoming messages/events from various inbound queues, processes these messages/events, and produces outgoing traffic to appropriate hardware interfaces.

The IPMC implements a number of subsidiary threads in addition, to serve RTM module discovery and e-keying management.



The Application layer can also operate in standalone mode intended to debug the payload without requiring a shelf manager.

Figure 8-2 Firmware Architecture

8.4

HPM.1 Components

All embedded software images are upgraded via HPM.1 protocol. The following are the HPM.1 components:

 IPMI bootloader









IPMI firmware

IPMI FRU information

U-boot firmware

FPGA



The HPM.1 components have different component properties due to its different physical implementation:

Table 8-1 HPM.1 Components

Components ID

IPMI bootloader

Payload cold reset required

1 no

0 yes IPMI firmware

IPMI FRU information

2 yes u-boot firmware

FPGA

5 yes

4 yes (even power cycle) yes no no no

Deferred activation support no

Comparism support no no no no no

Preparation support yes yes yes yes yes

Rollback/backup support no supported without backup command supported without backup command supported without backup command supported without backup command

Component name

IPMI B/L

IPMI F/W

IPMI F/I

PYLD F/W

PYLD FPGA



8.4.1

FPGA Firmware Upgrade

The FPGA device is a special HPM.1 component. Physically it consists of one working and one golden image. The working image can be overwritten and the golden image is write-protected.

Thus only the working component can be programmed.

Figure 8-3 FPGA Memory Map

If the FPGA determines that the working image is broken, it automatically selects the golden image to boot. This mechanism is close to HPM.1 automatic rollback. However, manual/automatic rollback can be performed only once (selection of the golden image is possible by writing "foo" data into the working image only. The FPGA bootloader determines the corrupt working image and jumps to the golden image). Note that this is a limitation, manual rollback to the old working image is not possible. Rollback means switching to the golden version.

A payload cold reset is not enough to execute a new FPGA component. In this case, a power cycle is required.



8.4.2

Payload Firmware Upgrade

The HPM.1 component u-boot is implemented with two SPI flashes, one active and one backup. The IPMC always writes to the backup flash. Automatic rollback is implemented via fail-safe architecture. For details about failsafe, see

Fail Safe Logic and Watchdog Support on page 142 .

The IPMC always upgrades the backup boot flash as intended. However, the HPM1 command

Activate Firmware

does not reboot the payload firmware unconditionally. Instead the blade can be rebooted gracefully to activate the firmware.

Executing two u-boot firmware upgrades without a payload reset does not upgrade both flashes for security reason (just the backup flash can be programmed).

Crisis recovery is fully supported. Two broken u-boot images can be reprogrammed via IPMI with the help of the ShMM.

8.4.3

IPMC Firmware Upgrade

The HPM1 component IPMI firmware stores its active and backup image within one physical flash. A small bootloader is used to either jump to the active or to the backup image depending on the boot flags indicating successful boot. The bootloader is implemented as HPM1 component; however there is no backup image.

The boot loader maintains redundant copies of the firmware in flash. Each time the IPMI firmware is upgraded, a redundant copy of the current IPMI firmware is made in flash. Once the new IPMI firmware is programmed, the IPMI controller resets itself to boot from the new image. The boot loader also validates new IPMI firmware images. If the power up of the IPMI controller is successful, then the actual image is made active and the previously active image is made backup. If the power up fails, the boot loader automatically recovers from crisis by switching to the first firmware image that has booted before.

The IPMI controller can be upgraded via KCS or IPMB interface. To ensure that the payload is not interrupted during IPMI firmware upgrade, the IPMI controller stores all operational information, such as e-keying, hot-swap state, last events to be queued, graceful shutdown timeout, latest pin settings, and so on in non-volatile storage.



8.4.4

Manual Rollback

To be able to switch from an active component to its rollback version, the HPM1 command

Initiate Manual Rollback

is enhanced with a 2 request data argument, to enable users to select the component which should be rolledback. This is done to overcome a limitation in the HPM1 specification. Using this command extension, you can initiate the component rollback without previous firmware upgrades.

8.4.5

Retrieving Versioning Information

Retrieving the actual and backup version of the components is possible without switching payload firmware boot banks. We recommend to use fcu for embedded firmware upgrade.

For example, the following terminal output illustrates the component versions: hayabusa(avh012):119 ./fcu -q -t8a --lan=192.168.42.50

********************[[[[[REPORT BEGIN]]]]]********************

OPERATION : Query

RESULT : SUCCESS

MESSAGE : Device : 0065CD-2003-hpm.1-ipmc

Part number : 123456789123456789123

Part revision :

BANK : A - Operational

Firmware Name : IPMI F/W

Firmware Version : 2.0.00000002

BANK : B - Rollback

Firmware Name : IPMI F/W


BANK : D - Operational

Firmware Name : IPMI B/L


BANK : G - Operational

Firmware Name : IPMI F/I




BANK : J - Operational

Firmware Name : PYLD FPGA

Firmware Version : 0.40.0000000F

BANK : K - Rollback

Firmware Name : PYLD FPGA


BANK : M - Operational

Firmware Name : PYLD F/W


BANK : N - Rollback

Firmware Name : PYLD F/W

Firmware Version : 1.0.0000000A

********************[[[[[ REPORT END ]]]]]********************

8.5

Sensors

This section describes the analog and discrete Sensors available at the ATCA-9405.

Table 8-2 on page 118 , lists the sensor identification numbers and information regarding the

sensor type, name, supported thresholds, assertion and deassertion information, and a brief description of the sensor purpose.

Table 8-2 ATCA-9405 Specific Sensors

Nr

0

Sensor

Name

Hot Swap

Carrier

Sensor Type

Hot Swap

0xF0

Event/

Reading

Type

Sensorspecific discrete

0x6F

Event

Data

Byte 1

0x4

0x5

0x6

0x7

0x0

0x1

0x2

0x3

Event Data

Byte 2

[7:4] = Cause

[3:0] = Previous

State

Event Data

Byte 3

FRU ID

Event

Threshold/

Description

0x0: M0

0x1: M1

0x2: M2

0x3: M3

0x4: M4

0x5: M5

0x6: M6

0x7: M7

Assertion

Deassertion Rearm

Assertion Auto



Table 8-2 ATCA-9405 Specific Sensors (continued)

Nr

1

Sensor

Name Sensor Type

HS_ARTM Hot Swap

0xF0

2

3

Version change

IPMB

Physical

Version

Change

0x2B

Physical

IPMB-0

0xF1

Event/

Reading

Type


0x6F


0x6F


0x6F

0x0

0x1

0x2

0x3

Event

Data

Byte 1

0x4

0x5

0x6

0x7

0x0

0x1

0x2

0x3

0x7

Event Data

Byte 2

[7:4] = Cause

[3:0] = Previous

State

Change type

[7:4] = Channel

Number

[3:0] = Reserved

Event Data

Byte 3

FRU ID

0xFF reading

5 12.0V

6 +5.0V

7 3.3V

8

9

3.3V

Mgmt

1.2V

10 1.05V

11 1.0V

Switch

4 BMC

Watchdog

Watchdog 2

0x23


0x6F

Voltage

0x02

Voltage

0x02

Voltage

0x02

Voltage

0x02

Voltage

0x02

Voltage

0x02

Voltage

0x02

Threshold

0x01

Threshold

0x01

Threshold

0x01

Threshold

0x01

Threshold

0x01

Threshold

0x01

Threshold

0x01

0x0

0x1

0x2

0x3

0x8

See IPMI Spec reading reading reading reading reading reading reading

0xFF threshold threshold threshold threshold threshold threshold threshold

Event

Threshold/

Description

0x0: M0

0x1: M1

0x2: M2

0x3: M3

0x4: M4

0x5: M5

0x6: M6

0x7: M7

0x7: Software or F/W change successful

Assertion

Deassertion Rearm

Assertion Auto

Assertion Auto

0x0: IPMB-A disabled,

IPMB-B disabled

0x1: IPMB-A enabled,

IPMB-B disabled

0x2: IPMB-A disabled,

IPMB-B enabled

0x3: IPMB-A enabled,

IPMB-B enabled

0x0: Timer expired

0x1: Hard Reset

0x2: Power Down

0x3: Power Cycle

0x8: Timer Interrupt unr uc lnr lc

Assertion

Assertion unr uc lnr lc unr uc lnr lc unr uc lnr lc unr uc lnr lc unr uc lnr lc unr uc lnr lc

Assertion/

Deassertion

Assertion/

Deassertion

Assertion/

Deassertion

Assertion/

Deassertion

Assertion/

Deassertion

Assertion/

Deassertion

Assertion/

Deassertion

Auto

Auto

Auto

Auto

Auto

Auto

Auto

Auto

Auto




Nr

Sensor

Name

12 1.0V

13

14 switch temp

P2020 temp

Sensor Type

Voltage

0x02

Temp

0x01

Temp

0x01

15 outlet temp

Temp

0x01

16 inlet temp Temp

0x01

17 IPMC

POST

18 BootBank

Management

Subsystem

Health

0x28

OEM

0xD2

19 Fw Prog

SP

System

Firmware

Progress

0x0F


0x6F


0x6F

Event/

Reading

Type

Threshold

0x01

Threshold

0x01

Threshold

0x01

Threshold

0x01

Threshold

0x01 digital

Discrete

0x06

Event

Data

Byte 1

Event Data

Byte 2 reading

0x0

0x1

0x0

0x0

0x1

0x2 reading reading reading reading

0xFF

0xFF

See IPMI Spec

20 OS Boot

SP

OS Boot

0x1F


0x6F

0x0

0x1

0x2

0x3

0x4

0x5

0x6

0xFF

Event Data

Byte 3 threshold threshold threshold threshold threshold

0xFF

0xFF

Event

Threshold/

Description unr uc lnr lc unr uc lnr lc unr uc lnr lc unr uc lnr lc unr uc lnr lc

0x0: Performance Met

0x1: Performance

Lags

Assertion

Deassertion Rearm

Assertion/

Deassertion

Auto

Auto Assertion/

Deassertion

Assertion/

Deassertion

Assertion/

Deassertion

Assertion/

Deassertion

Assertion

Auto

Auto

Auto

Auto

0x0: Boot Bank A Assertion Auto

See IPMI Spec

0xFF

0x0: System Firmware

Error


Hang


Progress

0x0: A: boot completed

0x1: C: boot completed

0x2: PXE boot completed

0x3: Diagnostic boot completed

0x4: CD_ROM boot completed

0x5: ROM boot completed

0x6: boot completed

Assertion

Assertion

Auto

Auto




Nr

Sensor

Name

21 Boot Err

SP

Sensor Type

Boot Error

0x1E

Event/

Reading

Type


0x6F

Event

Data

Byte 1

0x0

0x1

0x2

0x3

0x4

Event Data

Byte 2

0xFF

22 ATCA-

9405

IPMC

OEM

0xD5


0x6F

0x0

0x1

0x2

0x3

0x4

0x5

0x0

0x1

See IPMI Spec 23 Power

Good

24 Reset

Source

Power Supply

0x08

OEM

0xDA


0x6F


0x6F

0x0 0x00

25 PP #0

DDR1 temp

26 PP #0

DDR2 temp

27 PP #0

DDR3 temp

Temp

0x01

Temp

0x01

Temp

0x01

Threshold

0x01

Threshold

0x01

Threshold

0x01

ATCA-9405 Installation and Use (6806800M71F) reading reading reading

Event Data

Byte 3

0xFF

0xFF

[7] = Paload

IPMC reset

[6] = reserved

[5] = SPP

Hreset

[4] = Push

Button Reset

RTM

[3] = SW Prog

Watchdog

Reset

[2] = Pus

Button Reset

[1] = reserved

[0] = Power

GOOD Reset threshold unr uc unc

Event

Threshold/

Description

0x0: No Bootable media

0x1: Non-bootable diskette

0x2: PXE Server not found

0x3: Invalid boot sector

0x4: Timout waiting for user selection

0x0: Watchdog Reset

0x1: Software Reset

0x2: Power Failure

0x3: Hard Boot

0x4: Cold Boot

0x5: Warm Boot

0x0: Presence detected

0x1: Power Supply

Failure detected

0x0: Payload Reset detected. Cause delivered in Event

Byte 2/3

Assertion

Deassertion Rearm

Assertion Auto

Assertion

Assertion

Assertion

Auto

Auto

Auto

Assertion/

Deassertion

Auto threshold unr uc unc threshold unr uc unc

Assertion/

Deassertion

Auto

Assertion/

Deassertion

Auto

121



Nr

Sensor

Name

28 PP #0

DDR4 temp

29 PP #1

DDR1 temp

30 PP #1

DDR2 temp

31 PP #1

DDR3 temp

32 PP #1

DDR4 temp

33 SP CPU

Status

Sensor Type

Temp

0x01

Temp

0x01

Temp

0x01

Temp

0x01

Temp

0x01

Processor

0x07

Event/

Reading

Type

Threshold

0x01

Threshold

0x01

Threshold

0x01

Threshold

0x01

Threshold

0x01


0x6F

Event

Data

Byte 1

Event Data

Byte 2 reading

0x7

0x8

0xA reading reading reading reading

0xFF

34 PP #0 CPU

Status

Processor

0x07


0x6F

0x1

0x7

0x8

0xA

0xFF

35 PP #1 CPU

Status

Processor

0x07

36

37

38

FPGA

Status

-48v A

Volts

-48v B

Volts

Processor

0x07

Voltage

0x02

Voltage

0x02


0x6F

0x1

0x7

0x8

0xA

0xFF


0x6F

Threshold

0x01

Threshold

0x01

0x7

0x8

0xB

0xFF reading reading

Event Data

Byte 3 threshold threshold threshold threshold threshold

0xFF

0xFF

0xFF

0xFF threshold threshold

Event

Threshold/

Description unr uc unc unr uc unc unr uc unc unr uc unc unr uc unc

0x7: Processor

Presence detected

0x8: Processor disabled

0xA: ProcHot

0x1: Thermal Trip

0x7: Processor

Presence detected


0xA: ProcHot

0x1: Thermal Trip

0x7: Processor

Presence detected


0xA: ProcHot

0x7: Processor

Presence detected


0xB: Conf CRC Error unr uc lnr lc unr uc lnr lc

Assertion

Deassertion Rearm

Assertion/

Deassertion

Auto

Assertion/

Deassertion

Auto

Assertion/

Deassertion

Auto

Assertion/

Deassertion

Auto

Assertion/

Deassertion

Auto

Assertion Auto

Assertion

Assertion

Assertion

Auto

Auto

Auto

Assertion/

Deassertion

Assertion/

Deassertion

Auto

Auto




Nr

Sensor

Name

39 -48v

Amps

40 HoldUp

Cap Volts

41 PWR

Entry

Temp

42 PWR

Entry

Status

Sensor Type

Current

0x03

Voltage

0x02

Temp

0x01

OEM

0xD7

Event/

Reading

Type

Threshold

0x01

Threshold

0x01

Threshold

0x01


0x6F

Event

Data

Byte 1

Event Data

Byte 2 reading

0x0 reading reading

43 FPGA

Watchdog

OEM

0xCF


0x6F

0x1

Event Data

Byte 3 threshold threshold threshold

Event

Threshold/

Description

No Thresholds unr uc lnr lc unr uc unc

Synchor Pwr Entr

Module:

[6] = VOUT_low

[5] = Hotswap

[4] = Holdup

[2] = Alarm

[1] = Enable_B

[0] Enable_A

Emerson Pwr Entry

Module:

[7] = DIG_Fault

[6] =

HUCapEngage

[5] =

Hotswap_Enable

[4] =

HUCap_Switch

[3] =

Alarm_Control

[1] = DIG_Alarm

[0] =

Sec_MCU_Fault

All other bits are reserved

See IPMI Spec 0xFF

[7:6] = Pwr

Entry Module

0 = Synchor

1 = Emerson

Emerson Pwr

Entry Module:

[2] =

DIG_EnableA

[1] =

DIG_EnableB

[0] =

Mcu_Fault

All other bits are reserved

0x0: Pwr Entry

Module Status

Change detected

0x1: Hard Reset

Assertion

Deassertion Rearm

Auto

Assertion/

Deassertion

Assertion/

Deassertion

Auto

Auto

Assertion Auto

Assertion Auto




Nr

Sensor

Name

44 CPLD

PwrF SP

Sensor Type

OEM

0xE0

Event/

Reading

Type


0x6F

Event

Data

Byte 1

0x4

0x5

0x6

0x7

0x0

0x1

0x2

0x3

Event Data

Byte 2

45 CPLD

PwrF PP0

OEM

0xE1

46 CPLD

PwrF PP1

OEM

0xE2


0x6F

0x4

0x5

0x6

0x7

0x0

0x1

0x2

0x3


0x6F

0x4

0x5

0x6

0x7

0x0

0x1

0x2

0x3

Event Data

Byte 3

Event

Threshold/

Description

0x0: 12V Power Good

0x1: 5.0V/3.3V Power

Good


Good


Good

0x4: 1.0 Power Good

Switch

0x5: 1.2 Power Good

FPGA

0x6: 1.5V/1.05V

Power Good ETH SP

0x7: reserved

0x0: 3.3V Power Good

PP2


PP2

0x2: 1.00V Power

Good GPP PP2

0x3: VQLM Power

Good PP2

0x4: VDDR Power

Good PP2

0x5: reserved

0x6: Reserved

0x7: reserved


PP1


PP1

0x2: 1.00V Power

Good GPP PP1

0x3: VQLM Power

Good PP1

0x4: VDDR Power

Good PP1

0x5: reserved

0x6: Reserved

0x7: reserved

Assertion

Deassertion Rearm

Assertion Auto

Assertion

Assertion

Auto

Auto




Nr

Sensor

Name

47 CPLD

PwrF

IPMC

48 CPLD

PwrF

FPGA

Sensor Type

OEM

0xE3

OEM

0xE4

Event/

Reading

Type


0x6F


0x6F

Event

Data

Byte 1

0x4

0x5

0x6

0x7

0x0

0x1

0x2

0x3

Event Data

Byte 2

0x0

0x1

0x2

0x3

0x4

0x5

0x6

0x7

49 ADT7461

#0 temp

50 PP #0

Temp

51 ADT7461

#1 temp

52 PP #1

Temp

53 48V A

Supply

54 48V B

Supply

Temp

0x01

Temp

0x01

Temp

0x01

Temp

0x01

Power Supply

0x08

Power Supply

0x08

Threshold

0x01

Threshold

0x01

Threshold

0x01

Threshold

0x01


0x6F


0x6F

0x0

0x1

0x0

0x1 reading reading reading reading

See IPMI Spec

See IPMI Spec threshold threshold threshold threshold

0xFF

Event Data

Byte 3

0xFF

Event

Threshold/

Description

0x0: RTM Power

Good

0x1: RTM MGMT

Power Good

0x2: RTM PP Power

Good

0x3: RTM PP Fault

0x4: TCAM Power

Good

0x5: reserved

0x6: Reserved

0x7: reserved

0x0: Glue Logic FPGA

Done

0x1: Glue Logic FPGA

Init

0x2: CONC CRC ERR

0x3: FPGA Done RTM

0x4: FPGA INIT_N

RTM

0x5: CONF CRC ERR

RTM

0x6: Reserved

0x7: reserved unr uc unc

Assertion

Deassertion Rearm

Assertion Auto

Assertion Auto

Auto unr uc unc unr uc unc unr uc unc

Assertion/

Deassertion

Assertion/

Deassertion

Assertion/

Deassertion

Assertion/

Deassertion

Assertion/

Deassertion

Auto

Auto

Auto

Auto 0x0: Presence detected

0x1: Power Supply

Failure detected

0x0: Presence detected

0x1: Power Supply

Failure detected

Assertion/

Deassertion

Auto




Nr

Sensor

Name

55 Fw Prog

PP #0

Sensor Type

System

Firmware

Progress

0x0F

Event/

Reading

Type


0x6F

Event

Data

Byte 1

0x0

0x1

0x2

Event Data

Byte 2

See IPMI Spec

56 Fw Prog

PP #1

System

Firmware

Progress

0x0F


0x6F

0x0

0x1

0x2

See IPMI Spec

Event Data

Byte 3

See IPMI Spec

See IPMI Spec

Event

Threshold/

Description


Error


Hang


Progress


Error


Hang


Progress

Assertion

Deassertion Rearm

Assertion Auto

Assertion Auto

8.5.1

Firmware Progress, OS Boot, and Boot Error Sensor

The IPMC firmware provides a Firmware Progress, OS Boot, and Boot Error Sensor to enable SP payload firmware and SP payload OS to report boot progress and OS Boot via IPMI event messages.

The firmware progress sensor is of type 0x0F (System Firmware Progress) and is used to pass payload status information to the IPMC, which is then logged to the SEL (both local and remote). While the payload is booting, the payload logs events to the Firmware Progress

Sensor to indicate the progress of the boot process.

The boot error sensor is of type 0x1E (Boot Error) and is used to pass boot failure information to the IPMC, which is then logged to the SEL.

The OS Boot sensor is of type 0x1F (OS Boot) and is used to inform the IPMC when the operating system has completed its boot up sequence.

8.5.2

Boot Bank Supervision Sensor

The boot bank supervision sensor is intended to always give the actual boot bank, from which the payload has booted last. The boot bank information received from this sensor may differ from the boot bank selection performed, in case if the boot bank selection has changed after the payload has booted.



8.5.3

POST Results Sensor

The POST results sensor is of type 0x28 (Management subsystem health), which returns information on whether the power-on self-test (POST) of the IPMI firmware passes or not. For more information on POST, see

POST on page 130 .

8.5.4

Power Good Sensor

The Payload Power sensor is of type 0x08 (Power Supply) which reports the state of the payload power. Since the Digital Power Monitor can disable payload power on its own due to a faulty

DC-DC converter, the IPMC monitors the health and reports an event when the Digital Power

Monitor disables power on its own. As a result, the IPMC proactively transitions the IPMC from

M4 to M6 (to M1) with a cause code of 0x09 (Unexpected Deactivation). This automatic shutdown is meant to keep the IPMCs state in-line with the payload state.

8.5.5

Power Interface Sensors

A PowerOne Power input module (Synqor) is used for the 48v to 12v conversion monitoring.

The Synqor includes sensors which monitor the shelf's 48v input feeds current, hold-up capacitor voltage, on-board temperature, and internal status. The status sensor reading can be

decoded as shown in Table 8-3 on page 127 .

Table 8-3 Status Sensor's Sensor Reading

Bit 7

Bit 6

Bit 5

Bit 4

Bit 3

Bit 2 reserved 0

-48v Output Under

Voltage Alarm

0: Output Voltage is below threshold

1: Output Voltage is above threshold

Hot-swap Switch State 0: Hot-swap switch is off

1: Hot-swap switch is on

Holdup Switch State 0: Holdup Cap is not connected to -48V

Out

1: Holdup Cap is connected to -48V Out

Reserved

Alarm Signal State

0

0: Primary side Alarm is not set

1: Primary side Alarm is set



Table 8-3 Status Sensor's Sensor Reading (continued)

Bit 1

Bit 0

Voltage Feed B Enabled 0: Enable B is Disabled

1: Enable B is Enabled

Voltage Feed A

Enabled

0: Enable A is Disabled

1: Enable A is Enabled

8.5.6

Reset Cause Sensor

This sensor is implemented to monitor the last payload reset cause, such as hard reset, front panel reset, and so on. The IPMC evaluates the Reset Cause Register within the Glue Logic

FPGA.

8.5.7

Presence Sensors

These sensors are implemented for each SFP as well as for the cpus and the FPGAs. These sensors provide the presence and absence status. Also, the PP #1 and PP #0 specific sensor can assert TEMP ALERT, the FPGAs can assert CONF_ERROR.

8.5.8

Voltage and Temperature Sensors

Voltage and temperature sensors are available at the front blade and at the RTM.

Table 8-4 Voltage and Temperature Sensor Devices

I2C address I2C bus

0x5E IPMC private

Domain

Front blade

0x92

0x96

0x9C

IPMC private

IPMC private

IPMC private

Front blade

Front blade

Front blade

Purpose

48V Feed A

48V Feed B

Current

Holdup

Temp

Status

Temperature Switch

Temperature P2020

Temperature outlet

Device

Power Entry Module

LM75

LM75

LM75



Table 8-4 Voltage and Temperature Sensor Devices (continued)

I2C address I2C bus

0x9E IPMC private

Int ADC IPMC private

0x98

0x98

0xA0

0xA2

0xA4

0xA6

0xA0

0xA2

0xA4

0xA6

0x90

0x92

0x94

IPMC private2

IPMC private2

IPMC private2

IPMC private2

IPMC private2

IPMC private2

IPMC private2

IPMC private2

IPMC private2

IPMC private2

MMC

MMC

MMC

Domain

Front blade

Front blade

Front blade

Front blade

Front blade

Front blade

Front blade

Front blade

Front blade

Front blade

Front blade

Front blade

RTM

RTM

RTM

Purpose

Temperature inlet

Device

LM75

12V

5V

3.3V Mgmt

3.3V

1.2V

1.05V

1.0 V Switch

1.0V

Temperature cpu PP0

H8S ADC

Temperature cpu PP1

Temperature of PP0

DIMM

Temperature of PP0

DIMM

Temperature of PP0

DIMM

Temperature of PP0

DIMM

Temperature of PP1

DIMM

Temperature of PP1

DIMM

Temperature of PP1

DIMM

Temperature of PP1

DIMM

Temperature Inlet

ADT7461

ADT7461

LM75

Temperature Outlet LM75

Temperature P220 cpu MAX1617



Table 8-4 Voltage and Temperature Sensor Devices (continued)

I2C address I2C bus

Int ADC MMC

0x94 MMC

Domain

RTM

Mezzanine

Card

Purpose

12V

3.3V

1.8V

0.9V

Temperature

Device

ATMEL ADC

LM75

8.6

POST

POST is executed at IPMC startup when either a hard (blade physically extracted/reinserted) or cold (IPMI Command) reset is performed. POST verifies the functionality of SRAM, IPMB-0,

EEPROM data storage, FRU-Information, and all devices (primarily sensors) attached to the

IPMCs private master-only I2C bus. A detailed description of POST tests are as follows:

130









FRU-Information - This test verifies that the FRU-Information is readable from the external

EEPROM where it is stored. Once read, each section's checksum is computed and validated.

IPMB-0 - This test reads the ready signals coming from the I2C buffers. This test passes as long as both ready signals are active and both IPMB busses (IPMB-A and IPMB-B) are enabled.

EEPROM - This test verifies that the EEPROM contents are readable via I2C. Since the IPMC stores its runtime and persistent data here, proper operation is crucial.

Master-Only I2C - This test verifies that all expected devices attached to the master-only

I2C bus are accessible.

The IPMC contains a sensor of type 0x28 (Management Subsystem Health) which reports the results of the IPMCs POST. If all tests pass, then the sensor reads Performance Met; otherwise it reports Performance Lags. If POST fails, the POST sensor generates an event to the SEL with the Performance Met/Performance Lag offsets.

To obtain results of POST, the IPMC supports the IPMI standard command Get Self Test

Results

with OEM extensions. This IPMI command can be run at anytime.

ATCA-9405 Installation and Use (6806800M71F)


8.7

FRU Inventory

The ATCA-9405 implements two intelligent FRU's (IPMC and MMC).

Every FRU provides its own FRU information (serial, part, MAC addresses). Depending on the presence of a module, its FRU information is visible or not.

Table 8-5 FRU Information and SEL at EEPROM Storage

I2C Address

0xA2

0xA6

Device internal

I2C bus

IPMC

IPMC

MMC

Domain

Front blade

Front blade

RTM

Purpose

FRU Information

SEL

FRU Information

The FRU of the RTM is not hot-swappable. This is important to ensure that the system management application (HPI-B) does not have to deal with dynamic FRU population.

Dynamic inventory data of the SFPs is read at OS level.

The MAC addresses of an FRU are stored within the multi-record area of the FRU information.

Emerson Network Power has defined a MAC address multi-record for this purpose, for more

information see MAC Address FRU OEM records on page 131 .

8.7.1

MAC Address FRU OEM records

The Emerson Network Power MAC Address record is specified in

Table 8-6 on page 131 .

Table 8-6 Emerson ECC MAC Address Record

Offset

0

1

2

Length

1

1

1

Description

Record Type ID. A value of C0h (OEM) is used for Emerson ECC OEM records.

End of List/Version

[7] End of List. Set to 1b for the last record

[6:4] Reserved. Write as 000b.

[3:0] Record format version. Write as 2h.

Record Length



Table 8-6 Emerson ECC MAC Address Record (continued)

8

9

10

11

6

7

4

5

Offset

3

1

1

1

N*9

1

1

1

1

Length

1

Description

Record Checksum (zero checksum)

Header Checksum (zero checksum)

LSB of Manufacturer ID. Write as CDh.

Second Byte of Manufacturer ID. Write as 65h.

MSB of Manufacturer ID. Write as 00h.

Motorola Record ID. 01h for Emerson ECC MAC Address Record.

Record Format Version. 01h for this specification.

Number of MAC Address Descriptors (N).

Emerson ECC MAC Address Descriptors. See

Table 8-7 on page 132 , Emerson

ECC MAC Address Descriptor.

Table 8-7 Emerson ECC MAC Address Descriptor

Offset

0

1

2

3

Length

1

1

1

6

Description

Interface Type. See


Length Identifier (for example: 6 =

48 bit MAC, 8 = WWPN)

MAC Address Count (M) (specifying a continuous pool of MAC addresses starting with the MAC address specified in this descriptor)

M = 1: this descriptor specifies one

MAC address

M > 1: this descriptor specifies a pool of MAC addresses with M count

MAC Address. (Canonical form, the

LSB (least significant bit) first.



Table 8-8 Interface Type Assignments

08h

09h

10h

11h

04h

05h

06h

07h

Interface type

01h

02h

03h

11h - FFh

Description

ATCA Base Interface

ATCA Base Interface

Front/Rear Panel

Mezzanine Module

Serial over LAN (SOL)

Fibre Channel / WWPN

AMC/MicroTCA Common Options Region

AMC/MicroTCA Fat Pipe Region

AMC/MicroTCA Extended Fat Pipe Region

ATCA Update Channel

Multi-type (Base, Fabric, and Update channel (or two types of it) are connected to a onboard switch) reserved

The SP provides 12 MAC addresses in its FRU information:





2 x P2020 to the switch

1 x P2020 to the front







1 x Terminal Server

3 x 2 CN6880 to the switch

1 x 2 CN6880 to the front

8.8

Reset and Power Domains

The ATCA-9405 provides the following FRU instances:





FRU #0: front board management and switch

FRU #1: RTM



Each FRU instance can be reset separately. Each FRU instance is implemented as a managed

FRU having its own hot-swap state machine and FRU information.

8.9

Power Management

The ATCA-9405 provides three power levels to be selected by the ShMM. The IPMC selects the cavium core frequency of both processors to manage blade power consumption. At Power

Level 1, both processors are configured for 800MHz only, at power level 2, both processors run at 1000MHz, and at power level 3, both processors run at their maximum speed.

The power levels to be provided by the IPMC depend on the cavium cpus version and capabilities. The IPMC is evaluating the FRU information of the board. The IPMC provides just two power levels in case the Cavium cpus equipped support just 1000MHz.

Table 8-9 Power Levels

2

3

Power level

1

Cavium CPU frequency

[MHz]

800

1000

1200

Power consumption

[watts]

200

300

400

8.10 U-Boot Boot Configuration Parameters

The IPMC stores u-boot environment variables, which match the variables saved in the nonvolatile storage of P2020. When u-boot starts, it first copies its environment parameter set from its NVRAM into memory. Then it reads parameters from the IPMC, adds new parameters to the parameter set in memory, and deletes or modifies existing ones. During runtime, only the memory copy of the parameter set is used.

The parameters stored in the IPMC are not automatically saved back to the NVRAM of u-boot.

The IPMI command used to manage the boot configuration variables is Set/Get System

Boot Options

together with parameter #100.

The advantage of storing u-boot environment variables in IPMC non-volatile memory is that those can be set by the ShMM or across HPI applications as well. The system manager decides from which boot device the blade should boot from.



The boot configuration parameters are stored as sets of <parameter name> and <value> pairs. Thus, they can be easily enhanced and there are no dependencies between different versions of IPMC firmware and payload firmware. The IPMC provides a set of boot configuration parameters and the payload firmware initializes those parameters.

Figure 8-4 IPMC Boot Parameter Storage Configuration Flow



The boot options should be stored as a sequence of zero terminated strings. Table 8-10 on page 136 , describes in detail the format of the boot options to be used when setting or reading

the System Boot Options parameter #100.

Table 8-10 IPMC Boot Parameter Storage Format

Byte

0-1

Description

Number of bytes used for boot parameters (LSB first)

2-n

N+1 - n+2

The number of bytes must be calculated and written into these two bytes by the software which writes into the storage area. The values 0x0000 and 0xFFFF indicate that no data has been written to the storage area. If you are reading from the storage area and you find any of these two values, your software assumes that no boot firmware boot options have previously been written to the storage area.

Boot Parameters data

The boot parameters are stored as ASCII text with the following general format: <name>=<value>, where all name/value pairs are separated by a zero byte. The end of the boot parameter data is indicated by two zero bytes. Allowed and supported name/value pairs are blade specific.

16 bit checksum over the boot parameters data section (LSB first)

When writing or reading from the storage area, you can only read or write chunks of 16 bytes at a time. For this reason, the IPMC memory is divided into numbered blocks of 16 bytes which need to be addressed individually. For this purpose the block selector field in the request data field is used.

8.11 Asynchronous Event Notification

To inform payload applications about graceful shutdown/reboot requests, the FRU

Activate (Deactivate) and FRU Control (Graceful Reboot) command message is routed as a LUN2 message to payload interface.

If the payload application has registered to these commands via OpenIPMI library, it gets informed and can take all necessary actions before the payload is gracefully rebooted/shutdown.



Graceful Reboot and Graceful Shutdown is also communicated to the Intel CPU via internal communication channel.

8.12 Serial Line Selection

All payload serial interfaces (COM #0 of PP #0, PP #1, SP) of the ATCA-9405 can be redirected to the terminal server. It is even possible to redirect two serial interfaces to the terminal server in parallel. Thus it is possible to have one terminal server specific channel configured to redirect the SP serial interface and the second channel configured to redirect either the serial interface of the first octeon, or of the second one. It is not possible to have both serial interfaces of the octeon redirected to the terminal server.

Note that the serial instance 0 of the terminal server is reserved for the serial interface of the SP and instance 1 for either PP #0 or PP #1.

There are three connectors at the front panel. One connector (serial instance 0) is used to share the serial interface of the SP and the IPMC and the other two (serial instance 1 and 2) are used to connect to the serial interfaces of the cavium cpus.

In addition, there is a serial connector at the RTM. Either the serial interface of the first octeon or the serial interface of the second octeon is redirected to this interface.



There is a combined board serial line selection available. The serial line selection is implemented via OEM IPMI command.

Figure 8-5 IPMC Serial Line Selection



The serial line selection is implemented non-persistently to ensure that the serial interfaces always can be accessed easily after power-up. By default, the serial line selection selects the front-panel connectors after power-up.

8.13 Built-in Terminal Server

The ATCA-9405 provides a built-in terminal server (TS) based on the embedded controller

MCF5223X ColdFire from Freescale. All serial payload data can be accessed via the Terminal

Server.

The IPMC selects the serial source to be routed to the terminal server and configures the TS specific parameters via a separate communication interface (I2C). The parameters for the network interface of the terminal server are:





MAC address

IP addresses







Net mask

Gateway IP address

Baud rate

Depending on the serial line selection, either the payload serial interface of the SP and the serial interface of the first cavium cpu, or the payload serial interface of the SP and the serial interface of the second cavium cpu can be accessed both at a time via telnet protocol.

The Shelf Manager configures the TS using the IPMI commands Set/Get LAN Configuration

Parameters and Set/Get SOL Configuration parameter.

There are two dedicated TS OEM channels available (channel = 0x05, 0x06) that are defined to be used with both Base Interfaces.

The built-in terminal server is not implemented with the use of RMCP packets. Furthermore there is no SOL client required to establish a telnet session.



Due to the fact, that there is no authenticated IPMI communication to the IPMC, the channels are implemented IPMI session-less. For TS channel properties, see

Table 8-11 on page 140

.

Table 8-11 TS Channel Information

Channel Protocol Type

Channel Medium Type

Session support

Vendor ID

Auxiliary Channel Info

OEM Protocol

OEM

Session-less

EMERSON IANA

0x1C

0x60

0x00

0xCD 0x65 0x00

8.13.1 Evaluating the Version of the Telnet Server Firmware

The firmware version of the terminal server can be retrieved with the IPMI command Get SOL

Configuration,

executed with the OEM parameter 192.

ipmicmd -k "0 <ipmb slot> 0 c 22 5 C0 0 0" smi 0

8.13.2 Establishing a Telnet Session

SOL client is not required to establish a serial connection to the ATCA-9405 payload serial line via network Base Interface #1 or #2. The TS can be configured very easily via IPMI commands.

To establish a telnet session at OEM channel 5, follow the configuration steps executed from the ShMM first (steps in bold are mandatory if IP address of TS is not default):

1. This step is not required if LAN parameters are not modified (step 2 to 4 is not executed).

To enable LAN configuration, the Set_In_Progress flag must be set: ipmicmd -k "0 <ipmb slot> 0 c 1 5 0 1" smi 0

2. This step is not required if the IPMC default is used: default IP address 172.17.0.220.

To set the IP address, execute the following command: ipmicmd -k "0 <ipmb slot> 0 c 1 5 3 <ip addr>" smi 0 for example, if the IP addresss is 192.168.1.100, then the command is:

ipmicmd -k "0 <ipmb slot> 0 c 1 5 3 c0 a8 01 64" smi 0



Note: This value is stored internally and sent to the TS when the SOL_ENABLE flag is set with the IPMI command Set SOL Configuration. This IP address is invalidated by clearing the

SOL_ENABLE

flag.

3. This step is not required if the IPMC default is used: default subnet mask 255.255.0.0

To set the subnet mask, execute the following commands: ipmicmd -k "0 <ipmb slot> 0 c 1 5 6 <subnet mask>" smi 0

4. This step is not required if the IPMC default is used: default gateway IP address

172.17.0.254

To set the gateway IP address, execute the following commands: ipmicmd -k "0 <ipmb slot> 0 c 1 5 c <ip addr>" smi 0

5. To enable SOL configuration, the Set_In_Progress flag must be set ipmicmd -k "0 <ipmb slot> 0 c 21 5 0 1" smi 0

6. This step is not required if the IPMC default is used: default baud rate is 9600

To set the non-volatile bit-rate, execute the following command: ipmicmd -k "0 <ipmb slot> 0 c 21 5 5 <bit-rate>" smi 0

Note: bit-rate 6 = 9600baud, 7 =19.2kbaud, 8=38.4kbaud

7. To set the SOL_ENABLE flag, execute the following commands: ipmicmd -k "0 <ipmb slot> 0 c 21 5 1 1 smi 0

Note: Telnet session is not possible without enabling the SOL.



8. To redirect the serial line of the SP from front connector to the TS, execute the following command: ipmicmd -k "0 <ipmb slot> 0 2e 15 cd 65 0 3 0 4" smi 0

9. Open the telnet session telnet <IP address>

To configure channel 6 of the terminal server, execute command in steps 1-7 again, but replace the channel argument from 5 to 6 and do not use the same IP address. Two telnet sessions are possible at the same time.

To redirect the serial line of the PP #0 from front connector to the TS, execute the following command: ipmicmd -k "0 <ipmb slot> 0 2e 15 cd 65 0 3 0 0" smi 0

To redirect the serial line of the PP #1 from front connector to the TS, execute the following command: ipmicmd -k "0 <ipmb slot> 0 2e 15 cd 65 0 3 1 1" smi 0

For more details on terminal server, refer

Built-in Terminal Server on page 139 .

8.14 Fail Safe Logic and Watchdog Support

The IPMC firmware supports automatic fail safe logic for the payload firmware on the SP.

8.14.1 SP BMC Watchdog

When the IPMC transitions to M4 (Active), the IPMC automatically enables the BMC Watchdog with the following settings:

Timer Use: BIOS/POST

Timer Actions: Hard Reset

Timer Countdown Value: 30 Seconds

SP firmware (U-Boot) must disable or reset the BMC Watchdog within 30 seconds of payload activation. If there is a failure in disabling or resetting the BMC Watchdog, then the IPMC performs a payload reset.



The IPMC automatically switches the boot banks on SP, provided the failsafe logic is enabled via

OEM command.

When the fail safe logic is triggered as a result of the BMC Watchdog timeout, a System

Firmware Progress sensor SEL event is logged as follows:

Event Data Byte 1: 0xA1 (System Firmware Hang)

Event Data Byte 2: 0x00 (SPP CPU)

Event Data Byte 3: 0xXX (Failed Boot Bank ID: 0=Bank A; 1=Bank B)

Fail Safe logic makes three attempts to boot the payload successfully. After three attempts, the fail safe logic is automatically disabled and the boot bank is left in the original state (before the payload was booted). In addition, this logic is only enabled upon a hard reset of the IPMC firmware, a cold or warm IPMC reset does not enable this functionality.

Fail Safe is disabled by default and can be enabled with the IPMI command Set Feature

Configuration

. For more information, see Set Feature Configuration Command on page 149 .

8.15 Payload Interface

The IPMC communicates with the payload via its host Keyboard Style Controller (KCS) interface. The Renesas H8S provides support for LPC/KCS in hardware. KCS is defined by the

IPMI 1.5 Specification.

8.16 Payload Boot Bank Selection

The ATCA-9405 provides redundant payload boot flashes for crisis recovery. The IPMC manages from which boot bank the payload should boot from.



The IPMI command Set System Boot Options together with the parameter #96 is used to specify the payload boot-bank from which the payload should boot from.

Figure 8-6 Payload Boot Bank Selection

8.17 Settable Graceful Shutdown Timeout

The IPMI command Set System Boot Options together with the parameter #98 is used to specify the timeout for Graceful Shutdown. The value of the graceful shutdown timeout is specified for both CPUs.

By default, this value is set to 10 sec.



8.18 FPGA Health Check

During normal operation the health of the FPGA is periodically checked by dedicated FPGA internal logic. In the case of a CRC error, the signal CONF_CRC_ERR is asserted to inform the system that FPGA logic may be corrupted. Such an error is handled like a power failure.

The IPMC provides a dedicated FPGA Status sensor indicating a CONF_CRC_ERROR. The ShMM is informed about CONF_CRC_ERROR with an event. In such a case the blade is shutdown by the IPMC.

8.19 Local System Event Log (SEL)

The ATCA-9405 IPMC supports a local SEL. The local SEL size is configured to hold 1K entries in a circular FIFO buffer. Once the circular buffer is full, the next SEL entry overwrites the oldest SEL entry in the buffer. All events are automatically logged locally to the local SEL, before being passed to the SEL of the Shelf. This includes all events that occur from the local MMC.

To support the local SEL, a software emulated RTC (Real Time Clock) is enabled which upon startup requests the local time from the shelf manager by sending an IPMI standard command

Get SEL Time

. Once the initial time is received, the IPMC maintains the time locally and no further synchronization is performed with the shelf manager.

8.20 IPMI Hardware Watchdog

For crisis recovery purpose, the IPMI building block provides a hardware watchdog. The IPMI firmware is reset, if it does not trigger the watchdog.



8.21 Emerson OEM Command Set

In addition to standard commands defined by IPMI and PICMG specifications, Emerson defines a set of OEM commands to extend the features that Emerson products may have. Many features are product-specific; therefore, not all OEM commands are implemented on a product. Refer to the document of the particular product for the complete command set implemented on the product.

Table 8-12 Emerson OEM Commands

Command

Set Serial Output

Get Serial Output

Set Feature Configuration

Get Feature Configuration

CMD

15h

16h

1Eh

1Fh

Defined in

2.20.1

0

2.20.3

2.20.4

Emerson OEM request messages uses NetFn 2Eh and the response messages uses NetFn 2Fh.

8.21.1 Set Serial Output Command

This command allows you to set the serial output source for a particular serial port connector.

Table 8-13 Set Serial Output Command

Byte

Request

Data

1

2

3

Data field

LSB of Emerson IANA Enterprise Number. A value of

CDh is used.

2nd byte of Emerson IANA Enterprise Number. A value of 65h is used.

MSB of Emerson IANA Enterprise Number. A value of

00h is used.



Table 8-13 Set Serial Output Command (continued)

Byte

4

Response

Data

5

6

1

2

3

4

Data field

Serial connector type:

0 = Front panel connector

1 = RTM panel connector

2 = reserved

3 = Onboard device (that is, Terminal Server)

All other values are reserved.

Serial connector instance number. A sequential number starts from zero.

Serial output selector. For more information, see


Completion Code

LSB of Emerson IANA Enterprise Number. A value of

CDh is used


MSB of Emerson IANA Enterprise Number. A value of

00h is used.

The following serial output selector assignments can be mapped to a serial connector type and instance:

Table 8-14 Serial Output Selector Assignments

Serial Output Source

Payload serial interface PP #0

Payload serial interface PP #1

IPMC serial interface 1 reserved

Payload serial interface SP reserved

Serial Output Selector

00h

01h

02h

03h

04h

05h - ffh



IPMI command examples:

 To set the serial COM #0 of SP to the front connector instance 0 (default): ipmicmd -k "0 <ipmb slot> 0 2e 15 cd 65 0 0 0 4" smi 0





To set the IPMC serial to front connector instance 0: ipmicmd -k "0 <ipmb slot> 0 2e 15 cd 65 0 0 0 2" smi 0

To set the serial COM #0 of PP #0 to the front connector instance 1 (default): ipmicmd -k "0 <ipmb slot> 0 2e 15 cd 65 0 0 1 0" smi 0













To set the serial COM #0 of PP #1 to the front connector instance 2 (default): ipmicmd -k "0 <ipmb slot> 0 2e 15 cd 65 0 0 2 1" smi 0

To set the serial COM #0 of SP to the RTM connector instance 0: ipmicmd -k "0 <ipmb slot> 0 2e 15 cd 65 0 1 0 2" smi 0

To set the serial COM #0 of SP to the terminal server # 0: ipmicmd -k "0 <ipmb slot> 0 2e 15 cd 65 0 3 0 4" smi 0

To set the serial COM #0 of SP to the terminal server #1: ipmicmd -k "0 <ipmb slot> 0 2e 15 cd 65 0 3 1 4" smi 0

To set the serial COM #0 of PP #0 to the terminal server #0: ipmicmd -k "0 <ipmb slot> 0 2e 15 cd 65 0 3 0 0" smi 0

To set the serial COM #0 of PP #1 to the terminal server #1: ipmicmd -k "0 <ipmb slot> 0 2e 15 cd 65 0 3 1 1" smi 0

8.21.2 Get Serial Output Command

This command allows you to determine which serial output source goes to a particular serial port connector.

Table 8-15 Get Serial Output Command

Byte

Request

Data

1

2

3

Data field

LSB of Emerson IANA Enterprise Number. A value of CDh is used.


MSB of Emerson IANA Enterprise Number. A value of 00h is used.



Table 8-15 Get Serial Output Command (continued)

Byte

4

Response

Data

5

1

2

3

4

5

Data field

Serial connector type:

0 = Front panel connector

1 = RTM panel connector

2 = reserved

3 = On-board device (that is, Terminal Server, P4080 COM #1 to Intel

COM #0)

All other values are reserved.

Serial connector instance number. A sequential number starts from zero.

Completion Code




Serial output selector. For more information, see

Table 8-14 on page

147

.

8.21.3 Set Feature Configuration

This command is used to enable/disable features within the IPMC during runtime.

Table 8-16 Set Feature Configuration Command

Byte

Request

Data

1

2

3

4

Data field




Feature Selector. For more information, see




Table 8-16 Set Feature Configuration Command (continued)

Byte

5

6

Response

Data

1

2

3

4

Data field

Feature Configuration.

00h = disabled (Feature Selector = E0)

01h = enabled (Feature Selector = E0)

02h = restore factory default (golden) (Feature Selector = E1)

C0h = reload selected FPGA image (Feature Selector = E1)

03h - FFh = reserved

Persistency / Duration

00h = volatile. Actual duration depends on implementation.


Completion Code is Generic, plus the following command-specific completion codes:

80h = feature selector not supported.

81h = feature configuration not supported

82h = configuration persistency / duration not supported




Table 8-17 on page 150 , provides the feature set supported with ATCA-9405:

Table 8-17 Feature Selector Assignments

Feature Selector

E0h

E1h

Description

FAILSAFE Function

Enable/Disable

Select FPGA flash



8.21.4 Get Feature Configuration

This command is used to retrieve the IPMI feature set being configured.

Table 8-18 Get Feature Configuration Command

Byte

Request

Data

1

2

3

4

Response

Data

1

4

5

2

3

6

Data field




Feature Selector. For more information, see


Completion Code is Generic, plus the following command-specific completion codes:

80h = feature selector not supported.




Feature Configuration

00h = disabled (Feature Selector = E0)

01h = enabled (Feature Selector = E0)

02h = restore factory default (golden) (Feature Selector = E1)

C0h = reload selected FPGA image (Feature Selector = E1)

C1h = enabled and activated (Feature Selector = E0)


Persistency / Duration




Artesyn ATCA-9405-Installation and Use

Chapter 8

Intelligent Peripheral Management Controller

8.1

Overview

8.2

Functional Overview

8.3

Firmware Architecture

8.4

HPM.1 Components

8.4.1

FPGA Firmware Upgrade

8.4.2

Payload Firmware Upgrade

8.4.3

IPMC Firmware Upgrade

8.4.4

Manual Rollback

8.4.5

Retrieving Versioning Information

8.5

Sensors

8.5.1

Firmware Progress, OS Boot, and Boot Error Sensor

8.5.2

Boot Bank Supervision Sensor

8.5.3

POST Results Sensor

8.5.4

Power Good Sensor

8.5.5

Power Interface Sensors

8.5.6

Reset Cause Sensor

8.5.7

Presence Sensors

8.5.8

Voltage and Temperature Sensors

8.6

POST

8.7

FRU Inventory

8.7.1

MAC Address FRU OEM records

8.8

Reset and Power Domains

8.9

Power Management

8.10 U-Boot Boot Configuration Parameters

8.11 Asynchronous Event Notification

8.12 Serial Line Selection

8.13 Built-in Terminal Server

8.13.1 Evaluating the Version of the Telnet Server Firmware

8.13.2 Establishing a Telnet Session

8.14 Fail Safe Logic and Watchdog Support

8.14.1 SP BMC Watchdog

8.15 Payload Interface

8.16 Payload Boot Bank Selection

8.17 Settable Graceful Shutdown Timeout

8.18 FPGA Health Check

8.19 Local System Event Log (SEL)

8.20 IPMI Hardware Watchdog

8.21 Emerson OEM Command Set

8.21.1 Set Serial Output Command

8.21.2 Get Serial Output Command

8.21.3 Set Feature Configuration

8.21.4 Get Feature Configuration

Related manuals

Emerson

EKR-1000

Artesyn Embedded Technology

ATCA-9405

Emerson

RTM-ATCA-7150

Emerson

RTM-ATCA-7350

Table of contents