1 files changed, 118 insertions, 0 deletions
diff --git a/roms/skiboot/doc/release-notes/skiboot-6.0.5.rst b/roms/skiboot/doc/release-notes/skiboot-6.0.5.rst
new file mode 100644
index 000000000..c185015d1
--- /dev/null
+++ b/roms/skiboot/doc/release-notes/skiboot-6.0.5.rst
@@ -0,0 +1,118 @@
+.. _skiboot-6.0.5:
+
+=============
+skiboot-6.0.5
+=============
+
+skiboot 6.0.5 was released on Wednesday July 11th, 2018. It replaces
+:ref:`skiboot-6.0.4` as the current stable release in the 6.0.x series.
+
+It is recommended that 6.0.5 be used instead of any previous 6.0.x version.
+
+Over :ref:`skiboot-6.0.4` we have several bug fixes, including important ones
+for NVLINK2 and NX.
+
+PCI/PHB4
+========
+
+- phb4: Delay training till after PERST is deasserted
+
+  This helps some cards train on the second PERST (ie fast-reboot). The
+  reason is not clear why but it helps, so YOLO!
+- pci: Fix PCI_DEVICE_ID()
+
+  The vendor ID is 16 bits not 8. This error leaves the top of the vendor
+  ID in the bottom bits of the device ID, which resulted in e.g. a failure
+  to run the PCI quirk for the AST VGA device.
+
+  Fixes: 2b841bf0ef1b (present in v5.7-rc1)
+
+PHB4/CAPI
+=========
+- phb4/capp: Calculate STQ/DMA read engines based on link-width for PEC
+
+  Presently in CAPI mode the number of STQ/DMA-read engines allocated on
+  PEC2 for CAPP is fixed to 6 and 0-30 respectively irrespective of the
+  PCI link width. These values are only suitable for x8 cards and
+  quickly run out if a x16 card is plugged to a PEC2 attached slot. This
+  usually manifests as CAPP reporting TLBI timeout due to these messages
+  getting stalled due to insufficient STQs.
+
+  To fix this we update enable_capi_mode() to check if PEC2 chiplet is
+  in x16 mode and if yes then we allocate 4/0-47 STQ/DMA-read engines
+  for the CAPP traffic.
+- capi: Select the correct IODA table entry for the mbt cache.
+
+  With the current code, the capi mmio window is not correctly configured
+  in the IODA table entry. The first entry (generally the non-prefetchable
+  BAR) is overwrriten.
+  This patch sets the capi window bar at the right place.
+
+Sensors
+=======
+
+- occ: sensors: Fix the size of the phandle array 'sensors' in DT
+
+  Fixes: 99505c03f493 (present in v5.10-rc4)
+
+NPU2/NVLINK2
+============
+
+- npu2/hw-procedures: Fence bricks via NTL instead of MISC
+
+  There are a couple of places we can set/unset fence for a brick:
+
+  1. MISC register: NPU2_MISC_FENCE_STATE
+  2. NTL register for the brick: NPU2_NTL_MISC_CFG1(ndev)
+
+  Recent testing of ATS in combination with GPU reset has exposed a side
+  effect of using (1); if fence is set for all six bricks, it triggers a
+  sticky nmmu latch which prevents the NPU from getting ATR responses.
+  This manifests as a hang in the tests.
+
+  We have npu2_dev_fence_brick() which uses (1), and only two calls to it.
+  Replace the call which sets fence with a write to (2). Remove the
+  corresponding unset call entirely. It's unneeded because the procedures
+  already do a progression from full fence to half to idle using (2).
+- opal/hmi: Display correct chip id while printing NPU FIRs.
+
+  HMIs for NPU xstops are broadcasted to all chips. All cores on all the
+  chips receive HMI. HMI handler correctly identifies and extracts the
+  NPU FIR details from affected chip, but while printing FIR data it
+  prints chip id and location code details of this_cpu()->chip_id which
+  may not be correct. This patch fixes this issue.
+
+  Fixes: 7bcbc78c (present in v6.0.1)
+
+VPD
+===
+
+- vpd: Add vendor property to processor node
+
+  Processor FRU vpd doesn't contain vendor detail. We have to parse
+  module VPD to get vendor detail.
+- vpd: Sanitize VPD data
+
+  On OpenPower system, VPD keyword size tells us the maximum size of the data.
+  But they fill trailing end with space (0x20) instead of NULL. Also spec
+  doesn't stop user to have space (0x20) within actual data.
+
+  This patch discards trailing spaces before populating device tree.
+
+NX/VAS for POWER9
+=================
+
+- NX: Add NX coprocessor init opal call
+
+  The read offset (4:11) in Receive FIFO control register is incremented
+  by FIFO size whenever CRB read by NX. But the index in RxFIFO has to
+  match with the corresponding entry in FIFO maintained by VAS in kernel.
+  VAS entry is reset to 0 when opening the receive window during driver
+  initialization. So when NX842 is reloaded or in kexec boot, possibility
+  of mismatch between RxFIFO control register and VAS entries in kernel.
+  It could cause CRB failure / timeout from NX.
+
+  This patch adds nx_coproc_init opal call for kernel to initialize
+  readOffset (4:11) and Queued (15:23) in RxFIFO control register.
+
+  Fixes: 3b3c5962f432 (present in v5.8-rc1)