Skip to main content
All Posts By


CIP Member Codethink Reveals Technical Report Card

By Blog

CIP’s mission is to extend the life of industrial systems and solutions by up to 10 years. To do this, a lot of testing, testing and more testing has to happen! Codethink helps lead CIP’s Technical Steering Committee and plays an integral role in the technical community. As such, Codethink shares updates and progress reports on an ongoing basis. In this new blog post, Agustin Benito Bethencourt shares what Codethink has been focusing on this year and the results of these efforts.

CIP 4.4 kernel maintenance
Ben Hutchings, CIP’s Debian kernel maintainer, has been the 4.4-cip kernel
maintainer for almost two years now. His role is to design, establish and consolidate the CIP kernel maintenance process, integrating it with the upstream stable kernel process as much as possible, reducing exceptions to the minimum, since they will be maintained by CIP on its own for the coming years. Until now, almost all of those exceptions are directly related to platform
specific features.

This year, as maintainer, Ben is focused on security as well as supporting the CIP community, providing advice and answering questions about the Linux Kernel and the Debian LTS process.

Several versions of the CIP kernel have been released so far in 2018, being the latest one published this past May 18th, version 4.4.130-cip23. A new version of the CIP kernel will be published right before the Open Source Summit Japan 2018 starts.

If you are interested in using the CIP 4.4 kernel, please visit:

After industrial leader Moxa joined CIP in 2017, Codethink put efforts in promoting other kernel developers from CIP Members to participate in the kernel 4.4 stable review process. This is being one of the most rewarding activities for Codethink. Bringing new blood to a critical process for so many companies could become one of the most relevant contributions CIP can
make to the Kernel community.

After the strategy change decided by CIP at the end of 2017, Codethink has put Board at Desk(B@D)[3], the tool based on used to test the kernel, in maintenance mode, at least until the new CIP testing infrastructure is up and running. kernelci and LAVA versions have been updated, some minor improvements to ease the configuration has been merged, the Renesas board IWG20M is now supported in B@D and the documentation has been improved. Led by Robert Marshall from Codethink Ltd, two activities will focus the test automation efforts the coming weeks/months:

* Move B@D into containers, which will allow us to share efforts with AGL and
integrate B@D with the new CIP testing infrastructure.

* Modify the current integration process so B@D becomes more resilient to
upstream changes with heavy impact to the tool.

These actions will reduce the maintenance effort so they will allow us to
focus on creating tests.

Other activities
Codethink contributes to CIP in several other areas as well. Agustín Benito will talk about the CIP kernel process at Open Source Summit Japan 2018 and introduce CIP to Open Source developers at the OpenSouthCode  in June. Codethink has also contributed to the CIP blog with an article earlier this year and is an active participant at the CIP Technical Steering Committee.

For more information, visit CIP’s wiki page:

CIP Launches B@D v1.0

By Blog

The Civil Infrastructure Platform (CIP) project, hosted by The Linux Foundation, announces the publication of a new version of Board At Desk v1.0, a customized and easy to deploy instance of the kernelci and LAVA projects that should allow developers to test Linux kernels on boards connected to their own development machines using the tooling provided by one of the most successful Open Source testing projects.

Board at Desk (B@D) v1.0 is provided in two forms:

  • As a vagrant VM recipe.
  • As a VM image, widely called a B@D box.

Please visit the CIP Testing project Download page to download the latest Board At Desk (B@D v1.0) box.

With this effort, the CIP project is moving towards a “shared and trusted testing” targeting not just those directly involved in maintaining the CIP kernel but any kernel developer that has physical access to a board. This reduces deployment, configuration and maintenance costs. B@D introduces a “local” approach to which is a distributed service centrally managed. In addition, CIP intends to increase the number of developers and organizations willing to participate in upstream kernel testing by providing a simple mechanism to evaluate the technologies developed by that community (LAVA and kernelci) which CIP considers upstream.

Some of the most important new features shipped with this B@D release include:

  • LAVA has been updated to 2017.7 version.
  • B@D now works on Windows 10 systems.
  • B@D now works behind a webproxy.
  • initramfs is now built locally, increasing reliability.

Newer version of LAVA

The LAVA community releases a new LAVA version every month. CIP testing team have updated Board at Desk LAVA version to 2017.7, released this past July. It comes with many new features, enhancements and bug fixes that allow the CIP testing project to introduce more verbose reports, prevents issues related with partitions being filled with system logs, etc..

B@D supports Linux and Windows as host OS

