Firmware upgrading method, upper computer and zero terminal

Abstract

The invention provides a firmware upgrading method, an upper computer and a zero terminal. The method comprises the following steps: acquiring the capacity of the SD card; selecting the type of the SD card needing to be manufactured; wherein the type of the SD card comprises a conventional SD card, an SD starting card, an SD repairing card and an SD upgrading card; selecting firmware compiled in the compiling environment in advance; wherein the firmware is composed of a plurality of files; according to the capacity of the SD card and the type of the SD card needing to be manufactured, corresponding content and a starting mark are written into a preset sector format. According to the firmware upgrading method, different types of SD cards can be manufactured through upper computer software, and a USB interface or a GMAC interface used in a conventional upgrading scheme is omitted.

Description

Technical Field

[0001] This disclosure relates to the field of firmware upgrade technology, specifically to a firmware upgrade method, a host computer, and a terminal. Background Technology

[0002] Most current firmware upgrade solutions for zero-terminal devices are based on USB or GMAC interfaces. For example, after creating the firmware on a PC, the firmware is upgraded via the USB port of the zero-terminal device, or the firmware is copied to a USB flash drive beforehand and then the USB flash drive is connected to the zero-terminal device for upgrade. In a real production environment, it is very likely that every USB port will be occupied (users connect peripherals such as mice and keyboards). The same applies to firmware upgrades via GMAC interface (which may also be occupied). Therefore, considering this situation, it is necessary to improve the current solution. Summary of the Invention

[0003] The purpose of this disclosure is to overcome the shortcomings of the prior art and provide a firmware upgrade method, a host computer, and a terminal. This firmware upgrade method can create different types of SD cards through host computer software, saving the USB interface or GMAC interface used in conventional upgrade schemes.

[0004] According to a first aspect of the present disclosure, a firmware upgrade method is provided, applied to a host computer, comprising the following steps:

[0005] Get the capacity of the SD card;

[0006] Select the type of SD card to be created; wherein, the SD card type includes regular SD card, SD boot card, SD repair card and SD upgrade card;

[0007] Select the firmware that has been pre-compiled in the compilation environment; wherein the firmware consists of multiple files;

[0008] Based on the capacity of the SD card and the type of SD card to be made, write the corresponding content and boot flag into the pre-set sector format.

[0009] In one embodiment, if the SD card to be created is an SD boot card, the step of writing corresponding content and a boot flag in a pre-defined sector format according to the capacity of the SD card and the type of SD card to be created includes:

[0010] The selected firmware, pre-compiled in the compilation environment, is written to the SD boot card and used as main memory, so that when the zero terminal boots from the SD boot card, the firmware and other files are stored on the SD boot card.

[0011] In one embodiment, if the SD card to be created is an SD repair card, the step of writing corresponding content and a boot flag in a pre-defined sector format according to the capacity of the SD card and the type of SD card to be created includes:

[0012] The auxiliary program loader and the linux.itb and u-boot.itb checksums in the SD repair card are read from the SD repair card, and the linux.itb and u-boot.itb checksums in the SD repair card are compared with the corresponding checksums in the main memory of the zero terminal.

[0013] If the linux.itb and u-boot.itb checksums in the SD repair card are consistent with the corresponding checksums in the main memory of the zero terminal, then the size and loading address of the auxiliary program loader are parsed from the header information of the auxiliary program loader, and the auxiliary program loader and the general boot loader are loaded and run.

[0014] After the general bootloader starts, it parses the image_header_t header information of Linux and jumps to the Linux load address. Linux completes the initialization of each functional module of the system, including the mounting of the root file system, and finally completes the system startup.

[0015] In one embodiment, if the SD card to be created is an SD upgrade card, the step of writing corresponding content and a boot flag in a pre-defined sector format according to the capacity of the SD card and the type of SD card to be created includes:

[0016] Read the auxiliary program loader from the SD upgrade card;

[0017] Parse the size and load address of the helper loader from the header information of the helper loader, and load and run the helper loader and read the general boot loader for loading;

