[Skiboot] skiboot-5.5.0-rc2 released
Stewart Smith
stewart at linux.vnet.ibm.com
Tue Apr 4 12:57:37 AEST 2017
I tagged and pushed 5.5.0-rc2 today.
If all goes well, there'll be one or two small things to merge before
the final 5.5.0.
release notes below:
.. _skiboot-5.5.0-rc2:
skiboot-5.5.0-rc2
=================
skiboot-5.5.0-rc2 was released on Monday April 3rd 2017. It is the second
release candidate of skiboot 5.5, which will become the new stable release
of skiboot following the 5.4 release, first released November 11th 2016.
skiboot-5.5.0-rc2 contains all bug fixes as of :ref:`skiboot-5.4.3`
and :ref:`skiboot-5.1.19` (the currently maintained stable releases).
For how the skiboot stable releases work, see :ref:`stable-rules` for details.
The current plan is to cut the final 5.5.0 by April 8th, with skiboot 5.5.0
being for all POWER8 and POWER9 platforms in op-build v1.16 (Due April 12th).
This is a short cycle as this release is mainly targetted towards POWER9
bringup efforts.
Following skiboot-5.5.0, we will move to a regular six week release cycle,
similar to op-build, but slightly offset to allow for a short stabilisation
period. Expected release dates and contents are tracked using GitHub milestone
and issues: https://github.com/open-power/skiboot/milestones
Over :ref:`skiboot-5.5.0-rc1`, we have the following changes:
NVLINK2
-------
- Introduce NPU2 support
NVLink2 is a new feature introduced on POWER9 systems. It is an
evolution of of the NVLink1 feature included in POWER8+ systems but
adds several new features including support for GPU address
translation using the Nest MMU and cache coherence.
Similar to NVLink1 the functionality is exposed to the OS as a series
of virtual PCIe devices. However the actual hardware interfaces are
significantly different which limits the amount of common code that
can be shared between implementations in the firmware.
This patch adds basic hardware initialisation and exposure of the
virtual NVLink2 PCIe devices to the running OS.
- npu2: Add OPAL calls for nvlink2 address translation services (see :ref:`OPAL_NPU2`)
Adds three OPAL calls for interacting with NPU2 devices:
:ref:`OPAL_NPU_INIT_CONTEXT`, :ref:`OPAL_NPU_DESTROY_CONTEXT` and
:ref:`OPAL_NPU_MAP_LPAR`.
These are used to setup and configure address translation services
(ATS) for a process/partition on a given NVLink2 device.
POWER9
------
- hdata/memory: ignore homer and occ reserved ranges
We populate these from the HOMER BARs in the PBA directly. There's no
need to take the hostboot supplied values so just ignore the
corresponding reserved ranges.
- hdata/vpd: Parse the OpenPOWER OPFR record
Parse the OpenPOWER FRU VPD (OPFR) record on OpenPOWER instead
of the VINI records.
- hdata/vpd: Parse additional VINI records
These records provide hardware version details, CCIN extension information,
card type details and hardware characteristics of the FRU
- hdata/cpu: account for p9 shared caches
On P9 the L2 and L3 caches are shared between pairs of SMT=4 cores.
Currently this is not accounted for when creating caches nodes in
the device tree. This patch adds additional checking so that a
cache node is only created for the first core in the pair and
the second core will reference the cache correctly.
- hdata: print backtraces on HDAT errors
- hdat: ignore zero length reserves
Hostboot can export reserved regions with a length of zero and these
should be ignored rather than being turned into reserved range. While
we're here fix a memory leak by moving the "too large" region check
to before we allocate space for the label.
- SLW: Add init for power9 power management
This patch adds new function to init core for power9 power management.
SPECIAL_WKUP_* SCOM registers, if set, can hold the cores from going into
idle states. Hence, clear PPM_SPECIAL_WKUP_HYP_REG scom register for each
core during init. (This init are not required for MAMBO)
PCI
---
- hw/phb3: Adjust ECRC on root port dynamically
The Samsung NVMe adapter is lost when it's connected to PMC 8546 PCIe
switch, until ECRC is disabled on the root port. We found similar issue
prevously when Broadcom adapter is connected to same part of PCIe switch
and it was fixed by commit 60ce59ccd0e9 ("hw/phb3: Disable ECRC on Broadcom
adapter behind PMC switch"). Unfortunately, the commit doesn't fix
the Samsung NVMe adapter lost issue.
This fixes the issues by disable ECRC generation/check on root port
when PMC 8546 PCIe switch ports are found. This can be extended for
other PCIe switches or endpoints in future: Each PHB maintains the
count of PCI devices (PMC 8546 PCIe switch ports currently) which
require to disable ECRC on root port. The ECRC functionality is
enabled when first PMC 8546 switch port is probed and disabled when
last PMC 8546 switch port is destroyed (in PCI hot remove scenario).
Except PHB's reinitialization after complete reset, the ECRC on
root port is untouched.
- core/pci: Fix lost NVMe adapter behind PMC 8546 switch
The NVMe adapter in below PCI topology is lost. The root cause is
the presence bit on its PCI slot is missed, but the PCIe link has
been up. The PCI core doesn't probe the adapter behind the slot,
leading to lost NVMe adapter in the particular case.
- PHB3 root port
- PLX switch 8748 (10b5:8748)
- PLX swich 9733 (10b5:9733)
- PMC 8546 swtich (11f8:8546)
- NVMe adapter (1c58:0023)
This fixes the issue by overriding the PCI slot presence bit with
PCIe link state bit.
- hw/phb4: Locate AER capability position if necessary
- core/pci: Disable surprise hotplug on root port
- core/pci: Ignore PCI slot capability on root port
We are creating PCI slot on root port, where the PCI slot isn't
supported from hardware. For this case, we shouldn't read the PCI
slot capability from hardware. When bogus data returned from the
hardware, we will attempt to the PCI slot's power state or enable
surprise hotplug functionality. All of them can't be accomplished
without hardware support.
This leaves the PCI slot's capability list 0 if PCICAP_EXP_CAP_SLOT
isn't set in hardware (pcie_cap + 0x2). Otherwise, the PCI slot's
capability list is retrieved from hardware (pcie_cap + 0x14).
- phb4: Default to PCIe GEN2 on DD1
Default to PCIe GEN2 link speeds on DD1 for stability.
Can be overridden using nvram pcie-max-link-speed=4 parameter.
- phb3/4: Set max link speed via nvram
This adds an nvram parameter pcie-max-link-speed to configure the max
speed of the pcie link. This can be set from the petitboot prompt
using: ::
nvram -p ibm,skiboot --update-config pcie-max-link-speed=4
This takes preference over anything set in the device tree and is
global to all PHBs.
Tests
-----
- Mambo/Qemu boot tests: expect (and fail) on checkstop
This allows us to fail a lot faster if we checkstop
--
Stewart Smith
OPAL Architect, IBM.
More information about the Skiboot
mailing list