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.

When the system is ready to move to the field, most of the times the particular pysical link between host and target used at the development stage must be removed. In the worst case, the system must run without any NFS filesystem or file transfer services, relying only on its hardware resources (for example, the on-board ram RAM and flash memories). Resources that These resources are obviously limited, due to the nature of the embedded systems. Generally speaking, the procedure used to deploy the system configuration highly depends on the specific application; however, some topics are quite common. The following sections shine a light on these topics. ==Using an evaluation kit for the development stage==Often, it is convenient to carry out the development stage with an evaluation kit such as [[AXEL_ULite_and_SBC_Lynx_Embedded_Linux_Kit_(XUELK)|XUELK]] and [[Axel_Embedded_Linux_Kit_(XELK)|XELK]]. This is the case, for instance, when the final hardware platform is not available yet. It is worth remembering that, in this scenario, '''it is mandatory to port the software Board Support Package (BSP) to the final hardware platform when migrating from the evaluation kit'''. Conventionally, the BSP consists of:* Firmware (if any)* Bootloader (typically U-Boot) and, optionally, its device tree* Linux kernel and its device tree* Root file system.'''If not properly ported, the BSP may cause irreversible damage to the platform or severe malfunctioning as it is strictly related to the underlying hardware.''' Therefore, '''it is strongly discouraged to run the binary files released for DAVE Embedded Systems' evaluation kits on different platforms unless you know what you are doing.'''

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.

Customers who build their products using '''DAVE Embedded Systems'''' SOMs (NaonAXEL Lite, LizardAXEL ULite, QongBORA, ZefeerORCA,...) usually provide MAC numbers by themselves by acquiring them from IEEE. In fact, there are many reasons for this. Three can be stressed: