Bureaucrats, dave_user, Administrators
4,650
edits
Changes
no edit summary
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].
= Startup sequence = ==Configuring the boot loader== === Handling the serial port ===U-Boot implements a text console on the serial port. This console can be used to stop the startup sequence to allow an interactive session with the human operator. This is very useful during debug operations, but by default, any character the bootloader receives during the startup sequence stops this process. As a side effect, any spurious character received from the serial port devoted to the console is able to prevent the bootloader to complete the automatic boot process (and typically to start the operating system). For this reason, before moving to the field it is highly recommended to configure the bootloader to halt the sequence when receiving a specific string instead. Fortunately, Autoboot process is deeply configurable: parameters defining the retry behaviour and the strings used to stop booting can be specified. Please read the README.autoboot file, provided inside the documentation directory of the U-Boot sources, for more details. ===Automating operations at boot loader level===Modern boot loaders such as U-Boot allows automating boot operations in an extremely flexible fashion. Thanks to the scripting capabilities, it is possible to execute complex scripts. For more details, see for instance [https://elinux.org/ECE597_boot.scr this tutorial] or [https://elinux.org/ECE597_boot.scr this page]. ==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]]. =Misc=== Watchdog ==
Typically, during application development, the watchdog device included in the embedded system is turned off. Before moving to the field, enabling the watchdog is often a mandatory choice (*). The use of this peripheral is a little bit tricky because it involves both U-Boot and Linux. The following sequence shows the typical scenario when the system is working on the field:
(*) Enabling the watchdog functionality has several system-level consequences as well. As such, system integrators need the freedom to decide whether to enable it or not. For instance, there are applications for which the system integrators do not want to enable the watchdog. They prefer that their final users are aware of software hangs and that the users reset the board manually. Of course, this approach might not make any sense in case of unattended devices.
== Setting the MAC address of network interfaces==
In case the system provides an Ethernet interface, it must be guaranteed that each device is delivered with a unique MAC address. MAC addresses are managed by IEEE Registration Authority:
IEEE Registration Authority
'''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 (Naon, Lizard, Qong, Zefeer,...) usually provide MAC numbers by themselves by acquiring them from IEEE. In fact , there are many reasons for thatthis. 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.
* 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.
* /dev/mtd5 -> additional file system
Basically , we can upgrade the system through the bootloader or through the kernel.
Finally, we assume that only the aforementioned components should be upgraded. In case the system equips external '''microcontrollers, FPGAs, CPLDs,''' etc, different strategies must be taken into account depending on the particular case.
=== Local upgrading ===
When the system doesn't allow a remote access, an operator must locally access the system through its user interface (in the best case) or through the serial port (in the worst case). If the
system provides a USB port, SD, MMC or PCMCIA slot, the system can retrieve the upgrade packages from those memory devices; if the user interface features a sort of upgrade command, the operator should just plug the device and activate the upgrade function. The serial port is the last option to connect to the system and manually send the proper commands to complete the upgrade procedure.
* Run the make tool <pre>make PROGRAMS=”dropbear dbclient scp” MULTI=1 STATIC=1</pre>
More information are 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).
