skiboot v6.3-rc2 release notes

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

1 files changed, 96 insertions, 0 deletions

diff --git a/doc/release-notes/skiboot-6.3-rc2.rst b/doc/release-notes/skiboot-6.3-rc2.rst
new file mode 100644
index 00000000..fe44f667
--- /dev/null
+++ b/doc/release-notes/skiboot-6.3-rc2.rst
@@ -0,0 +1,96 @@
+.. _skiboot-6.3-rc2:
+
+skiboot-6.3-rc2
+===============
+
+skiboot v6.3-rc2 was released on Thursday April 11th 2019. It is the second
+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.
+
+skiboot v6.3-rc2 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-rc1`, we have the following changes:
+
+- libflash/ipmi-hiomap: Fix blocks count issue
+
+  We convert data size to block count and pass block count to BMC.
+  If data size is not block aligned then we endup sending block count
+  less than actual data. BMC will write partial data to flash memory.
+
+  Sample log ::
+
+    [  594.388458416,7] HIOMAP: Marked flash dirty at 0x42010 for 8
+    [  594.398756487,7] HIOMAP: Flushed writes
+    [  594.409596439,7] HIOMAP: Marked flash dirty at 0x42018 for 3970
+    [  594.419897507,7] HIOMAP: Flushed writes
+
+  In this case HIOMAP sent data with block count=0 and hence BMC didn't
+  flush data to flash.
+
+- opal/hmi: Never trust a cow!
+
+  With opencapi, it's fairly common to trigger HMIs during AFU
+  development on the FPGA, by not replying in time to an NPU command,
+  for example. So shift the blame reported by that cow to avoid crowding
+  my mailbox.
+- hw/npu2: Dump (more) npu2 registers on link error and HMIs
+
+  We were already logging some NPU registers during an HMI. This patch
+  cleans up a bit how it is done and separates what is global from what
+  is specific to nvlink or opencapi.
+
+  Since we can now receive an error interrupt when an opencapi link goes
+  down unexpectedly, we also dump the NPU state but we limit it to the
+  registers of the brick which hit the error.
+
+  The list of registers to dump was worked out with the hw team to
+  allow for proper debugging. For each register, we print the name as
+  found in the NPU workbook, the scom address and the register value.
+- hw/npu2: Report errors to the OS if an OpenCAPI brick is fenced
+
+  Now that the NPU may report interrupts due to the link going down
+  unexpectedly, report those errors to the OS when queried by the
+  'next_error' PHB callback.
+
+  The hardware doesn't support recovery of the link when it goes down
+  unexpectedly. So we report the PHB as dead, so that the OS can log the
+  proper message, notify the drivers and take the devices down.
+- hw/npu2: Fix OpenCAPI PE assignment
+
+  When we support mixing NVLink and OpenCAPI devices on the same NPU, we're
+  going to have to share the same range of 16 PE numbers between NVLink and
+  OpenCAPI PHBs.
+
+  For OpenCAPI devices, PE assignment is only significant for determining
+  which System Interrupt Log register is used for a particular brick - unlike
+  NVLink, it doesn't play any role in determining how links are fenced.
+
+  Split the PE range into a lower half which is used for NVLink, and an upper
+  half that is used for OpenCAPI, with a fixed PE number assigned per brick.
+
+  As the PE assignment for OpenCAPI devices is fixed, set the PE once
+  during device init and then ignore calls to the set_pe() operation.
+
+- opal-api: Reserve 2 OPAL API calls for future OpenCAPI LPC use
+
+  OpenCAPI Lowest Point of Coherency (LPC) memory is going to require
+  some extra OPAL calls to set up NPU BARs. These calls will most likely be
+  called OPAL_NPU_LPC_ALLOC and OPAL_NPU_LPC_RELEASE, we're not quite ready
+  to upstream that code yet though.
+
+- cpufeatures: Add tm-suspend-hypervisor-assist and tm-suspend-xer-so-bug node
+
+  tm-suspend-hypervisor-assist for P9 >=DD2.2
+  And a tm-suspend-xer-so-bug node for P9 DD2.2 only.
+
+  I also treat P9P as P9 DD2.3 and add a unit test for the cpufeatures
+  infrastructure.
+
+  Fixes: https://github.com/open-power/skiboot/issues/233