aboutsummaryrefslogtreecommitdiff
path: root/include/ipmi.h
AgeCommit message (Collapse)AuthorFilesLines
2019-07-26SPDX-ify all skiboot codeStewart Smith1-15/+2
Use Software Package Data Exchange (SPDX) to indicate license for each file that is unique to skiboot. At the same time, ensure the (C) who and years are correct. See https://spdx.org/ Signed-off-by: Stewart Smith <stewart@linux.ibm.com> [oliver: Added a few missing files] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-06-13sparse: fix incorrect type assignment in core/ipmi.cStewart Smith1-1/+2
core/ipmi.c:262:44: warning: incorrect type in assignment (different base types) core/ipmi.c:262:44: expected unsigned long long [usertype] opal_event_ipmi_recv core/ipmi.c:262:44: got restricted beint64_t Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2019-05-09platforms/astbmc: Check for SBE validation stepSamuel Mendoza-Jonas1-0/+7
On some POWER8 astbmc systems an update to the SBE requires pausing at runtime to ensure integrity of the SBE. If this is required the BMC will set a chassis boot option IPMI flag using the OEM parameter 0x62. If Skiboot sees this flag is set it waits until the SBE update is complete and the flag is cleared. Unfortunately the mystery operation that validates the SBE also leaves it in a bad state and unable to be used for timer operations. To workaround this the flag is checked as soon as possible (ie. when IPMI and the console are set up), and once complete the system is rebooted. Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-05-09include/ipmi: Fix incorrect chassis commandsSamuel Mendoza-Jonas1-7/+7
These commands are listed in the order they appear in the IPMI specification but with the wrong values - correct them! Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-05-09ipmi: ensure forward progress on ipmi_queue_msg_sync()Stewart Smith1-0/+9
BT responses are handled using a timer doing the polling. To hope to get an answer to an IPMI synchronous message, the timer needs to run. We can't just check all timers though as there may be a timer that wants a lock that's held by a code path calling ipmi_queue_msg_sync(), and if we did enforce that as a requirement, it's a pretty subtle API that is asking to be broken. So, if we just run a poll function to crank anything that the IPMI backend needs, then we should be fine. This issue shows up very quickly under QEMU when loading the first flash resource with the IPMI HIOMAP backend. Reported-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Stewart Smith <stewart@linux.ibm.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-02-20hw/bt: Add backend interface to disable ipmi message retry optionVasant Hegde1-0/+1
During boot OPAL makes IPMI_GET_BT_CAPS call to BMC to get BT interface capabilities which includes IPMI message max resend count, message timeout, etc,. Most of the time OPAL gets response from BMC within specified timeout. In some corner cases (like mboxd daemon reset in BMC, BMC reboot, etc) OPAL may not get response within timeout period. In such scenarios, OPAL resends message until max resend count reaches. OPAL uses synchronous IPMI message (ipmi_queue_msg_sync()) for few operations like flash read, write, etc. Thread will wait in OPAL until it gets response from BMC. In some corner cases like BMC reboot, thread may wait in OPAL for long time (more than 20 seconds) and results in kernel hardlockup. This patch introduces new interface to disable message resend option. We will disable message resend option for synchrous message. This will greatly reduces kernel hardlock up issues. This is short term fix. Long term solution is to convert all synchronous messages to asynhrounous one. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2018-10-10ipmi: Introduce registration for SEL command handlersAndrew Jeffery1-0/+5
Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2018-05-09ipmi: Add BMC firmware version to device treeVasant Hegde1-0/+7
BMC Get device ID command gives BMC firmware version details. Lets add this to device tree. User space tools will use this information to display BMC version details. Stewart, I have added bmc information under /ibm,firmware-version node as its firmware version. But may be we should add new node (/bmc/firmware). So that we can keep BMC related information separately. Let me know your thoughts on this. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
2017-07-13IPMI: Move MAX_IPMI_SENSORS macro to ipmi.hVasant Hegde1-0/+2
..so that it can be used in other places as well. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-11-08Add BMC platform to enable correct OEM IPMI commandsStewart Smith1-5/+1
An out of tree platform (p8dtu) uses a different IPMI OEM command for IPMI_PARTIAL_ADD_ESEL. This exposed some assumptions about the BMC implementation in our core code. Now, with platform.bmc, each platform can dictate (or detect) the BMC that is present. We allow it to be set at runtime rather than purely statically in struct platform as it's possible to have differing BMC implementations on the one machine (e.g. AMI BMC or OpenBMC). Acked-by: Jeremy Kerr <jk@ozlabs.org> [stewart@linux.vnet.ibm.com: remove enum, update (C) years] Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-08hw/bt: fix IPMI_GET_BT_CAPS definitionCédric Le Goater1-1/+1
Specified in IPMI docs: http://www.intel.com.au/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf page 587 under BMC Device and Messaging Command Signed-off-by: Cédric Le Goater <clg@fr.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-11-17hw/bt: Ask the BMC for its BT interface capabilitiesCyril Bur1-0/+1
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-09-09IPMI: Introduce attention callVasant Hegde1-0/+3
Presently abort() function is not working on BMC based machine. System hangs after abort/assert call. We have to reboot machine from BMC (IPMI command or BMC console). This patch introduces attention functionality for BMC based machine. It logs eSEL event that contains OPAL version, file info and backtrace. And calls cec_reboot... which takes care of rebooting host. Note: - This patch uses ipmi_queue_msg() instead of ipmi_queue_msg_sync() as we are having some issues with sync path. This will resolved once we sort out [1]. - This patch calls cec_reboot to reboot machine after logging eSEL event. It queues IPMI message and bt_poll() should be working until we pass reboot IPMI message to BMC. Hence we have while loop with time_wait_ms(). Alternatively we can use xscom_trigger_xstop().. but it will stop immediately and eSEL logging fails. [1] https://lists.ozlabs.org/pipermail/skiboot/2015-August/001824.html Sample eSEL output after assert call: ------------------------------------ [hegdevasant@hegdevasant bin]$ strings fir01bmc.150820.120511.eSel.binary BB821410 AT8335-GTA000000000000 AT8335-GTA000000000000UD ATDESC OPAL version : skiboot-5.1.1-44-geae3999-hegdevasant-dirty-bb31bfd File info : core/init.c:463:0 CPU 0060 Backtrace: S: 0000000031d83bc0 R: 000000003006086c .ipmi_terminate+0x110 S: 0000000031d83c60 R: 0000000030017f90 ._abort+0x80 S: 0000000031d83ce0 R: 0000000030017fd8 .assert_fail+0x34 S: 0000000031d83d60 R: 0000000030013dcc .load_and_boot_kernel+0x784 S: 0000000031d83e30 R: 000000003001437c .main_cpu_entry+0x57c S: 0000000031d83f00 R: 0000000030002544 boot_entry+0x194 Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-09-09IPMI: Move MAX_PEL_SIZE to ipmi.hVasant Hegde1-0/+8
We want to use MAX_PEL_SIZE in other code (like attention) as well. Hence move this to ipmi.h. Also rename MAX_PEL_SIZE as IPMI_MAX_PEL_SIZE to reflect its IPMI specific macro. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-09-09IPMI: Pre-allocate memory for PANIC eventVasant Hegde1-0/+3
Currently we allocate ipmi_msg for every eSEL event.. But in PANIC its not advised to allocate memory. Hence pre-allocate ipmi_msg for PANIC event. Note that we continue to allocate memory for normal event. Also with current implementation we can log only one eSEL event in PANIC path. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-08-14IPMI: Add SEL event with eSEL record IDVasant Hegde1-0/+1
Our PEL logs doesn't contain timestamp as we don't have timesource. Hence create SEL event for every eSEL log with eSEL record ID. This event will be used to get PEL event time. New SEL event contains eSEL record ID. Sample output: ------------- SEL Record ID : 0016 Record Type : 02 Timestamp : 08/09/2015 12:35:16 Generator ID : 0020 EvM Revision : 04 Sensor Type : System Event Sensor Number : 61 Event Type : Generic Discrete Event Direction : Assertion Event Event Data (RAW) : 011400 Description : State Asserted Sensor ID : System Event (0x61) Entity ID : 1.0 Sensor Type (Discrete): System Event Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-08-14IPMI: Fix eSEL loggingVasant Hegde1-0/+3
Presently we are passing PEL log without adding Extended SEL record. Hence logging eSEL event is failing. This patch sends Extended SEL structure before sending actual PEL log. So that BMC understands its eSEL log and logs it appropriately. eSEL format: <IPMI SEL header> : <eSEL record> : <PEL data> Note that we use sensor type "System Event (0x12)" for logging OPAL events. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Cc: Alistair Popple <alistair@popple.id.au> Cc: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-07-10ipmi: Provide a macro for netfn return codeNeelesh Gupta1-0/+2
Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com> Cc: Alistair Popple <alistair@popple.id.au> Acked-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-07-03core/ipmi: Provide the dequeue message interfaceNeelesh Gupta1-0/+3
Add a wrapper for the client to be able to invoke the backend dequeue message function. Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com> Cc: Alistair Popple <alistair@popple.id.au> Acked-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-03-04hw/ipmi: Set boot count sensorJoel Stanley1-0/+3
The boot count sensor is a discrete sensor that is set once the system is up and running. On successful boot, the BMC expects the sensor to be set to 2. Signed-off-by: Joel Stanley <joel@jms.id.au>
2015-03-04hw/ipmi: Set firmware progress sensorJoel Stanley1-0/+5
We set the IPMI firmware progress sensor to indicate the boot progress of the system. The x86-centric IPMI names don't fit perfectly into what skiboot does, but they do give some indication of the system state. Signed-off-by: Joel Stanley <joel@jms.id.au>
2015-03-04hw/ipmi: Add API for setting sensorsJoel Stanley1-0/+9
This allows setting a given IPMI sensor to a given value. There are helpers for setting the firmware boot progress that will be used for updating the BMC with the host boot progress. The sensor ids are parsed from the device tree. If the sensor cannot be found we will silently continue. Signed-off-by: Joel Stanley <joel@jms.id.au>
2015-03-04hw/ipmi: Disable flash access when requestedJoel Stanley1-2/+3
BMC based systems contain a PNOR to provide flash storage. The host normally has exclusive access to the PNOR, however the BMC may use IPMI to request access to perform functions such as update the firmware. Indicate to users of the flash that the device is busy by taking the lock, and setting a per-flash busy flag, which causes flash operations to return OPAL_BUSY. Minor changes from Jeremy Kerr Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
2015-02-09ipmi/wdt: Add ipmi watchdog timer supportAlistair Popple1-0/+12
Add support for an ipmi watchdog timer. During skiboot initialisation this patch will cause the system to be reset if opal_run_pollers() isn't called for more than 60 seconds. Once the payload is started the watchdog timer will be reset and a pre-timeout interrupt set. The payload should then receive the interrupt and call into skiboot which will disable the watchdog timer. Signed-off-by: Alistair Popple <alistair@popple.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-02-09ipmi: Implement Read Event and SEL parsingJoel Stanley1-0/+3
The read event mechanism is used when the BMC has an asynchronous message for the host. It sets a flag that we read with Get Message Flags, and then we read the message using Read Event. This event message contains a SEL message. There are two OEM SEL messages we expect from the AMI BMC: - graceful power operations. This is when the BMC wants the host to power down or reboot. - PNOR Locking. When the BMC wants to access the PNOR, it requests that the host not touch it. This patch implements the parsing. Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-02-09ipmi: Set BMC Global Enables to enable notificationsJoel Stanley1-0/+2
For OEM events including graceful power down and BMC PNOR access we want to receive notification whenever a message is ready to be read from the BMC. This requires the Event Message Buffer flag to be enabled. This is the equivalent of doing mc setenables event_msg=on with ipmitool, except the message must come from the BT interface in order to have permission to modify the flags. Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-02-09ipmi: handle SMS_ATN eventsJeremy Kerr1-0/+15
When the bt interface sets the SMS_ATN flag, we perform a Get Message Flags to determine what messages are available. The only message type currently processed is the Event Message Buffer, which provides SEL messages for indicating OEM specific events such as graceful system shutdown and PNOR access requested. These events will be handled by the IPMI layer in skiboot. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-02-09ipmi: Add support for synchronous message sendingAlistair Popple1-0/+4
This patch adds support for sending ipmi messages synchronously. This is necessary to allow messages to be sent during skiboot initialisation as interrupt servicing/polling is controlled by the host operating system which is not yet running. Signed-off-by: Alistair Popple <alistair@popple.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-02-09ipmi: Add a function to (re)initialise a message without allocationAlistair Popple1-0/+7
Currently the only functions we have for initialising ipmi messages with the correct values also allocate memory for the message. In some cases we want to reuse previously allocated messages to avoid continually freeing/allocating memory. This patch introduces a function which (re)initialises a previously allocated message and converts existing instances of this behaviour over to the new function. Signed-off-by: Alistair Popple <alistair@popple.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2014-12-02esel: Add a logging backend for bmc based machinesAlistair Popple1-0/+8
This patch adds a backend for bmc based machines running AMI firmware supporting the OEM extended sel commands. Errors are logged in pel format to the bmc. Signed-off-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2014-12-02ipmi/bt: Enable adding messages to the start of the queueAlistair Popple1-0/+4
By default new ipmi messages are added to the end of the transmission queue. However sometimes it is necessary to add messages to the start of the queue. This patch adds a new ipmi function that adds messages to the start of the transmission queue. Signed-off-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2014-12-02ipmi/fru: Add support for populating fru dataAlistair Popple1-2/+6
This patch adds basic support for populating some fru data. Currently we only support adding the skiboot version number to the product information area. Signed-off-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2014-10-30ipmi: Add an opal interface to the ipmi stackAlistair Popple1-0/+13
This patch adds two opal calls (opal_ipmi_send and opal_ipmi_recv) to allow an operating system to send and receive arbitrary ipmi messages to the BMC. Signed-off-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-10-01ipmi/bt: Improve message validation and allow out-of-order command responsesAlistair Popple1-1/+1
This patch adds validation of the ipmi cmd and netfn numbers returned by the bmc. It also ensures the sequence number is correct by searching the outstanding message queue for the corresponding sequence number. Signed-off-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-10-01ipmi: Add ipmi_present APIJoel Stanley1-0/+3
Similar to the use of fsp_present, this is so code can safely call functions which may not work on the platform they are running on, or as protection against calling before the device is initialised. Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-10-01ipmi/power: Add power state IPMI commandJoel Stanley1-0/+19
This sends command 20.7, Set ACPI Power State. It is to be used to inform a BMC of the runtime state of the system. We drop the ACPI part from the function name to avoid confusion. As soon as IPMI is up, the palmetto platform init code will set the power ptate to S0/working. Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-10-01ipmi/power: Update chassis control commandJoel Stanley1-2/+2
Linux sends us a 0 when shutting down. This means we don't need to pass the u64 to the IPMI driver. Add a check that the value is what we expect in case Linux changes it's behaviour in the future. When rebooting, we should send the BMC a HARD_RESET command (0x03), not POWER_CYCLE (0x02). While we are here, trim some whitespace and drop opal from the IPMI function name for readability. Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-10-01bt/ipmi: Convert to using asynchronous messagingAlistair Popple1-1/+2
Previously we were doing synchronous messaging and cranking the bt state machine from within OPAL. This was not ideal as it could potentially take control away from the OS for long periods of time if the BMC is busy. This patch solves the problem using the opal_poll api to do asynchronous messaging. Signed-off-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-10-01ipmi: Refactored ipmi layer to use generic backendAlistair Popple1-11/+52
The initial implementation of the ipmi stack was still tightly coupled with the backend (in this case bt). This patch refactors the ipmi code to use a generic backend device. The core ipmi messaging functionality and the implementation of specific commands has also been split into different files. Signed-off-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-10-01bt/ipmi: Fixup allocation of bt/ipmi messagesAlistair Popple1-2/+1
The original implementation of the bt and ipmi layers required the bt, ipmi and message data to be allocated separately. This is sub-optimal as it could cause excessive memory fragmentation. This patch fixes the problem by adding a function to the bt layer to allocate space for both the required data and bt/ipmi message. Signed-off-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-08-15ipmi: Correct chassis control messageJoel Stanley1-6/+28
I misread the spec when implementing the chassis control message. This fixes the message, as well as correcting the naming of the IPMI fields to better reflect what they represent. Signed-off-by: Joel Stanley <joel@jms.id.au> Acked-by: Jeremy Kerr <jeremy.kerr@au.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-08-13plat/palmetto: Add shutdown and rebootJoel Stanley1-0/+9
Rebooting and power down for the Palmetto is done by the BMC, which we speak to over the BT interface using IPMI. Implement the IPMI chassis commands which are used for power control, and hook them up to the palmetto platform callbacks for shutdown and reboot. Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-08-13ipmi: Add a base IPMI stack with a BT driverAlistair Popple1-0/+75
This patch adds a basic IPMI layer to the sapphire core and support for a BT IPMI interface as found on the Aspeed BMC of the Palmetto platform [ Changed the compatible property -- BenH ] Signed-off-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
generated by cgit v1.1 at 2024-07-09 12:13:20 +0000