[0018] After the general bootloader starts, it parses the image_header_t header information of Linux and jumps to the Linux load address. Linux completes the initialization of each functional module of the system, including the mounting of the root file system, and finally completes the system startup.

[0019] According to a second aspect of the present disclosure, a firmware upgrade method is provided, applied to a zero-terminal device, the method comprising:

[0020] Determine whether an SD card is installed in the zero terminal;

[0021] When an SD card is installed in the zero terminal, check whether the value at the preset sector of the SD card is the preset value;

[0022] If the value at the preset sector of the SD card is a preset value, then determine whether the preset sector has a boot flag for storing the SD card;

[0023] If a boot flag for storing an SD card is set in the preset sector, and the flag is a first preset value, then the SD card is determined to be an upgrade card or a test card, and firmware is read from the SD card to boot the zero terminal.

[0024] In one embodiment, the method further includes:

[0025] If a boot flag for the storage card is set in the preset sector, and the flag is a second preset value, the SD card is determined to be a boot card, and firmware is read from the SD card to boot the zero terminal.

[0026] In one embodiment, the method further includes:

[0027] If a startup flag for the storage card is set in the preset sector, and the flag is a third preset value, then the SD card is determined to be a repair card;

[0028] Read the linux.itb and u-boot.itb checksums from the SD card, and compare the linux.itb and u-boot.itb checksums from the SD card with the corresponding checksums in the main memory of the zero terminal.

[0029] If the checksums of linux.itb and u-boot.itb in the SD card are consistent with the corresponding checksums in the main memory of the zero terminal, then the firmware is read from the SD card to start the zero terminal.

[0030] In one embodiment, if the checksums of linux.itb and u-boot.itb in the SD card are both consistent with the corresponding checksums in the main memory of the zero terminal, then reading the firmware from the SD card to boot the zero terminal includes:

[0031] Parse the size and load address of the helper loader from the header information of the helper loader, and load and run the helper loader and read the general boot loader for loading;

[0032] After the generic bootloader starts, it parses the image_header_t header information of Linux and jumps to the Linux load address. Linux completes the initialization of each functional module of the system, including mounting the root file system, and finally completes the system boot.

[0033] According to a third aspect of the present disclosure, a host computer is provided, comprising: an acquisition module, a selection module, a selection module, and a writing module; wherein...

[0034] The acquisition module is used to acquire the capacity of the SD card;

[0035] The selection module is used to select the type of SD card to be created; wherein, the SD card type includes regular SD card, SD boot card, SD repair card and SD upgrade card;

[0036] The selected module is used to select firmware that has been pre-compiled in the compilation environment; wherein the firmware consists of multiple files;

[0037] The writing module is used to write corresponding content and a boot flag in a pre-set sector format according to the capacity of the SD card and the type of SD card to be made.

[0038] According to a fourth aspect of the present disclosure, a zero-terminal is provided, the zero-terminal comprising:

[0039] The judgment module is used to determine whether an SD card is installed in the zero terminal;

[0040] When an SD card is installed in the zero terminal, the viewing module checks whether the value at a preset sector of the SD card is a preset value.

[0041] The determining module is used to determine whether a boot flag for storing the SD card is set in the preset sector when the value at the preset sector of the SD card is a preset value.

[0042] The reading module is configured to set a boot flag for storing the SD card in the preset sector, and when the flag is a first preset value, determine that the SD card is an upgrade card or a test card, and then read the firmware from the SD card to start the zero terminal.

[0043] The firmware upgrade method provided in this disclosure can create different types of SD cards through host computer software, thereby saving the USB interface or GMAC interface used in conventional upgrade schemes. Attached Figure Description

[0044] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0045] Figure 1 This is a schematic diagram of the structure of a host computer provided in an embodiment of this disclosure.

[0046] Figure 2This is a flowchart illustrating a firmware upgrade method provided in an embodiment of the present disclosure.

[0047] Figure 3 This is a schematic diagram of the firmware loading process in a firmware upgrade method provided in an embodiment of this disclosure.

[0048] Figure 4 This is a flowchart illustrating a firmware upgrade method provided in an embodiment of the present disclosure.

