kernel: Move to 4.13 kernel

We have 236 commits, 127 files changed, 17766 insertions(+), 2128
deletions(-). Some of these are backports from upstream. This list
does not include patches from the 4.13 stable releases, but we do
include those in the dev-4.13 branch.

     1  Alexey Khoroshilov
    34  Andrew Jeffery
     1  Arnd Bergmann
     1  Benjamin Herrenschmidt
     1  Bhumika Goyal
     1  Brad Bishop
     1  Brendan Higgins
     11  Christopher Bostic
     1  Cyril Bur
    14  Cédric Le Goater
    49  Edward A. James
     3  Gavin Shan
     1  Guenter Roeck
     8  Ivan Mikhaylov
     1  Jacek Anaszewski
     1  James Feist
     7  Jeremy Kerr
    72  Joel Stanley
     2  Julia Lawall
     1  Ken Chen
     6  Lei YU
     3  Milton Miller
     1  Mykola Kostenok
     1  Patrick Venture
     2  Philipp Zabel
     1  Rick Altherr
    11  Samuel Mendoza-Jonas
     2  Wei Yongjun
     1  Xo Wang
     1  Yong Li

Note that the 4.13 branch is EOL'd by the Linux community, and as such
should not be used for any products beyond development.

React to removal of occ hwmon instances from device trees with a
new startup/shutdown mechanism for phosphor-hwmon.

To fix this, a helper script will be used to start the service that
will pass the service the device tree name if it is present, or the
udev device path if it isn't.  This script will still run from the
udev rule as before, but it will stop and start the service itself
without using the SYSTEMD_WANTS attribute.

As the path to the hwmon environment file matches the service
template argument, the paths for the OCC .conf files need to change
to match the device path instead of the previous device tree path.

Note that the pure device path would have the hwmon instance number
in it, but since that can't be known ahead of time it is stripped
off by the script that starts the service.

In addition, the pure device path for the OCCs contain several
':'s, meaning the associated environment files would also need to.
However, Yocto/Bitbake cannot handle a ':' in a file path, so they
are converted to '--'s by the script that starts the service and
phosphor-hwmon will convert them back internally when it starts.

The service file also needed some changes now that the service
lifetime is no longer controlled by systemd via SYSTEMD_WANTS.

This script will be called by a udev rule to start and
stop phosphor-hwmon when the hwmon device driver is started
and stopped.

It is passed both the device path and the OF_FULLNAME device
tree attribute.  If OF_FULLNAME is present, it will start the
service with that as its template argument, otherwise it will
use the device path.  This is to handle devices that aren't in
the device tree so they won't have OF_FULLNAME.

If a '/hwmon/hwmonN' is in the path it is removed, as this path
is also used as a path to an environment file and so must be
known ahead of time, which the hwmon instance N is not.

If there is a ':' in the path name, it is converted to a '--'.
Yocto/Bitbake cannot handle a ':' in file paths.

Resolves openbmc/openbmc#2953

Change-Id: I815be4d6d9e1cbea8428bb1bb8c332776ee71ece
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
20 files changed
tree: cd93f8bf6835b035ba908d1755eebab845891749
  1. import-layers/
  2. meta-openbmc-bsp/
  3. meta-openbmc-machines/
  4. meta-phosphor/
  5. .gitignore
  6. .gitreview
  7. .templateconf
  8. openbmc-env
  9. README.md
  10. setup
README.md

OpenBMC

Build Status

The OpenBMC project can be described as a Linux distribution for embedded devices that have a BMC; typically, but not limited to, things like servers, top of rack switches or RAID appliances. The OpenBMC stack uses technologies such as Yocto, OpenEmbedded, systemd, and D-Bus to allow easy customization for your server platform.

Setting up your OpenBMC project

1) Prerequisite

  • Ubuntu 14.04
sudo apt-get install -y git build-essential libsdl1.2-dev texinfo gawk chrpath diffstat
  • Fedora 23
sudo dnf install -y git patch diffstat texinfo chrpath SDL-devel bitbake
sudo dnf groupinstall "C Development Tools and Libraries"

2) Download the source

git clone git@github.com:openbmc/openbmc.git
cd openbmc

3) Target your hardware

Any build requires an environment variable known as TEMPLATECONF to be set to a hardware target. OpenBMC has placed all known hardware targets in a standard directory structure meta-openbmc-machines/meta-[architecture]/meta-[company]/meta-[target]. You can see all of the known targets with find meta-openbmc-machines -type d -name conf. Choose the hardware target and then move to the next step. Additional examples can be found in the OpenBMC Cheatsheet

MachineTEMPLATECONF
Palmettometa-openbmc-machines/meta-openpower/meta-ibm/meta-palmetto/conf
Barreleyemeta-openbmc-machines/meta-openpower/meta-rackspace/meta-barreleye/conf
Zaiusmeta-openbmc-machines/meta-openpower/meta-ingrasys/meta-zaius/conf
Witherspoonmeta-openbmc-machines/meta-openpower/meta-ibm/meta-witherspoon/conf

As an example target Palmetto

export TEMPLATECONF=meta-openbmc-machines/meta-openpower/meta-ibm/meta-palmetto/conf

4) Build

. openbmc-env
bitbake obmc-phosphor-image

Additional details can be found in the docs repository.

Build Validation and Testing

Commits submitted by members of the OpenBMC GitHub community are compiled and tested via our Jenkins server. Commits are run through two levels of testing. At the repository level the makefile make check directive is run. At the system level, the commit is built into a firmware image and run with an arm-softmmu QEMU model against a barrage of CI tests.

Commits submitted by non-members do not automatically proceed through CI testing. After visual inspection of the commit, a CI run can be manually performed by the reviewer.

Automated testing against the QEMU model along with supported systems are performed. The OpenBMC project uses the Robot Framework for all automation. Our complete test repository can be found here.

Submitting Patches

Support of additional hardware and software packages is always welcome. Please follow the contributing guidelines when making a submission. It is expected that contributions contain test cases.

Bug Reporting

Issues are managed on GitHub. It is recommended you search through the issues before opening a new one.

Features of OpenBMC

Feature List

  • REST Management
  • IPMI
  • SSH based SOL
  • Power and Cooling Management
  • Event Logs
  • Zeroconf discoverable
  • Sensors
  • Inventory
  • LED Management
  • Host Watchdog
  • Simulation
  • Code Update Support for multiple BMC/BIOS images
  • POWER On Chip Controller (OCC) Support

Features In Progress

  • Full IPMI 2.0 Compliance with DCMI
  • Verified Boot
  • HTML5 Java Script Web User Interface
  • BMC RAS

Features Requested but need help

  • OpenCompute Redfish Compliance
  • OpenBMC performance monitoring
  • cgroup user management and policies
  • Remote KVM
  • Remote USB
  • OpenStack Ironic Integration
  • QEMU enhancements

Finding out more

Dive deeper in to OpenBMC by opening the docs repository.

Contact