Age | Commit message (Collapse) | Author | Files | Lines |
|
Resolves : the warray bounds warning during compilation
/build/libc/include/string.h:34:16: warning: '__builtin_memset' offset [0, 2097151] is out of the bounds [0, 0] [-Warray-bounds]
34 | #define memset __builtin_memset
hw/fsp/fsp.c:1855:9: note: in expansion of macro 'memset'
1855 | memset(fsp_tce_table, 0, PSI_TCE_TABLE_SIZE);
use volatile pointer to avoid optimization introduced with gcc-11 on constant
address assignment to pointer.
Signed-off-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
|
|
POWER10 IMC support:
Add POWER10 scom addresses for IMC
Add support for IMC trace-mode
Fix the catalog subit for POWER10
Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
This reverts commit a4788a49f004a91bb8ca015336abf9ae119fbc52.
Above patch was added to handle host power down with FSP in R/R state.
But FSP is not liking OPAL giving up PSI link early in R/R process. For
FSP initiated R/R OPAL should wait until we get PSI interrupt. Hence
reverting above commit.
Also partially reverting commit e04a34af to make fsp_dpo_pending as
global variable.
We have made several improvement in the way we handle FSP communication
and also in power down path. Now if host sends powerdown message when
FSP in RR, OPAL return OPAL_BUSY_EVENT. Kernel will run poller() and
retry power down message after sometime. So I think this patch will not
have any side effect on power down path.
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Acked-by: Ananth N Mavinakayanahalli <ananth@linux.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
SPDX makes it a simpler diff.
I have audited the commit history of each file to ensure that they are
exclusively authored by IBM and thus we have the right to relicense.
The motivation behind this is twofold:
1) We want to enable experiments with coreboot, which is GPLv2 licensed
2) An upcoming firmware component wants to incorporate code from skiboot
and code from the Linux kernel, which is GPLv2 licensed.
I have gone through the IBM internal way of gaining approval for this.
The following files are not exclusively authored by IBM, so are *not*
included in this update (I will be seeking approval from contributors):
core/direct-controls.c
core/flash.c
core/pcie-slot.c
external/common/arch_flash_unknown.c
external/common/rules.mk
external/gard/Makefile
external/gard/rules.mk
external/opal-prd/Makefile
external/pflash/Makefile
external/xscom-utils/Makefile
hdata/vpd.c
hw/dts.c
hw/ipmi/ipmi-watchdog.c
hw/phb4.c
include/cpu.h
include/phb4.h
include/platform.h
libflash/libffs.c
libstb/mbedtls/sha512.c
libstb/mbedtls/sha512.h
platforms/astbmc/barreleye.c
platforms/astbmc/garrison.c
platforms/astbmc/mihawk.c
platforms/astbmc/nicole.c
platforms/astbmc/p8dnu.c
platforms/astbmc/p8dtu.c
platforms/astbmc/p9dsu.c
platforms/astbmc/vesnin.c
platforms/rhesus/ec/config.h
platforms/rhesus/ec/gpio.h
platforms/rhesus/gpio.c
platforms/rhesus/rhesus.c
platforms/astbmc/talos.c
platforms/astbmc/romulus.c
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
[oliver: fixed up the drift]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
__fsp_fillmsg() is called from fsp_fillmsg() and fsp_mkmsg(). Both
callers wrap it in a va_start() / va_end() pair so using va_end()
inside the function is almost certainly wrong.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Add the definition of the CAPP microcode for DD2.3 to the lid map.
Cc: skiboot-stable@lists.ozlabs.org # v6.5+
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Tested-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
This replaces several instances dt accesses with higher level
primitives throughout the tree.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
In several cases the make test reference .dts files were incorrectly
byteswapped, these are fixed here too.
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
There are a number of proc_gen branches removed that are trivially
dead code and comments that refer to P7. As well as those:
- Oliver points out that add_xics_icps() must be unused on POWER8
because it asserts if number of threads > 4, so remove it.
- Change 16b7ae641 ("Remove POWER7 and POWER7+ support") removed all
references to opal_boot_trampoline, so remove that.
- It also removed the only non-trival choose_bus implementation, so
that is removed and its caller simplified.
- Remove the paca code, later CPUs use pcia.
Cc: Stewart Smith <stewart@flamingspork.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
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>
|
|
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>
|
|
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>
|
|
Below message is confusing. Lets make it clear.
FSP sends "R/R complete notification" whenever there is a dump. We use `flag`
to identify whether its its R/R completion -OR- just new dump notification.
[ 483.406351956,6] FSP: SP says Reset/Reload complete
[ 483.406354278,5] DUMP: FipS dump available. ID = 0x1a00001f [size: 6367640 bytes]
[ 483.406355968,7] A Reset/Reload was NOT done
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
hw/fsp/fsp.c:1011:17: warning: passing an object that undergoes default argument promotion to
'va_start' has undefined behavior [-Wvarargs]
va_start(list, add_words);
^
hw/fsp/fsp.c:1007:59: note: parameter of type 'u8' (aka 'unsigned char') is declared here
void fsp_fillmsg(struct fsp_msg *msg, u32 cmd_sub_mod, u8 add_words, ...)
^
[CC] platforms/ibm-fsp/apollo-pci.o
hw/fsp/fsp.c:1026:17: warning: passing an object that undergoes default argument promotion to
'va_start' has undefined behavior [-Wvarargs]
va_start(list, add_words);
^
hw/fsp/fsp.c:1016:47: note: parameter of type 'u8' (aka 'unsigned char') is declared here
struct fsp_msg *fsp_mkmsg(u32 cmd_sub_mod, u8 add_words, ...)
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Add support to load the imc catalog from a lid file packaged
as part of the system firmware. Lid number allocated
is 0x80f00103.lid.
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Update fsp_lid_map to include CAPP ucode lid for phb4-chipid ==
0x202d1 that corresponds to P9 DD-2.2 chip.
Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Reviewed-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
a. Surveillance response times out and OPAL triggers a HIR
b. Before the HIR process kicks in, OPAL gets a PSI interrupt indicating link down
c. HIR process continues and OPAL tries to write to DRCR; PSI link inactive => xstop
OPAL should confirm that the FSP is not already in reset in the HIR path.
[V2] Handle the case where a second reset is triggered due to the two resets
happening in succession.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Tested-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Commit 42d5d047 fixed scenario where DPO has been initiated, but FSP went
into reset before the CEC power down came in. But this is generic issue
that can happen in normal shutdown path as well.
Hence disable PSI link as soon as we detect FSP impending R/R.
CC: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
CC: Stewart Smith <stewart@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Update fsp_lid_map to include CAPP ucode lids for phb4-chipid ==
0x200d1 and phb4-chipid == 0x201d1 that corresponds to P9 DD-2.0 &
DD-2.1 chips respectively.
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
OPAL sends MBOX message to FSP and updates message state from fsp_msg_queued
-> fsp_msg_sent. fsp_sync_msg() queues message and waits until we get response
from FSP. During FSP R/R we move outstanding MBOX messages from msgq to rr_queue
including inflight message (fsp_reset_cmdclass()). But we are not resetting
inflight message state.
In extreme croner case where we sent message to FSP via fsp_sync_msg() path
and FSP R/R happens before getting respose from FSP, then we will endup waiting
in fsp_sync_msg() until everything becomes normal.
This patch adds fsp_in_rr() check to fsp_sync_msg() and return error to caller
if FSP is in R/R.
CC: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Acked-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
CAPP microcode flash download and CAPP upload for PHB4.
A new file 'capp.c' is created to receive common capp code for PHB3 and
PHB4.
Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
For timed out FSP messages, we set message status as "fsp_msg_timeout".
But most FSP driver users (like surviellance) are ignoring this field.
They always look for FSP returned status value in callback function
(second byte in word1). So we endup treating timed out message as success
response from FSP.
Sample output:
[69902.432509048,7] SURV: Sending the heartbeat command to FSP
[70023.226860117,4] FSP: Response from FSP timed out, word0 = d66a00d7, word1 = 0 state: 3
....
[70023.226901445,7] SURV: Received heartbeat acknowledge from FSP
[70023.226903251,3] FSP: fsp_trigger_reset() entry
Here SURV code thought it got valid response from FSP. But actually we didn't
receive response from FSP.
This patch fixes above issue by updating status field in response structure.
CC: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Acked-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Presently we print word0 and word1 in error log. word0 contains
sequence number and command class. One has to understand word0
format to identify command class.
Lets explicitly print command class, sub command etc.
CC: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Acked-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Trigging a Host Initiated Reset (when the host detects the FSP has gone
out to lunch and should be rebooted), would cause "Unknown Command" messages
to appear in the OPAL log.
This patch implements those messages
How to trigger FSP RR(HIR):
$ putmemproc 300000f8 0x00000000deadbeef
s1 k0:n0:s0:p00
ecmd_ppc putmemproc 300000f8 0x00000000deadbeef
Log showing unknown command:
/ # cat /sys/firmware/opal/msglog | grep -i ,3
[ 110.232114723,3] FSP: fsp_trigger_reset() entry
[ 188.431793837,3] FSP #0: Link down, starting R&R
[ 464.109239162,3] FSP #0: Got XUP with no pending message !
[ 466.340598554,3] FSP-DPO: Unknown command 0xce0900
[ 466.340600126,3] FSP: Unhandled message ce0900
The message we need to handle is "Get PLID after host initiated FipS
reset/reload". When the FSP comes back from HIR, it asks "hey, so, which
error log explains why you rebooted me?". So, we tell it.
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
During FSP R/R, the FSP is inaccessible and will lose state. Messages to the
FSP are generally queued for sending later.
It does seem like the FSP fails to process any subseuqent messages of certain
classes (SP info -- ipmi) if it receives queued mbox messages it isn't expecting.
In certain other cases (sensors), the FSP driver returns a default code (async
completion) even though there is no known bound from the time of this error
return to the actual data being available. The kernel driver keeps waiting
leading to soft-lockup on the host side.
Mitigate both these (known) cases by returning OPAL_BUSY so the host driver
knows to retry later.
With this change, the sensors command works fine when the FSP comes back.
This version also resolves the remaining IPMI issues
Signed-off-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Tested-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
If we were to terminate in a poller, we'd call op_display() which
called pollers which hit the recursive poller warning, which ended
in not much fun at all.
This patch will skip the running of pollers and instead run
the FSP poller to set the op-panel display before attn.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
I was only ever set to true
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
fsp_allocmsg() returns true even if msg->resp memory allocation fails.
Validate msg->resp memory allocation as well.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Reviewed-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Philippe Bergheaud <felix@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Since we are anyway on the way to standby and apparently the other
hypervisor also does this.
Tested-by: Vipin K Parashar <vipin@linux.vnet.ibm.com>
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In a scenario where the DPO has been initiated, but the FSP then went into
reset before the CEC power down came in, OPAL may not give up the link since
it may never see the PSI interrupt. So, if we are in dpo_pending and an FSP
reset is detected via the DISR, give up the PSI link voluntarily.
Tested-by: Vipin K Parashar <vipin@linux.vnet.ibm.com>
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In the event that we had no IO paths up, we could index -1 into the
array of iopaths, no doubt causing casual amounts of fun.
Although, since this is in early boot code only, the possibility of
this being a problem is quite slim.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
See https://github.com/lucasdemarchi/codespel
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
There are now no users of the call_out parameter and future users should
use the log_append_msg() and log_append_data() functions, so remove all
references to call_out.
Signed-off-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Safety check...
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This means VPD LID is already loaded before we start preloading
kernel and initramfs LIDs, thus ensuring VPD doesn't have to wait
for them to finish being read from FSP.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Now that opal.h includes opal-api.h, there are a bunch of files that
include both but don't need to.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
commit c789772 introduced an asynchronous mechanism to load LID resource for
FSP systems. But after this change some of the FSP based system failed
to load/boot petitboot kernel.
While fetching LID resource in multiple chunks, we depend on return
status from FSP whether there is more data available to fetch or not.
As per FSP mailbox documentation, fetch cmd returns status=2 which means,
there is more data pending, and status=0 means we have reached end-of-file.
But in reality FSP don't behave as per the document. It looks like we
always get status=0 irrespective of whether end of file is reached or not.
The old implementation (fsp_sync_msg) used to rely on (wlen < chunk) check
to decide whether we reached end of file or not.
Ideally, FSP folks should be fix their code as per documentation. But until
they do, adding the old check back here again.
Without this patch some system won't be able to boot into petitboot kernel.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This moves away from using fsp_sync_msg in fsp_fetch_data and instead
using the platform hooks for start_preload_resource() to actually queue
up a load and having the plumbing for checking if a resource is loaded yet.
This gets rid of the "pollers called with locks held" warning we got
heaps of previously. You can now boot some FSP systems without getting
this warning at all.
This also sets the stage for starting load of LIDs much earlier to when
they're needed, improving boot time.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
No functional changes in what happens, just have two calls, one for
queueing preload the other for waiting until it has loaded.
future patches will introduce platform specific queueing.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
During Reset/Reload, we currently enable FSP interrupts on PSIHBCR
even before the DISR handshake is complete. Fix that.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
hw/fsp/fsp.c:920:13: warning: function 'fsp_fillmsg' with external linkage has definition
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Acked-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Add ability to read CAPI microcode to load_resource() implementations. We use
the cfam chipid as the subid.
FSP load_resource() contains a map of cfam chipid to lid numbers.
PNOR load_resource() doesn't change, but requires a properly formatted
partition with EC values in the TOC matching the appropriate cfam chipid.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|