The previous version only supported Linux based systems as host OS. This new version of B@D also supports Windows 10 expanding the potential targets to those engineers who use this proprietary operating system in their development machines.

B@D now works behind a webproxy

Many organizations works behind a webproxy. B@D needed to give an answer to this use case, popular among CIP Members. Thanks to some contributions from Daniel Sangorrin, a Toshiba developer, Board at Desk now works behind a webproxy.

initramfs is now built locally

Previously Board At Desk was using the initiramfs provided by Linaro in their infrastructure. This created in B@D a dependency on the network connection latency that, under certain circumstances led to errors due to timeouts. Now initramfs is built locally which improves the speed of the tests, removing that need to access to internet.

In addition to the above, other features have been added and several bugs has been fixed, making Board at Desk more robust and reliable than before. Further information about this new Board At Desk (B@D v1.0) release can be found at the B@D Feature Page.

If you are interested in testing kernels using Board at Desk, meet the developers at the cip-dev mailing list. If you find bugs in KernelCI or LAVAv2 themselves, please report them upstream. If you find them in the configuration or any of the previously described topics, please report them in the CIP-testing bug tracker. More general information about the CIP testing project can be found in the CIP wiki.

Board At Desk (B@D) and forthcoming challenges

By Blog

B@D released on May 31st


During ELC 2017, CIP project members introduced the beta version of what is being called Board At Desk – Single Developer (B@D), an effort by the CIP testing team to integrate LAVAv2 and KernelCI into a Debian-based virtual machine allowing Kernel hackers and maintainers to test any Linux Kernel on a board directly connected to a laptop. For CIP developers, the focus is the CIP Kernel, based on Linux 4.4 LTS and the reference boards designated by the CIP TSC (Technical Steering Committee). This May 31st 2017 the CIP testing team released the first fully working version of this virtual machine, labelled as B@D v0.9.1. Read about what comes with it and how to use it in the Release Announcement.B@D v0.9.1

In this first release the CIP testing team has tried to satisfy the requirements of as many developers as possible who could use B@D.  In order to reduce the complexity of setting up the environment to use the tools, Vagrant was the selected technology. VirtualBox has been chosen as the initial virtualisation technology in order to also support the needs of those who use Windows to create Linux systems. We are looking forward to incorporating KVM into the equation as soon as possible, thus improving the experience of those using Linux to produce Linux based systems.


Detailed step by step documentation to deploy and configure B@D, connect to the Beaglebone Black, and test the CIP Kernel is also provided. The CIP testing team has put significant effort into making the toolset easy to deploy and configure so that users can focus on testing rather than worrying too much about the tooling.


I would like to publicly thank all developers that have made this release possible, particularly my colleagues at Codethink Don Brown, Robert Marshall, Christos Karamitsos, Ben Hutchings and Lachlan Mackenzie.


CIP at Open Source Summit Japan 2017


If you are attending Open Source Summit Japan pass by the CIP booth to see how easy it is to use B@D to test a Kernel in a BeagleBone Black. Renesas is currently working towards making sure B@D also supports Renesas RZ/G1M. There will be additional demos at the CIP booth from Hitachi, Siemens, Toshiba and Plat’Home.


CIP is also organising an open Workshop session. You can propose topics for it or simply join us. It will take place at the OSSJ venue the day before the OSSJ starts, that is May 30th. Please check this wiki page if you are interested in attending, proposing topics or contacting. There will also be a talk on Friday 2nd June about the latest CIP news.


Forthcoming actions on the testing front


Now that we have the tool, our next step is to start setting up the CIP testing project following an architecture design that does not rely on a centralised testing service.


If we can guarantee that several developers are using the same testing tool to test a specific Kernel feature on a CIP kernel, using the same test in a cloned environment, the resulting output should be identical, which can be confirmed by sharing the results, among other measures. Several assumptions will need to be made like the creation of a similar chain of trust and transparency that any Open Source project has when it comes to code development. Other measures will need to be considered towards reproducibility and traceability of any test result.


In summary, we would like to translate the idea of treating testing like coding in an open environment such as CIP. You can read more about it in the CIP testing project landing page.


The described approach has a low risk, in my opinion. If we face scalability issues, a centralised service can be created so the investment can be rapidly adapted. But the bigger benefit of this approach will be cost since the required initial investment is limited. The project will grow organically, compared to a centralised testing service, limiting the financial risk too.


The current plan is to present some results at ELCE, which will take place in Prague in October 2017.