skiboot-5.11 release notes

Signed-off-by: Stewart Smith <stewart@linux.ibm.com>

1 files changed, 828 insertions, 0 deletions

diff --git a/doc/release-notes/skiboot-5.11.rst b/doc/release-notes/skiboot-5.11.rst
new file mode 100644
index 00000000..53eb9baf
--- /dev/null
+++ b/doc/release-notes/skiboot-5.11.rst
@@ -0,0 +1,828 @@
+.. _skiboot-5.11:
+
+skiboot-5.11
+============
+
+skiboot v5.11 was released on Friday April 6th 2018. It is the first
+release of skiboot 5.11, which is now the new stable release
+of skiboot following the 5.10 release, first released February 23rd 2018.
+
+It is *not* expected to keep the 5.11 branch around for long, and instead
+quickly move onto a 6.0, which will mark the basis for op-build v2.0 and
+will be required for POWER9 systems.
+
+It is expected that skiboot 6.0 will follow very shortly. Consider 5.11
+more of a beta release to 6.0 than anything. For POWER9 systems it should
+certainly be more solid than previous releases though.
+
+skiboot v5.11 contains all bug fixes as of :ref:`skiboot-5.10.4`
+and :ref:`skiboot-5.4.9` (the currently maintained stable releases). There
+may be more 5.10.x stable releases, it will depend on demand.
+
+For how the skiboot stable releases work, see :ref:`stable-rules` for details.
+
+Over skiboot-5.10, we have the following changes:
+
+New Platforms
+-------------
+
+- Add VESNIN platform support
+
+  The Vesnin platform from YADRO is a 4 socked POWER8 system with up to 8TB
+  of memory with 460GB/s of memory bandwidth in only 2U. Many kudos to the
+  team from Yadro for submitting their code upstream!
+
+New Features
+------------
+
+- fast-reboot: enable by default for POWER9
+
+  - Fast reboot is disabled if NPU2 is present or CAPI2/OpenCAPI is used
+
+- PCI tunneled operations on PHB4
+
+  - phb4: set PBCQ Tunnel BAR for tunneled operations
+
+    P9 supports PCI tunneled operations (atomics and as_notify) that are
+    initiated by devices.
+
+    A subset of the tunneled operations require a response, that must be
+    sent back from the host to the device. For example, an atomic compare
+    and swap will return the compare status, as swap will only performed
+    in case of success.  Similarly, as_notify reports if the target thread
+    has been woken up or not, because the operation may fail.
+
+    To enable tunneled operations, a device driver must tell the host where
+    it expects tunneled operation responses, by setting the PBCQ Tunnel BAR
+    Response register with a specific value within the range of its BARs.
+
+    This register is currently initialized by enable_capi_mode(). But, as
+    tunneled operations may also operate in PCI mode, a new API is required
+    to set the PBCQ Tunnel BAR Response register, without switching to CAPI
+    mode.
+
+    This patch provides two new OPAL calls to get/set the PBCQ Tunnel
+    BAR Response register.
+
+    Note: as there is only one PBCQ Tunnel BAR register, shared between
+    all the devices connected to the same PHB, only one of these devices
+    will be able to use tunneled operations, at any time.
+  - phb4: set PHB CMPM registers for tunneled operations
+
+    P9 supports PCI tunneled operations (atomics and as_notify) that require
+    setting the PHB ASN Compare/Mask register with a 16-bit indication.
+
+    This register is currently initialized by enable_capi_mode(). But, as
+    tunneled operations may also work in PCI mode, the ASN Compare/Mask
+    register should rather be initialized in phb4_init_ioda3().
+
+    This patch also adds "ibm,phb-indications" to the device tree, to tell
+    Linux the values of CAPI, ASN, and NBW indications, when supported.
+
+    Tunneled operations tested by IBM in CAPI mode, by Mellanox Technologies
+    in PCI mode.
+
+- Tie tm-suspend fw-feature and opal_reinit_cpus() together
+
+  Currently opal_reinit_cpus(OPAL_REINIT_CPUS_TM_SUSPEND_DISABLED)
+  always returns OPAL_UNSUPPORTED.
+
+  This ties the tm suspend fw-feature to the
+  opal_reinit_cpus(OPAL_REINIT_CPUS_TM_SUSPEND_DISABLED) so that when tm
+  suspend is disabled, we correctly report it to the kernel.  For
+  backwards compatibility, it's assumed tm suspend is available if the
+  fw-feature is not present.
+
+  Currently hostboot will clear fw-feature(TM_SUSPEND_ENABLED) on P9N
+  DD2.1. P9N DD2.2 will set fw-feature(TM_SUSPEND_ENABLED).  DD2.0 and
+  below has TM disabled completely (not just suspend).
+
+  We are using opal_reinit_cpus() to determine this setting (rather than
+  the device tree/HDAT) as some future firmware may let us change this
+  dynamically after boot. That is not the case currently though.
+
+Power Management
+----------------
+
+- SLW: Increase stop4-5 residency by 10x
+
+  Using DGEMM benchmark we observed there was a drop of 5-9% throughput with
+  and without stop4/5. In this benchmark the GPU waits on the cpu to wakeup
+  and provide the subsequent data block to compute. The wakup latency
+  accumulates over the run and shows up as a performance drop.
+
+  Linux enters stop4/5 more aggressively for its wakeup latency. Increasing
+  the residency from 1ms to 10ms makes the performance drop <1%
+- occ: Set up OCC messaging even if we fail to setup pstates
+
+  This means that we no longer hit this bug if we fail to get valid pstates
+  from the OCC. ::
+
+    [console-pexpect]#echo 1 > //sys/firmware/opal/sensor_groups//occ-csm0/clear
+    echo 1 > //sys/firmware/opal/sensor_groups//occ-csm0/clear
+    [   94.019971181,5] CPU ATTEMPT TO RE-ENTER FIRMWARE! PIR=083d cpu @0x33cf4000 -> pir=083d token=8
+    [   94.020098392,5] CPU ATTEMPT TO RE-ENTER FIRMWARE! PIR=083d cpu @0x33cf4000 -> pir=083d token=8
+    [   10.318805] Disabling lock debugging due to kernel taint
+    [   10.318808] Severe Machine check interrupt [Not recovered]
+    [   10.318812]   NIP [000000003003e434]: 0x3003e434
+    [   10.318813]   Initiator: CPU
+    [   10.318815]   Error type: Real address [Load/Store (foreign)]
+    [   10.318817] opal: Hardware platform error: Unrecoverable Machine Check exception
+    [   10.318821] CPU: 117 PID: 2745 Comm: sh Tainted: G   M             4.15.9-openpower1 #3
+    [   10.318823] NIP:  000000003003e434 LR: 000000003003025c CTR: 0000000030030240
+    [   10.318825] REGS: c00000003fa7bd80 TRAP: 0200   Tainted: G   M              (4.15.9-openpower1)
+    [   10.318826] MSR:  9000000000201002 <SF,HV,ME,RI>  CR: 48002888  XER: 20040000
+    [   10.318831] CFAR: 0000000030030258 DAR: 394a00147d5a03a6 DSISR: 00000008 SOFTE: 1
+
+
+mbox based platforms
+^^^^^^^^^^^^^^^^^^^^
+
+For platforms using the mbox protocol for host flash access (all BMC based
+OpenPOWER systems, most OpenBMC based systems) there have been some hardening
+efforts in the event of the BMC being poorly behaved.
+
+- mbox: Reduce default BMC timeouts
+
+  Rebooting a BMC can take 70 seconds. Skiboot cannot possibly spin for
+  70 seconds waiting for a BMC to come back. This also makes the current
+  default of 30 seconds a bit pointless, is it far too short to be a
+  worse case wait time but too long to avoid hitting hardlockup detectors
+  and wrecking havoc inside host linux.
+
+  Just change it to three seconds so that host linux will survive and
+  that, reads and writes will fail but at least the host stays up.
+
+  Also refactored the waiting loop just a bit so that it's easier to read.
+- mbox: Harden against BMC daemon errors
+
+  Bugs present in the BMC daemon mean that skiboot gets presented with
+  mbox windows of size zero. These windows cannot be valid and skiboot
+  already detects these conditions.
+
+  Currently skiboot warns quite strongly about the occurrence of these
+  problems. The problem for skiboot is that it doesn't take any action.
+  Initially I wanting to avoid putting policy like this into skiboot but
+  since these bugs aren't going away and skiboot barfing is leading to
+  lockups and ultimately the host going down something needs to be done.
+
+  I propose that when we detect the problem we fail the mbox call and punt
+  the problem back up to Linux. I don't like it but at least it will cause
+  errors to cascade and won't bring the host down. I'm not sure how Linux
+  is supposed to detect this or what it can even do but this is better
+  than a crash.
+
+  Diagnosing a failure to boot if skiboot its self fails to read flash may
+  be marginally more difficult with this patch. This is because skiboot
+  will now only print one warning about the zero sized window rather than
+  continuously spitting it out.
+
+Fast Reboot Improvements
+------------------------
+
+Around fast-reboot we have made several improvements to harden the fast
+reboot code paths and resort to a full IPL if something doesn't look right.
+
+- core/fast-reboot: zero memory after fast reboot
+
+  This improves the security and predictability of the fast reboot
+  environment.
+
+  There can not be a secure fence between fast reboots, because a
+  malicious OS can modify the firmware itself. However a well-behaved
+  OS can have a reasonable expectation that OS memory regions it has
+  modified will be cleared upon fast reboot.
+
+  The memory is zeroed after all other CPUs come up from fast reboot,
+  just before the new kernel is loaded and booted into. This allows
+  image preloading to run concurrently, and will allow parallelisation
+  of the clearing in future.
+- core/fast-reboot: verify mem regions before fast reboot
+
+  Run the mem_region sanity checkers before proceeding with fast
+  reboot.
+
+  This is the beginning of proactive sanity checks on opal data
+  for fast reboot (with complements the reactive disable_fast_reboot
+  cases). This is encouraged to re-use and share any kind of debug
+  code and unit test code.
+- fast-reboot: occ: Only delete /ibm, opal/power-mgt nodes if they exist
+- core/fast-reboot: disable fast reboot upon fundamental entry/exit/locking errors
+
+  This disables fast reboot in several more cases where serious errors
+  like lock corruption or call re-entrancy are detected.
+- capp: Disable fast-reboot whenever enable_capi_mode() is called
+
+  This patch updates phb4_set_capi_mode() to disable fast-reboot
+  whenever enable_capi_mode() is called, irrespective to its return
+  value. This should prevent against a possibility of not disabling
+  fast-reboot when some changes to enable_capi_mode() causing return of
+  an error and leaving CAPP in enabled mode.
+- fast-reboot: occ: Delete OCC child nodes in /ibm, opal/power-mgt
+
+  Fast-reboot in P8 fails to re-init OCC data as there are chipwise OCC
+  nodes which are already present in the /ibm,opal/power-mgt node. These
+  per-chip nodes hold the voltage IDs for each pstate and these can be
+  changed on OCC pstate table biasing. So delete these before calling
+  the re-init code to re-parse and populate the pstate data.
+
+Debugging/SRESET improvemens
+----------------------------
+
+Since :ref:`skiboot-5.11-rc1`:
+
+- core/cpu: Prevent clobbering of stack guard for boot-cpu
+
+  Commit 90d53934c2da ("core/cpu: discover stack region size before
+  initialising memory regions") introduced memzero for struct cpu_thread
+  in init_cpu_thread(). This has an unintended side effect of clobbering
+  the stack-guard cannery of the boot_cpu stack. This results in opal
+  failing to init with this failure message: ::
+
+    CPU: P9 generation processor (max 4 threads/core)
+    CPU: Boot CPU PIR is 0x0004 PVR is 0x004e1200
+    Guard skip = 0
+    Stack corruption detected !
+    Aborting!
+    CPU 0004 Backtrace:
+     S: 0000000031c13ab0 R: 0000000030013b0c   .backtrace+0x5c
+     S: 0000000031c13b50 R: 000000003001bd18   ._abort+0x60
+     S: 0000000031c13be0 R: 0000000030013bbc   .__stack_chk_fail+0x54
+     S: 0000000031c13c60 R: 00000000300c5b70   .memset+0x12c
+     S: 0000000031c13d00 R: 0000000030019aa8   .init_cpu_thread+0x40
+     S: 0000000031c13d90 R: 000000003001b520   .init_boot_cpu+0x188
+     S: 0000000031c13e30 R: 0000000030015050   .main_cpu_entry+0xd0
+     S: 0000000031c13f00 R: 0000000030002700   boot_entry+0x1c0
+
+  So the patch provides a fix by tweaking the memset() call in
+  init_cpu_thread() to skip over the stack-guard cannery.
+- core/lock.c: ensure valid start value for lock spin duration warning
+
+  The previous fix in a8e6cc3f4 only addressed half of the problem, as
+  we could also get an invalid value for start, causing us to fail
+  in a weird way.
+
+  This was caught by the testcases.OpTestHMIHandling.HMI_TFMR_ERRORS
+  test in op-test-framework.
+
+  You'd get to this part of the test and get the erroneous lock
+  spinning warnings: ::
+
+    PATH=/usr/local/sbin:$PATH putscom -c 00000000 0x2b010a84 0003080000000000
+    0000080000000000
+    [  790.140976993,4] WARNING: Lock has been spinning for 790275ms
+    [  790.140976993,4] WARNING: Lock has been spinning for 790275ms
+    [  790.140976918,4] WARNING: Lock has been spinning for 790275ms
+
+  This patch checks the validity of timebase before setting start,
+  and only checks the lock timeout if we got a valid start value.
+
+
+Since :ref:`skiboot-5.10`:
+
+- core/opal: allow some re-entrant calls
+
+  This allows a small number of OPAL calls to succeed despite re-entering
+  the firmware, and rejects others rather than aborting.
+
+  This allows a system reset interrupt that interrupts OPAL to do something
+  useful. Sreset other CPUs, use the console, which allows xmon to work or
+  stack traces to be printed, reboot the system.
+
+  Use OPAL_INTERNAL_ERROR when rejecting, rather than OPAL_BUSY, which is
+  used for many other things that does not mean a serious permanent error.
+- core/opal: abort in case of re-entrant OPAL call
+
+  The stack is already destroyed by the time we get here, so there
+  is not much point continuing.
+- core/lock: Add lock timeout warnings
+
+  There are currently no timeout warnings for locks in skiboot. We assume
+  that the lock will eventually become free, which may not always be the
+  case.
+
+  This patch adds timeout warnings for locks. Any lock which spins for more
+  than 5 seconds will throw a warning and stacktrace for that thread. This is
+  useful for debugging siturations where a lock which hang, waiting for the
+  lock to be freed.
+- core/lock: Add deadlock detection
+
+  This adds simple deadlock detection. The detection looks for circular
+  dependencies in the lock requests. It will abort and display a stack trace
+  when a deadlock occurs.
+  The detection is enabled by DEBUG_LOCKS (enabled by default).
+  While the detection may have a slight performance overhead, as there are
+  not a huge number of locks in skiboot this overhead isn't significant.
+- core/hmi: report processor recovery reason from core FIR bits on P9
+
+  When an error is encountered that causes processor recovery, HMI is
+  generated if the recovery was successful. The reason is recorded in
+  the core FIR, which gets copied into the WOF.
+
+  In this case dump the WOF register and an error string into the OPAL
+  msglog.
+
+  A broken init setting led to HMIs reported in Linux as: ::
+
+    [    3.591547] Harmless Hypervisor Maintenance interrupt [Recovered]
+    [    3.591648]  Error detail: Processor Recovery done
+    [    3.591714]  HMER: 2040000000000000
+
+  This patch would have been useful because it tells us exactly that
+  the problem is in the d-side ERAT: ::
+
+    [  414.489690798,7] HMI: Received HMI interrupt: HMER = 0x2040000000000000
+    [  414.489693339,7] HMI: [Loc: UOPWR.0000000-Node0-Proc0]: P:0 C:1 T:1: Processor recovery occurred.
+    [  414.489699837,7] HMI: Core WOF = 0x0000000410000000 recovered error:
+    [  414.489701543,7] HMI: LSU - SRAM (DCACHE parity, etc)
+    [  414.489702341,7] HMI: LSU - ERAT multi hit
+
+  In future it will be good to unify this reporting, so Linux could
+  print something more useful. Until then, this gives some good data.
+
+NPU2/NVLink2 Fixes
+------------------
+- npu2: Add performance tuning SCOM inits
+
+  Peer-to-peer GPU bandwidth latency testing has produced some tunable
+  values that improve performance. Add them to our device initialization.
+
+  File these under things that need to be cleaned up with nice #defines
+  for the register names and bitfields when we get time.
+
+  A few of the settings are dependent on the system's particular NVLink
+  topology, so introduce a helper to determine how many links go to a
+  single GPU.
+- hw/npu2: Assign a unique LPARSHORTID per GPU
+
+  This gets used elsewhere to index items in the XTS tables.
+- NPU2: dump NPU2 registers on npu2 HMI
+
+  Due to the nature of debugging npu2 issues, folk are wanting the
+  full list of NPU2 registers dumped when there's a problem.
+- npu2: Remove DD1 support
+
+  Major changes in the NPU between DD1 and DD2 necessitated a fair bit of
+  revision-specific code.
+
+  Now that all our lab machines are DD2, we no longer test anything on DD1
+  and it's time to get rid of it.
+
+  Remove DD1-specific code and abort probe if we're running on a DD1 machine.
+- npu2: Disable fast reboot
+
+  Fast reboot does not yet work right with the NPU. It's been disabled on
+  NVLink and OpenCAPI machines. Do the same for NVLink2.
+
+  This amounts to a port of 3e4577939bbf ("npu: Fix broken fast reset")
+  from the npu code to npu2.
+- npu2: Use unfiltered mode in XTS tables
+
+  The XTS_PID context table is limited to 256 possible pids/contexts. To
+  relieve this limitation, make use of "unfiltered mode" instead.
+
+  If an entry in the XTS_BDF table has the bit for unfiltered mode set, we
+  can just use one context for that entire bdf/lpar, regardless of pid.
+  Instead of of searching the XTS_PID table, the NMMU checkout request
+  will simply use the entry indexed by lparshort id instead.
+
+  Change opal_npu_init_context() to create these lparshort-indexed
+  wildcard entries (0-15) instead of allocating one for each pid. Check
+  that multiple calls for the same bdf all specify the same msr value.
+
+  In opal_npu_destroy_context(), continue validating the bdf argument,
+  ensuring that it actually maps to an lpar, but no longer remove anything
+  from the XTS_PID table. If/when we start supporting virtualized GPUs, we
+  might consider actually removing these wildcard entries by keeping a
+  refcount, but keep things simple for now.
+
+CAPI/OpenCAPI
+-------------
+
+Since :ref:`skiboot-5.11-rc1`:
+
+- capi: Poll Err/Status register during CAPP recovery
+
+  This patch updates do_capp_recovery_scoms() to poll the CAPP
+  Err/Status control register, check for CAPP-Recovery to complete/fail
+  based on indications of BITS-1,5,9 and then proceed with the
+  CAPP-Recovery scoms iif recovery completed successfully. This would
+  prevent cases where we bring-up the PCIe link while recovery sequencer
+  on CAPP is still busy with casting out cache lines.
+
+  In case CAPP-Recovery didn't complete successfully an error is returned
+  from do_capp_recovery_scoms() asking phb4_creset() to keep the phb4
+  fenced and mark it as broken.
+
+  The loop that implements polling of Err/Status register will also log
+  an error on the PHB when it continues for more than 168ms which is the
+  max time to failure for CAPP-Recovery.
+
+Since :ref:`skiboot-5.10`:
+
+- npu2-opencapi: Add OpenCAPI OPAL API calls
+
+  Add three OPAL API calls that are required by the ocxl driver.
+
+  - OPAL_NPU_SPA_SETUP
+
+    The Shared Process Area (SPA) is a table containing one entry (a
+    "Process Element") per memory context which can be accessed by the
+    OpenCAPI device.
+
+  - OPAL_NPU_SPA_CLEAR_CACHE
+
+    The NPU keeps a cache of recently accessed memory contexts. When a
+    Process Element is removed from the SPA, the cache for the link must be
+    cleared.
+
+  - OPAL_NPU_TL_SET
+
+    The Transaction Layer specification defines several templates for
+    messages to be exchanged on the link. During link setup, the host and
+    device must negotiate what templates are supported on both sides and at
+    what rates those messages can be sent.
+- npu2-opencapi: Train OpenCAPI links and setup devices
+
+  Scan the OpenCAPI links under the NPU, and for each link, reset the card,
+  set up a device, train the link and register a PHB.
+
+  Implement the necessary operations for the OpenCAPI PHB type.
+
+  For bringup, test and debug purposes, we allow an NVRAM setting,
+  "opencapi-link-training" that can be set to either disable link training
+  completely or to use the prbs31 test pattern.
+
+  To disable link training: ::
+
+    nvram -p ibm,skiboot --update-config opencapi-link-training=none
+
+  To use prbs31: ::
+
+    nvram -p ibm,skiboot --update-config opencapi-link-training=prbs31
+- npu2-hw-procedures: Add support for OpenCAPI PHY link training
+
+  Unlike NVLink, which uses the pci-virt framework to fake a PCI
+  configuration space for NVLink devices, the OpenCAPI device model presents
+  us with a real configuration space handled by the device over the OpenCAPI
+  link.
+
+  As a result, we have to train the OpenCAPI link in skiboot before we do PCI
+  probing, so that config space can be accessed, rather than having link
+  training being triggered by the Linux driver.
+- npu2-opencapi: Configure NPU for OpenCAPI
+
+  Scan the device tree for NPUs with OpenCAPI links and configure the NPU per
+  the initialisation sequence in the NPU OpenCAPI workbook.
+- capp: Make error in capp timebase sync a non-fatal error
+
+  Presently when we encounter an error while synchronizing capp timebase
+  with chip-tod at the end of enable_capi_mode() we return an
+  error. This has an to unintended consequences. First this will prevent
+  disabling of fast-reboot even though CAPP is already enabled by this
+  point. Secondly, failure during timebase sync is a non fatal error or
+  capp initialization as CAPP/PSL can continue working after this and an
+  AFU will only see an error when it tries to read the timebase value
+  from PSL.
+
+  So this patch updates enable_capi_mode() to not return an error in
+  case call to chiptod_capp_timebase_sync() fails. The function will now
+  just log an error and continue further with capp init sequence. This
+  make the current implementation align with the one in kernel 'cxl'
+  driver which also assumes the PSL timebase sync errors as non-fatal
+  init error.
+- npu2-opencapi: Fix assert on link reset during init
+
+  We don't support resetting an opencapi link yet.
+
+  Commit fe6d86b9 ("pci: Make fast reboot creset PHBs in parallel")
+  tries resetting any PHB whose slot defines a 'run_sm' callback. It
+  raises an assert when applied to an opencapi PHB, as 'run_sm' calls
+  the 'freset' callback, which is not yet defined for opencapi.
+
+  Fix it for now by removing the currently useless definition of
+  'run_sm' on the opencapi slot. It will print a message in the skiboot
+  log because the PHB cannot be reset, which is correct. It will all go
+  away when we add support for resetting an opencapi link.
+- capp: Add lid definition for P9 DD-2.2
+
+  Update fsp_lid_map to include CAPP ucode lid for phb4-chipid ==
+  0x202d1 that corresponds to P9 DD-2.2 chip.
+- capp: Disable fast-reboot when capp is enabled
+
+
+PCI
+---
+
+Since :ref:`skiboot-5.11-rc1`:
+
+- phb4: Reset FIR/NFIR registers before PHB4 probe
+
+  The function phb4_probe_stack() resets "ETU Reset Register" to
+  unfreeze the PHB before it performs mmio access on the PHB. However in
+  case the FIR/NFIR registers are set while entering this function,
+  the reset of "ETU Reset Register" wont unfreeze the PHB and it will
+  remain fenced. This leads to failure during initial CRESET of the PHB
+  as mmio access is still not enabled and an error message of the form
+  below is logged: ::
+
+     PHB#0000[0:0]: Initializing PHB4...
+     PHB#0000[0:0]: Default system config: 0xffffffffffffffff
+     PHB#0000[0:0]: New system config    : 0xffffffffffffffff
+     PHB#0000[0:0]: Initial PHB CRESET is 0xffffffffffffffff
+     PHB#0000[0:0]: Waiting for DLP PG reset to complete...
+     <snip>
+     PHB#0000[0:0]: Timeout waiting for DLP PG reset !
+     PHB#0000[0:0]: Initialization failed
+
+  This is especially seen happening during the MPIPL flow where SBE
+  would quiesces and fence the PHB so that it doesn't stomp on the main
+  memory. However when skiboot enters phb4_probe_stack() after MPIPL,
+  the FIR/NFIR registers are set forcing PHB to re-enter fence after ETU
+  reset is done.
+
+  So to fix this issue the patch introduces new xscom writes to
+  phb4_probe_stack() to reset the FIR/NFIR registers before performing
+  ETU reset to enable mmio access to the PHB.
+
+Since :ref:`skiboot-5.10`:
+
+- pci: Reduce log level of error message
+
+  If a link doesn't train, we can end up with error messages like this: ::
+
+    [   63.027261959,3] PHB#0032[8:2]: LINK: Timeout waiting for electrical link
+    [   63.027265573,3] PHB#0032:00:00.0 Error -6 resetting
+
+  The first message is useful but the second message is just debug from
+  the core PCI code and is confusing to print to the console.
+
+  This reduces the second print to debug level so it's not seen by the
+  console by default.
+- Revert "platforms/astbmc/slots.c: Allow comparison of bus numbers when matching slots"
+
+  This reverts commit bda7cc4d0354eb3f66629d410b2afc08c79f795f.
+
+  Ben says:
+  It's on purpose that we do NOT compare the bus numbers,
+  they are always 0 in the slot table
+  we do a hierarchical walk of the tree, matching only the
+  devfn's along the way bcs the bus numbering isn't fixed
+  this breaks all slot naming etc... stuff on anything using
+  the "skiboot" slot tables (P8 opp typically)
+- core/pci-dt-slot: Fix booting with no slot map
+
+  Currently if you don't have a slot map in the device tree in
+  /ibm,pcie-slots, you can crash with a back trace like this: ::
+
+    CPU 0034 Backtrace:
+     S: 0000000031cd3370 R: 000000003001362c   .backtrace+0x48
+     S: 0000000031cd3410 R: 0000000030019e38   ._abort+0x4c
+     S: 0000000031cd3490 R: 000000003002760c   .exception_entry+0x180
+     S: 0000000031cd3670 R: 0000000000001f10 *
+     S: 0000000031cd3850 R: 00000000300b4f3e * cpu_features_table+0x1d9e
+     S: 0000000031cd38e0 R: 000000003002682c   .dt_node_is_compatible+0x20
+     S: 0000000031cd3960 R: 0000000030030e08   .map_pci_dev_to_slot+0x16c
+     S: 0000000031cd3a30 R: 0000000030091054   .dt_slot_get_slot_info+0x28
+     S: 0000000031cd3ac0 R: 000000003001e27c   .pci_scan_one+0x2ac
+     S: 0000000031cd3ba0 R: 000000003001e588   .pci_scan_bus+0x70
+     S: 0000000031cd3cb0 R: 000000003001ee74   .pci_scan_phb+0x100
+     S: 0000000031cd3d40 R: 0000000030017ff0   .cpu_process_jobs+0xdc
+     S: 0000000031cd3e00 R: 0000000030014cb0   .__secondary_cpu_entry+0x44
+     S: 0000000031cd3e80 R: 0000000030014d04   .secondary_cpu_entry+0x34
+     S: 0000000031cd3f00 R: 0000000030002770   secondary_wait+0x8c
+    [   73.016947149,3] Fatal MCE at 0000000030026054   .dt_find_property+0x30
+    [   73.017073254,3] CFAR : 0000000030026040
+    [   73.017138048,3] SRR0 : 0000000030026054 SRR1 : 9000000000201000
+    [   73.017198375,3] HSRR0: 0000000000000000 HSRR1: 0000000000000000
+    [   73.017263210,3] DSISR: 00000008         DAR  : 7c7b1b7848002524
+    [   73.017352517,3] LR   : 000000003002602c CTR  : 000000003009102c
+    [   73.017419778,3] CR   : 20004204         XER  : 20040000
+    [   73.017502425,3] GPR00: 000000003002682c GPR16: 0000000000000000
+    [   73.017586924,3] GPR01: 0000000031c23670 GPR17: 0000000000000000
+    [   73.017643873,3] GPR02: 00000000300fd500 GPR18: 0000000000000000
+    [   73.017767091,3] GPR03: fffffffffffffff8 GPR19: 0000000000000000
+    [   73.017855707,3] GPR04: 00000000300b3dc6 GPR20: 0000000000000000
+    [   73.017943944,3] GPR05: 0000000000000000 GPR21: 00000000300bb6d2
+    [   73.018024709,3] GPR06: 0000000031c23910 GPR22: 0000000000000000
+    [   73.018117716,3] GPR07: 0000000031c23930 GPR23: 0000000000000000
+    [   73.018195974,3] GPR08: 0000000000000000 GPR24: 0000000000000000
+    [   73.018278350,3] GPR09: 0000000000000000 GPR25: 0000000000000000
+    [   73.018353795,3] GPR10: 0000000000000028 GPR26: 00000000300be6fb
+    [   73.018424362,3] GPR11: 0000000000000000 GPR27: 0000000000000000
+    [   73.018533159,3] GPR12: 0000000020004208 GPR28: 0000000030767d38
+    [   73.018642725,3] GPR13: 0000000031c20000 GPR29: 00000000300b3dc6
+    [   73.018737925,3] GPR14: 0000000000000000 GPR30: 0000000000000010
+    [   73.018794428,3] GPR15: 0000000000000000 GPR31: 7c7b1b7848002514
+
+  This has been seen in the lab on a witherspoon using the device tree
+  entry point (ie. no HDAT).
+
+  This fixes the null pointer deref.
+
+Bugs Fixed
+----------
+Since :ref:`skiboot-5.11-rc1`:
+
+- cpufeatures: Fix setting DARN and SCV HWCAP feature bits
+
+  DARN and SCV has been assigned AT_HWCAP2 (32-63) bits: ::
+
+    #define PPC_FEATURE2_DARN               0x00200000 /* darn random number insn */
+    #define PPC_FEATURE2_SCV                0x00100000 /* scv syscall */
+
+  A cpufeatures-aware OS will not advertise these to userspace without
+  this patch.
+- xive: disable store EOI support
+
+  Hardware has limitations which would require to put a sync after each
+  store EOI to make sure the MMIO operations that change the ESB state
+  are ordered. This is a killer for performance and the PHBs do not
+  support the sync. So remove the store EOI for the moment, until
+  hardware is improved.
+
+  Also, while we are at changing the XIVE source flags, let's fix the
+  settings for the PHB4s which should follow these rules :
+
+  - SHIFT_BUG    for DD10
+  - STORE_EOI    for DD20 and if enabled
+  - TRIGGER_PAGE for DDx0 and if not STORE_EOI
+
+Since :ref:`skiboot-5.10`:
+
+- xive: fix opal_xive_set_vp_info() error path
+
+  In case of error, opal_xive_set_vp_info() will return without
+  unlocking the xive object. This is most certainly a typo.
+- hw/imc: don't access homer memory if it was not initialised
+
+  This can happen under mambo, at least.
+- nvram: run nvram_validate() after nvram_reformat()
+
+  nvram_reformat() sets nvram_valid = true, but it does not set
+  skiboot_part_hdr. Call nvram_validate() instead, which sets
+  everything up properly.
+- dts: Zero struct to avoid using uninitialised value
+- hw/imc: Don't dereference possible NULL
+- libstb/create-container: munmap() signature file address
+- npu2-opencapi: Fix memory leak
+- npu2: Fix possible NULL dereference
+- occ-sensors: Remove NULL checks after dereference
+- core/ipmi-opal: Add interrupt-parent property for ipmi node on P9 and above.
+
+  dtc complains below warning with newer 4.2+ kernels. ::
+
+    dts: Warning (interrupts_property): Missing interrupt-parent for /ibm,opal/ipmi
+
+  This fix adds interrupt-parent property under /ibm,opal/ipmi DT node on P9
+  and above, which allows ipmi-opal to properly use the OPAL irqchip.
+
+Other fixes and improvements
+----------------------------
+
+- core/cpu: discover stack region size before initialising memory regions
+
+  Stack allocation first allocates a memory region sized to hold stacks
+  for all possible CPUs up to the maximum PIR of the architecture, zeros
+  the region, then initialises all stacks. Max PIR is 32768 on POWER9,
+  which is 512MB for stacks.
+
+  The stack region is then shrunk after CPUs are discovered, but this is
+  a bit of a hack, and it leaves a hole in the memory allocation regions
+  as it's done after mem regions are initialised. ::
+
+      0x000000000000..00002fffffff : ibm,os-reserve - OS
+      0x000030000000..0000303fffff : ibm,firmware-code - OPAL
+      0x000030400000..000030ffffff : ibm,firmware-heap - OPAL
+      0x000031000000..000031bfffff : ibm,firmware-data - OPAL
+      0x000031c00000..000031c0ffff : ibm,firmware-stacks - OPAL
+      *** gap ***
+      0x000051c00000..000051d01fff : ibm,firmware-allocs-memory@0 - OPAL
+      0x000051d02000..00007fffffff : ibm,firmware-allocs-memory@0 - OS
+      0x000080000000..000080b3cdff : initramfs - OPAL
+      0x000080b3ce00..000080b7cdff : ibm,fake-nvram - OPAL
+      0x000080b7ce00..0000ffffffff : ibm,firmware-allocs-memory@0 - OS
+
+  This change moves zeroing into the per-cpu stack setup. The boot CPU
+  stack is set up based on the current PIR. Then the size of the stack
+  region is set, by discovering the maximum PIR of the system from the
+  device tree, before mem regions are intialised.
+
+  This results in all memory being accounted within memory regions,
+  and less memory fragmentation of OPAL allocations.
+- Make gard display show that a record is cleared
+
+  When clearing gard records, Hostboot only modifies the record_id
+  portion to be 0xFFFFFFFF.  The remainder of the entry remains.
+  Without this change it can be confusing to users to know that
+  the record they are looking at is no longer valid.
+- Reserve OPAL API number for opal_handle_hmi2 function.
+- dts: spl_wakeup: Remove all workarounds in the spl wakeup logic
+
+  We coded few workarounds in special wakeup logic to handle the
+  buggy firmware. Now that is fixed remove them as they break the
+  special wakeup protocol. As per the spec we should not de-assert
+  beofre assert is complete. So follow this protocol.
+- build: use thin archives rather than incremental linking
+
+  This changes to build system to use thin archives rather than
+  incremental linking for built-in.o, similar to recent change to Linux.
+  built-in.o is renamed to built-in.a, and is created as a thin archive
+  with no index, for speed and size. All built-in.a are aggregated into
+  a skiboot.tmp.a which is a thin archive built with an index, making it
+  suitable or linking. This is input into the final link.
+
+  The advantags of build size and linker code placement flexibility are
+  not as great with skiboot as a bigger project like Linux, but it's a
+  conceptually better way to build, and is more compatible with link
+  time optimisation in toolchains which might be interesting for skiboot
+  particularly for size reductions.
+
+  Size of build tree before this patch is 34.4MB, afterwards 23.1MB.
+- core/init: Assert when kernel not found
+
+  If the kernel doesn't load out of flash or there is nothing at
+  KERNEL_LOAD_BASE, we end up with an esoteric message as we try to
+  branch to out of skiboot into nothing ::
+
+      [    0.007197688,3] INIT: ELF header not found. Assuming raw binary.
+      [    0.014035267,5] INIT: Starting kernel at 0x0, fdt at 0x3044ad90 13029
+      [    0.014042254,3] ***********************************************
+      [    0.014069947,3] Fatal Exception 0xe40 at 0000000000000000
+      [    0.014085574,3] CFAR : 00000000300051c4
+      [    0.014090118,3] SRR0 : 0000000000000000 SRR1 : 0000000000000000
+      [    0.014096243,3] HSRR0: 0000000000000000 HSRR1: 9000000000001000
+      [    0.014102546,3] DSISR: 00000000         DAR  : 0000000000000000
+      [    0.014108538,3] LR   : 00000000300144c8 CTR  : 0000000000000000
+      [    0.014114756,3] CR   : 40002202         XER  : 00000000
+      [    0.014120301,3] GPR00: 000000003001447c GPR16: 0000000000000000
+
+  This improves the message and asserts in this case: ::
+
+    [    0.014042685,5] INIT: Starting kernel at 0x0, fdt at 0x3044ad90 13049 bytes)
+    [    0.014049556,0] FATAL: Kernel is zeros, can't execute!
+    [    0.014054237,0] Assert fail: core/init.c:566:0
+    [    0.014060472,0] Aborting!
+- core: Fix 'opal-runtime-size' property
+
+  We are populating 'opal-runtime-size' before calculating actual stack size.
+  Hence we endup having wrong runtime size (ex: on P9 it shows ~540MB while
+  actual size is around ~40MB). Note that only device tree property is shows
+  wrong value, but reserved-memory reflects correct size.
+
+  init_all_cpus() calculates and updates actual stack size. Hence move this
+  function call before add_opal_node().
+
+- mambo: Add fw-feature flags for security related settings
+
+  Newer firmwares report some feature flags related to security
+  settings via HDAT. On real hardware skiboot translates these into
+  device tree properties. For testing purposes just create the
+  properties manually in the tcl.
+
+  These values don't exactly match any actual chip revision, but the
+  code should not rely on any exact set of values anyway. We just define
+  the most interesting flags, that if toggled to "disable" will change
+  Linux behaviour. You can see the actual values in the hostboot source
+  in src/usr/hdat/hdatiplparms.H.
+
+  Also add an environment variable for easily toggling the top-level
+  "security on" setting.
+- direct-controls: mambo fix for multiple chips
+- libflash/blocklevel: Correct miscalculation in blocklevel_smart_erase()
+
+  If blocklevel_smart_erase() detects that the smart erase fits entire in
+  one erase block, it has an early bail path. In this path it miscaculates
+  where in the buffer the backend needs to read from to perform the final
+  write.
+- libstb/secureboot: Fix logging of secure verify messages.
+
+  Currently we are logging secure verify/enforce messages in PR_EMERG
+  level even when there is no secureboot mode enabled. So reduce the
+  log level to PR_ERR when secureboot mode is OFF.
+
+Testing / Code coverage improvements
+------------------------------------
+
+Improvements in gcov support include support for newer GCCs as well
+as easily exporting the area of memory you need to dump to feed to
+`extract-gcov`.
+
+- cpu_idle_job: relax a bit
+
+  This *dramatically* improves kernel boot time with GCOV builds
+
+  from ~3minutes between loading kernel and switching the HILE
+  bit down to around 10 seconds.
+- gcov: Another GCC, another gcov tweak
+- Keep constructors with priorities
+
+  Fixes GCOV builds with gcc7, which uses this.
+- gcov: Add gcov data struct to sysfs
+
+  Extracting the skiboot gcov data is currently a tedious process which
+  involves taking a mem dump of skiboot and searching for the gcov_info
+  struct.
+  This patch adds the gcov struct to sysfs under /opal/exports. Allowing the
+  data to be copied directly into userspace and processed.
+