# Intro to Device Testing

Embedded platforms targeted for Linaro Remote Labs and Validation & CI Labs
require a common set of features, despite variations in functionality. This
section provides an overview of the minimum required features and supporting
information necessary for efficient integration into a Linaro Remote Lab
infrastructure.

## Console Connectivity and Access

Connecting a console from the LAA to the DUT is essential for initial bring-up,
enablement, and capturing test outputs to validate DUT functionality and status.
Embedded platforms use various connection methods, including USB, Serial UART,
and Network Connections, with communication protocols such as Telnet and SSH.
For UART, configuring parameters like baud rate is critical for a successful
connection. Additionally, understanding commonly used software tools like PuTTY,
minicom, and SSH is important, as this information influences both hardware
interfaces and software configurations required for effective DUT communication.

## Firmware Update and Recovery

A critical aspect of integrating embedded systems into a validation and test CI
infrastructure is understanding the processes, procedures, and tools required
for firmware updates and recovery, especially for restoring a “bricked” DUT. Key
considerations include memory type and capacity (ROM, RAM, EEPROM) and memory
layout, which influence how firmware is stored and executed. The choice of
bootloader technology (U-Boot, GRUB, UEFI) is also significant, with some, like
UEFI, required for compliance (e.g., SystemReady). Additionally, understanding
recovery mechanisms and fallback options is essential for maintaining system
reliability.


## Power and Reset Considerations

Understanding power provision to the DUT is essential, as it directly impacts
reset functionality and automation. Key factors include input voltage range and
tolerance, power sources (e.g., power barrel connector, header pins, USB, or
PoE), and thermal considerations such as heat sinks or airflow requirements.
Some platforms support multiple power sources, which can affect automation; for
example, if a DUT remains powered via PoE while attempting a reset through a
power barrel connector, the reset may fail. Additionally, some platforms require
a physical button press for reset necessitating modifications for automation.
These details must be assessed during the solution evaluation phase, as they can
influence the MIB selection for integrating a DUT into a Linaro Remote Lab. The
LAA can supply various voltage levels (e.g., 3.3V or 1.8V) through an MIB
connector if required, and while a header pin reset option is ideal, it is not
always available.

## Network Connectivity

Understanding and providing information on how the DUT connects to an Ethernet
network is important. Is there a physical RJ45 connector? What are the details
on initial connectivity?  Are SSH connections needed/used? (See the
[Console Connectivity and
Access](#console-connectivity-and-access)
section) Is the network boot a supported configuration? All these details are
helpful in understanding during the initial setup phases to deploy an optimal
solution.

## OS Installation

Providing details about the OS is crucial for automation. Key considerations
include whether the OS needs to be downloaded on each boot cycle or if a default
image is locally installed on the DUT. Additionally, understanding whether the
installation process is fully automated or requires manual intervention is
essential. Any specific requirements or nuances related to OS installation help
ensure a smooth setup for the automated test environment.

## Documentation and Tooling

Platform providers should supply comprehensive documentation covering all the
features discussed, including schematics, board layout, bootloader installation
and recovery procedures, known issues, logging configuration, custom tooling or
scripts, version compatibility, and firmware installation procedures. This
information is essential for seamless integration and automation within the test
environment.