historical/m0-applesillicon.git/xnu-qemu-arm64-5.1.0/roms/skiboot/doc/device-tree/ibm,firmware-versions.rst

ibm,firmware-versions node
==========================

The `ibm,firmware-versions` node contains information on the versions of
various firmware components as they were **during boot**. It **does not**
change if there are pending or runtime updates. It represents (to the best
of boot firmware's ability) what versions of firmware were during this boot.

================= ======== ============================================
Property          Required Value
================= ======== ============================================
version           POWER9   See below
skiboot           N        component version number
occ               N        component version number
buildroot         N        component version number
capp-ucode        N        component version number
petitboot         N        component version number
open-power        N        component version number
hostboot-binaries N        component version number
MACHINE-xml       N        MACHINE (e.g. habanero) machine XML version
hostboot          N        component version number
linux             N        component version number
================= ======== ============================================

``version`` property
^^^^^^^^^^^^^^^^^^^^

This property **must** exist on POWER9 and above systems. It **may** exist
on POWER8 systems.

If this property exists, it **must** conform to this specification.
It's a single version number of the firmware image. In the event of a system
supporting multiple firmware sides, this represents the **default** boot side.
That is, the version that is applicable when determining if a machine
requires a firmware update.

Examples (for three different platforms):

- ``IBM-sandwich-20170217``
- ``open-power-habanero-v1.14-45-g78d89280c3f9-dirty``
- ``open-power-SUPERMICRO-P8DTU-V2.00.GA2-20161028``

To compare two versions (for the purpose of determining if the current
installed firmware is in need of updating to the one being compared against)
we need a defined set of rules on how to do this comparison.

Version numbers are **not** intended to be compared across platforms.

The version string may include a description at the start of it. This
description can contain any set of characters but **must not** contain
a '-' followed by a digit. It also **must not** contain '-v' or '-V' followed
by a digit.

Each part of the version string is separated by a '-' character. Leading
sections are ignored, until one starts with a digit (0-9) or a 'v' or 'V',
followed by a digit. Where there is a leading 'v' or 'V', it is also stripped.

For the above three examples, we'd be left with:

- ``20170217``
- ``1.14-45-g78d89280c3f9-dirty``
- ``2.00.GA2-20161028``

Each section is now compared until a difference is found. All comparisons
are done *lexically*. The lexical comparison sorts in this order: tilde (~),
all letters, non-letters. The tilde is special and sorts before an end of part.
This allows the common usage of designating pre-release builds by a tailing
section beginning with a '~'.

For example: "1.0~20170217", "1.0~rc4" and "1.0~beta1" all sort
**before** "1.0"

Note that "1.0beta" sorts **after** "1.0"

The start of the version string contains an optional *epoch*. If not present,
it is zero. This allows a reset of versioning schemes. All versions with an
epoch of N+1 are greater than those with epoch N, no matter what the version
strings would compare. For example "0:4.0" is **less** than "1:1.0". Increasing
the epoch should **not** be a regular occurance.

For the remainder of the version strings, each part (separated by '.' or '-')
is compared lexically. There are two exceptions: any part beginning with "-g"
or "-p" followed by a hexadecimal string is compared as a string, and if they
are different the versions are determined to be different. For example, the
sections "-g78d89280c3f9" and "-g123456789abc" differ and for all comparisons
(less than, greater than, equal) the result should be true.

For those who have been paying attention, this scheme should look very
familiar to those who are familiar with RPM and Debian package versioning.

The below table shows comparisons between versions and what the result should
be:

=========================== =========================== ====================
A                           B                           Result
=========================== =========================== ====================
1.14-45-g78d89280c3f9-dirty 1.14-45-g78d89280c3f9-dirty Equal
1.14-45-g78d89280c3f9-dirty 1.14-45-g78d89280c3f9       A > B
1.14-45-g78d89280c3f9-dirty 1.14-45-g123456789abc       A < B, A > B, A != B
1.14-45-g78d89280c3f9-dirty 1.14-46                     A < B
1.14-45-g78d89280c3f9-dirty 1.15                        A < B
1.14-45-g78d89280c3f9-dirty 1:1.0                       A < B
1.0                         1.0~daily20170201           A > B
1.0.1                       1.0~daily20170201           A > B
1.0                         1.0.1                       A < B
1.0                         1.0beta                     A < B
=========================== =========================== ====================

Examples
^^^^^^^^

New style (required for POWER9 and above):

.. code-block:: dts

   ibm,firmware-versions {
		version = "open-power-habanero-v1.14-45-g78d89280c3f9-dirty";
		skiboot = "5.4.0";
		occ = "d7efe30";
		linux = "4.4.32-openpower1";
   };

Old-style:

.. code-block:: dts

        ibm,firmware-versions {
                occ = "d7efe30-opdirty";
                skiboot = "5.4.0-opdirty";
                buildroot = "211bd05";
                capp-ucode = "1bb7503-opdirty";
                petitboot = "v1.3.1-opdirty-d695626";
                open-power = "habanero-f7b8f65-dirty";
                phandle = <0x1000012e>;
                hostboot-binaries = "56532f5-opdirty";
                habanero-xml = "6a78496-opdirty-526ff79";
                hostboot = "09cfacb-opdirty";
                linux = "4.4.32-openpower1-opdirty-85cf528";
        };