The above should prove that getting an embedded Linux platform up and running is not a daunting task anymore. There are of course further things to consider during product development, which require more specific knowledge. Fortunately, it is not required nor too time-consuming for many solutions.
1) Driver development
When designing hardware, one has to be aware of the equivalent software support. As Linux is the standard choice of silicon vendors for testing their own reference designs, there is a strong chance device drivers will be available for all chosen components. When replacing a particular part in the system with another one, checking whether a driver exists first is strongly recommended – reducing BoM cost is understandable, but the amount of time required to enable functionality for a non-supported hardware module should not be underestimated.
2) BSP adaptation
When choosing a System-on-Module, BSP development can be greatly simplified, lowering overall time-to-market. Whether you choose this path or roll your own, developers will have to update their kernel configuration to match the underlying hardware. The recommended way for this task is to start from a known similar hardware configuration and adapt it accordingly; the Linux kernel, for most architectures such as ARM, does this through what is called the device tree, a separate binary file containing the hardware description.
All peripherals and controllers need to be listed within this file and the kernel will dynamically load appropriate drivers and modules based on the selected and desired configuration. It is important to note that understanding the device tree format (DTS/DTI) can be daunting at first and requires some expertise to properly map hardware components with the appropriate and corresponding software pieces.
3) Boot time optimization
By default, neither the bootloader, kernel, or root file system are optimized for boot time. If your product requires a short boot time, as needed in multiple industries such as the automotive vertical, each component will need to be altered to reach this requirement. Multiple techniques exist for this purpose and usually involve various tricks to be used together to meet this goal, such as using u-boot’s Falcon mode, deferring driver init calls, parallelizing boot scripts, etc.
4) Power consumption optimization
Power management and power consumption optimization are not tasks to be considered lightly, especially for battery-operated devices such as handhelds. By default, the Linux kernel provided by silicon vendors may not even reach the System-on-Chip lowest possible power state, requiring very low-level development in order to manage to shutdown particular components of the SoC (eventually including the cores themselves) using clock gating and power domain hardware mechanisms. This complex work is required for the system to truly go into a deep suspend state. Furthermore, the hardware needs to be carefully designed in order to prevent peripherals from being powered up at all times and be properly software-controlled. This subject is quite broad and should not be underestimated – battery longevity is one of the most important factors for end-users and unfortunately very often considered an after-thought during product development.
5) Real-time capabilities
Embedded Linux is not a real-time operating system by default. Depending on your product needs, the soft real-time configuration of the Linux kernel may be satisfactory; running Linux in a hard real-time environment is also possible through the use of third-party components, such as Xenomai, a framework that provides a pervasive, interface-agnostic, hard real-time support to user space applications. Integration of such components is not straightforward and will likely require modifications of existing drivers which applications rely on in order to make them real-time capable.
6) System update
Whether it is via a simple USB thumb drive or over the air, system updates can also be a key product feature. Linux unfortunately does not have any standard mechanism for such as task, unlike other higher-level operating systems such as Android. This process typically requires modifications at multiple levels, usually involving bootloader modifications and dedicated user-space scripts or applications, and could handle bootloader, kernel, application, or entire root file system updates. Various implementations exist in the industry with the ultimate goal of maintaining device integrity and avoiding bricking due to potential data corruption or power loss during updates – implementations could be a simple ping-pong mechanism with two distinct partitions being updated every other time, or go as far as having individual partitions for each software component including a recovery or factory image for more extreme scenarios. Companies such as Witekio have ready-to-use solutions available that can be leveraged for multiple kinds of hardware configurations.