1 method 1: the payload os supports acpi, 2 method 2: the payload os does not support acpi, Ipmi firmware user guide am5030 – Kontron AM5030 IPMI User Manual
Page 38

IPMI Firmware User Guide
AM5030
Page 38
ID: 1042-7364, Rev. 1.0
9.1
Method 1: The Payload OS Supports ACPI
Requirements:
• ACPI support must be enabled in the BIOS menu.
• The ACPI daemon must be active.
• An ACPI power button event must result in a sleep state.
Part of the Hot Swap Operation sequence to be processed by MMC and OS:
• On command of the carrier controller, the MMC simulates the pressing and release of the
“power button” to force an ACPI event.
• The ACPI daemon detects this ACPI event and initiates the shut down of the payload
software system.
• At the end of shut down the payload hardware system reports the sleep state to the MMC
by setting the appropriate signal line.
• The MMC detects the sleep state and reports this to the carrier controller (“quiesced”) so
that the Hot Swap processing can be continued and finished.
By default the MMC waits endlessly for the sleep state. Please note: Some Shelf Managers or
MCHs use a time out to simply switch off of a module which needs too much time to reach sleep
state. As this might be an undesirable situation, refer to the appropriate manual for further as-
sistance. In any event, if an endless wait is to be avoided, it is possible to set a timeout time for
the module's MMC after which the system will be switched off unconditionally. For the setting
of the timeout refer to 3.4, OEM Module Quiescence Feedback.
9.2
Method 2: The Payload OS Does Not Support ACPI
Requirements:
• At system start on the payload side the Kontron shutdown daemon 'grnsd' must be start-
ed. It is included in the Linux board support packages for the AM5030. This daemon com-
municates cyclically with the MMC for the exchange of states, commands and
acknowledgments. For this, it uses the “OEM Module Quiescence Feedback” command.
Refer to chapter 3.4. In principle it plays the same role as the ACPI daemon of Method 1
above.
Part of the Hot Swap Operation sequence to be processed by MMC and OS:
• On command of the carrier controller the MMC sets a “shut down request” flag.
• The 'grnsd' daemon recognizes this request in the response to its cyclical “OEM Module
Quiescence Feedback” command and initiates the shut down of the payload software
system.
• At the end of the shut down process, the 'grnsd' daemon informs the MMC by setting the
appropriate flag when calling the “OEM Module Quiescence Feedback” command.
• The MMC reports this to the carrier controller so that the Hot Swap processing can be
continued and finished.
By default the MMC waits endlessly for this information. If an endless wait is to be avoided, it
is possible to set a timeout time after which the system will be switched off unconditionally. For
the setting of the timeout refer to 3.4, OEM Module Quiescence Feedback.