mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-11-26 12:20:50 +07:00
c7e64b9ce0
This enables support for userspace to fetch and initiate FSP and
Platform dumps from the service processor (via firmware) through sysfs.
Based on original patch from Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Flow:
- We register for OPAL notification events.
- OPAL sends new dump available notification.
- We make information on dump available via sysfs
- Userspace requests dump contents
- We retrieve the dump via OPAL interface
- User copies the dump data
- userspace sends ack for dump
- We send ACK to OPAL.
sysfs files:
- We add the /sys/firmware/opal/dump directory
- echoing 1 (well, anything, but in future we may support
different dump types) to /sys/firmware/opal/dump/initiate_dump
will initiate a dump.
- Each dump that we've been notified of gets a directory
in /sys/firmware/opal/dump/ with a name of the dump type and ID (in hex,
as this is what's used elsewhere to identify the dump).
- Each dump has files: id, type, dump and acknowledge
dump is binary and is the dump itself.
echoing 'ack' to acknowledge (currently any string will do) will
acknowledge the dump and it will soon after disappear from sysfs.
OPAL APIs:
- opal_dump_init()
- opal_dump_info()
- opal_dump_read()
- opal_dump_ack()
- opal_dump_resend_notification()
Currently we are only ever notified for one dump at a time (until
the user explicitly acks the current dump, then we get a notification
of the next dump), but this kernel code should "just work" when OPAL
starts notifying us of all the dumps present.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
42 lines
1.5 KiB
Plaintext
42 lines
1.5 KiB
Plaintext
What: /sys/firmware/opal/dump
|
|
Date: Feb 2014
|
|
Contact: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Description:
|
|
This directory exposes interfaces for interacting with
|
|
the FSP and platform dumps through OPAL firmware interface.
|
|
|
|
This is only for the powerpc/powernv platform.
|
|
|
|
initiate_dump: When '1' is written to it,
|
|
we will initiate a dump.
|
|
Read this file for supported commands.
|
|
|
|
0xXX-0xYYYY: A directory for dump of type 0xXX and
|
|
id 0xYYYY (in hex). The name of this
|
|
directory should not be relied upon to
|
|
be in this format, only that it's unique
|
|
among all dumps. For determining the type
|
|
and ID of the dump, use the id and type files.
|
|
Do not rely on any particular size of dump
|
|
type or dump id.
|
|
|
|
Each dump has the following files:
|
|
id: An ASCII representation of the dump ID
|
|
in hex (e.g. '0x01')
|
|
type: An ASCII representation of the type of
|
|
dump in the format "0x%x %s" with the ID
|
|
in hex and a description of the dump type
|
|
(or 'unknown').
|
|
Type '0xffffffff unknown' is used when
|
|
we could not get the type from firmware.
|
|
e.g. '0x02 System/Platform Dump'
|
|
dump: A binary file containing the dump.
|
|
The size of the dump is the size of this file.
|
|
acknowledge: When 'ack' is written to this, we will
|
|
acknowledge that we've retrieved the
|
|
dump to the service processor. It will
|
|
then remove it, making the dump
|
|
inaccessible.
|
|
Reading this file will get a list of
|
|
supported actions.
|