Overview

To enable a platform in ONELab, there are several steps required. The figure below breaks this process into 5 high-level sequential steps.

When a platform is evaluated for inclusion in any Remote Lab, there are several logical steps that need understood and need stepped through. This section provides an overview of this process and focuses on the portions of the enablement process that are common across all Linaro Remote Labs.

The remainder of this section will walk through the steps described in the above diagram.

Setup Prerequisites

ONELab Account Registration / Subscription Enablement

In order to have a platform or payload enabled in ONELab, a user must have set up an account with Linaro. Once your account is set up, you will be provided a login at the level that supports the account level set up.

To enquire about obtaining a ONELab account, please contact Linaro at support@linaro.org.

Platform Prerequisites

For integration into ONELab, the following platform requirements must be met.

1. The platform should implement the Minimum Featureset for Automated Device Testing

2. EFI HTTP boot via wired Ethernet must be implemented, and boot target must be configurable via the serial interface.

3. The platform have a LAVA Device Type created (and upstreamed where possible) and there is a LAVA device dictionary to map LAA to DUT power, Ethernet, serial and reset.

As always, Linaro Consulting Services can provide support in meeting the above should help be needed.

In addition to these Generic requirements, each ONELab lab instance will have lab-specific requirements associated with it as outlined below:

1. The board is capable of running the Arm SystemReady Architecture Compliance Suite (ACS) test suite for SystemReady DT.

   Note this doesn’t mean it’s been certified, just that it’s able to run the tests. Contact Linaro Developer Services if support needed in preparing a platform to pass SystemReady DT.

2. Linaro strongly recommends that the board passes all applicable ACS tests since that shows the board has the capability to run other ONELab IoT tests.

   If there are any known failures they should be discussed as part of the Comprehensive Assessmemt Review.

3. The platform may also be PSA Certified but this is not a hard requirement. As a reminder, the high level requirements for this include the following:

   • Support for Secure Boot

   • Support for H/W Root of Trust functions to support secure operations such as key generation & storage, identity, and authentication

   • Secure storage of sensitive data such as keys & credentials

   • Secure and reliable software update

   • Threat protection as outlined in the PSA Threat Model and Security Analysis document (TMSA).

   • Cryptographic function support (encryption/decryption, hashing & digital signatures

   • Authentication/authorization access control

   • Session protection for secure inter-device communication

   • Audit & Logging of security relevant events

   • Detection of analogous behaviors

   • Other general requirements such as Physical Security (anti-tamper), attack recovery, and a secure lifecycle management solution are also included

As noted above, Linaro Consulting Services can provide support in meeting the above if help needed.

ONELab Comprehensive Assessment Review

To get started with integrating a platform into ONELab, the platform is analyzed following the process in this section to determine its readiness to be added to ONELab. The output of this step will include recommended next steps for ONELab Readiness.

This “Comprehensive Assessment Review” is a joint activity where Linaro experts meet with the partner to evaluate what’s needed to add hardware to ONELab. Each platform has unique characteristics that may require additional details. These are evaluated to determine the best way to enable the platform / DUT for automation. For an overview of the types of characteristics we look for when evaluating a platforms suitability for ONELab, please see the Introduction to Automated Device Testing section of LAA Users Guide.

Once the this process has been completed with Linaro, an LAA with the recommended Mechanical Interface Board(MIB) is shipped to the location where the LAA will be enabled. This may be a partner facility or a Linaro location if it’s determined that Linaro support is the best option for expedient enablement. The DUT, MIB, and LSIB will be assembled and the assembled system will be ready to go through the ONELab Onsite Setup.

The review process is performed as follows:

1. Partner: Fill out the ONELab Platform Assessment Review questionnaire and submit.

   You can also click on the following QR code to complete the survey from a mobile device:

   

   Include as much information as possible including the download of both Schematics and Board layout for Linaro experts to review.

   Completing this form ensures alignment between teams and improves the efficiency of the Assessment Review, focusing on the platform’s readiness for automation

   This is a good time to run the ACS tests locally per the Locally Running ACS section.

2. Linaro: Schedule the joint Linaro-Partner Assessment Review

   When the questionnaire is submitted, Linaro will reach out to the email provided by the submitter to schedule an initial sync call to answer any technical opens and discuss next steps.

Note

Refer to the LAA Overview for an overview of key considerations vendors should keep in mind when developing platforms for integration into a Test Automation Framework such as ONELab.

3. Linaro/Partner: Conduct the scheduled Assessment Review meeting and evaluate the checklist results along with relevant documentation to determine the next steps. These may include:

   • Is the board suitable for automation? If so, provide the partner with recommended next steps.

     • Physical modifications required to automate

     • Are there any software features that need to be implemented and/or tested?

   • Is a MIB required, if so which one?

     • If a custom MIB needed, create a plan

   • Does the platform need a custom LAVA Device Dictionary and Device Type developed? If so create the plan/strategy to complete this.

Note

For this step, it is may be necessary for the Linaro Engineering team to undertake some pre-work to support the initial bringup. Pre-work will be identified during the Assessment Review and, once completed, the working setup is sent to the customer premises for completion of the bringup.

ONELab Onsite Setup

This section assumes that the ONELab Comprehensive Assessment Review has been completed and the user has received their LAA along with the appropriate MIB and any supporting equipment. Since ONELab is based up Linaro’s Remote Lab technology, Linaro will ship a LAA to your preferred location to connect to the Lab.

The steps to set up the LAA and DUT, including LAA unboxing, bring-up, LAVA enablement and initial configuration, is common across all of Linaro Labs. For details about completing this, please appropriate section of the LAA Users Guide.

Warning

It is necessary for the LAA to establish outbound ethernet connections to register with the cloud service and poll for its next task. This step may require the partner company to work with their IT department to enable suitable network access for the LAA. For further details on this, please see the LAA Customer Lab Installation Details section of the LAA Users Guide.

Operational QuickStart

Now that you’ve recieved your LAA, the steps below can be referred to in order to begin interoperability testing on ONELab:

• Package your firmware. See the ONELab Firmware Packaging & Upload chapter.

• Log into ONELab through the Linaro Solutions Hub

• Connect to ONELab. See the Connect to the ONELab Cloud Service chapter

• Upload your firmware. See the Firmware Upload - Create Release Stream chapter.

• Kick off the initial interoperability Compliance Run. These will be selectable from the page you created your Release Stream from.

• Monitor job status and review results. See the Processing the results chapter.

See the ONELab User Interface chapter for additional functionality including promoting results to the public explore board and more.

Payload/Distribution Validation

Part of the ONELab testing to to validate interoperability of payloads. Payloads include various OS’s and applications. Per the SystemReady specs, a goal is to validate a Linux distribution from each of the main package managers. Thus testing Debian(apt), Fedora(YUM), Yocto(opkg), and Suse(Zypper) is an example of providing confidence that a firmware will boot OS’s from each. There are of course other less-used package managers, the four listed here are just examples of 4 of the more popular. This is a guideline, not a hard requirement, and it’s possible to pass ONELab Compliance testing without validating on a certain subset of package managers.

When it comes to other payloads, ONELab supports the validation of applications from vendors that want to demonstrate confidence that their application support interoperability across multiple platforms.

Note that the installation of Application payloads is currently a manual process requiring the Linaro ONELab support team to enable these. Please contact us.

Generic Payload(non-OS) Requirements

Non-OS Payloads shall be provided in a binary image. Once an image complies with the above, you may kick off a compliance run against the payload. ONELab automation will trigger new test runs whenever relevant updates occur in the infrastructure and the Dashboards will be updated with the latest results related to the payload under test.