[0049] Figure 5 This is a schematic diagram of the SD card boot process in a firmware upgrade method provided in a disclosed embodiment.

[0050] Figure 6 This is a structural diagram of a host computer provided in an embodiment of the present disclosure.

[0051] Figure 7 This is a structural diagram of a zero-terminal embodiment provided in this disclosure. Detailed Implementation

[0052] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0053] SD cards can be used in zero-terminal devices for functions such as large-capacity data storage, data transfer, and firmware upgrades. This disclosure presents a multi-functional SD card, such as a standard SD card (for regular data storage without special operation by the host computer), an SD upgrade card for production / test version firmware upgrades, an SD repair card (similar to an upgrade card, used for firmware repair), and an SD boot card (allowing the zero-terminal to boot directly from the SD card without copying firmware to main memory). By creating different types of SD cards using host computer software, different functional types of SD cards can be realized.

[0054] Figure 1 This is a schematic diagram of the structure of a host computer provided in an embodiment of this disclosure. Figure 1 As shown, the USB flash drive and SD card in this embodiment are used to create SD cards of different functional types (regular cards and special cards), and the host computer software is used to write firmware programs (composed of multiple ITB files) for different purposes into the SD card.

[0055] Figure 2 This is a schematic flowchart illustrating a firmware upgrade method provided in an embodiment of this disclosure. Figure 2 As shown, this method is applied to a host computer and includes:

[0056] Step 201: Obtain the capacity of the SD card;

[0057] In this step, after inserting the SD card into the USB flash drive, the USB flash drive is then inserted into the PC. Once the host computer recognizes the USB flash drive, the SD card can be considered a storage device. The host computer will then use the fdisk command to obtain the specific capacity of the SD card.

[0058] Step 202: Select the type of SD card to be created; wherein, the SD card type includes regular SD card, SD boot card, SD repair card and SD upgrade card;

[0059] In this step, different types of SD cards will have different boot processes depending on their boot flags.

[0060] Step 203: Select the firmware that has been pre-compiled in the compilation environment; wherein the firmware consists of multiple files;

[0061] Step 204: Based on the capacity of the SD card and the type of SD card to be made, write the corresponding content and boot flag into the preset sector format.

[0062] In this step, click Figure 1 The host computer will start the creation process by clicking the "Start Creation" button. Depending on the selections in steps 201 and 202, the host computer software will write different content into the pre-specified sector format. The host computer software will use the dd command to write firmware and boot flag information into different sectors. After writing is complete, SD cards of different functional types can be created.

[0063] It should be noted that, Figure 1 The format button is used to format the SD card. The test option is only for testing the firmware version; the rest is the same as the upgrade card boot process.

[0064] The following is a description of the SD card identifier in this embodiment:

[0065] Multifunctional SD cards created using host computer software can be broadly categorized into regular cards and special cards. Special cards are further divided into upgrade cards, boot cards, and repair cards. Different functional types of cards are distinguished by special markers in a specific sector (address). For example, if the starting value at the 66th sector of the SD card is 0xFCDCFCDC, it indicates a special card. During terminal startup, the firmware is read from the SD card for loading, thus booting the device. Otherwise, it is a regular card. After identifying a special card, a marker is stored at the 68th sector (512 bytes per sector). For example, 0 indicates an upgrade card, 1 indicates a boot card, and 2 indicates a repair card. Specifically, the SD card markers in this embodiment are explained in Table 1.

[0066] Table 1

[0067] Card logo Card type 0 Upgrade card / test card 1 Startup Card 2 Repair card

[0068] It should be noted that the conventional SD card in this embodiment does not require special settings from the host computer software and can be used for conventional data storage functions, such as storing data in the actual production environment, such as videos.

[0069] In one embodiment, if the SD card to be created is an SD boot card, the step of writing corresponding content and a boot flag in a pre-defined sector format according to the capacity of the SD card and the type of SD card to be created includes:

[0070] The selected firmware, pre-compiled in the compilation environment, is written to the SD boot card and used as main memory, so that when the zero terminal boots from the SD boot card, the firmware and other files are stored on the SD boot card.

