Bureaucrats, dave_user, Administrators
4,650
edits
Changes
→Boot time
= Introduction =
Deployment of [[Embedded Linux]] systems is the typical operation which follows the development phase. When the application is ready and fully tested in the develoment development environment, it's time to take the system to the field for the “real work”. This phase brings a lot of concerns to cope with, for example creating a suitable root filesystem, saving the data properly, implement and implementing successful on-the-field update strategies. This how-to guide explains how to solve lists some of the problems connected common issues related to the deployment of an embedded linux Linux system.
= The development environment =
Please note that init implementations can differ: Busybox offers its own version while other distributions, like Angstrom, can provide the classic System V version. More modern distros, like Ubuntu, implements Upstart, a complete replacement of the init daemon. For further information on the init process, please visit [http://www.yolinux.com/TUTORIALS/LinuxTutorialInitProcess.html this page].
= Non-volatile memories partitioning scheme =
In general, many different schemes can be implemented. Cost, reliability, speed are just some of the parameters to be considered when designing the partitioning scheme. [[Standalone_boot_(BELK/BXELK)|This article]] shows two quite different schemes on the same platform, for example.
= Startup sequence =
==Boot time==
Some applications require a quick boot time. When deploying an embedded Linux system, this time has to be evaluated in order to verify if it matches the system requirement, if any. Should the boot sequence is too long, several techniques can be used to speed it up. For more details, please see [[SDVX-TN-001:_Fast_boot_time|this page]] or [https://elinux.org/Boot_Time this article]].
Generally speaking, it is worth to remember that '''different type of memories can lead to largely different boot times'''. A common scenario is the following:
* The proof of concept (PoC) of a new product is developed using a microSD card as boot memory. Everything is stored there: bootloader, o.s. kernel, root file system, etc.
*Then, the software is deployed onto the target according to the final production configuration by using SoM's onboard non-volatile memories. See [[Standalone_boot_(BELK/BXELK)#Use_case_.231|this real case]] as an example. Due to the fact that a large portion of the software is stored onto the NAND flash, the overall boot time may increase significantly. Why?
**microSD card has a synchronous interface to the host, while raw NAND flashes used on DAVE Embedded Systems system-on-modules have not. Data communication between the system-on-chio (SoC) and the memory is much slower.
**More importantly, raw NAND flashes are unmanaged memories. Unlike microSD cards, they don't embed a controller for handling the commands received from the host and taking care of low-level management of the underlying memory (which is based on NAND flash technology as well). This includes but is not limited to wear leveling, bad blocks management, and read errors handling. In the case of raw NAND flashes, these tasks are all performed by the operating system running on the host processor.
= On-the-field software upgrades =
More information is available in README, INSTALL and MULTI files included in the Dropbear distribution. Please note that for recent systems, as Lizard and Naon, Dropbear can be installed from '''pre-built packages''' (please refer to the distribution's package-manager documentation).
=Security=
Nowadays, a large number of newly designed embedded systems are used in Internet-connected products. As such, these systems have to face severe issues in terms of cybersecurity. This topic is huge and it is obviously beyond the scope of this document. It is worth remembering, however, that modern SOCs provide a rich set of native functionalities that address this issue. For instance, see [[XUELK-WP-001:_Secure_boot_on_iMX6UL|this page]] or [[BELK-TN-001:_Real-timeness,_system_integrity_and_TrustZone%C2%AE_technology_on_AMP_configuration|this technical note]]. These documents show how some of such functionalities were leveraged on DAVE Embedded Systems products.
For a more general discussion about the security of Internet-connected devices, see for example the [https://www.iotsecurityfoundation.org/ IoT Security foundation website] or [https://www.microsoft.com/en-us/research/publication/seven-properties-highly-secure-devices/ this paper] by Microsoft.
=Licensing=
It is known that a GNU/Linux system is based on a large amount of open source software. Consequently, the manufacturers of a product embedding such software must deal with the open source license compliance.
This topic is beyond the scope of this document, but a couple of links are provided anyway:
*[https://elinux.org/Legal_Issues This article] provides an overview of license-related legal issues
*Yocto build system generates automatically a manifest file to make the compliance management easier. For more details, please refer to [[https://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#maintaining-open-source-license-compliance-during-your-products-lifecycle|this link]]
=Certifications=
In general, all the products must conform to a set of standards in order to get the certificates required to be sold ([https://en.wikipedia.org/wiki/CE_marking CE marking] and [https://en.wikipedia.org/wiki/FCC_Declaration_of_Conformity FCC_Declaration_of_Conformity] are two well-known examples.
In many cases, software modifications to the Board Support Package (BSP) or the user applications are required to pass the compliance tests dictated by these regulations (*). In a typical scenario, these modifications are usually carried out after the development of the user applications. Nevertheless, these changes must be committed to the source repositories in order to be part of the production images that are stored into the product.
(*) A common example is the enabling of the spread-spectrum technique to reduce the electromagnetic emission peak associated with a digital clock, which is usually implemented at boot loader level.
=Misc=
* Even if '''DAVE Embedded Systems''' programs the MAC address in flash (as an example) at the manufacturing stage, the customer may erase, overwrite, modify this number for the actual CPU module. Also, the strategy and the position (NOR, NAND, E2PROM,...) of the MAC address may vary. '''DAVE Embedded Systems''' cannot guarantee - in other words - that MAC address is maintained in the form and position it had when delivered.
* An end-product hosting a '''DAVE Embedded Systems''' CPU module is not always a '''DAVE Embedded Systems'''' product. When it is (and there are some examples), '''DAVE Embedded Systems''' puts the proper MAC address on the product. When it's not, DAVE can't provide MAC addresses: as already stated, the list of DAVE's MAC addresses is public, and by reading this list everybody can see that the product manufacturer is '''DAVE Embedded Systems''', which is not true.
==Handling different product models==
It is quite common to manufacture different product models on the top of the same hardware platform. In such cases, it is convenient to use a unified software for all models. DAVE Embedded Systems provides the [[ConfigID_and_UniqueID|ConfigID]] mechanism that can be exploited to achieve this goal. ConfigID can be exploited at boot loader level, at kernel level, and at application level.
