skiboot v6.3-rc3 release notesv6.3-rc3

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

1 files changed, 228 insertions, 0 deletions

diff --git a/doc/release-notes/skiboot-6.3-rc3.rst b/doc/release-notes/skiboot-6.3-rc3.rst
new file mode 100644
index 0000000..6591e27
--- /dev/null
+++ b/doc/release-notes/skiboot-6.3-rc3.rst
@@ -0,0 +1,228 @@
+.. _skiboot-6.3-rc3:
+
+skiboot-6.3-rc3
+===============
+
+skiboot v6.3-rc3 was released on Thursday May 2nd 2019. It is the third
+release candidate of skiboot 6.3, which will become the new stable release
+of skiboot following the 6.2 release, first released December 14th 2018.
+
+Skiboot 6.3 will mark the basis for op-build v2.3. I expect to tag the final
+skiboot 6.3 in the next week (I also predicted this last time, so take my
+predictions with a large amount of sodium).
+
+skiboot v6.3-rc3 contains all bug fixes as of :ref:`skiboot-6.0.19`,
+and :ref:`skiboot-6.2.3` (the currently maintained
+stable releases).
+
+For how the skiboot stable releases work, see :ref:`stable-rules` for details.
+
+Over :ref:`skiboot-6.3-rc2`, we have the following changes:
+
+
+- Expose PNOR Flash partitions to host MTD driver via devicetree
+
+  This makes it possible for the host to directly address each
+  partition without requiring each application to directly parse
+  the FFS headers.  This has been in use for some time already to
+  allow BOOTKERNFW partition updates from the host.
+
+  All partitions except BOOTKERNFW are marked readonly.
+
+  The BOOTKERNFW partition is currently exclusively used by the TalosII platform
+
+- Write boot progress to LPC port 80h
+
+  This is an adaptation of what we currently do for op_display() on FSP
+  machines, inventing an encoding for what we can write into the single
+  byte at LPC port 80h.
+
+  Port 80h is often used on x86 systems to indicate boot progress/status
+  and dates back a decent amount of time. Since a byte isn't exactly very
+  expressive for everything that can go on (and wrong) during boot, it's
+  all about compromise.
+
+  Some systems (such as Zaius/Barreleye G2) have a physical dual 7 segment
+  display that display these codes. So far, this has only been driven by
+  hostboot (see hostboot commit 90ec2e65314c).
+
+- Write boot progress to LPC ports 81 and 82
+
+  There's a thought to write more extensive boot progress codes to LPC
+  ports 81 and 82 to supplement/replace any reliance on port 80.
+
+  We want to still emit port 80 for platforms like Zaius and Barreleye
+  that have the physical display. Ports 81 and 82 can be monitored by a
+  BMC though.
+
+- Copy and convert Romulus descriptors to Talos
+
+  Talos II has some hardware differences from Romulus, therefore
+  we cannot guarantee Talos II == Romulus in skiboot.  Copy and
+  slightly modify the Romulus files for Talos II.
+
+- npu2: Disable Probe-to-Invalid-Return-Modified-or-Owned snarfing by default
+
+  V100 GPUs are known to violate NVLink2 protocol in some cases (one is when
+  memory was accessed by the CPU and they by GPU using so called block
+  linear mapping) and issue double probes to NPU which can cope with this
+  problem only if CONFIG_ENABLE_SNARF_CPM ("disable/enable Probe.I.MO
+  snarfing a cp_m") is not set in the CQ_SM Misc Config register #0.
+  If the bit is set (which is the case today), NPU issues the machine
+  check stop.
+
+  The snarfing feature is designed to detect 2 probes in flight and combine
+  them into one.
+
+  This adds a new "opal-npu2-snarf-cpm" nvram variable which controls
+  CONFIG_ENABLE_SNARF_CPM for all NVLinks to prevent the machine check
+  stop from happening.
+
+  This disables snarfing by default as otherwise a broken GPU driver can
+  crash the entire box even when a GPU is passed through to a guest.
+  This provides a dial to allow regression tests (might be useful for
+  a bare metal). To enable snarfing, the user needs to run: ::
+
+    sudo nvram -p ibm,skiboot --update-config opal-npu2-snarf-cpm=enable
+
+  and reboot the host system.
+
+- hw/npu2: Show name of opencapi error interrupts
+- core/pci: Use PHB io-base-location by default for PHB slots
+
+  On witherspoon only the GPU slots and the three pluggable PCI slots
+  (SLOT0, 1, 2) have platform defined slot names. For builtin devices such
+  as the SATA controller or the PLX switch that fans out to the GPU slots
+  we have no location codes which some people consider an issue.
+
+  This patch address the problem by making the ibm,slot-location-code for
+  the root port device default to the ibm,io-base-location-code which is
+  typically the location code for the system itself.
+
+  e.g. ::
+
+    pciex@600c3c0100000/ibm,loc-code
+                     "UOPWR.0000000-Node0-Proc0"
+
+    pciex@600c3c0100000/pci@0/ibm,loc-code
+                     "UOPWR.0000000-Node0-Proc0"
+
+    pciex@600c3c0100000/pci@0/usb-xhci@0/ibm,loc-code
+                     "UOPWR.0000000-Node0"
+
+  The PHB node, and the root complex nodes have a loc code of the
+  processor they are attached to, while the usb-xhci device under the
+  root port has a location code of the system itself.
+
+- hw/phb4: Read ibm,loc-code from PBCQ node
+
+  On P9 the PBCQs are subdivided by stacks which implement the PCI Express
+  logic. When phb4 was forked from phb3 most of the properties that were
+  in the pbcq node moved into the stack node, but ibm,loc-code was not one
+  of them. This patch fixes the phb4 init sequence to read the base
+  location code from the PBCQ node (parent of the stack node) rather than
+  the stack node itself.
+- hw/xscom: add missing P9P chip name
+- asm/head: balance branches to avoid link stack predictor mispredicts
+
+  The Linux wrapper for OPAL call and return is arranged like this: ::
+
+      __opal_call:
+          mflr   r0
+          std    r0,PPC_STK_LROFF(r1)
+          LOAD_REG_ADDR(r11, opal_return)
+          mtlr   r11
+          hrfid  -> OPAL
+
+      opal_return:
+          ld     r0,PPC_STK_LROFF(r1)
+          mtlr   r0
+          blr
+
+  When skiboot returns to Linux, it branches to LR (i.e., opal_return)
+  with a blr. This unbalances the link stack predictor and will cause
+  mispredicts back up the return stack.
+- external/mambo: also invoke readline for the non-autorun case
+- asm/head.S: set POWER9 radix HID bit at entry
+
+  When running in virtual memory mode, the radix MMU hid bit should not
+  be changed, so set this in the initial boot SPR setup.
+
+  As a side effect, fast reboot also has HID0:RADIX bit set by the
+  shared spr init, so no need for an explicit call.
+- opal-prd: Fix memory leak in is-fsp-system check
+- opal-prd: Check malloc return value
+- hw/phb4: Squash the IO bridge window
+
+  The PCI-PCI bridge spec says that bridges that implement an IO window
+  should hardcode the IO base and limit registers to zero.
+  Unfortunately, these registers only define the upper bits of the IO
+  window and the low bits are assumed to be 0 for the base and 1 for the
+  limit address. As a result, setting both to zero can be mis-interpreted
+  as a 4K IO window.
+
+  This patch fixes the problem the same way PHB3 does. It sets the IO base
+  and limit values to 0xf000 and 0x1000 respectively which most software
+  interprets as a disabled window.
+
+  lspci before patch: ::
+
+    0000:00:00.0 PCI bridge: IBM Device 04c1 (prog-if 00 [Normal decode])
+            I/O behind bridge: 00000000-00000fff
+
+  lspci after patch: ::
+
+    0000:00:00.0 PCI bridge: IBM Device 04c1 (prog-if 00 [Normal decode])
+            I/O behind bridge: None
+
+- build: link with --orphan-handling=warn
+
+  The linker can warn when the linker script does not explicitly place
+  all sections. These orphan sections are placed according to
+  heuristics, which may not always be desirable. Enable this warning.
+- build: -fno-asynchronous-unwind-tables
+
+  skiboot does not use unwind tables, this option saves about 100kB,
+  mostly from .text.
+- hw/xscom: Enable sw xstop by default on p9
+
+  This was disabled at some point during bringup to make life easier for
+  the lab folks trying to debug NVLink issues. This hack really should
+  have never made it out into the wild though, so we now have the
+  following situation occuring in the field:
+
+  1) A bad happens
+  2) The host kernel recieves an unrecoverable HMI and calls into OPAL to
+     request a platform reboot.
+  3) OPAL rejects the reboot attempt and returns to the kernel with
+     OPAL_PARAMETER.
+  4) Kernel panics and attempts to kexec into a kdump kernel.
+
+  A side effect of the HMI seems to be CPUs becoming stuck which results
+  in the initialisation of the kdump kernel taking a extremely long time
+  (6+ hours). It's also been observed that after performing a dump the
+  kdump kernel then crashes itself because OPAL has ended up in a bad
+  state as a side effect of the HMI.
+
+  All up, it's not very good so re-enable the software checkstop by
+  default. If people still want to turn it off they can using the nvram
+  override.
+- opal/hmi: Initialize the hmi event with old value of TFMR.
+
+  Do this before we fix TFAC errors. Otherwise the event at host console
+  shows no thread error reported in TFMR register.
+
+  Without this patch the console event show TFMR with no thread error:
+  (DEC parity error TFMR[59] injection) ::
+
+    [   53.737572] Severe Hypervisor Maintenance interrupt [Recovered]
+    [   53.737596]  Error detail: Timer facility experienced an error
+    [   53.737611]  HMER: 0840000000000000
+    [   53.737621]  TFMR: 3212000870e04000
+
+  After this patch it shows old TFMR value on host console: ::
+
+    [ 2302.267271] Severe Hypervisor Maintenance interrupt [Recovered]
+    [ 2302.267305]  Error detail: Timer facility experienced an error
+    [ 2302.267320]  HMER: 0840000000000000
+    [ 2302.267330]  TFMR: 3212000870e14010