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.
In a customer’s production line during mass production, an SD card was used for firmware flashing.
After the 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 power off 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 the flashing was complete.
Logically, this process seems to have no issues. However, problems still occurred with high probability. After thorough investigation, it was found that the executable program contained a secondary decompression operation and called a Linux shell command 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 powering off and restarting upon hearing the buzzer, this could lead to the device being restarted before the 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 outage occurs before the 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 (such as ext4 with journaling)
Using a file system that supports journaling can reduce the risk of data corruption due to unexpected power outages.
Optimize power-off strategies
The production process can be modified to issue the buzzer alert only after the system self-check is completed, avoiding human error.
Through the above optimizations, the issues caused by asynchronous file writing during firmware flashing can be effectively reduced, improving the reliability of industrial production.
The views expressed in this article are solely those of the author and do not represent the views of the platform.
If there are any objections, please feel free to contact us.
If there is any infringement, please contact us for removal.
Previous Highlights Review
The first snow of 2021! Analysis of Intel’s Q4 2020 financial report
Accelerating functional simulation using hardware-assisted verification tools
Blog: The challenges of die size and photomaskâCost models for lithography scanner throughput
Blog Dispatch: Race condition in digital circuits
