| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
[ Upstream commit 53408440edb30de7ad18f12db285f15a0863fbc3 ]
A problem was found with the way we manage the I2C signal to reset
adapters. Skiboot currently always drives the value of the opencapi
reset signal. We set the I2C pin for reset in output mode and keep it
in output mode permanently. And since the reset signal is inverted, it
is explicitly set to high by the I2C controller pretty much all the
time.
When the opencapi card is powered off, for example on a reboot,
actively driving the I2C reset pin to high keeps applying a voltage to
part of the FPGA, which can leak current, send the FPGA in a bad state
since it's unexpected or even damage the card. To prevent damaging
adapters, the recommendation from the hardware team is to switch back
the pin to input mode at the end of a reset cycle. There are pull-up
resistors on the planar of all the platforms to make sure the reset
signal is high "naturally". When the slot is powered off, the reset
pin won't be kept high by the i2c controller any more.
Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
[ Upstream commit 80fd2e963bd4364ee8c3b5a06215d8cbdfe04fcb ]
The XSCOM read/write OPAL calls are largely there to support running
PRD in the OS. PRD itself handles submitting error logs (if needed)
when a XSCOM operation fails so there's no need to send an error log
from inside of OPAL.
Cc: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
[ Upstream commit 9be9a77a8352aee0bb74ac0d79f55e1238f76285 ]
A bug in the NVidia driver can cause an UR HMI which fences bricks
(links). At the moment we clear fence status only for bricks of a specific
devices, however this does not appear to be enough and we need to clear
fences for all bricks. This is ok as we do not allow using GPUs
individually anyway.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Acked-by: Reza Arbab <arbab@linux.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
[ Upstream commit 6b512fceb4210d5cf166912ef72c90cd29caec67 ]
The slw patch saving array is too small, which results in slw_reinit
overwriting 32 bytes beyond the end of it. The size is increased to
0x100, which is the architecture interrupt vector size.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
[ Upstream commit a810d1fe7a1631dc1eb211ff70885f044cb40904 ]
The current assert/abort implementation for BMC based system invokes cec
reboot after printing backtrace. This means that BMC never gets notified
about OPAL crash/termination. This sometimes leads into never ending
IPL-ing loop if OPAL keeps aborting very early in boot path.
Trigger a software xstop (OPAL TI) to inform BMC about the OPAL
termination. BMC is capable of catching checkstop signal and facilitate in
rebooting (IPL-ing) host.
With AutoReboot policy, OpenBMC handles checkstop signals and counts them
against the reboot counter. In cases where OPAL is crashing before host
reaches to runtime, OpenBMC will move the system in Quiesced state after 3
or so attempts of IPL/reboot so that system can be debugged. When OPAL
triggers software checkstop it causes all the CPU threads to be stooped and
moved to quiesced state. Hence OPAL don't need to explicitly stop all CPUs
before calling software xstop.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
[ Upstream commit 24664b48642845d620e225111bf6184f3c102f60 ]
The RX clock mux in the NVLink PHY can glitch, which will manifest in
hard to diagnose behavior--at best, a checkstop during the first link
traffic. The only reliable way we found to detect this was by checking
for a discrepancy in the credits we expect to receive during link
training.
Since the time the check was added, we've found that
* Commit ac6f1599ff33 ("npu2: hw-procedures: Add phy_rx_clock_sel()")
does work around the original glitch.
* Asserting is too harsh. Before root cause was established, it was
thought this could have been a manufacturing defect and we wanted to
loudly fail hardware acceptance boot cycle tests.
* It seems there is a valid situation in which credits are off from
the expected value. During GPU hot reset, a CPU prefetch across the link
can affect the credit count before we check.
Given all of the above, remove the assert().
Cc: stable # 6.0.x
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
[ Upstream commit e85e2e2b8b0a4dd96e10343df19df1a161cd6aac ]
If you try to allocate an amount of LPC memory that's not a power of 2,
we round the value up to the nearest power of 2.
By the magic of C, "1 << n" gets treated as an int, even if you're
assigning it to a uint64_t.
Change 1 to 1ULL to fix this.
(C, it's great.)
Reported-by: Alastair D'Silva <alistair@d-silva.org>
Cc: skiboot-stable@lists.ozlabs.org
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
[ Upstream commit 6cf9ace9d69dcb5c37b328625132bc5c9624b778 ]
On Aspeed BMCs can be configured to route LPC IO address 0x80 to a GPIO
port. Some systems use this to implement a boot progress indicator, but
not all of them.
There's no easy way to tell if this has been setup or not and if it
hasn't we get an LPC SYNC no-response error from out LPC master. When we
reach Linux and enable interrupts this results in this spurious error
being printed:
LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010082
lpc_probe_write() is intended to catch situations where the peripherial
being written to might not be configured, so use that instead of
lpc_outb() to squash the error.
Cc: Ranga <stewart@flamingspork.com>
Cc: Andrew Jeffery <andrew@aj.id.au>
Acked-by: Andrew Jeffery <andrew@aj.id.au>
[oliver: fixed the test]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
[ Upstream commit e97391ae2bb5a146a5041453f9185326654264d9 ]
When the maximum number of interrupts per chip is reached,
xive_try_allocate_irq() returns an internal XIVE error:
XIVE_ALLOC_NO_SPACE. But its value 0xffffffff is interpreted as a
positive value by its caller opal_xive_allocate_irq() and not as an
error.
opal_xive_allocate_irq() returns this value to Linux which also
considers 0xffffffff as a valid interrupt number and tries to get the
interrupt characteritics using opal_xive_get_irq_info(). This OPAL
calls finally fails leading to all sort of errors on the host which is
not prepared for such a scenario. Code impacted are the IPI setup and
the both XIVE KVM devices.
Fix by returning OPAL_RESOURCE from xive_try_allocate_irq() which is
consistent with the other errors returned by this routine. This fixes
the behavior in opal_xive_allocate_irq() and in Linux.
A workaround could be introduced in Linux to consider 0xffffffff as a
OPAL_RESOURCE value. This assumption is valid with the current XIVE
IRQ number encoding.
Fixes: 07946e68f47a ("xive: Add interrupt allocator")
Reported-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
[oliver: Added fixes tag]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
There is a MIN() macro definition in skiboot.h. Remove the redundant
definition from here and use that one.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Acked-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
The max() macro definition incorrectly returns the minimum value. The
max() macro is used to ensure that PERST has been asserted for 250ms and
that we wait 100ms seconds for the ETU logic in the CRESET_START PHB4
PCI slot state. However, by returning the minimum value there is no
guarantee that either of these requirements are met.
Correct macro definitions for MIN and MAX are already provided in
skiboot.h. Remove the redundant/incorrect versions here and switch to
using the standard ones.
Fixes: 70edcbb4b39d ("hw/phb4: Skip FRESET PERST when coming from
CRESET")
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
While the the ETU is in reset we cannot access any of the PHB registers.
If a PHB register is accessed via the XSCOM indirect interface then
we'll cause an ETU reset error which may prevent the PHB from being
re-initialised once the reset is lifted.
Prevent register accesses while in reset by adding a flag that is set
while the ETU reset bit is high and checking that flag in the XSCOM
(ASB) backdoor register access path.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Helping someone troubleshoot a Garrison machine, I noticed some of the
BDFs printed here are wrong:
npu_dev_bind_pci_dev: No PCI device for NPU device 0004:00:00.0 to bind to. If you expect a GPU to be there, this is a problem.
npu_dev_bind_pci_dev: No PCI device for NPU device 0004:00:01.0 to bind to. If you expect a GPU to be there, this is a problem.
npu_dev_bind_pci_dev: No PCI device for NPU device 0004:00:04.0 to bind to. If you expect a GPU to be there, this is a problem.
npu_dev_bind_pci_dev: No PCI device for NPU device 0004:00:05.0 to bind to. If you expect a GPU to be there, this is a problem.
Change the prlog() call to print them correctly.
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
List all 16 ATSD registers in the device tree, not just the first 8.
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Enable powerbus snooping here, or else MMIO to any NTL/NDL registers
will cause a checkstop.
This was not an issue in Simics simulation, but discovered rather
quickly during bringup on a real Axone chip.
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
The SM blocks have multiple MISC_CFG registers. For example, there are
both CS.SM0.MCP.MISC.CONFIG0 and CS.SM0.SNP.MISC.CONFIG0. Rename our
macro for the former to more clearly reflect this and avoid a clash when
the latter is added.
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Currently when the Function Number bits of a BDF are needed the bit
operations to get it are free coded. There are many places where the
Function Number is used, so make a macro to use instead of free coding
it everytime.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Currently when the Device Number bits of a BDF are needed the bit
operations to get it are free coded. There are many places where the
Device Number is used, so make a macro to use instead of free coding it
everytime.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Currently when the Bus Number bits of a BDF are needed the bit
operations to get it are free coded. There are many places where the
Bus Number is used, so make a macro to use instead of free coding it
everytime.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
The P9 pervasive spec uses the term "EP" to refer to the combination of
an EQ chiplet and its two child EX chiplets. Nothing else seems to use
the term EP and in Skiboot all the uses of the XSCOM_ADDR_P9_EP() macro
are to translate the address of EQ specific SCOM registers.
Change the name of our address calculation macros to match the general
terminology to make what it does clearer.
Cc: Anju T Sudhakar <anju@linux.vnet.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
During boot SBE and early hostboot does not use HIOMAP protocol to get image
from PNOR. Instead it expects PNOR TOC and Hostboot Boot Loader to be
available at particular address in LPC bus. mbox daemon in BMC side takes
care of this during normal boot. Once boot is complete mbox daemon switches
to normal mode.
During normal reboot, BMC side mbox daemon gets notification and takes care of
loading PNOR TOC and HBBL to LPC bus again.
In MPIPL path, OPAL calls SBE S0 interrupt to initiate MPIPL. BMC will not be
aware of this. But SBE expects PNOR TOC and HBBL to be available in LPC bus at
predefined address. Hence call HIOMAP Reset from OPAL in assert path.
This needs working LPC and IPMI driver in OPAL. If we have issue in these
drivers then we may not be able to reset BMC MBOX properly. Hence MPIPL may
fail. We have to live with this until we find a way to intiate BMC on MPIPL.
CC: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
[oliver: rebased]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Crashing CPU PIR is required to get proper backtrace from core file.
Save crashing CPU PIR before triggering MPIPL. Post MPIPL OPAL will
pass saved PIR to kernel and kernel will use that to create OPAL dump.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
[oliver: rebased]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
On FSP based system we call 'attn' instruction. FSP detects attention and
initiates memory preserving IPL. On BMC system we have to call SBE S0
interrupt to initiate memory preserving IPL.
This patch adds support to call SBE S0 interrupt in assert path.
Sequence :
- S0 interrupt on secondary chip SBE
- S0 interrupt on primary chip SBE
Note that this is hooked to ipmi_terminate path. We have HDAT flag for MPIPL
support. If MPIPL is not supported then we don't create 'ibm,opal/dump' node
and we will fall back to existing termination flow.
Finally we want to log error log to BMC before triggerring MPIPL. Hence this
patch re-organizes ipmi_terminate() such that we call ipmi_log_terminate_event()
before triggering MPIPL.
Note:
- At present we do not have a proper way to detect SBE is alive or not.
So we wait for predefined time and then call normal reboot.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
[oliver: rebased]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
OPAL relocates itself during boot. During memory preserving IPL hostboot needs
to access relocated OPAL base address to get MDST, MDDT tables. Hence send
relocated base address to SBE via 'stash MPIPL config' chip-op. During next
IPL SBE will send stashed data to hostboot... so that hostboot can access
these data.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
[oliver: rebased]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
The MPIPL facility needs to store region and type information
corresponding with each MDST entry.
- data region : dump data regions (like DUMP_REGION_* )
- dump type : Reflects MDST entry usage (used by SYSDUMP -OR- FADUMP)
The existing type field is currently not used by FSP and/or firmware, so it
is safe to re-purpose it.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
[oliver: rebased]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
MDST is a ntuple inside SPIRAH. Its just a interface to pass memory ranges
to be captured as part of dump to FSP/Hostboot. Today OPAL is using MDST
ntuple to pass list of memory region (mostly OPAL console and host dmesg)
to be collected as part of SYSDUMP. Soon we are going to support OPAL MPIPL
feature (aka Memory Preserving IPL). Even MPIPL uses MDST/MDDT table.
Hence rename files based on feature instead of some table name:
- fsp-mdst-table.c -> fsp-sysdump.c
- fsp-mdst-table.h -> opal-dump.h (This will cater both SYSDUMP and MPIPL)
- Rename structure -> dump_mdst_table -> mdst_table
This patch does renaming and header file adjustment. No functionality changes.
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
[oliver: rebased]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Unlike POWER8, nominal frequency is not the highest guaranteed
frequency of the POWER9 chip. In POWER9, the highest guaranteed
frequency is greater than the nominal frequency and is referred
to as base frequency. In POWER9 base frequency is the highest
frequency the processor will operate at when ALL cores are active
and in ANY operating condition. This patch exports the turbo pstate
as the base frequency as per OCC documentation.
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
[oliver: delete ibm,pstate-base on fast reboot]
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
When sending messages to the SBE we log the message using a multi-line
log message that looks like this:
[ 96.390873752,8] SBE: Message queued [chip id = 0x0]:
Reg0 : 000002010054d401
Reg1 : 0000000000030d40
Reg2 : 0000000000000000
Reg3 : 0000000000000000
The lack of a common prefix makes the log messages annoying to deal with
since you can just grep for SBE: to get all the SBE related messages,
and you can't use grep -v to remove them. There's no real benifit to
squashing all this into a single prlog() call, so use a for loop to
print the registers. With this patch the output is:
[ 93.253511545,8] SBE: Message queued [chip id = 0x0]:
[ 93.253512343,8] SBE: Reg0 : 000002010059d401
[ 93.253513167,8] SBE: Reg1 : 0000000000030d40
[ 93.253513894,8] SBE: Reg2 : 0000000000000000
[ 93.253514627,8] SBE: Reg3 : 0000000000000000
Cc: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Acked-by: Stewart Smith <stewart@linux.ibm.com>
Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
|
|
A few years ago, the OpenBMC code added support for a "heartbeat"
command to send to the host. This command is used after the BMC is reset
to check if the host is running. Support was never added to the host
side however so currently when the BMC sends this command, this appears
in the host console:
IPMI: unknown OEM SEL command ff received
There is no response needed by the host (other then the low level
acknowledge of the command which already occurs). This commit
handles the command so the error is no longer printed (does nothing with
the command though since no action is needed). Here's the tested output
of this patch in the host console (with debug enabled):
IPMI: BMC issued heartbeat command: 00
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
Convert the npu3 files to use SPDX headers.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
POWER9P systems have been upgraded with NVLink 3.0 interconnects. The
underlying hardware is fundamentally different--each POWER9 chip has
(1 NPU) * (3 stacks) * (2 bricks) = (6 links)
Where in each POWER9P chip, there are
(3 NPUs) * (4 bricks) = (12 links)
This flatter hierarchy simplifies the firmware implementation a bit, but
also prevents sharing much common code with npu2.
As in previous versions, initialize the hardware and expose each link to
the OS as a virtual PCIe device. This initial support covers NVLink
devices only, with OpenCAPI to follow.
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
To prepare for npu3, add a few checks in codepaths that are only for
npu2. Compare against PVR_TYPE_P9, as npu3 will be in systems of
PVR_TYPE_P9P (or greater). Alternatively, check for dt compatibility
with "ibm,power9-npu" because npu3 will use "ibm,power9-npu3".
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Abstract the OPAL entry points for npu2, moving them to a new file. This
prepares us to add parallel npu3 versions of the same APIs.
No functional change.
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Move this to a separate compilation unit with its own header, for reuse.
The code formerly in npu2.c is copied verbatim. The #defines formerly in
npu2-regs.h have been reformatted and changed to use PPC_BITMASK()
instead of multiple consecutive PPC_BIT()s.
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Stewart Smith <stewart@linux.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
Add the physical memory map for Axone systems. According to
'make hw-check', there are no holes or overlapping regions.
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Acked-by: Michael Neuling <mikey@neuling.org>
Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Acked-by: Stewart Smith <stewart@linux.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
When new chip types are added, phys_map_init() will need to know which
memory map it should use.
Instead of directly checking PVR, make it an argument to the function,
so that 'make hw-check' can test all the maps.
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Acked-by: Michael Neuling <mikey@neuling.org>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Acked-by: Stewart Smith <stewart@linux.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
How did I notice one dup in aa56d9a2abdb ("Remove duplicate npu-common.o
from $(HW_OBJS)"), but not the other five? Remove them too.
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Reviewed-by: Alistair Popple <alistair@popple.id.au>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.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>
|
|
The embedded controller that Rhesus uses is exclusive to that platform,
make it purely part of tha platform
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
hw/lpc-uart.c:674:47: warning: incorrect type in argument 1 (different base types)
hw/lpc-uart.c:674:47: expected restricted beint32_t [usertype] be_val
hw/lpc-uart.c:674:47: got unsigned int const [usertype]
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
|
|
On NVLink2 bridge reset, we purge all L2/L3 caches in the system.
This is an asynchronous operation, we have a 2ms timeout here. There are
reports that this is not enough and "PURGE L3 on core xxx timed out"
messages appear (for the reference: on the test setup this takes
280us..780us).
This defines the timeout as a macro and changes this from 2ms to 20ms.
This adds a tracepoint to tell how long it took to purge all the caches.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Add support for the pci-eeh-verbose NVRAM flag on PHB3. We've had this
on PHB4 since forever and it has proven very useful when debugging EEH
issues. When testing changes to the Linux kernel's EEH implementation
it's fairly common for the kernel to crash before printing the EEH log
so it's helpful to have it in the OPAL log where it can be dumped from
XMON.
Note that unlike PHB4 we do not enable verbose mode by default. The
nvram option must be used to explicitly enable it.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
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: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
|
|
Now, with CONFIG_FSP=0/1 we have:
1.6M/1.4M skiboot.lid
323K/375K skiboot.lid.xz
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>
|
