Bootloader-based remote update mechanism for reliable Embedded Software

Source: Micro-Computer Information Author: Wang Heng Wang Yu Wang Quan Li Yong

1. With the wide application of embedded systems in various fields, maintenance of embedded software becomes increasingly important [1]. After the embedded system is put into the actual environment for operation, some errors that cannot be fully tested during software development will be exposed. During the runtime of the embedded system, users also tend to propose new functional and performance requirements for embedded software. Therefore, the update of embedded software has gradually become an important issue in the practical application of embedded systems. When a large number of embedded systems are installed, or the installation location is inconvenient, manual update is costly. Remote automatic update: a wired or wireless communication interface is designed in the embedded system to implement automatic update of embedded software through remote communication. This method can effectively reduce the embedded software update and maintenance costs, so it has been widely concerned. The current research on the New Technology of Embedded Software Remote self-updating mainly focuses on the design of the update method, and there is no in-depth research on how to ensure the reliability of the update process. The reliability of updates is mainly affected by two factors: first, the reliability of remote data transmission Update and the reliability of startup after system update. Embedded Linux and Windows
For more complex operating systems such as Ce, an independent bootloader program [2] [3] is generally designed to initialize the system and guide the embedded operating system. The startup of an embedded system with this structure is closely related to bootloader. This paper proposes a highly reliable remote automatic update mechanism for Embedded Systems Using bootloader, the software and hardware design is based on the embedded system of ARM microprocessor [4], embedded Linux operating system [5] and wireless communication interface. Then, the update mechanism is applied to the actual system for testing, and the conclusion of this article is given.

2. Update the overall structure of the system.

This section takes the arm and embedded Linux operating system as an example to introduce the overall structure of the remote self-update system. An embedded system that supports remote self-update can be divided into two parts: the front-end operation module and the background control module. The front-end operating module uses the S3C2410 microprocessor based on the arm9-core, with a clock speed of up to 200 MHz. It is equipped with 8 m Ram and 32 m flash memory, and runs the arm-Linux embedded operating system, it has a independently designed bootloader program. The background control module is used to remotely control the front-end operation module and is the core of the system control. The front-end operating module is connected to the CDMA2000-1X wireless communication system through the wireless module bcm860, and then connected to the Internet. CDMA2000-1X is the first generation of mobile communication system, supporting high-speed data grouping business. The background control module is connected directly to the Internet in a wired manner, and standard TCP/IP-based communication is implemented between it and the foreground running module. Status information, control information, and update files are all transmitted on this data link.

Figure 1 System Structure

3. Update System Software Design

3.1 flash memory Layout

