aboutsummaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2021-06-24phb4: Disable TCE cache line bufferFrederic Barrat1-0/+1
[ Upstream commit 15b93a301509ba7813343540e25b47ba395674b9 ] This patch implements a circumvention for HW557787. It disables the TCE cache line buffer as, under heavy loads, there's a possibility of an entry being re-allocated incorrectly. Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2021-01-06Revert "mowgli: Limit slot1 to Gen3 by default"LuluTHSu1-1/+0
[ Upstream commit de20b93849c3cdee62ff066e079b5460737e8609 ] This reverts commit 5262cdd1b99f77bca5951fc8132f9795ef0c2b87. When link reset/retrain, this method cannot maintain the max-link-speed limit, so remove it. Signed-off-by: LuluTHSu <Lulu_Su@wistron.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
2020-11-02phb4: Finish removing P9 DD1 workaround on LSIsCédric Le Goater1-1/+0
Commit ad7e9a67c4e4 ("xive/p9: obsolete OPAL_XIVE_IRQ_SHIFT_BUG flags") forgot to remove the internal flag. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-11-02mowgli: Limit slot1 to Gen3 by defaultLuluTHSu1-0/+1
Refer to the spec. of mowgli, limit the slot to Gen3 speed. For mowgli platform spec. Cc: skiboot-stable@lists.ozlabs.org Signed-off-by: LuluTHSu <Lulu_Su@wistron.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01skiboot.lds.S: Move BSS start up a bit to accommodate a larger .dataOliver O'Halloran1-2/+2
Witht addition of libtss and mbedtls the .data section now overlaps the start of the .bss section. Adding a few MB to the offset doesn't hurt. Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01secvar/backend: add edk2 derived key updates processingNayna Jain1-0/+1
As part of secureboot key management, the scheme for handling key updates is derived from tianocore reference implementation[1]. The wrappers for holding the signed update is the Authentication Header and for holding the public key certificate is ESL (EFI Signature List), both derived from tianocore reference implementation[1]. This patch adds the support to process update queue. This involves: 1. Verification of the update signature using the key authorized as per the key hierarchy 2. Handling addition/deletion of the keys 3. Support for dbx (blacklisting of hashes) 4. Validation checks for the updates 5. Supporting multiple ESLs for single variable both for update/verification 6. Timestamp check 7. Allowing only single PK 8. Failure Handling 9. Resetting keystore if the hardware key hash changes [1] https://github.com/tianocore/edk2-staging.git Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Signed-off-by: Eric Richter <erichte@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01secvar/storage: add secvar storage driver for pnor-based p9Eric Richter1-0/+1
This patch implements the platform specific logic for persisting the secure variable storage banks across reboots via the SECBOOT PNOR partition. For POWER 9, all secure variables and updates are stored in the in the SECBOOT PNOR partition. The partition is split into three sections: two variable bank sections, and a section for storing updates. The driver alternates writes between the two variable sections, so that the final switch from one set of variables to the next can be as atomic as possible by flipping an "active bit" stored in TPM NV. PNOR space provides no lock protection, so prior to writing the variable bank, a sha256 hash is calculated and stored in TPM NV. This hash is compared against the hash of the variables loaded from PNOR to ensure consistency -- otherwise a failure is reported, no keys are loaded (which should cause skiroot to refuse to boot if secure boot support is enabled). Signed-off-by: Eric Richter <erichte@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01core/flash.c: add SECBOOT read and write supportClaudio Carvalho1-0/+3
In secure boot enabled systems, the petitboot linux kernel verifies the OS kernel against x509 certificates that are wrapped in secure variables controlled by OPAL. These secure variables are stored in the PNOR SECBOOT partition, as well as the updates submitted for them using userspace tools. This patch adds read and write support to the PNOR SECBOOT partition in a similar fashion to that of NVRAM, so that OPAL can handle the secure variables. Signed-off-by: Claudio Carvalho <cclaudio@linux.ibm.com> Signed-off-by: Eric Richter <erichte@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01secvar: change backend hook interface to take in bank referencesNayna Jain1-5/+17
Previously, backends were implicitly expected to operate on global references to the variable and update banks. This patch changes the interface for this driver to instead take the banks in as an argument. This removes the implict dependency on these references, makes the design consistent with the storage driver, and also will simplify unit testing of these functions. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Signed-off-by: Eric Richter <erichte@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-10-01include/secvar.h: add .lockdown() hook to secvar storage driverEric Richter1-3/+4
Previously, it was implied that the storage driver would lock itself after performing a write action. As this behavior is not particularly clear when reviewing the main secvar flow, this action instead has been made explicit. Signed-off-by: Eric Richter <erichte@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07Add POWER9 Cumulus processor PVR typeVaidyanathan Srinivasan1-0/+15
Add PVR checks and feature mapping for POWER9 Cumulus chip. Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07cpu: Make cpu_get_core_index() return the fused core numberBenjamin Herrenschmidt2-0/+11
cpu_get_core_index() currently uses pir_to_core_id() which returns an EC number always (ie, a normal core number) even in fused core mode. This is inconsistent with cpu_get_thread_index() which returns a thread within a fused core (0...7) on P9. So let's make things consistent and document it. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07cpu: Keep track of the "ec_primary" in big core moreBenjamin Herrenschmidt1-0/+1
The "EC" primary is the primary thread of an EC, ie, the corresponding small core "half" of the big core where the thread resides. It will be necessary for the direct controls to target the right half when doing special wakeups among others. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07chip: Fix pir_to_thread_id for fused coresBenjamin Herrenschmidt1-0/+7
pir_to_core_id() and pir_to_thread_id() are extensively used by the direct controls code and are expected to return the "normal" (non-fused, aka EC) core/thread IDs. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07xive: Set the fused core mode properlyBenjamin Herrenschmidt1-0/+1
Set or clear the fused core mode bit in the XIVE inits properly. While HostBoot is supposed to do it, I prefer not depending on it doing the right thing, since we already configure that register ourselves anyway. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07Add basic P9 fused core supportRyan Grimm3-0/+40
P9 cores can be configured into fused core mode where two core chiplets function as an 8-threaded, single core. So, bump four to eight in boot_entry when in fused core mode and cpu_thread_count in init_boot_cpu. The HID, AMOR, TSCR, RPR require the first active thread on that core chiplet to load the copy for that core chiplet. So, send thread 1 of a fused core to init_shared_sprs in boot_entry. The code checks for fused core mode in the core thead state register and puts a field in struct cpu_thread. This flag is checked when updating the HID and in XIVE code when setting the special bar. For XSCOM, the core ID is the non-fused EX. So, create macros to arrange the bits. It's fairly verbose but somewhat readable. This was tested on a P9 ZZ with 16 fused cores and ran HTX for over 24 hours. Signed-off-by: Ryan Grimm <grimm@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07Fix typos in commentGustavo Romero1-2/+2
Fix two typos in comment describing a member of 'platform' struct. Signed-off-by: Gustavo Romero <gromero@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-08-07Update comments for bit manipulation macrosGustavo Romero1-3/+3
Bit manipulation code was updated but comments related to it were not. This commit updates the comments for the main macros, GET/SETFIELD, to make them match the code. Signed-off-by: Gustavo Romero <gromero@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-06-30mpipl: Delay MPIPL registration until OPAL init is completeVasant Hegde1-0/+3
If OPAL boot fails after MPIPL init (opal_mpipl_init()) then we call MPIPL boot instead of reboot. BMC is not aware of MPIPL. Hence it may result in continuous MPIPL loop (boot -> crash -> MPIPL -> boot). If OPAL boot fails (before loading kernel) then its better to call reboot. So that BMC can detect `n` number of boot failures (generally n = 3) and stop booting. That way we can avoid continuous loop. This patch moves MPIPL init to the end of init process (just before starting kernel). So that if we fail to boot OPAL we call normal reboot. Also this patch introduces new function to detect MPIPL is enabled or not (is_mpipl_enabled()). And in assert() path we check for this function instead of `dump` DT node. So that it will make sure we will not call MPIPL until opal_mpipl_init is complete. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-06-11include/ocmb.h: Add a newline to end of fileNicholas Piggin1-1/+1
Sparse complains about no newline at end of file. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-06-11io: endian annotations and fixNicholas Piggin1-24/+24
Annotate io accessor pointer types with endian. sparse caught a bug in memcpy_from_ci, which is fixed. From: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-06-11core/mce: add support for decoding and handling machine checksNicholas Piggin2-0/+53
This provides an initial facility to decode machine checks into human readable strings, plus a minimum amount of metadata that a handler has to understand in order to deal with the machine check. For now this is only used by skiboot to make MCE reporting nicer, and an ERAT flush recovery attempt which is more about code coverage than really being helpful. *********************************************** Fatal MCE at 00000000300c9c0c .memcmp+0x3c MSR 9000000000141002 Cause: instruction fetch TLB multi-hit error Effective address: 0x00000000300c9c0c ... The intention is to subsequently provide an OPAL API with this information that will enable an OS to implement a machine independent OPAL machine check driver. The code and data tables are derived from Linux code that I wrote, so relicensing is okay. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-06-11core: interrupt markers for stack tracesNicholas Piggin2-1/+7
Use magic marker in the exception stack frame that is used by the unwinder to decode the interrupt type and NIA. The below example trace comes from a modified skiboot that uses virtual memory, but any interrupt type will appear similarly. CPU 0000 Backtrace: S: 0000000031c13580 R: 0000000030028210 .vm_dsi+0x360 S: 0000000031c13630 R: 000000003003b0dc .exception_entry+0x4fc S: 0000000031c13830 R: 0000000030001f4c exception_entry_foo+0x4 --- Interrupt 0x300 at 000000003002431c --- S: 0000000031c13b40 R: 000000003002430c .make_free.isra.0+0x110 S: 0000000031c13bd0 R: 0000000030025198 .mem_alloc+0x4a0 S: 0000000031c13c80 R: 0000000030028bac .__memalign+0x48 S: 0000000031c13d10 R: 0000000030028da4 .__zalloc+0x18 S: 0000000031c13d90 R: 000000003002fb34 .opal_init_msg+0x34 S: 0000000031c13e20 R: 00000000300234b4 .main_cpu_entry+0x61c S: 0000000031c13f00 R: 00000000300031b8 boot_entry+0x1b0 --- OPAL boot --- Signed-off-by: Nicholas Piggin <npiggin@gmail.com> [oliver: the new stackentry fields made our test heaps too small] Signed-off-by: Oliver O'Halloran <oohall@gmail.com> fixup! core: interrupt markers for stack traces
2020-06-11skiboot.lds.S: introduce PAGE_SIZE, use it to lay out sectionsNicholas Piggin1-0/+3
Separate code, data, read-only data, and other significant sections with PAGE_SIZE alignment. This enables memory protection for these sections with a later patch. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-06-11fast-reboot: improve fast reboot sequenceNicholas Piggin1-0/+1
The current fast reboot sequence is not as robust as it could be. It is this: - Fast reboot CPU stops all other threads with direct control xscoms; - it disables ME (machine checks become checkstops); - resets its SPRs (to get HID[HILE] for machine check interrupts) and overwrites exception vectors with our vectors, with a special fast reboot sreset vector that fixes endian (because OS owns HILE); - then the fast reboot CPU enables ME. At this point the fast reboot CPU can handle machine checks with the skiboot handler, but no other cores can if the OS had switched HILE (they'll execute garbled byte swapped instructions and crash badly). - Then all CPUs run various cleanups, XIVE, resync TOD, etc. - The boot CPU, which is not necessarily the same as the fast reboot initiator CPU, runs xive_reset. This is a lot of code to run, including locking and xscoms, with machine check inoperable. - Finally secondaries are released and everyone sets SPRs and enables ME. Secondaries on other cores don't wait for their thread 0 to set shared SPRs before calling into the normal OPAL secondary code. This is mostly okay because the boot CPU pauses here until all secondaries reach their idle code, but it's not nice to release them out of the fast reboot code in a state with various per-core SPRs in flux. Fix this by having the fast reboot CPU not disable ME or reset its SPRs, because machine checks can still be handled by the OS. Then wait until all CPUs are called into fast reboot and spinning with ME disabled, only then reset any SPRs, copy remaining exception vectors, and now skiboot has taken over the machine check handling, then the CPUs enable ME before cleaning up other things. This way, the region with ME disabled and SPRs and exception vectors in flux is kept absolutely minimal, with no xscoms, no MMIOs, and few significant memory modifications, and all threads kept closely in step. There are no windows where a machine check interrupt may execute garbage due to mismatched HILE on any CPU. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-06-11move the __this_cpu register to r16, reserve r13-r15Nicholas Piggin1-1/+6
There have been several bugs between Linux and OPAL caused by both using r13 for their primary per-CPU data address. This patch moves OPAL to use r16 for this, and prevents the compiler from touching r13-r15 (r14,r15 allow Linux to use additional fixed registers in future). This helps code to be a little more robust, and may make crashes in OPAL (or debugging with pdbg or in simulators) easier to debug by having easy access to the PACA. Later, if we allow interrupts (other than non-maskable) to be taken when running in skiboot, Linux's interrupt return handler does not restore r13 if the interrupt was taken in PR=0 state, which would corrupt the skiboot r13 register, so this allows for the possibility, although it will have to become a formal OPAL ABI requirement if we rely on it. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> [oliver: x86_64 has an r13, but not an r16 so the tests broke] Signed-off-by: Oliver O'Halloran <oohall@gmail.com> wip: fix __this_cpu() in the test cases
2020-06-04Disable protected execution facilityRyan Grimm2-0/+7
This patch disables Protected Execution Faciltiy (PEF). This software procedure is needed for the lab because Cronus will be configured to bring the machine up with PEF on. Hostboot has a similar procedure for running with PEF off. Skiboot can run with PEF on but the kernel cannot; the kernel will take a machine check when trying to write a protected resource, such as the PTCR. So, use this until we have an ultravisor, or if we want to use BML with Cronus without UV = 1. Signed-off-by: Ryan Grimm <grimm@linux.ibm.com> Tested-by: Alistair Popple <alistair@popple.id.au> [oliver: replaced bare urfid with a macro for toolchain compatibility] Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-06-03occ: Fix false negatives in wait_for_all_occ_init()Gautham R. Shenoy1-0/+3
Currently the wait_for_all_occ_init() function determines that the OCCs associated with every Chip has been initialized by verifying if the "Valid" bit in pstate table of that OCC is set. However, on chips where all the EX units are guarded, the OCC, even though it is active, does not update the pstate_table. Currently as a result of this, OPAL concludes that the OCC is not functional and not only disable Pstate initialization, but incorrectly report that that OCCs were not initialized, thereby cutting other features such as sensors. Fix this by ensuring that * We check if there is atleast one active EX unit in the chip before checking if the OCC is active. * On platforms with OCC-OPAL communication interface version 0x90 * wait_for_all_occ_init() only checks if the occ_state in the OCC dynamic area is set to "Active State". * move the "Valid" bit check to add_cpu_pstate_properties(), which is where we create the device-tree entries for frequency scaling. Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Tested-by: Pavaman Subramaniyam <pavsubra@in.ibm.com> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-05-26Detect fused core mode and bail outJoel Stanley1-0/+16
Fused code mode is currently not supported in OPAL. Continuing to boot the system would result in errors at later stages of boot. Wait for console to be up and print message for developers to check and fix the system modes. Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Tested-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-05-26platform/mihawk: Tune equalization settings for opencapiFrederic Barrat1-0/+7
The Bittware 250SOC adapter on Mihawk was showing a high count of CRC errors on one of the opencapi slots. The PHY team suggested new equalization settings to correct the errors. All existing adapters have been tested on mihawk to make sure the settings are compatible. However, the new settings should not be used on platforms other than mihawk. The changes specific to mihawk are: - Update the tx_ffe_pre_coeff and tx_ffe_post_coeff input parameters used during zcal - turn off the tx_ffe_boost parameter through scom Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Cc: skiboot-stable@lists.ozlabs.org # skiboot-op940.x Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-05-26opal entry: Fix LE skiboot clobbering r10 argumentNicholas Piggin1-4/+5
Fortunately no OPAL calls seem to use 8 arguments yet. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-04-08hw/ocmb: Add OCMB SCOM supportOliver O'Halloran1-0/+13
Add a driver for the SCOM ranges of the OCMB. Unlike most chips the OCMB has two different (three if you count OpenCAPI config space) register spaces and we need to ensure that the right access size is used on each. Additionally the SCOM interface is a bit non-standard in that a full physical address is passed as the SCOM address rather than a register number so we don't need to perform any address transformations, we just need to verify that the address falls into one of the nominated address ranges. Cc: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-04-08hw/centaur: Convert to use the new scom APIOliver O'Halloran1-2/+2
Currently we assume any xscom_read / write targeted at a chipid with 0x8 as the top four bits is intended to be a centaur SCOM. On non-P8 platforms there is no reason to assume this so covert it to use the new struct scom_controller infrastructure. Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-04-08hw/xscom: Add scom infrastructureOliver O'Halloran1-0/+12
Currently the top nibble of the "part ID" is used to determine the type of a xscom_read() / xscom_write() call. This was mainly done for the benefit of PRD on P8 which would do "targeted" SCOMs to EX (core) chiplets and rely on skiboot to do find the actual scom address. Similarly, PRD also relied on this to access the SCOMs of centaur chips which are accessed via FSI on P8. On P9 PRD moved to only doing non-targeted scoms where it would only ever supply a "part ID" which was the fabric ID of the chip to be SCOMed. The centaur support was also unnecessary since OPAL didn't support any P9 systems with Centaurs. However, on future systems we will have to support memory buffer chips again so we need to expand the SCOM support to accomodate them. To do this, allow skiboot components to register a SCOM read and write() function for chip ID. This will allow us to ensure the P8 EX chiplet and Centaur SCOM code is only ever used on P8, freeing up the Part ID address space for other uses. Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-03-30hw/phb4: Tune GPU direct performance on witherspoon in PCI modeFrederic Barrat1-0/+2
Good GPU direct performance on witherspoon, with a Mellanox adapter on the shared slot, requires to reallocate some dma engines within PEC2, "stealing" some from PHB4&5 and giving extras to PHB3. It's currently done when using CAPI mode. But the same is true if the adapter stays in PCI mode. In preparation for upcoming versions of MOFED, which may not use CAPI mode, this patch reallocates dma engines even in PCI mode for a series of Mellanox adapters that can be used with GPU direct, on witherspoon and on the shared slot only. The loss of dma engines for PHB4&5 on witherspoon has not shown problems in testing, as well as in current deployments where CAPI mode is used. Here is a comparison of the bandwidth numbers seen with the PHB in PCI mode (no CAPI) with and without this patch. Variations on smaller packet sizes can be attributed to jitter and are not that meaningful. # OSU MPI-CUDA Bi-Directional Bandwidth Test v5.6.1 # Send Buffer on DEVICE (D) and Receive Buffer on DEVICE (D) # Size Bandwidth (MB/s) Bandwidth (MB/s) # with patch without patch 1 1.29 1.48 2 2.66 3.04 4 5.34 5.93 8 10.68 11.86 16 21.39 23.71 32 42.78 49.15 64 85.43 97.67 128 170.82 196.64 256 385.47 383.02 512 774.68 755.54 1024 1535.14 1495.30 2048 2599.31 2561.60 4096 5192.31 5092.47 8192 9930.30 9566.90 16384 18189.81 16803.42 32768 24671.48 21383.57 65536 28977.71 24104.50 131072 31110.55 25858.95 262144 32180.64 26470.61 524288 32842.23 26961.93 1048576 33184.87 27217.38 2097152 33342.67 27338.08 Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Cc: skiboot-stable@lists.ozlabs.org # skiboot-op940.x Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-03-30Revert "FSP: Disable PSI link whenever FSP tells OPAL about impending R/R"Vasant Hegde1-0/+1
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>
2020-03-12Re-license contributions from Raptor Computer SystemsOliver O'Halloran2-2/+2
The following files contain contributions from Timothy Pearson at Raptor Computer Systems. He has agreed to re-license these contributions as Dual Apache 2.0 / GPLv2+, so amend the SPDX tag to reflect that. hw/phb4.c include/phb4.h include/platform.h platforms/astbmc/talos.c platforms/astbmc/romulus.c Cc: Timothy Pearson <tpearson@raptorengineering.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-03-12Re-license IBM written files as Apache 2.0 OR GPLv2+Stewart Smith99-99/+99
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>
2020-03-11hw/fsp: Fix GENERIC_FAILURE mailbox status codeOliver O'Halloran1-2/+1
The 0xEF return code is used to tell the hypervisor that the FSP was not able to replicate an NVRAM write to the secondary FSP. The GENERIC_FAILURE is using this code instead of the correct 0xFE code which indicates a generic error condition. We already have a FSP_STATUS_GENERIC_ERROR for 0xFE so convert the existing users of FSP_STATUS_GENERIC_FAILURE to use GENERIC_ERROR and remove the duplicate. Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-02-26errorlog: Replace hardcode value with macroVasant Hegde1-0/+2
Suggested-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-02-26core/platform: Add an explicit fast-reboot typeOliver O'Halloran1-0/+1
The OPAL_CEC_REBOOT2 OPAL call allows a specific type of reboot to be requested. We can use this to allow the OS to request a fast-reboot explicitly rather than relying on nvram hacks to change the default behaviour. Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-02-24PCI: create optional loc-code platform callbackKlaus Heinrich Kiwi1-0/+8
Some platforms (mostly OpenPower-based) will favor a short, slot-label-based string for the "ibm,loc-code" DT property. Other platforms such as ZZ/FSP-based platforms will prefer the fully-qualified slot-location-code for it. This patches creates a new operation on the platform struct, allowing for an optional callback to create the "ibm,loc-code" property in a platform-specific way. If the callback is not defined, use the cleaned-up default that was in use so far. Signed-off-by: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-02-12npu2-opencapi: Allow platforms to identify physical slotsFrederic Barrat1-0/+1
This patch lets each platform define the name of the opencapi slots. It makes it easier to identify which physical card is generating errors or messages in the linux or skiboot log files. The patch provides slot names for mihawk and witherspoon. If the platform doesn't define any, then we default to 'OPENCAPI-xxxx' There are various ways to find out about the slot names: skiboot log lspci command (if the PCI hotplug driver pnv-php is loaded) lshw checking the device tree and probably others.... Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-02-12mpipl: Rework memory reservation for OPAL dumpVasant Hegde1-0/+3
During boot, OPAL reserves memory required to capture OPAL dump and architected register data. During MPIPL, hostboot will copy OPAL dump to this memory. Post MPIPL kernel will use this memory to create opalcore. We use mem_reserve_fw() for this reservation. At present this reservation happens late in the init path. It may clash with memory allocated by local_alloc(). We have two option to fix above issue: - Use local_alloc() for allocating memory for OPAL dump This works fine on first boot. We can use this method to reserve memory. But Post MPIPL we still want to reserve destination memory to make sure no one is stomping this area. Also this reservation might have happened in between other local_allocations. So in Post MPIPL boot allocator may not find enough memory in first region for other local_alloc() requests and may throw mem_alloc() error before trying to allocate from other regions. - Early memory reservation for OPAL dump Allocate and reserve memory just after memory region init. This patch uses second approach to fix reservation issue. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-01-29hw/npu2-opencapi: Support multiple LPC devicesAndrew Donnellan1-5/+2
Currently, we only have a single range for LPC memory per chip, and we only allow a single device to use that range. With upcoming Hostboot/SBE changes, we'll use the chip address extension mask to give us multiple ranges by using the masked bits of the group ID. Each device can now allocate a whole 4TB non-mirrored region. We still don't do >4TB ranges. If the extension mask is not set correctly, we'll fall back to only permitting one device and printing an error suggesting a firmware upgrade. Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-01-29npu3: Register virtual PHBs with static IDsFrederic Barrat2-1/+12
Assigning opal IDs to virtual PHBs dynamically may lead to userland seeing the PCI domain ID for an adapter vary when adding or removing another adapter (GPU or opencapi). This patch switches to using static opal IDs for virtual PHBs, based on their ibm,phb-index property, which was made static by a previous patch. Note that the PCI domain IDs will increase on the second chip (or more, if we had more) because we now reserve 16 IDs per chip for PHBs. This affects Axone only. We don't change anything on P9 and npu2, to avoid altering how domain IDs have been shown on already GA'd platforms. Reviewed-by: Reza Arbab <arbab@linux.ibm.com> Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-01-29npu3: Don't use the device tree to assign the phb-index of the PHBFrederic Barrat1-0/+6
On Axone, there's a 1-to-1 mapping between virtual PHBs and NPUs. We could keep assigning the phb-index of the virtual PHB from the value found in the npu node of the device tree, but to be consistent with P9/npu2 and avoid confusion, this patch assigns the phb-index when the virtual PHB is created, based on the npu index, similarly to what we do on P9. Reviewed-by: Reza Arbab <arbab@linux.ibm.com> Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2020-01-29npu2: Rework phb-index assignments for virtual PHBsFrederic Barrat1-1/+19
Until now, opencapi PHBs were not using the 'ibm,phb-index' property, as it was thought unnecessary. For nvlink, a phb-index was associated to the npu when parsing hdat data, and the nvlink PHB was reusing the same value. It turns out it helps to have the 'ibm,phb-index' property for opencapi PHBs after all. Otherwise it can lead to wrong results on platforms like mihawk when trying to match entries in the slot table. We end up with an opencapi device inheriting wrong properties in the device tree, because match_slot_phb_entry() default to phb-index 0 if it cannot find the property. Though it doesn't seem to cause any harm, it's wrong and a future patch is expected to start using the slot table for opencapi, so it needs fixing. The twist is that with opencapi, we can have multiple virtual PHBs for a single NPU on P9. There's one PHB per (opencapi) brick. Therefore there's no 1-to-1 mapping between the NPU and PHB index and it no longer makes sense to associate a phb-index to a npu. With this patch, opencapi PHBs created under a NPU use a fixed mapping for their phb-index, based on the brick index. The range of possible values is 7 to 12. Because there can only be one nvlink PHB per NPU, it is always using a phb-index of 7. A side effect is that 2 virtual PHBs on 2 different chips can have the same phb-index, which is similar to what happens for 'real' PCI PHBs, but is different from what was happening on a nvlink-only witherspoon so far. Reviewed-by: Reza Arbab <arbab@linux.ibm.com> Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-12-16fix simple sparse warningsNicholas Piggin2-2/+3
Should be no real code change, these mostly update type declarations that sparse complains about. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
2019-12-16add more sparse endian annotationsNicholas Piggin2-3/+3
This fixes quite a few sparse endian annotations across the tree. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
generated by cgit v1.1 at 2024-10-18 18:26:01 +0000