[0071] In this embodiment, the zero terminal boots directly from the SD card. The firmware is written to the SD card by the host computer, and the SD card is used as the main memory. When the zero terminal boots from the SD card, the firmware and other files (if any) are stored on the SD card and do not need to be copied to the zero terminal's local main memory. This method greatly facilitates users in updating firmware without having to write the firmware to the zero terminal's local main memory.

[0072] In one embodiment, if the SD card to be created is an SD repair card, the step of writing corresponding content and a boot flag in a pre-defined sector format according to the capacity of the SD card and the type of SD card to be created includes:

[0073] The auxiliary program loader and the linux.itb and u-boot.itb checksums in the SD repair card are read from the SD repair card, and the linux.itb and u-boot.itb checksums in the SD repair card are compared with the corresponding checksums in the main memory of the zero terminal.

[0074] If the linux.itb and u-boot.itb checksums in the SD repair card are consistent with the corresponding checksums in the main memory of the zero terminal, then the size and loading address of the auxiliary program loader are parsed from the header information of the auxiliary program loader, and the auxiliary program loader and the general boot loader are loaded and run.

[0075] After the general bootloader starts, it parses the image_header_t header information of Linux and jumps to the Linux load address. Linux completes the initialization of each functional module of the system, including the mounting of the root file system, and finally completes the system startup.

[0076] In this embodiment, after the zero terminal is powered on, the Bootrom reads the SPL from the SD card. The SPL then reads U-boot based on its information. During the SPL loading phase, the card type is detected. If the boot flag is 2, the u-boot.itb and linux.itb files on the SD card are compared with the original itb files in the zero terminal. If they match, the subsequent boot loading process continues. Then, U-boot and Linux are loaded. Here, Linux includes the Kernel and Rootfs (root file system). The LinuxKernel initializes system components and devices. After everything is ready, the first user-space program, Init, is called to initialize user space. Its function is similar to an upgrade card, except that this type of card is used when the zero terminal firmware is corrupted. When firmware corruption occurs, the SD repair card can be used to repair the zero terminal, meaning the firmware does not need to be updated or upgraded.

[0077] In one embodiment, if the SD card to be created is an SD upgrade card, the step of writing corresponding content and a boot flag in a pre-defined sector format according to the capacity of the SD card and the type of SD card to be created includes:

[0078] Read the auxiliary program loader from the SD upgrade card;

[0079] Parse the size and load address of the helper loader from the header information of the helper loader, and load and run the helper loader and read the general boot loader for loading;

[0080] After the general bootloader starts, it parses the image_header_t header information of Linux and jumps to the Linux load address. Linux completes the initialization of each functional module of the system, including the mounting of the root file system, and finally completes the system startup.

[0081] In this embodiment, the upgrade process of the SD upgrade card is similar to that of the SD repair card, and it also follows the loading steps of Bootroom, SPL, U-boot, and Linux. The difference is that if the boot flag read is 0, no checksum (CRC check) comparison is performed, and the subsequent loading process is directly carried out.

[0082] The specific partitions of the SD card in this embodiment are shown in Table 2.

[0083] Table 2

[0084] Offset Data segment Sector 0-63 gpt.bin(GPT Partition table) Sector 64-79 Startup flags, etc. (0 / 1 / 2, etc.) Sector 80-95 u-boot.itb checksum Sector 96-127 linux.itb checksum Sector 128-1023 dfd-uboot-spl.bin(SPL with header) Sector 1024-2047 u-boot.itb (U-boot) Remaining space linux.itb (Linux kernel and rootfs)

[0085] Figure 3 This is a schematic diagram of the firmware loading process in a firmware upgrade method provided in an embodiment of this disclosure.

[0086] Figure 4 This is a schematic flowchart illustrating a firmware upgrade method provided in an embodiment of this disclosure. Figure 4 As shown, this method is applied to zero terminals and includes:

[0087] Step 401: Determine whether an SD card is installed in the zero terminal;

[0088] In this step, the zero terminal is powered on and booted, and the bootrom scans the storage devices to determine whether an SD card is installed in the zero terminal.

