Click on the aboveblue text to follow us
In industrial production, firmware flashing is a critical step to ensure the normal operation of products.
However, in practical applications, due to the asynchronous nature of file writing in the Linux system, it may lead to incomplete firmware flashing, thereby affecting the normal startup and operation of the device.
This article will reveal the firmware flashing issues caused by asynchronous file writing in the Linux system through a practical case and discuss corresponding solutions.
During the mass production process on a customer’s production line, SD cards were used for firmware flashing.
After flashing is completed, a buzzer alerts the production line workers that they can proceed to the next step. Upon hearing the buzzer, the workers immediately cut power and restart the device to enter the testing phase.
However, during subsequent testing, it was found that some products exhibited anomalies during startup.
Further analysis revealed that the customer used a decompression method to flash the system firmware:
- The decompression command was executed.
- A binary executable program was run.
- The buzzer sounded, indicating that flashing was complete.
Logically, this process seems correct. However, the problem still occurred with high probability. After thorough investigation, it was found that the executable program contained a secondary decompression operation and invoked Linux shell commands using system().
system() creates a new subprocess, causing the buzzer sound and the secondary decompression to execute in different processes without a strict sequence.
According to the logic of cutting power immediately after the buzzer sounds, this could lead to the device being restarted before decompression is complete, ultimately resulting in incomplete file flashing and abnormal system startup.
The Linux system employs a page cache mechanism to cache written content. User write operations are actually delayed, referred to as “dirty data”.
Scenarios for dirty page data to be written back to disk include:
- When free memory falls below a specific threshold, the kernel must write dirty pages back to disk to free up memory.
- When dirty pages have resided in memory for longer than a specific threshold, the kernel performs a write-back operation to prevent dirty pages from residing indefinitely.
- When a user process calls sync() or fsync() system calls, the kernel forces the write-back of data as instructed.
If the decompression script does not include a sync command, or if the program does not call fsync() after decompression or writing, the system will rely on the default write-back mechanism mentioned above.
If a power cut occurs before dirty pages are written back to the storage device, the file content may be incomplete, leading to startup anomalies.
To address the above issues, the following measures can be taken to ensure data integrity:
Add synchronization operations in the update script
Immediately execute the sync command after decompressing the firmware to ensure data is written to disk.
Use fsync()
Explicitly call fsync(fd) after performing file write operations to ensure data is synchronized to the storage device.
Avoid using system() for critical operations
system() may lead to concurrent execution; it is recommended to use more controllable methods like execv() to execute commands, ensuring the order of task execution.
Adopt a journaling file system (e.g., ext4 with journaling)
Using a file system that supports journaling can reduce the risk of data corruption due to unexpected power cuts.
Optimize power cut strategies
The production process can be modified to issue the buzzer alert only after the system self-check is complete, avoiding human error.
Through these optimizations, the issues caused by asynchronous file writing during firmware flashing can be effectively reduced, enhancing the reliability of industrial production.
Click to read the original text for more exciting content~