Bureaucrats, dave_user, Administrators
8,186
edits
Changes
→Various
= Moving to the field =
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.'''
= Root file systems =
One of the greatest challenges for embedded systems manufacturers is to guarantee that the software on the system can be updated in the easiest way. On-the-field software upgradability is a major requirement that allows to replace bogus code and to enhance application features. How to perform this operation is highly platform-dependent. The following section shows in detail a specific situation.
As a general rule of thumb, '''it is highly recommended to avoid package-based systems such as rpm or deb to implement reliable software upgrade mechanisms.'''
== U-Boot/Linux system ==
'''DAVE Embedded Systems''' owns an IAB (Individual Address Block, a set of 4096 addresses), that is in the public listing, so everyone can find out that an address is associated to '''DAVE Embedded Systems'''. Note that the registration authority provides only IABs and OUIs (16000000+ addresses), and that a company is not allowed to request another IAB until at least 95% of the MAC addresses of the previous IAB have been used.
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:
* A CPU module is NOT an end-product. It is not a product that goes directly to the final user as a LAN PCI board, or a printer server. So, in case of CPU modules, who gets a CPU module and build its own product with it, is responsible for handling the MAC address.
** in case of WDT intervention: tracking of watchdog event for software analysis
* MAC addresses handling: see [http://standards.ieee.org/develop/regauth/index.html IEEE registration authority]
* runtime automatic detection and configuration: possible usage of [[ConfigID_and_UniqueID | ConfigID]] technique