[0089] Step 402: When an SD card is installed in the zero terminal, check whether the value at the preset sector of the SD card is the preset value;

[0090] In this step, after identifying the SD card, check if the value at sector 66 of the SD card is 0xFCDCFCDC. If it is, continue checking the boot flag at sector 66 plus 600 bytes. If not, it means it is a regular card, only used for data storage, and the subsequent process will not proceed.

[0091] Step 403: If the value at the preset sector of the SD card is a preset value, then determine whether the preset sector has a boot flag for storing the SD card.

[0092] In the steps, if the value at sector 66 of the SD card is 0xFCDCFCDC, then continue to check if the boot flag of the SD card is stored at sector 66 plus 600 bytes.

[0093] Step 404: If a boot flag for storing an SD card is set in the preset sector and the flag is a first preset value, the SD card is determined to be an upgrade card or a test card, and the firmware is read from the SD card to start the zero terminal.

[0094] In this step, if the boot flag of the SD card is stored in sector 66 plus 600 bytes and the boot flag is 1, it is determined that the SD card is an upgrade card or a test card, and the firmware is read from the SD card to boot the zero terminal; if the boot flag of the SD card is not stored in sector 66 plus 600 bytes, it means that it is a regular card and is only used for storing data, and there is no further process.

[0095] In one embodiment, the method further includes:

[0096] If a boot flag for the storage card is set in the preset sector, and the flag is a second preset value, the SD card is determined to be a boot card, and firmware is read from the SD card to boot the zero terminal.

[0097] In this embodiment, if the boot flag of the SD card is stored in sector 66 plus 600 bytes and the boot flag is 1, the SD card is determined to be a boot card, and then the firmware is read from the SD card to boot the zero terminal.

[0098] In one embodiment, the method further includes:

[0099] If a startup flag for the storage card is set in the preset sector, and the flag is a third preset value, then the SD card is determined to be a repair card;

[0100] Read the linux.itb and u-boot.itb checksums from the SD card, and compare the linux.itb and u-boot.itb checksums from the SD card with the corresponding checksums in the main memory of the zero terminal.

[0101] If the checksums of linux.itb and u-boot.itb in the SD card are consistent with the corresponding checksums in the main memory of the zero terminal, then the firmware is read from the SD card to start the zero terminal.

[0102] In this embodiment, if the boot flag of the SD card is stored at sector 66 plus 600 bytes, and the boot flag is 2, then it indicates that it is a repair card. Next, the two checksums of linux.itb and u-boot.itb in the SD card are read and compared with the two checksums in main memory. If they match, the subsequent process continues; otherwise, the normal boot process is followed.

[0103] In one embodiment, if the checksums of linux.itb and u-boot.itb in the SD card are both consistent with the corresponding checksums in the main memory of the zero terminal, then reading the firmware from the SD card to boot the zero terminal includes:

[0104] Parse the size and load address of the helper loader from the header information of the helper loader, and load and run the helper loader and read the general boot loader for loading;

[0105] After the generic bootloader starts, it parses the image_header_t header information of Linux and jumps to the Linux load address. Linux completes the initialization of each functional module of the system, including mounting the root file system, and finally completes the system boot.

[0106] In this embodiment, after the checksum comparison is successful, the bootrom will parse the size and load address of the spl from the sb_header header information of the spl, and then load and run the spl. The spl will initialize the ddr and read u-boot for loading.

[0107] When loading u-boot, the system first reads the u-boot header (image_header_t) to obtain information such as u-boot's size, starting address, and load address. Then, it jumps to the load address to begin execution. u-boot primarily performs hardware initialization tasks, including setting the processor mode, initializing memory, and loading Linux.

[0108] After u-boot starts, it parses the image_header_t header information of Linux and eventually jumps to the Linux load address. Linux will complete the initialization of each functional module of the system, including mounting the root file system, and finally complete the system startup.

[0109] Understandably, if the startup flag is 0 or 1, the startup process does not require a checksum comparison process.

[0110] It should be noted that when creating firmware on a PC, the header information for each ITB is added by tools. For example, mksheader adds the sb_header header to spl, mkimage adds the image_header_t header to u-boot, and mkimage adds the image_header_t header to linux. Each ITB has a header added by the tool, and then the upper-level tool parses it and loads it according to the information contained in the header.

