Age | Commit message (Collapse) | Author | Files | Lines |
|
We currently have the "pci-eeh-verbose" NVRAM flag that causes phb4 to
print a register dump when it detects the PHB has been fenced. This is
useful for debugging most EEH issues since the kernel may not be ready
to handle EEH events when the problem is first detected.
There's no real reason this needs to be specific to PHB4 so this patch
moves the nvram flag handling into the generic init path (along with the
pcie_max_link_speed flag) so we can add a similar function for PHB3.
Signed-off-by: Oliver O'Halloran <oohall@gmail.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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
- 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>
|
|
Never present in a public OPAL release, and only kernels prior to 3.11
would ever attempt to call it.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
While this call was technically implemented by skiboot, no code has ever called
it, and it was only ever implemented for the p7ioc-phb back-end (i.e. POWER7).
Since this call was unused in Linux, and that POWER7 with OPAL was only ever
available internally, so it should be safe to remove the call.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
These seem to be remnants of one of the OPAL incarnations prior to
OPALv3. These calls have never been implemented in skiboot, and never
used by an upstream kernel (nor a PowerKVM kernel).
It's rather safe to just document them as never existing.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Not ever used by upstream linux or PowerKVM tree. Never implemented in
skiboot (not even in ancient internal only tree).
So, it's incredibly safe to remove.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
This call was introduced all the way back at the end of 2012, before
OPAL was public. The #define for the OPAL call was introduced to the
Linux kernel in June 2013, and the call was never used in any kernel
tree ever (as far as we can find).
Thus, it's quite safe to remove this completely unused and completely
untested OPAL call.
Fixes: https://github.com/open-power/skiboot/issues/99
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
OPAL_PCI_SET_HUB_TCE_MEMORY
Since we have not supported p5ioc systems since skiboot 5.2, it's pretty
safe to just wholesale remove these OPAL calls now.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
There's no reason we need remnants hanging around that aren't used, so
remove them and save a handful of bytes at runtime.
Simultaneously, document the OPAL call removal.
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Currently the trace_get and trace_empty functions operate on a tracebuf
struct. This requires being able to write to that struct. If dump_trace
were able to use these functions it would be convenient as it would
reduce code duplication and these functions are already unit tested.
However, a tracebuf accessed via mmaping will not be able to be written.
The tracebuf struct fields that need to be written are only to be used
by a reader. The fields are never used by a writer. Add a new structure
for readers, trace_reader, which contains these fields and remove them
from the tracebuf struct. Change trace_get and trace_empty to use the
trace_reader struct and update the unit tests accordingly.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Every property in the device-tree under /ibm,opal/firmware/exports has a
sysfs node created in /firmware/opal/exports. Add properties with the
physical address and size for each trace buffer so they are exported.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
The names given to the trace buffers when exported to sysfs should show
what cpu they are associated with to make it easier to understand there
output. The debug_descriptor currently stores the address and length of
each trace buffer and this is used for adding properties to the device
tree. Extend debug_descriptor to include a cpu associated with each
trace. This will be used for creating properties in the device-tree
under /ibm,opal/firmware/exports/.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
We want to be able to mmap the trace buffers to be used by the
dump_trace tool. This means that the trace bufferes must be page
aligned. Currently they are aligned to 4K. Most power systems have a
64K page size. On systems with a 4K page size, 64K aligned will still be
page aligned. Change the allocation of the trace buffers to be 64K
aligned.
The trace_info struct that contains the trace buffer is actually what is
allocated aligned memory. This means the trace buffer itself is not
actually aligned and this is the address that is currently exposed
through sysfs. To get around this change the address that is exposed to
sysfs to be the trace_info struct. This means the lock in trace_info is
now visible too.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
We would like the be able to mmap the trace buffers so that the
dump_trace tool is able to make use of the existing functions for
reading traces in external/trace. Mmaping is done by pages which means
that buffers should be aligned to page size. This is not as simple as
setting the buffer length to a page aligned value as the buffers each
have a header and leave space for an extra entry at the end. These must
be taken into account so the entire buffer will be page aligned.
The current method of calculating buffer offsets is to use a mask and
bitwise 'and'. This limits the potential sizes of the buffer to powers
of two. The initial justification for using the mask was that the
buffers had different sizes so the offset needed to based on information
the buffers carried with them, otherwise they could overflow.
Being limited to powers of two will make it impossible to page align the
entire buffer. Change to using modulo for calculating the buffer offset
to make a much larger range of buffer sizes possible. Instead of the
mask, make each buffer carry around the length of the buffer to be used
for calculating the offset to avoid overflows.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
The parallel_test uses the cpu field of the trace_hdr struct. However it
is expected that some of the trace entries that are gotten will be
trace_overflow structs. This type of entry leaves the cpu field
indeterminate when it is interpreted as a trace_hdr struct. This means
it possible tests will fail when they try to use the cpu field of an
overflow struct, as the cpu field could hold anything.
Move the checks that use the cpu field until after it has been
determined the trace entry is an overflow type.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
A position for the boot_tracebuf is allocated in skiboot.lds.S.
However, without a __section attribute the boot trace buffer is not
placed in the correct location, meaning that it also will not be
correctly aligned. Add the __section attribute to ensure it will be
placed in its allocated position.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
A mock cpu thread structure is used for testing the skiboot trace
buffers. This contains the parts of the actual structure that are needed
for the tests. Within the mock structure the type used for servo_no is
different from the real structure. Change the type so it is consistent.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Contrary to popular belief, skiboot developers are imperfect and
occasionally write locking bugs. When we exit skiboot, we check if we're
still holding any locks, and if so, we print an error with a list of the
locks currently held and the locations where they were taken.
However, this only tells us the location where lock() was called, which may
not be enough to work out what's going on. To give us more to go on with,
we can store backtrace data in the lock and print that out when we
unexpectedly still hold locks.
Because the backtrace data is rather big, we only enable this if
DEBUG_LOCKS_BACKTRACE is defined, which in turn is switched on when
DEBUG=1.
(We disable DEBUG_LOCKS_BACKTRACE in some of the memory allocation tests
because the locks used by the memory allocator take up too much room in the
fake skiboot heap.)
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Use compiler builtins for the string functions, and compile the
libc/string/ directory with -O2.
This reduces instructions booting skiboot in mambo by 2.9 million in
slow-sim mode, or 3.8 in normal mode, for less than 1kB image size
increase.
This can result in the compiler warning more cases of string function
problems.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Trade size for speed and avoid de-duplicating strings in the fdt.
This costs about 2kB in fdt size, and saves about 8 million instructions
(almost half of all instructions) booting skiboot in mambo.
This was tracked down by Michael Neuling <mikey@neuling.org>.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Upgrade libfdt/ to github.com/dgibson/dtc.git 243176c ("Fix bogus
error on rebuild")
This copies dtc/libfdt/ to skiboot/libfdt/, with the only change in
that directory being the addition of README.skiboot and Makefile.inc.
This adds about 14kB text, 2.5kB compressed xz. This could be reduced
or mostly eliminated by cutting out fdt version checks and unused
code, but tracking upstream is a bigger benefit at the moment.
This loses commits:
14ed2b842f61 ("libfdt: add basic sanity check to fdt_open_into")
bc7bb3d12bc1 ("sparse: fix declaration of fdt_strerror")
As well as some prehistoric similar kinds of things, which is the
punishment for us not being good downstream citizens and sending
things upstream! Syncing to upstream will make that effort simpler
in future.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
On P9 there are GPIO port 0, 1, 2 for GPIO interrupt, and DIO interrupt
is used to handle the interrupts.
Add support to the DIO interrupts:
1. Add dio_interrupt_register(chip, port, callback) to register the
interrupt;
2. Add dio_interrupt_deregister(chip, port, callback) to deregister;
3. When interrupt on the port occurs, callback is invoked, and the
interrupt status is cleared.
Signed-off-by: Lei YU <mine260309@gmail.com>
[oliver: Fixed Makefile.inc merge conflict]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Use null-terminated strings consistently, making the maximum string
length in all cases the same, and avoiding dt_add_property_nstr.
This avoids the following warning that appears after adding more
checking to string ops:
core/pci-slot.c: In function ‘pci_slot_add_loc’:
skiboot/libc/include/string.h:19:17: warning: ‘__builtin_strncpy’
specified bound 80 equals destination size [-Wstringop-truncation]
#define strncpy __builtin_strncpy
core/pci-slot.c:244:3: note: in expansion of macro ‘strncpy’
strncpy(loc_code, label, sizeof(loc_code));
^~~~~~~
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
This catches a few more error cases in fdt building.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Skip the fast reboot checksum, which costs about 4 million cycles
booting skiboot in mambo.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Fast reboot gets disabled for a number of reasons e.g. the availability
of nvlink. However this doesn't actually affect the ability to perform fast
reboot if no nvlink device is actually present.
Add a nvram option for fast-reset where if it's set to
"im-feeling-lucky" then perform the fast-reboot irrespective of if it's
previously been disabled.
Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Acked-by: Russell Currey <ruscur@russell.cc>
[stewart: update nvram_query_eq to nvram_query_eq_dangerous]
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Most nvram options used by skiboot are just for debug or testing for
regressions. They should never be used long term.
We've hit a number of issues in testing and the field where nvram
options have been set "temporarily" but haven't been properly cleared
after, resulting in crashes or real bugs being masked.
This patch marks most nvram options used by skiboot as dangerous and
prints a chicken to remind users of the problem.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Reviewed-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Acked-By: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|