Firmware upgrading method and embedded device
By accessing and judging the memory card format during the boot loader operation stage of the embedded device, firmware upgrades are realized using the exFAT format memory card, solving the problem of the inability to upgrade the exFAT format memory card in the boot loader stage in the prior art, and improving the upgrade efficiency and compatibility.
Patent Information
- Application Number
- CN202311528925.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-11-16
- Publication Date
- 2025-05-16
AI Technical Summary
Existing embedded devices cannot use exFAT format memory cards to upgrade firmware during the boot loader operation stage, resulting in failure to upgrade normally. It takes a long time to upgrade firmware during the operating system operation stage, occupying more hardware resources, and increasing product costs.
By accessing the memory card and judging its storage format during the boot loader operation stage of the embedded device, the firmware upgrade file stored in the exFAT format memory card is read and executed in the corresponding way, and firmware upgrades in the boot loader operation stage are realized.
It realizes that firmware upgrades can be upgraded using the exFAT format memory card during the boot loader operation stage. Compared with firmware upgrades after entering the Linux system, it avoids setting up a separate backup area, saves hardware resources, and improves device compatibility.
Smart Images

Figure CN120010875A_ABST
Abstract
Description
Technical Field
[0001] The invention belongs to the field of embedded systems, and in particular relates to a firmware upgrading method and an embedded device. Background Art
[0002] With the development of video imaging technology, video recorders such as security monitoring equipment are constantly upgraded, especially in image resolution, from VGA (640*480) to standard definition (1280*720), to high definition (1920*1080), and 4K (3840*2160). For example, in the dash cam industry, because the resolution of video recording is constantly improving, and the video bit rate of the dash cam is very large, if the video resolution is set to 4K, the video bit rate will reach 20Mbit / s, and a one-minute video will occupy 150Mbyte of storage space. In this case, the capacity of the SD card and other storage cards of the video recording equipment needs to be continuously increased. The current mainstream uses large-capacity storage cards of 64G and 128G or more.
[0003] With the development of video image technology, large-capacity memory cards such as SD cards are widely used in devices such as video recorders. However, during the firmware upgrade process of the video recorder, there is a situation where the large-capacity memory card cannot be automatically upgraded due to storage format problems.
[0004] Specifically, when formatting an SD memory card on a computer running the Windows operating system, the default formatting for cards with a capacity of 32G or less is Fat32, and for cards with a capacity of more than 32G, it is formatted into exFAT format. At the same time, during the firmware upgrade process of embedded devices running Linux, such as video recorders, it is necessary to first store the firmware required for the upgrade in a memory card such as an SD card. When the memory card is inserted into the embedded device, the embedded device is powered on, and the system checks whether the firmware stored in the memory card needs to be upgraded by accessing the memory card. When the embedded device is performing a firmware upgrade, the firmware of the fat32 formatted memory card can be upgraded during the stage when the boot loader (uboot) is running, but at this stage, the exFAT formatted memory card cannot be correctly accessed, resulting in a failure to upgrade normally. Therefore, the embedded device cannot complete the firmware upgrade during the stage when the boot loader (uboot) is running. During the Linux operating system running stage, although the operating system can access fat32 and exFAT formatted storage cards and use firmware for upgrading, the storage card can only be accessed after the embedded device is powered on and the operating system is loaded. The firmware upgrade takes a long time. At the same time, a separate backup partition needs to be set up in the storage of the embedded device to facilitate the upgrade of the root file system. For embedded devices, more hardware resources need to be occupied, further increasing the product cost.
[0005] Specifically, the device runs the Linux system, and the firmware can be upgraded with a fat32 format SD card in the uboot stage. This method cannot perform normal firmware upgrades because the exFAT format card cannot be correctly accessed in the uboot stage. Under this condition, a large-capacity exFAT format SD card is not suitable as an upgrade card. The device runs the Linux system, and the firmware can be upgraded with a fat32 or exFAT format SD card in the operating system stage. This method, although the operating system can access a large-capacity exFAT format SD card, but because in the operating system stage, the first device is powered on to load the operating system, and then access the SD card, it takes a long time; the second is that it is generally necessary to set up a separate backup partition to facilitate the upgrade of the root file system. For embedded devices, it takes more hardware resources and has certain cost pressures.
[0006] In view of this, the current market is in urgent need of an embedded device that can perform firmware upgrades via a memory card, and the device can use the firmware stored in the memory card for upgrades during the operation of the boot loader, thereby solving the problem of not being able to use exFAT formatted memory cards to achieve firmware upgrades for embedded devices, thereby meeting market demand.
[0007] In addition, common technical terms include:
[0008] Linux, full name GNU / Linux, is a free to use and freely disseminated UNIX-like operating system, widely used in desktop systems, server systems, and embedded systems. It is widely used in many embedded devices, such as security cameras, driving recorders, etc. uboot, full name Universal Boot Loader, is usually used as a boot program for embedded devices. It can initialize and access memory, serial ports, storage devices, etc., and boot and load the operating system. SD card, full name SD memory card (Secure Digital Memory Card) is a new generation of high-speed storage device based on semiconductor flash memory. It is widely used in portable devices, such as digital cameras, camcorders, recorders, etc.
[0009] FAT32 is a disk file system format that uses a 32-bit binary number to record file allocation tables. FAT32 has good compatibility, but does not support files larger than 4GB.
[0010] exFAT is a file system suitable for flash memory introduced by Microsoft in Windows Embeded 5.0 and above. It is the successor of the FAT32 (File Allocation Table) file system and is mainly launched to solve the problem that FAT32 does not support 4G or larger files. Summary of the invention
[0011] In order to solve the above problems, the purpose of this application is to provide a firmware upgrade method and an embedded device to solve the problem that the exFAT formatted memory card cannot be used for firmware upgrade during the boot loader running stage.
[0012] Specifically, the technical solution of the present invention provides a firmware upgrade method, comprising the following steps:
[0013] S1, after the embedded device enters the bootloader running stage, it accesses the memory card;
[0014] S2, determining the storage format of the memory card: reading the boot sector information of the master boot area of the memory card, and determining the storage format through the offset byte;
[0015] S3, reading the firmware upgrade file in the memory card using a corresponding method according to the storage format: obtaining the file directory and file name of the exFAT format memory card, and determining whether the firmware upgrade file exists;
[0016] S4, execute the firmware upgrade file using a corresponding method.
[0017] According to a preferred embodiment, the storage format includes at least FAT32 and exFAT.
[0018] According to a preferred embodiment, the offset byte determining the storage format in step S2 includes the following steps:
[0019] Offset 0x03 bytes, exFAT file system; and / or
[0020] Offset 0x52 bytes is the FAT32 file system.
[0021] According to a preferred embodiment, the step S3 further comprises the following steps:
[0022] According to the boot sector information of the master boot area read, the BPB is obtained, and the root directory position is calculated using the first cluster starting sector, the root directory first cluster number, and the cluster size information;
[0023] Read the root directory partition information, find the directory item of the user file, and confirm whether the firmware upgrade file exists through the directory item attributes of the user file.
[0024] According to a preferred embodiment, the step of confirming whether the firmware upgrade file exists through the directory item attributes of the user file includes the following steps:
[0025] Read the attribute information of the user file's directory item with the first byte characteristic value of "C1H". If the entire user file directory item is traversed and a file consistent with the attribute information of the directory item with the first byte characteristic value of "C1H" is matched, then a firmware upgrade file exists; if no file consistent with the attribute information is matched, then no firmware upgrade file exists.
[0026] According to a preferred embodiment, the step of reading the firmware upgrade file in the memory card in step S3 includes: reading the contents of the firmware upgrade file in the memory card in the exFAT format, further including the following steps:
[0027] According to the byte offset position of the firmware upgrade file, the file size and the file start cluster number are obtained;
[0028] The sector where the firmware upgrade file is located can be located based on the BPB information, the first cluster starting sector, the root directory first cluster number, and the cluster size information;
[0029] According to the byte offset position of the firmware upgrade file, it is determined whether the file is stored continuously, and then the firmware upgrade file is read.
[0030] According to a preferred embodiment, wherein the firmware upgrade file is stored in fragments, the FAT table corresponding to the cluster is read, and the content corresponding to the number of bytes of the file size is read according to the cluster number of the next storage cluster stored in the FAT table.
[0031] According to a preferred embodiment, the execution of the firmware upgrade file includes the following steps: verifying the firmware upgrade file to determine whether the file itself is complete; verifying the firmware upgrade version to confirm whether an upgrade is required; and upgrading using the firmware upgrade file.
[0032] Specifically, the technical solution of the present invention also provides an embedded device, which includes the corresponding features of the above-mentioned firmware upgrade method.
[0033] Therefore, the advantages of the present application are: the firmware upgrade method and embedded device of the present invention can realize the firmware upgrade using the exFAT format storage card during the boot loader running phase, which is faster and more efficient than the firmware upgrade after entering the Linux system, and also avoids setting up a separate backup area, saving norflash resources, and improving the compatibility of the device.
[0034] With the widespread use of exFAT formatted memory cards (such as SD cards, TF cards, etc.), the boot loader (uboot) supporting exFAT access will bring convenience to users and avoid the problem that exFAT formatted memory cards cannot be upgraded, which is often encountered by users. Especially for memory cards below 32G, there is no need to format the memory card into FAT32 format, which is more convenient to use. BRIEF DESCRIPTION OF THE DRAWINGS
[0035] The drawings described herein are used to provide a further understanding of the present invention, constitute a part of this application, and do not constitute a limitation of the present invention.
[0036] Figure 1 Figure 1 is a flowchart of upgrading the firmware via a memory card during the bootloader running phase.
[0037] Figure 2 This is a schematic diagram of exFAT boot sector information.
[0038] Figure 3 This is a schematic diagram of FAT32 boot sector information.
[0039] Figure 4 It is a schematic diagram of user file directory items.
[0040] Figure 5 This is a schematic diagram of the firmware upgrade file C0 information. DETAILED DESCRIPTION
[0041] In order to more clearly understand the technical content and advantages of the present invention, the present invention is now further described in detail in conjunction with the accompanying drawings.
[0042] See also Figure 1 As shown, a schematic diagram of the process of upgrading the firmware through a memory card during the boot loader operation phase of the present invention is illustrated. After the embedded device is powered on and the memory card is inserted, the device performs the firmware upgrade according to the following steps:
[0043] S1. After the embedded device enters the boot loader (uboot) running stage, it determines whether a memory card is connected;
[0044] S2. Determine the storage format of the memory card, and determine whether the storage format is FAT32 or exFAT;
[0045] S3. Check the firmware upgrade file in the memory card according to the storage format and read it;
[0046] S4. Perform firmware upgrade using the firmware upgrade file.
[0047] Specifically, the embedded device actively attempts to read a memory card such as an SD card or a TF card during the boot loader (uboot) operation phase. If the memory card exists, it will attempt to access the memory card content in different storage formats and determine whether it is necessary to perform a firmware upgrade. The storage formats of the present invention include but are not limited to FAT32 and exFAT, and should also include other storage formats generated with the evolution of technology. For example, in the application of T31 / T40 / T41 model chips, the firmware is upgraded through an SD card during the uboot phase.
[0048] In step S2, the process of reading the storage format of the memory card is to read the boot sector information of the master boot area and determine the storage format in the form of the offset byte. Figure 2 The exFAT boot sector information diagram shown in the figure, the present invention determines whether it is an exFAT file system by offsetting 0x03 bytes. Figure 3 The schematic diagram of FAT32 boot sector information shown in the figure, the present invention determines whether it is a FAT32 file system by offsetting 0x52 bytes.
[0049] In the above S2, you can first determine whether the storage format is exFAT, and then enter step S3 after confirming that it is, and then determine whether it is FAT32 after confirming that it is not exFAT. If it is, then enter step S3, and if it is not, then end the firmware upgrade process. You can also first determine whether the storage format is FAT32, and then enter step S3 after confirming that it is, and then determine whether it is exFAT after confirming that it is not FAT32. If it is, then enter step S3, and if it is not, then end the firmware upgrade process. At the same time, if there are other storage formats that can be determined based on the offset bytes, they should also be within the scope of this patent. The storage formats can be confirmed by the offset bytes in turn. After confirming the storage format, start S3, and if it cannot be confirmed, end the firmware upgrade.
[0050] Step S3 also includes obtaining the file directory and file name of the exFAT format memory card and determining whether the firmware upgrade file exists. Specifically, it includes:
[0051] S31, according to the boot sector information of the master boot area read, obtain BPB (BIOS Parameter Block), and use the first cluster starting sector, the first cluster number of the root directory, and the cluster size information therein to calculate the root directory location;
[0052] S32, reading the root directory partition information, searching for the directory entry of the user file, and confirming whether the firmware upgrade file exists from the directory entry attributes of the user file.
[0053] The reading of the root directory partition information can find the volume label directory entry, the cluster bitmap file directory entry, the uppercase character file directory entry, and the user file directory entry, from which the user file directory entry needs to be found.
[0054] Each of the user files has at least three directory entry attributes, namely:
[0055] Attribute 1: The characteristic value of the first byte of the directory entry is "85H", which describes the basic information of the file, modification date, etc.
[0056] Attribute 2: The characteristic value of the first byte of the directory entry is "C0H", which is mainly used to find the cluster where the file is located, the size, etc.
[0057] Attribute 3: The characteristic value of the first byte of the directory entry is "C1H", which describes the file name.
[0058] In this way, the existence of the firmware upgrade file can be confirmed based on attribute 3 of the user file directory item.
[0059] See also Figure 4 The schematic diagram of the user file directory items is shown in FIG. Figure 4 In the command, the file named upate_firmeware.img is the firmware upgrade file. If the entire user file directory item is traversed and a file named upate_firmeware.img is matched, the firmware upgrade file exists. If no file named upate_firmeware.img is matched, the firmware upgrade file does not exist.
[0060] After completing the confirmation of the existence of the firmware upgrade file, the above step S3 further includes the following steps:
[0061] S33, reading the contents of the firmware upgrade file in the exFAT format memory card.
[0062] like Figure 4 As shown in the figure, the C1-beginning attribute information describes the file name, through which the upgrade firmware name can be found. The C0-beginning attribute information at the C1 position further describes the file size and cluster location. Figure 5 The firmware upgrade file C0 information diagram is shown in the figure. Figure 4 The data in the bold box is the information of the firmware upgrade file.
[0063] The following example shows how to read the firmware upgrade file of an exFAT format memory card:
[0064] S331. According to the byte offset 0x08 of the firmware upgrade file, the file size 0x800000 is obtained, which represents 8Mbyte.
[0065] S332. According to the byte offset 0x14 position of the firmware upgrade file, the file start cluster number is obtained, and the sector position can be located according to the previous BPB information, the first cluster start sector, the root directory first cluster number, and the cluster size information.
[0066] S333, according to the byte offset 0x01 position of the firmware upgrade file, determine whether the file is stored continuously, and then read the firmware upgrade file. If the value of the byte offset 0x01 position is 0x03, it means continuous storage. At this time, according to the first sector, read continuous 8Mbyte bytes; if the value of the byte offset 0x01 position is 0x01, it means fragmented storage, then the storage value in the item of the cluster corresponding to the fat table is the cluster number of the next storage cluster, and it is necessary to read the fat table information, and read 8Mbyte bytes in combination with the fat table information.
[0067] In the above step S4, before using the firmware upgrade file to upgrade the firmware, the version of the firmware information is first determined. If the versions are consistent, the upgrade is terminated; if the firmware information is different, the firmware is loaded into the memory, and norflash is written from the memory to complete the firmware upgrade, and the boot loader (uboot) is restarted.
[0068] The implementation of step S4 is shown below by way of example:
[0069] S41, perform MD5SUM verification on the firmware upgrade file to determine whether the file itself is complete;
[0070] S42, verifying the firmware upgrade version to confirm whether it needs to be upgraded;
[0071] S43. Upgrade the partitions that need to be updated, such as uboot, kernel, and file system partitions.
[0072] In addition to the above firmware upgrade method, the present invention also includes an embedded device capable of executing the above method, wherein the device has the corresponding hardware and functions mentioned in the firmware upgrade method.
[0073] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the embodiments of the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.
Claims
1. A firmware upgrade method, characterized in that: It includes the following steps: S1, after the embedded device enters the bootloader running stage, it accesses the memory card; S2, determining the storage format of the memory card: reading the boot sector information of the master boot area of the memory card, and determining the storage format through the offset byte; S3, reading the firmware upgrade file in the memory card using a corresponding method according to the storage format: obtaining the file directory and file name of the exFAT format memory card, and determining whether the firmware upgrade file exists; S4, execute the firmware upgrade file using a corresponding method.
2. A firmware upgrade method according to claim 1, characterized in that: The storage formats include at least FAT32 and exFAT.
3. A firmware upgrade method according to claim 1, characterized in that: Determining the storage format by offset byte in step S2 includes the following steps: Offset 0x03 bytes, exFAT file system; and / or Offset 0x52 bytes is the FAT32 file system.
4. A firmware upgrade method according to claim 1, characterized in that: The step S3 further comprises the following steps: According to the boot sector information of the master boot area read, the BPB is obtained, and the root directory position is calculated using the first cluster starting sector, the root directory first cluster number, and the cluster size information; Read the root directory partition information, find the directory item of the user file, and confirm whether the firmware upgrade file exists through the directory item attributes of the user file.
5. A firmware upgrade method according to claim 4, characterized in that: The method of confirming whether the firmware upgrade file exists through the directory item attributes of the user file includes the following steps: Read the attribute information of the first byte characteristic value of the user file directory item "C1H". If the entire user file directory item is traversed and a file consistent with the attribute information of the first byte characteristic value of the directory item "C1H" is matched, then a firmware upgrade file exists; if no file consistent with the attribute information is matched, then no firmware upgrade file exists.
6. The firmware upgrade method according to claim 1, characterized in that: The reading of the firmware upgrade file in the memory card in step S3 includes: reading the contents of the firmware upgrade file in the exFAT format memory card, and further includes the following steps: According to the byte offset position of the firmware upgrade file, the file size and the file start cluster number are obtained; The sector where the firmware upgrade file is located can be located based on the BPB information, the first cluster starting sector, the root directory first cluster number, and the cluster size information; According to the byte offset position of the firmware upgrade file, it is determined whether the file is stored continuously, and then the firmware upgrade file is read.
7. A firmware upgrade method according to claim 6, characterized in that: If the firmware upgrade file is stored in fragments, the FAT table corresponding to the cluster is read, and the content of the number of bytes corresponding to the file size is read according to the cluster number of the next storage cluster stored in the FAT table.
8. A firmware upgrade method according to claim 7, characterized in that: The execution of the firmware upgrade file includes the following steps: verifying the firmware upgrade file to determine whether the file itself is complete; verifying the firmware upgrade version to confirm whether an upgrade is required; and upgrading using the firmware upgrade file.
9. An embedded device, characterized in that It comprises the features of claims 1-8.