Age | Commit message (Collapse) | Author | Files | Lines |
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
We move the platform exit call much closer to executing the kernel,
which should all be safe, and in fact a much better time to do watchdog
related things.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
This decouples FSP platform from core skiboot logic by using this small
hack that may/may not be a good idea (although is already used
elsewhere, so at least we're consistent).
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
It's only used on FSP systems so should really just be part of that
platform support.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
We have an implementation for non-FSP systems now, and we shouldn't be
calling that from code in an fsp/ directory, so move op_display() to a
platform function.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
We throw a bunch of errors in errorlog code otherwise, which we should
fix, but we don't *have* to yet.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
GCC9 now catches this bug:
In file included from hdata/vpd.c:17:
In function ‘vpd_vini_parse’,
inlined from ‘vpd_data_parse’ at hdata/vpd.c:416:3:
/home/stewart/skiboot/include/skiboot.h:93:31: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
93 | #define prlog(l, f, ...) do { _prlog(l, pr_fmt(f), ##__VA_ARGS__); } while(0)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
hdata/vpd.c:390:5: note: in expansion of macro ‘prlog’
390 | prlog(PR_WARNING,
| ^~~~~
hdata/vpd.c: In function ‘vpd_data_parse’:
hdata/vpd.c:391:46: note: format string is defined here
391 | "VPD: CCIN desc not available for: %s\n",
| ^~
cc1: all warnings being treated as errors
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Only the reg member is sent anywhere (via xscom_write), so the structure
does not need to be packed.
Fixes GCC9 build problem:
hw/sbe-p9.c: In function ‘p9_sbe_msg_send’:
hw/sbe-p9.c:270:9: error: taking address of packed member of ‘struct p9_sbe_msg’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
270 | data = &msg->reg[0];
| ^~~~~~~~~~~~
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
We need this in the master branch so that the coverity_scan branch gets
picked up.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
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>
|
|
Fix this sparse warning:
core/stack.c:123:13: warning: symbol 'bt_lock' was not declared. Should it be static?
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
This is based on a patch from Cédric from way back in 2015 (probably
around the time we split opal.h into opal-api.h and opal-internal.h)
that for some reason never got merged.
It means that false warnings spat out of sparse due to our crazy-ass
macro usage get silenced.
It fixes warnings such as
"Using plain integer as NULL pointer"
when the prototype of the function is tested with the __test_args#
defines.
Suggested-by: Cédric Le Goater <clg@fr.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Repost of the same thing with Signed-off-by, and Acked-by from Michael Neuling.
This fixes a couple issues with external/mambo/skiboot.tcl so I can use the
mambo bogus net.
* newer distros (ubuntu 18.04) allow tap device to have a user specified
name instead of just tapN so we need to pass in a name not a number.
* need some kind of default for net_mac, and need the mconfig for it
to be set from an env var.
Thanks,
Aaron
Acked-by: Michael Neuling <mikey at neuling.org>
Signed-off-by: Aaron Sawdey <sawdey at linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
After putting all a GPU's links in reset, do a cache purge in case we
have CPU cache lines belonging to the now-unaccessible GPU memory.
Fixes: 68d11e4460ec ("npu2: Reset NVLinks when resetting a GPU")
Cc: skiboot-stable@lists.ozlabs.org
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Change "brigde" to "bridge".
Fixes: 68d11e4460ec ("npu2: Reset NVLinks when resetting a GPU")
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Fixes: https://github.com/open-power/skiboot/issues/134
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
The NPU2 is currently not passing any information to linux to explain
the cause of an HMI. NPU2 has three Fault Isolation Registers and over
30 of those FIR bits are configured to raise an HMI by default. We
won't be able to fit all possible state in the 32-bit xstop_reason
field of the HMI event, but we can still try to encode up to 4 HMI
reasons.
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Commit f8dfd699f584 ("hw/npu2: Setup an error interrupt on some
opencapi FIRs") converted some FIR bits default action from system
checkstop to raising an error interrupt. For 2 XSL error events that
can be triggered by a misbehaving AFU, the error interrupt is raised
twice, once for each link (the XSL logic in the NPU is shared between
2 links). So a badly behaving AFU could impact another, unsuspecting
opencapi adapter.
It doesn't look good and it turns out we can do better. We can mask
those 2 XSL errors. The error will also be picked up by the OTL logic,
which is per link. So we'll still get an error interrupt, but only on
the relevant link, and the other opencapi adapter can stay functional.
Fixes: f8dfd699f584 ("hw/npu2: Setup an error interrupt on some opencapi FIRs")
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Practically speaking this should/would never happen, but static analysis
caught it, and just *maybe* at some time in the future, someone will
have less of a terrible day debugging something terrible if we fix it.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
number of elements versus starting counting from 0.
Found by static analysis.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
It's been a good long while since either OPAL POWER7 user touched a
machine, and even longer since they'd have been okay using an old
version rather than tracking master.
There's also been no testing of OPAL on POWER7 systems for an awfully
long time, so it's pretty safe to assume that it's very much bitrotted.
It also saves a whole 14kb of xz compressed payload space.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
Enthusiasticly-Acked-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
If prd messages size is insufficient then read_prd_msg() call fails with
below error. And caller is not reallocating sufficient buffer. Also its
hard to guess the size.
sample log:
-----------
Mar 28 03:31:43 zz24p1 opal-prd: FW: error reading from firmware: alloc 32 rc -1: Invalid argument
Mar 28 03:31:43 zz24p1 opal-prd: FW: error reading from firmware: alloc 32 rc -1: Invalid argument
Mar 28 03:31:43 zz24p1 opal-prd: FW: error reading from firmware: alloc 32 rc -1: Invalid argument
....
Lets use `opal-msg-size` device tree property to allocate memory
for prd message.
Cc: Skiboot Stable <skiboot-stable@lists.ozlabs.org>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
This patch implements generic interface to pass data from FSP to HBRT during
runtime (FSP -> OPAL -> opal-prd -> HBRT).
OPAL gets notification from FSP for new HBRT messages. We will convert MBOX
message to firmware_notify format and send it to HBRT.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
This patch implements generic interface to pass data from HBRT to FSP
during runtime (HBRT -> opal-prd -> kernel -> OPAL -> FSP).
HBRT sends data via firmware_request interface. We have to convert that to
MBOX format and send it to FSP. OPAL uses TCE mapped memory to send data.
FSP will reuse same memory for response. Once processing is complete FSP
sends response to OPAL. Finally OPAL calls HBRT with firmware_response
message.
Also introduces new opal_msg type (OPAL_MSG_PRD2) to pass bigger prd message
to kernel.
- if (prd_msg > OPAL_MSG_FIXED_PARAMS_SIZE)
use OPAL_MSG_PRD2
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
On safer side, validate _opal_queue_msg() return value.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Acked-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
We have user space opal-prd running on ZZ. We don't use host services.
Hence do not call hservices_init().
CC: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Acked-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
- Test callback function
- Add test case to test OPAL_PARTIAL return value
- Add test for OPAL_PARAMETER return value
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Linux uses opal_get_msg (OPAL_GET_MSG) API to get OPAL messages. This interface
supports upto 8 params (64 bytes). We have a requirement to send bigger data to
Linux. This patch enhances OPAL to send bigger data to Linux.
- Linux will use "opal-msg-size" device tree property to allocate memory for
OPAL messages (previous patch increased "opal-msg-size" to 64K).
- Replaced `reserved` field in "struct opal_msg" with `size`. So that Linux
side opal_get_msg user can detect actual data size.
- If buffer size < actual message size, then opal_get_msg will copy partial
data and return OPAL_PARTIAL to Linux.
- Add new variable "extended" to "opal_msg_entry" structure to keep track
of messages that has more than 64byte data. We will allocate separate
memory for these messages and once kernel consumes message we will
release that memory.
Cc: Jeremy Kerr <jk@ozlabs.org>
Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Cc: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Acked-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Currently _opal_queue_msg() takes number of parameters. So far this was
fine as opal_queue_msg() was supporting only fixed number of parameters
(8 * 8 bytes). Soon we are going to introduce variable size parameter.
Hence num_params -> params_size.
Cc: Jeremy Kerr <jk@ozlabs.org>
Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Cc: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Acked-by Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Kernel calls opal_get_msg() API to read OPAL message. In this path OPAL
calls "callback" handler to inform caller that kernel read the opal
message. It assumes that read is always success. This assumption was
fine as message was always fixed size.
Next patch introduces variable size opal message. In that situation
opal_get_msg() may fail due to insufficient buffer size (ex: old kernel
and new OPAL combination). So lets add `return value` parameter to
"callback" handler. So that caller knows kernel didn't read the
message and take appropriate action.
Cc: Jeremy Kerr <jk@ozlabs.org>
Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Cc: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Acked-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Kernel will use `opal-msg-size` property to allocate memory for opal_msg.
We want to send bigger data from OPAL to kernel. Hence increase
opal-msg-size to 64K.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Acked-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
The existing skiboot events are being logged as EV_ACTION, however, the
TCG PC Client spec says that EV_ACTION events should have one of the
pre-defined strings in the event field recorded in the event log. For
instance:
- "Calling Ready to Boot",
- "Entering ROM Based Setup",
- "User Password Entered", and
- "Start Option ROM Scan.
None of the EV_ACTION pre-defined strings are applicable to the existing
skiboot events. Based on recent discussions with other POWER teams, this
patch proposes a convention on what PCR and event types should be used
for skiboot events. This also changes the skiboot source code to follow
the convention.
The TCG PC Client spec defines several event types, other than
EV_ACTION. However, many of them are specific to UEFI events and some
others are related to platform or CRTM events, which is more applicable
to hostboot events.
Currently, most of the hostboot events are extended to PCR[0,1] and
logged as either EV_PLATFORM_CONFIG_FLAGS, EV_S_CRTM_CONTENTS or
EV_POST_CODE. The "Node Id" and "PAYLOAD" events, though, are extended
to PCR[4,5,6] and logged as EV_COMPACT_HASH.
For the lack of an event type that fits the specific purpose,
EV_COMPACT_HASH seems to be the most adequate one due to its
flexibility. According to the TCG PC Client spec:
- May be used for any PCR except 0, 1, 2 and 3.
- The event field may be informative or may be hashed to generate the
digest field, depending on the component recording the event.
Additionally, the PCR[4,5] seem to be the most adequate PCRs. They would
be used for skiboot and some skiroot events. According to the TCG PC
Client, PCR[4] is intended to represent the entity that manages the
transition between the pre-OS and OS-present state of the platform.
PCR[4], along with PCR[5], identifies the initial OS loader.
In summary, for skiboot events:
- Events that represents data should be extended to PCR 4.
- Events that represents config should be extended to PCR 5.
- For the lack of an event type that fits the specific purpose,
both data and config events should be logged as EV_COMPACT_HASH.
Signed-off-by: Claudio Carvalho <cclaudio@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
OPAL call tokens 46, 47, and 48 have been unused since the dawn of time
as far as I can tell. Document the hole so the next person to assume
it's contigious doesn't get tripped up by it.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Resetting a GPU before resetting an NVLink leads to occasional HMIs
which fence some bricks and prevent the "reset_ntl" procedure from
succeeding at the "reset_ntl_release" step - the host system requires
reboot; there may be other cases like this as well.
This adds clearing of the fence bit in NPU.MISC.FENCE_STATE for
the NVLink which we are about to reset.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
phb4_training_trace() is used to monitor the Link Training Status
State Machine (LTSSM) of the PHB's data link layer. Currently it is only
used to observe the LTSSM while bringing up the link, but sometimes it's
useful to see what's occurring in other situations (e.g. link disable, or
secondary bus reset). This patch renames it to phb4_link_trace() and
allows the target LTSSM state and a flexible timeout to help in these
situations.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
The current LTSSM state was added to the PHB4 link trace output in
961547bceed3 ("phb4: Enhanced PCIe training tracing"). That patch
split enabling the LTSSM state output from the rest of the tracing code
in phb4_training_trace() to ensure that it would capture events from
right after PERST is lifted.
This is not really necessary since LTSSM state changes occur over
milliseconds. We lose nothing by delaying the enable slightly so
this patch moves it into phb4_training_trace() to keep the tracing
code in one place.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
The "disabled" and "loopback" states are missing from the table. We
never expect to see the second, but the first does occasionally come
up.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
While the PHB is fenced we can't use the MMIO interface to access PHB
registers. While processing a complete reset we inject a PHB fence to
isolate the PHB from the rest of the system because the PHB won't
respond to MMIOs from the rest of the system while being reset.
We assert PERST after the fence has been erected which requires us to
use the XSCOM indirect interface to access the PHB registers rather than
the MMIO interface. Previously we did that when asserting PERST in the
CRESET path. However in b8b4c79d4419 ("hw/phb4: Factor out PERST
control"). This was re-written to use the raw in_be64() accessor. This
means that CRESET would not be asserted in the reset path. On some
Mellanox cards this would prevent them from re-loading their firmware
when the system was fast-reset.
This patch fixes the problem by replacing the raw {in|out}_be64()
accessors with the phb4_{read|write}_reg() functions.
Reported-by: Carol L Soto <clsoto@us.ibm.com>
Fixes: b8b4c79d4419 ("hw/phb4: Factor out PERST control")
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Tested-by: Carol L Soto <clsoto@us.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|