ONELab Setup
ONELab Platform Enablement
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.
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.
The platform should implement the Minimum Featureset for Automated Device Testing
EFI HTTP boot via wired Ethernet must be implemented, and boot target must be configurable via the serial interface.
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:
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.
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.
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.
Firmware Upload File Creation
To be able to to leverage ONELab, you need to have your firmware built to be compatible with ONELab. ONELab accepts files in UEFI Capsules wrapped in a LVFS container.
To understand the steps to build compatible UEFI firmware to input into ONELab, please visit the ONELab Firmware Packaging & Upload chapter.
ONELab Comprehensive Assessment Review
To get started in the process of 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:
Partner: Fill out the ONELab Platform Assessment Review questionnaire and submit.
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
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.
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 setup 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 follow the steps in the Getting Started 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.
Connect to the ONELab Cloud Service
After device setup is complete, the next step is connecting the LAA over the cloud to the ONELab cloud infrastructure. This assumes the user already has a ONELab subscription and account.
This step is automated and upon the completion of the previous section, connection to the ONELab Cloud Service is complete.
Note
The ONELab Cloud Service will never initiate access into a corporate infrastructure. The LAA always initiates outbound connections to the ONELab Cloud Server from within any customer location. It will register availabilty to the cloud service and poll the service to check for CI tasks to perform.
Enable Platform Testing
After successfully connecting to the Cloud Server, the user can now schedule a conformance run by uploading the firmware to ONELab to test for compliance.
The steps to begin your firmware tests include:
Package your firmware in alignment with the ONELab Firmware Packaging & Upload section of this document.
Create a new Release Stream or update your firmware in an existing Release Stream as explained in the ONELab Scheduling a Conformance Run section of this document.
Schedule the conformance run as also shown in the ONELab Scheduling a Conformance Run section of this document.
These actions will automatically kick off the CI and allow the results to flow into the appropriate dashboards.
Processing the results
Once tests have kicked off and completed, the user is now ready to evaluate results.
ONELab provides an internal dashboard that displays the latest results as shown in the following figure. You can then choose to process the results including downloading test logs, rerunning tests, or making the results public sending them to the public dashboard (example shown below).
In the figure, there are several distinctions to be considered.
Each row represents a platform that is currently under test in ONELab. The default view is to see all platforms whose results have been configured for public access. See the Enable Platform Testing section on how to set this up for your platforms. - To view your private dashboard, the user must login
ONELab Payload/Distribution Validation
Part of the ONELab testing to to validate 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 SystemReady 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 will run on SystemReady compliant platforms.
The installation is currently a manual process requiring the Linaro ONELab support team to enable these. Please contact us.
Generic Payload Requirements
Any payloads shall be provided in a binary image. Once an image complies with the above, 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.
Each payload is required to provide a Python interpreter that can parse the results from the payload application and produce LAVA test results.