Board at Desk - Single Developer (B@D) Feature Page

This is the v1.0 release of Board-at-Desk, a Virtual Machine provisioned using Vagrant with Virtualbox as the hypervisor, that includes the following tooling:

• Kernel CI and LAVA Virtual Machines have been merged into one VM. Kernel CI is an automated system for the building of Linux kernels linked to large board farms allowing potential problems to be spotted before any changes reach the kernel mainline. LAVA is an infrastructure for specifying and controlling tests to be carried out on the Kernel CI controlled board farms.
• The VM hosts the Kernel CI Frontend, Backend and Storage Server as well as the LAVA server, scheduler and worker which includes the dispatcher.
• The primary focus is on the Beaglebone Black, the Renesas iwg20m and the CIP Kernel v4.4.83

These are the main features and improvements included in this new release

• Update of the VM to Debian Stretch
• Newer version of LAVA
• B@D supports Linux and Windows as host OS
• B@D now works behind a webproxy
• initramfs is now built locally
• Bug fixes

The previous release of B@D used a combination of Debian Jessie and Debian Testing - this made building a new virtual machine inherently unstable and produced problems when trying to use versions of packages which were not in Jessie but were older than the ones in testing. Codethink have decided to move the VM to use Debian Stretch this should make the product more stable.

The LAVA community releases a new LAVA version every month. The CIP testing team at Codethink 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..

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.

Many organizations work 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.

Previously, Board At Desk was using the initramfs 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 and that Linaro built version ran more slowly with an internal timeout. Now initramfs is built locally which improves the speed of the tests, also removing that need to access the internet.

• The Linaro kernel which was used in the earlier release is no longer accessible and therefore the wiki and the supplied tests as used in the wiki no longer access these files and only use the locally built kernel.
• The test suite used has been updated so the Beaglebone Black test has been amended to use the new location

At a high level, Board At Desk is a testing environment based on two basic components, LAVA and kernelci designed to allow any developer to test locally on any board a Linux kernel or a simple Linux based system, evaluate the results and share them, together with the logs, with their colleagues. What makes B@D different is that in order to do so, there is no need for a managed centralised service. It is designed to run locally.

Board At Desk - Single Developer, creates and publishes a VM that contains all the kernelci tools. Testing of any kernel is enabled by the installation of LAVA and the supply of, currently, a small number of health checks and reference tests. The test results can then be shared with other developers by using LAVA notifications either directly or via the cip-testing-results email list.

If we take a deeper look, there are several technologies and configurations involved. This block diagram tries to give a little more detail.

Board At Desk - Single Dev. block diagram- this lays out the structure of the testing environment. The host running GNU/Linux or Windows 10 runs B@D within a Vagrant environment, this environment is provisioned during initial boot with the kernelci and LAVA packages which pull in other necessary tools using ansible, apt-get and git so that the box is ready for kernel builds and testing.

These are the main software components and the versions shipped in the previous version compared to the current one.

KernelCI components included in this release vs the previous one:

LAVAv2 components included in this Board at Desk v1.0 are:

Other tools used in Board at desk v1.0

The overall CIP license policy can be read here .

A snapshot release was created in October 2018 to support the Renesas iwg20m board and include the latest bug fixes. See the Download page page for links.

This tutorial assumes that you have the following installed on the host machine:

• git v2.11.0 or better
• Vagrant v1.9.1 or better
• VirtualBox v4.3 or better
• Your username must be a member of the vboxusers group. You can add it with:
  • [user@host ~]$ sudo usermod -aG vboxusers user
• gpg v1.4.20 or better
• sha256sum v8.25 or better

otherwise the installation may fail.

• Install git, ssh and rsync from cygwin
• Vagrant v1.9.1 or better
• VirtualBox v4.3 or better
• For kernelci web interface you will need a Firefox or Chrome installation as the Windows browsers do not work with the KernelCI webserver.
• core.autocrlf=input is needed in the git settings for the scripts to run under Debian of the virtual machine
• Vagrant needs the guest additions vagrant plugin install vagrant-vbguest
• If you need to copy files onto the vm (not required by the provisioning script) you will also need the scp plugin vagrant plugin install vagrant-scp

• You will also need 13GB of disk space for the virtualbox vm or 12GB for the vagrant image for the initial install.
• The Vagrantfile allocates 2GB of memory for the virtual machine and we recommend at least this value

Follow these instructions to deploy and configure B@D, connect the board and test the reference examples:

1. Deploy B@D through Vagrant or by downloading the B@D standalone VM box directly.
2. Once deployed, configure B@D.
3. Depending upon the board you are using, connect the board Beaglebone Black or IWG20M - in the Renesas case you must provision the box yourself rather than downloading the pre-provisioned box - to the host machine, where B@D is deployed.
4. Build the kernel (system) to be tested and the required artifacts.
5. Check the reference test cases and try them as examples.

• Known Issues and workarounds when testing Civil Infrastructure Platform or the tools provided by the project.

• CIP testing releases, current and previous ones.
• CIP testing project Download page.
• CIP testing project landing page.
• CIP code is in Gitlab.com
• You are welcome to participate in CIP.

• LAVA v2 Pipeline Model.
• How to write LAVA v2, or “pipeline” jobs.
• More on writing Lavav2 tests.
• Online YAML Parser.

• Beaglebone Black
  • Beaglebone Black page.
  • U-Boot on the Beaglebone Black.
  • BeagleBone Black: Flash the On-Board Memory.
• Renesas iWave-M (iwg20m)
  • Board specs description.
• Information about new features being incorporated to the Linux Kernel that could be incorporated to the CIP kernel, so they can be tested in B@D.
• Set up instructions to bring a different board, but the same SoC, up.
• Cyclone V (not supported yet)
• Kernel CI https://kernelci.org/

Back to the parent page