The layout of flash memory in the traditional LINUX embedded system is shown in figure 2 (. To facilitate the description, we combine the Linux kernel and file system into a Linux image file. When the system updates the software, it first downloads the new image file to the memory, and then writes it to the Flash image file storage area to overwrite the old image file. This method does not consider possible interference during the update process. If a data update error or a write-down error occurs due to unexpected interference during the update, the bootloader may fail to start the new image file after the software is updated, and the front-end module may not run, and lost contact with the background control center to become an "isolated system ". In this case, manual processing can only be performed at the front-end system installation location, resulting in a high cost.

Figure 2 (a) Traditional flash layout (B) Flash layout of the Self-Update System

To improve the reliability of software updates, this mechanism re-designs the layout of flash memory, as shown in 2 (B. Three image file storage zones are designed after the bootloader storage zone. One storage zone is used to store the latest image file to be started, which is called the current zone; the other is used to store the image file of the previous version, which is called the previous version zone; the remaining storage area is used to store the original version of the image file, known as the first version of this area. The current zone and the previous version zone are located in the first two storage zones, which dynamically change with software updates. After each software update, the new image file is written to the pre-version area, so that the current zone is changed to the pre-version area, and the pre-version area is changed to the current zone. The initial version of this zone is fixed in the third partition. The stored image file is the initial program when the embedded system is put into operation. The content of this storage zone is not changed for each software update. In addition, a parameter storage area is designed at the high address of flash to store system configuration parameters that need to be solidified. The start point and update bit parameters are required for the update program. The start point is used to indicate the storage area from which the bootloader needs to load the image file, and the update bit is used to indicate the status of the system for software updates.

3.2 update Task Design

In an embedded Linux system, the update task is designed as a process blocking the update semaphore. After the system starts each time, the update process first reports the current software version number to the background control module, then checks the Flash update bit, and then enters the blocking status. After receiving the update command from the control module, the system releases the update semaphore and the update process starts to update the software. The update process uses the new program image file sent from the TCP receiving control module. Considering the characteristics of wireless data transmission, in order to enhance the transmission reliability, a set of sending and receiving protocols with verification, validation, and retransmission functions are designed at the application layer, to ensure that the data of the new image file can be transmitted to the memory of the front-end module through the Internet and mobile communication systems. After the new image file is downloaded, the update process first determines the location of the previous version area on flash, and then calls the flash read/write function to write the new image file to the previous version storage area. After writing, update location 1 and change the startup point. If the current program version is the original version, the new image file is written to the first two storage zones at the same time. The program process 3 of the update process is shown in.

Figure 3 Process update Flowchart

Figure 4 exception handling Flowchart

3.3 launch process after update

The front-end operating module has an independent Bootloader and is fixed at the low address of the flash memory. After the system is started, it can always enter the bootloader. Bootloader directs an image file in the three program storage areas by reading the startup point parameters of the parameter storage area. Under normal circumstances, the startup point parameter always points to the current zone. After the software is updated, the startup point switches between the storage zone 1 and storage zone 2, pointing to the storage zone of the new image file. In this way, when the update process restarts the front-end module, bootloader will guide the new image file.

To enhance the reliability of system startup after Software Update, this mechanism uses arm system exceptions to handle startup errors. There are 7 types of exceptions in the ARM architecture, including undefined commands, command prefetch abort, and data access abort, which are closely related to the startup process. Design an exception handling program to load the backup storage area's image files. When the bootloader fails to boot the new image file, it enters the exception handling function. In this function, the start point is changed to the previous version area, and the update location is 2, indicating that the start point has been changed twice. After the system is restarted, bootloader restores the image file of the previous version. When the software is updated, only new image files are written to the adjacent storage areas, and no operations are performed on the storage areas of the previous version of the program, in addition, the previous version of the program is a program that has been started normally before the update. Therefore, the previous version of the program should be successfully booted normally. If the program of the previous version still fails to be started due to unexpected interference, the exception handler function will be started again. Read the value of the update bit in the function. If the update bit is 2, point the start point to the primary zone and set the update position to 3. After the system is restarted, bootloader will guide the original version of the program image file. The original version of the image file has never been changed after the front-end module is installed, and has been verified and tested before the installation, with high reliability. When the new and previous versions of the program cannot be started successfully, the system tries to start the original version of the image file to ensure the normal operation of the basic functions of the system, make sure that there is no link between the front-end module and the background control module. The background control module learns the software update information based on the version number reported after the front-end module is started and takes corresponding measures. When the exception handling function reads the value of the start point, if the read value is abnormal or an error occurs, the start point is repaired, as shown in process 4 of the exception handling function. By using the startup point, update bit, and exception handling program, when the software update encounters interference and errors, this mechanism can choose to start the software versions of the two backups in sequence, this effectively improves the reliability of software updates and prevents the emergence of "isolated systems.

4. Test Results

This update mechanism is applied to an actual wireless remote monitoring system to verify and test its performance. First, test the running effect of the update process. The results show that each test update process can correctly start data transmission between the control module and introduce the validation and retransmission mechanisms at the application layer, the image files of the new program can be accurately transmitted to the front-end running module through the Internet and wireless networks. The focus of the test is the reliability of the new program startup after the system software is updated. Simulate the interference and data errors encountered during software update to test whether the bootloader can correctly start the backup program. The test simulates three types of situations: one is that the program image files on flash randomly encounter data errors at some addresses, another type is the random location of some data in the program image files on flash, and the third type is the value of the startup point. These three cases are divided into six specific solutions for testing. Each solution is tested 20 times to check whether the system can start the program image according to the expected results. The test scheme and result are shown in table 1.

From the test results, we can see that this update mechanism has the best effect on identifying data errors in flash. During each startup, the system can correctly enter the exception and start the backup program; the recognition rate for data address misplacement in Flash has reached more than 80%. When the program data is correct but the storage address is misplaced, there is a certain probability that the commands taken out by the ARM processor can be identified and executed, as a result, the program runs to an unknown state and the system cannot be started. In addition, the update mechanism has a strong ability to fix the configuration area, preventing startup failure due to data errors in the configuration area. The test results of the experimental platform show that this update mechanism can effectively improve the stability and reliability of the restart after the embedded software is updated, and has a strong self-recovery ability.

5 conclusion

This paper proposes a bootloader-based automatic remote update mechanism for embedded software. This update mechanism saves three image files at the same time, so more flash storage space is required, slightly increasing the hardware cost of the embedded system. However, this cost is worthwhile compared with the huge reduction in maintenance costs caused by remote, automated, and reliable update mechanisms.

The main innovation of this article: by setting up two backup program storage zones and using the exception mechanism of the embedded processor, the embedded system update has a strong self-recovery capability, it greatly improves the reliability of the embedded software update process, especially to prevent system startup failures after the embedded system update, which has high practical value. In addition, remote automatic update is implemented through the CDMA system, which can be free from Region restrictions and free from wiring, improving the convenience of remote update for embedded systems.