[0111] In this embodiment, SD card is short for Secure Digital Card; CRC is short for Cyclic Redundancy Check; USB is short for Universal Serial Bus; GMAC is short for Gigabit Media Access Controller; SPL is short for Secondary Program Loader; U-Boot is short for Universal Boot Loader; DDR is short for Double Data Rate SDRAM; Bootrom is short for Boot Read-Only Memory, which is a read-only memory (ROM) embedded in the chip, used to execute the initial boot code when the system is powered on or reset, initialize necessary hardware resources, and load the boot loader to prepare for the operating system to start.

[0112] The firmware upgrade method provided in this disclosure can create different types of SD cards through host computer software, thereby saving the USB interface or GMAC interface used in conventional upgrade schemes.

[0113] Figure 5 This is a schematic diagram of the SD card boot process in a firmware upgrade method provided in a disclosed embodiment.

[0114] Figure 6 This is a structural diagram of a host computer provided in an embodiment of this disclosure. Figure 6 As shown, the host computer includes: an acquisition module 601, a selection module 602, a selection module 603, and a writing module 604; wherein, the acquisition module 601 is used to acquire the capacity of the SD card; the selection module 602 is used to select the type of SD card to be created; wherein, the SD card type includes a regular SD card, an SD boot card, an SD repair card, and an SD upgrade card; the selection module 603 is used to select firmware pre-compiled in the compilation environment; wherein, the firmware consists of multiple files; the writing module 604 is used to write corresponding content and a boot flag in a pre-set sector format according to the capacity of the SD card and the type of SD card to be created.

[0115] Figure 7 This is a structural diagram of a zero-terminal embodiment provided in this disclosure. Figure 7As shown, the zero terminal includes: a judgment module 701, a viewing module 702, a determination module 703, and a reading module; wherein, the judgment module 701 is used to determine whether an SD card is installed in the zero terminal; when an SD card is installed in the zero terminal, the viewing module 702 checks whether the value at a preset sector of the SD card is a preset value; the determination module 703 is used to determine whether a boot flag for storing the SD card is set at the preset sector when the value at the preset sector of the SD card is a preset value; the reading module 704 is used to determine whether the SD card is an upgrade card or a test card when a boot flag for storing the SD card is set at the preset sector and the flag is a first preset value, and then reads firmware from the SD card to start the zero terminal.

[0116] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0117] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0118] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0119] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0120] Although preferred embodiments of this disclosure have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this disclosure.

[0121] Obviously, those skilled in the art can make various modifications and variations to this disclosure without departing from its spirit and scope. Therefore, if such modifications and variations fall within the scope of the claims of this disclosure and their equivalents, this disclosure is also intended to include such modifications and variations.

Claims

1. A firmware upgrade method, characterized in that, Applied to a host computer, the method includes: Get the capacity of the SD card; Select the type of SD card to be created; wherein, the SD card type includes regular SD card, SD boot card, SD repair card and SD upgrade card; Select the firmware that has been pre-compiled in the compilation environment; wherein the firmware consists of multiple files; Based on the capacity of the SD card and the type of SD card to be made, write the corresponding content and boot flag into the pre-set sector format.

2. The method according to claim 1, characterized in that, If the SD card to be created is an SD boot card, the step of writing the corresponding content and boot flag in the pre-set sector format according to the capacity of the SD card and the type of SD card to be created includes: The selected firmware, pre-compiled in the compilation environment, is written to the SD boot card and used as main memory, so that when the zero terminal boots from the SD boot card, the firmware and other files are stored on the SD boot card.

3. The method according to claim 1, characterized in that, If the SD card to be created is an SD repair card, the step of writing the corresponding content and boot flag in the pre-set sector format according to the capacity of the SD card and the type of SD card to be created includes: The auxiliary program loader and the linux.itb and u-boot.itb checksums in the SD repair card are read from the SD repair card, and the linux.itb and u-boot.itb checksums in the SD repair card are compared with the corresponding checksums in the main memory of the zero terminal. If the linux.itb and u-boot.itb checksums in the SD repair card are consistent with the corresponding checksums in the main memory of the zero terminal, then the size and loading address of the auxiliary program loader are parsed from the header information of the auxiliary program loader, and the auxiliary program loader and the general boot loader are loaded and run. After the general bootloader starts, it parses the image_header_t header information of Linux and jumps to the Linux load address. Linux completes the initialization of each functional module of the system, including the mounting of the root file system, and finally completes the system startup.

4. The method according to claim 1, characterized in that, If the required SD card type is an SD upgrade card, the step of writing corresponding content and a boot flag into the pre-defined sector format according to the SD card's capacity and the required SD card type includes: Read the auxiliary program loader from the SD upgrade card; Parse the size and load address of the helper loader from the header information of the helper loader, and load and run the helper loader and read the general boot loader for loading; After the general bootloader starts, it parses the image_header_t header information of Linux and jumps to the Linux load address. Linux completes the initialization of each functional module of the system, including the mounting of the root file system, and finally completes the system startup.

5. A firmware upgrade method, characterized in that, Applied to zero terminals, the method includes: Determine whether an SD card is installed in the zero terminal; When an SD card is installed in the zero terminal, check whether the value at the preset sector of the SD card is the preset value; If the value at the preset sector of the SD card is a preset value, then determine whether the preset sector has a boot flag for storing the SD card; If a boot flag for storing an SD card is set in the preset sector, and the flag is a first preset value, then the SD card is determined to be an upgrade card or a test card, and firmware is read from the SD card to boot the zero terminal.

6. The method according to claim 5, characterized in that, The method further includes: If a boot flag for the storage card is set in the preset sector, and the flag is a second preset value, the SD card is determined to be a boot card, and firmware is read from the SD card to boot the zero terminal.

7. The method according to claim 5, characterized in that, The method further includes: If a startup flag for the storage card is set in the preset sector, and the flag is a third preset value, then the SD card is determined to be a repair card; Read the linux.itb and u-boot.itb checksums from the SD card, and compare the linux.itb and u-boot.itb checksums from the SD card with the corresponding checksums in the main memory of the zero terminal. If the checksums of linux.itb and u-boot.itb in the SD card are consistent with the corresponding checksums in the main memory of the zero terminal, then the firmware is read from the SD card to start the zero terminal.

8. The method according to claim 7, characterized in that, If the checksums of linux.itb and u-boot.itb in the SD card are both consistent with the corresponding checksums in the main memory of the zero terminal, then reading the firmware from the SD card to boot the zero terminal includes: Parse the size and load address of the helper loader from the header information of the helper loader, and load and run the helper loader and read the general boot loader for loading; After the generic bootloader starts, it parses the image_header_t header information of Linux and jumps to the Linux load address. Linux completes the initialization of each functional module of the system, including mounting the root file system, and finally completes the system boot.

9. A host computer, characterized in that, The host computer includes: an acquisition module, a selection module, a selection module, and a writing module; wherein... The acquisition module is used to acquire the capacity of the SD card; The selection module is used to select the type of SD card to be created; wherein, the SD card type includes regular SD card, SD boot card, SD repair card and SD upgrade card; The selected module is used to select firmware that has been pre-compiled in the compilation environment; wherein the firmware consists of multiple files; The writing module is used to write corresponding content and a boot flag in a pre-set sector format according to the capacity of the SD card and the type of SD card to be made.

10. A zero-terminal, characterized in that, The zero-terminal includes: a judgment module, a viewing module, a determination module, and a reading module; wherein... The judgment module is used to determine whether an SD card is installed in the zero terminal; When an SD card is installed in the zero terminal, the viewing module checks whether the value at a preset sector of the SD card is a preset value. The determining module is used to determine whether a boot flag for storing the SD card is set in the preset sector when the value at the preset sector of the SD card is a preset value. The reading module is configured to set a boot flag for storing the SD card in the preset sector, and when the flag is a first preset value, determine that the SD card is an upgrade card or a test card, and then read the firmware from the SD card to start the zero terminal.

Images