CN113918199A - Method for updating underlying firmware program, storage medium and electronic device - Google Patents
Method for updating underlying firmware program, storage medium and electronic device Download PDFInfo
- Publication number
- CN113918199A CN113918199A CN202010664704.4A CN202010664704A CN113918199A CN 113918199 A CN113918199 A CN 113918199A CN 202010664704 A CN202010664704 A CN 202010664704A CN 113918199 A CN113918199 A CN 113918199A
- Authority
- CN
- China
- Prior art keywords
- interface
- firmware program
- program
- updated
- updating
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
Abstract
The application relates to the technical field of computer embedded software, in particular to an updating method of a bottom layer firmware program, a storage medium and electronic equipment, and solves the problems that the updating method of the bottom layer firmware program in the related technology is complex in operation, high in requirement on professional skills of operators, low in updating efficiency and unreliable in updating mode. The method comprises the following steps: receiving an update request, and acquiring an object code of a bottom firmware program to be updated; caching a bottom firmware program to be updated; judging a system boot starting mode, and judging whether interface switching is needed or not based on the system boot starting mode; if necessary, switching the system interface into a first interface; calling a first interface function to update a bottom layer firmware program to be updated, and verifying the updated bottom layer firmware program; switching the first interface back to the system interface; if not, calling an interface function corresponding to the system interface to update the stored bottom layer firmware program, and verifying the updated bottom layer firmware program.
Description
Technical Field
The present application relates to the field of computer embedded software technologies, and in particular, to a method for updating a bottom firmware program, a storage medium, and an electronic device.
Background
In the field of embedded industrial control, software updates to underlying firmware programs (such as operating systems and even boot programs) are often required for field maintenance. Whereas a conventional software update involves burning a program into memory through a JTAG (Joint Test Action Group) interface using an emulator. However, this method is cumbersome to operate, has a high requirement on the professional skills of the operator, and is very inconvenient to connect the JTAG interface by plugging the single board during field operation, which affects the program updating efficiency.
Also, the chip is disassembled and programmed by a burner, but the way of disassembling the hardware is also very unreliable. Online updating of the underlying firmware programs (boot program, operating system) by software has become a technology of increasing interest to developers and maintenance personnel.
And the online update of the bottom firmware program is realized through software, when the interface of a system boot starting mode is different from the interface of normally accessing the peripheral after the system is started, and the two interfaces can not be accessed simultaneously, the traditional software updating mode can cause the system to crash.
Therefore, the updating method of the bottom firmware program in the related technology is complex to operate, has high requirements on professional skills of operators, is low in updating efficiency, is unreliable in updating mode, and causes system crash due to interface access conflict.
Disclosure of Invention
In view of the above problems, the present application provides an update method, a storage medium, and an electronic device for a bottom firmware program, which solve the technical problems in the related art that the update method for the bottom firmware program is complicated to operate, has a high requirement on professional skills of operators, is low in update efficiency, is unreliable in update mode, and causes system crash due to interface access conflict.
In a first aspect, the present application provides a method for updating an underlying firmware program, the method including:
receiving an update request, and acquiring an object code of a bottom firmware program to be updated;
caching the bottom firmware program to be updated;
judging a system boot starting mode, and judging whether interface switching is needed or not based on the system boot starting mode;
if the interface switching is needed, switching the system interface to a first interface;
calling the first interface function to update the bottom layer firmware program to be updated, and verifying the updated bottom layer firmware program;
switching the first interface back to the system interface;
if the interface switching is not needed, calling an interface function corresponding to the system interface to update the stored bottom layer firmware program, and verifying the updated bottom layer firmware program.
According to an embodiment of the present application, optionally, the method for updating the underlying firmware program further includes:
acquiring a mutual exclusion semaphore before interface switching;
and updating the bottom firmware program and releasing the mutual exclusion semaphore after verification is completed.
According to an embodiment of the present application, optionally, in the method for updating the bottom firmware program, the system interface is a local bus control interface, the first interface is a serial peripheral interface, and the bottom firmware program includes at least one of a boot program and an operating system.
According to an embodiment of the present application, optionally, in the method for updating the underlying firmware program, the determining whether to perform interface switching based on the system boot starting manner includes:
when the system is booted and started from the serial peripheral interface, the bottom layer firmware program is stored in a memory connected with the serial peripheral interface and needs to be switched;
when the system is booted and started from the local bus control interface, the bottom layer firmware program is stored in a memory connected with the local bus control interface, and interface switching is not required.
According to an embodiment of the present application, optionally, in the method for updating the underlying firmware program, the switching the system interface to the first interface includes:
converting a preset IO pin from a high level to a low level;
and when the falling edge of the preset IO pin is detected, controlling the level value of an interface switching pin to be a low level so as to switch the system interface to be the first interface.
According to an embodiment of the present application, optionally, in the method for updating the underlying firmware program, the switching the first interface back to the system interface includes:
converting a preset IO pin from a low level to a high level;
and when the rising edge of the preset IO pin is detected, controlling the level value of an interface switching pin to be a high level so as to switch the first interface to be the system interface.
According to an embodiment of the present application, optionally, in the method for updating a bottom layer firmware program, the updating the bottom layer firmware program to be updated, and verifying the updated bottom layer firmware program includes:
step 1: determining a program programming offset address and the maximum capacity according to the type of the bottom layer firmware program to be updated, and backing up the original bottom layer firmware program of the system;
step 2: calculating the total number of blocks needing to be erased and the total number of pages needing to be written in for updating the bottom firmware program, judging whether the total capacity of the bottom firmware program is smaller than or equal to a preset maximum capacity, if so, executing the step 3, and if not, exiting the updating;
and step 3: erasing a block to be erased, and enabling a first counter to count once, wherein the initial value of the first counter is set to be zero; judging whether the numerical value recorded by the first counter is smaller than the total number of the blocks needing to be erased or not, if so, executing the step 3 again, and if not, executing the step 4;
and 4, step 4: sequentially writing a page of data of the bottom firmware program into a flash memory from the offset address, and enabling a second counter to count once, wherein the initial value of the second counter is set to be zero;
checking the written bottom firmware program, if the checking is successful, judging whether the number recorded by the second counter is less than the total number of the pages of the bottom firmware program to be written, if so, continuing to execute the step 4 until the number recorded by the second counter is more than or equal to the total number of the pages of the bottom firmware program;
and if the verification fails, restoring the bottom firmware program to be updated through the backed-up bottom firmware program.
According to an embodiment of the present application, optionally, in the method for updating the underlying firmware program, the determining a program programming offset address and a maximum capacity according to a type of the underlying firmware program to be updated includes:
judging the type of the bottom firmware program to be updated according to the preset type parameter;
when the preset type parameter is 0, the bottom-layer firmware program is a boot program, the offset address of the boot program is determined to be a first offset address, and the maximum capacity is a first preset capacity;
when the preset type parameter is 1, the bottom firmware program is an operating system, the offset address of the operating system is determined to be a second offset address, and the maximum capacity is a second preset capacity.
According to an embodiment of the application, optionally, in the method for updating the underlying firmware program, the total number of the blocks to be erased includes a minimum number of blocks required to constitute a capacity not less than a total capacity of the underlying firmware program, and the total number of the pages to be written includes a minimum number of pages required to constitute a capacity not less than the total capacity of the underlying firmware program.
According to an embodiment of the present application, optionally, in the method for updating the bottom layer firmware program, the verifying the updated bottom layer firmware program includes:
and judging whether the bottom firmware program in the flash memory is completely consistent with the bottom firmware program cached by the system, if so, successfully verifying, and if not, failing to verify.
In a second aspect, the present application provides a storage medium storing a computer program executable by one or more processors for implementing the method for updating an underlying firmware program as described above.
In a third aspect, the present application provides an electronic device, including a memory and a processor, where the memory stores a computer program, and the memory and the processor are communicatively connected to each other, and the computer program, when executed by the processor, performs the method for updating the underlying firmware program.
Compared with the prior art, the method for updating the bottom firmware program, the storage medium and the electronic device have the advantages that:
1. the method is compatible with two different boot starting modes of LBC and SPI, a boot program or an operating system is selected to be updated according to user requirements, and the boot program or the operating system can be restored to an original program when the update fails;
2. mutually exclusive semaphores are introduced to ensure that the interface mode is unchanged in the program updating process and avoid system crash caused by illegal access of the interface;
3. updating the bottom firmware program on line without disassembling hardware;
4. the method is simple to operate, has low requirements on professional skills of operators, and has high updating efficiency.
Drawings
The present application will be described in more detail hereinafter on the basis of embodiments and with reference to the accompanying drawings:
fig. 1 is a flowchart illustrating a method for updating a bottom firmware program according to an embodiment of the present disclosure;
fig. 2 is a schematic interface switching diagram of a method for updating a bottom-layer firmware program according to an embodiment of the present disclosure;
fig. 3 is a schematic update flow chart of an update method of an underlying firmware program according to an embodiment of the present application.
In the drawings, like parts are designated with like reference numerals, and the drawings are not drawn to scale.
Detailed Description
The following detailed description will be provided with reference to the accompanying drawings and embodiments, so that how to apply the technical means to solve the technical problems and achieve the corresponding technical effects can be fully understood and implemented. The embodiments and various features in the embodiments of the present application can be combined with each other without conflict, and the formed technical solutions are all within the scope of protection of the present application.
The invention provides a bottom firmware program updating method, a storage medium and electronic equipment, and solves the technical problems that the bottom firmware program updating method in the related technology is complex in operation, high in requirement on professional skills of operators, low in updating efficiency and unreliable in updating mode.
Example one
Fig. 1 is a flowchart illustrating a method for updating a bottom-level firmware program according to an embodiment of the present application, where as shown in fig. 1, the method includes:
step S110: receiving an update request, and acquiring an object code of a bottom firmware program to be updated;
step S120: caching the bottom firmware program to be updated;
step S130: judging a system boot starting mode, and judging whether interface switching is needed or not based on the system boot starting mode;
step S140: if the interface switching is needed, switching the system interface to a first interface;
step S150: calling the first interface function to update the bottom layer firmware program to be updated, and verifying the updated bottom layer firmware program;
step S160: switching the first interface back to the system interface;
step S170: if the interface switching is not needed, calling an interface function corresponding to the system interface to update the stored bottom layer firmware program, and verifying the updated bottom layer firmware program.
Further, the method also comprises the following steps: acquiring a mutual exclusion semaphore before interface switching;
and updating the bottom firmware program and releasing the mutual exclusion semaphore after verification is completed.
Further, the system interface is a local bus control interface, the first interface is a serial peripheral interface, and the bottom firmware program includes at least one of a boot program and an operating system.
The method and the device have the advantages that software updating is carried out on the bottom layer firmware program (such as an operating system and even a boot program) based on the Feiteng chip, two different boot starting modes including the local bus control interface LBC and the serial peripheral interface SPI can be supported, and the bottom layer firmware program can be flexibly, conveniently and reliably updated on line in a compatible mode with two boot starting modes and with the selectable update types.
The boot program is a program which needs to be started at the moment when the system is just powered on, completes the deployment of the minimum system and boots the loading of the operating system. Common boot programs are UBOOT, and bootrom in vxWorks.
The LBC interface and the SPI interface of the Feiteng chip multiplex 1GB address space together, the two interfaces cannot be used simultaneously, and configuration switching needs to be carried out through hardware pins. For example, a board booted from the SPI is connected to the processor through the LBC interface, and after the system is booted successfully, the interface mode needs to be switched from the SPI to the LBC to work normally. The boot-up mode of the system determines the storage location of the underlying firmware program in which interface is connected.
The booting mode of the system may be determined according to a preset pin, may also be determined according to a preset storage address of a program, and may also be determined by other existing technologies.
Based on the characteristics of the FT chip, if online update of the bottom firmware program is to be performed, it is first required to determine whether to perform switching between the LBC interface and the SPI interface, and it is required that interface modes are not allowed to be switched again in the program update process, otherwise, system crash may be caused by illegal access of the interfaces.
The Feiteng FT-2000A/2 is a localization processor provided by a Feiteng platform and oriented to equipment and an industrial control embedded system, integrates an independently developed kernel, and has the characteristics of low power consumption, strong real-time performance, high reliability, high safety and the like. In this example, FT-2000A/2 is used as an example for explanation.
Specifically, the user uploads the target code of the bottom firmware program to be updated to the peripheral FLASH memory through the remote client, and then sends an update request. The FLASH memory is connected with the FT-2000A/2 through an LBC interface, and a file system is hung on the FLASH memory, so that file management is facilitated for a user.
The LBC adopts an address line/data line multiplexing mode; the SPI is used for synchronous serial data transmission between the processor and the peripheral low-speed device; FLASH memory is a non-volatile memory, can store data for a long time even in the absence of current, and has storage characteristics equivalent to a hard disk.
Specifically, after receiving the update request, the system copies the bottom firmware program to be updated to the system cache through the I/O interface, determines whether the system boot start mode is from SPI boot or LBC boot, and determines and switches between the LBC interface and the SPI interface according to the boot mode.
Further, the determining whether to perform interface switching based on the system boot starting mode includes:
when the system is booted and started from the serial peripheral interface, the bottom layer firmware program is stored in a memory connected with the serial peripheral interface and needs to be switched;
when the system is booted and started from the local bus control interface, the bottom layer firmware program is stored in a memory connected with the local bus control interface, and interface switching is not required.
For example, the LBC interface may be connected with a plurality of peripheral devices through chip selection, and after the system is successfully started, the chip operates in the LBC mode to communicate with the peripheral devices.
Specifically, when updating the underlying firmware program, there are two cases in the boot mode: in the first case, the system is booted by SPI, i.e., the bottom-layer program is stored in FLASH connected to the SPI, and the interface mode needs to be switched from the original LBC interface to the SPI interface; and in the second case, the system is started by means of LBC boot, namely, the bottom layer program is stored in a FLASH connected with the LBC interface, and the interface does not need to be switched.
Whether the switching is needed or not, the interface mode is required to be kept unchanged during the program updating period, otherwise, illegal access is caused, so that a mutual exclusion semaphore is introduced when the interface is switched, the mutual exclusion semaphore is a blocking mode, and the switching between the LBC interface and the SPI interface is carried out after the mutual exclusion semaphore is successfully acquired.
The mutual exclusion semaphore is introduced during switching, so that other programs can be prevented from switching the LBC interface and the SPI interface again, and the interface mode is ensured to be kept unchanged during program updating.
Further, the switching the system interface to the first interface includes:
converting a preset IO pin from a high level to a low level;
and when the falling edge of the preset IO pin is detected, controlling the level value of an interface switching pin to be a low level so as to switch the system interface to be the first interface.
Specifically, a preset IO pin is converted from a high level to a low level; when the first control chip detects the falling edge of the preset IO pin, the level value of the second chip interface switching pin is controlled to be low level, so that the system interface is switched to be an SPI interface.
Further, the switching the first interface back to the system interface includes:
converting a preset IO pin from a low level to a high level;
and when the rising edge of the preset IO pin is detected, controlling the level value of an interface switching pin to be a high level so as to switch the first interface to be the system interface.
Specifically, a preset IO pin is converted from a low level to a high level; when the first control chip detects the rising edge of the preset IO pin, the level value of the second chip interface switching pin is controlled to be high level, so that the SPI interface is switched to be the system interface.
The preset IO pin can be a GPIO pin, the first control chip can be an FPGA (field programmable gate array), the second chip can be a FT-2000A/2, and the second chip interface switching pin is a spi _ lpc _ select pin; the FPGA is a field programmable gate array, the GPIO is a general purpose input/output port, the pin function of the FPGA can be controlled by a designer through a register and can be used for input, output or other special functions.
Fig. 2 is a schematic interface switching diagram of a method for updating a bottom-layer firmware program according to an embodiment of the present application, where as shown in fig. 2, the interface switching includes the following steps:
and caching the bottom firmware program corresponding to the target code according to the updating request, and acquiring the mutual exclusion semaphore of the system.
And judging whether interface switching is needed according to the boot starting mode of the system.
When interface switching is needed, a specific GPIO pin is controlled to be pulled down to a low level from a high level, the FPGA controls the level value of a SPI _ lpc _ select pin of the FT-2000A/2 to be the low level after capturing the falling edge of the specific GPIO pin, and the FT-2000A/2 controls the use of an SPI interface mode, so that the switching of two interface modes of an LBC interface and an SPI interface is realized; after the switching is completed, calling an SPI (serial peripheral interface) to update the stored bottom firmware program, and verifying the bottom firmware program;
then, a specific GPIO pin is controlled to be converted from a low level to a high level, the FPGA controls the level value of a spi _ lpc _ select pin of the FT-2000A/2 to be the high level after capturing the rising edge of the specific GPIO pin, and the FT-2000A/2 controls the use of an LBC interface mode, so that the switching to the original interface is realized; the mutex semaphore is released.
Specifically, the LBC and the SPI interface of the FT-2000A/2 share 0-1 GB of address space, the LBC interface and the SPI interface are switched through a SPI _ lpc _ select pin of chip hardware, when the SPI _ lpc _ select is at a high level, the 1GB of address space is used by the LBC, and when the SPI _ lpc _ select is at a low level, the 1GB of address space is used by the SPI.
When interface switching is not needed, an LBC interface is called to update the stored bottom firmware program, and the bottom firmware program is verified; the mutex semaphore is released.
Further, the updating the bottom firmware program to be updated and verifying the updated bottom firmware program includes:
step S210: determining a program programming offset address and the maximum capacity according to the type of the bottom layer firmware program to be updated, and backing up the original bottom layer firmware program of the system;
step S220: calculating the total number of blocks needing to be erased and the total number of pages needing to be written in for updating the bottom layer firmware program, judging whether the total capacity of the bottom layer firmware program is smaller than or equal to a preset maximum capacity, if so, executing the step S230, and if not, exiting the updating;
step S230: erasing a block to be erased, and enabling a first counter to count once, wherein the initial value of the first counter is set to be zero; judging whether the value recorded by the first counter is smaller than the total number of the blocks needing to be erased, if so, executing the step S230 again, and if not, executing the step S240;
step S240: sequentially writing data in a page of the bottom firmware program from the offset address into a flash memory, and enabling a second counter to count once, wherein the initial value of the second counter is set to be zero;
checking the written bottom firmware program, if the checking is successful, judging whether the number recorded by the second counter is less than the total number of the pages of the bottom firmware program to be written, if so, continuing to execute the step S240 until the number recorded by the second counter is more than or equal to the total number of the pages of the bottom firmware program;
and if the verification fails, restoring the bottom firmware program to be updated through the backed-up bottom firmware program.
Further, the determining a program programming offset address and a maximum capacity according to the type of the underlying firmware program to be updated includes:
judging the type of the bottom firmware program to be updated according to the preset type parameter;
when the preset type parameter is 0, the bottom-layer firmware program is a boot program, the offset address of the boot program is determined to be a first offset address, and the maximum capacity is a first preset capacity;
when the preset type parameter is 1, the bottom firmware program is an operating system, the offset address of the operating system is determined to be a second offset address, and the maximum capacity is a second preset capacity.
Further, the total number of blocks to be erased includes a minimum number of blocks required to constitute a capacity not less than the total capacity of the underlying firmware program, and the total number of pages to be written includes a minimum number of pages required to constitute a capacity not less than the total capacity of the underlying firmware program.
Further, the verifying the updated bottom firmware program includes:
and judging whether the bottom firmware program in the flash memory is completely consistent with the bottom firmware program cached by the system, if so, successfully verifying, and if not, failing to verify.
Fig. 3 is a schematic update flow chart of a method for updating a bottom layer firmware program according to an embodiment of the present application, where as shown in fig. 3, the bottom layer firmware program is referred to herein as a bottom layer program for short, and the steps of the update and read-back check work of the bottom layer program include:
step S310: and determining whether the TYPE of the bottom layer program needing to be updated is a bootstrap program or an operating system TYPE which is 0 according to the user parameter TYPE value, wherein the TYPE which is 1 represents updating the operating system, the rest parameter values are invalid and quit updating, and determining the programmed offset address and the maximum capacity of the bottom layer program.
The offset address offset of the boot program is 0, and the maximum size maxSize is 3MB, that is, 0x300000 bytes (prefix 0x indicates 16 systems). The offset address offset of the operating system is 0x300000 and the maximum size maxSize is 5MB, i.e., 0x500000 bytes.
Step S320: and backing up the original FLASH bottom program. And reading the original data in the FLASH into a system cache for backup from the offset address offset, wherein the read size is maxSize.
Step S330: determining the number of blocks needing to be erased and the number of read/write pages according to the actual size of the bottom-layer program, and if the actual size of the bottom-layer program exceeds the maximum capacity maxSize, exiting updating; if the actual size of the underlying program does not exceed the maximum capacity maxSiz, step S340 is executed.
The erasing of the FLASH takes a block as a basic unit, and the reading/writing takes a page as a basic unit, so that the number of blocks to be erased comprises the minimum number of blocks with the capacity not less than the total capacity of the bottom firmware, and the number of pages to be read/written comprises the minimum number of pages with the capacity not less than the total capacity of the bottom firmware.
For example, FLASH has a block size of 0x8000 bytes, a page size of 0x100 bytes, and a program size of 3000000 bytes, it is necessary to determine an offset address of the bottom program from step S310, and to start erasing 92 blocks (BlkNum ═ 92), and reading/writing 11719 pages (PageNum ═ 11719).
Step S340: sequentially wiping a block to be wiped from the offset address, and counting ErsCnt once; the ErsCnt and BlkNum are compared, and when ErsCnt < BlkNum, step S340 is executed again for the block erase operation.
Setting an initial value of the ErsCnt to 0, circularly calling an erasing function of the LBC or SPI interface, erasing a block each time, calling the interface once, counting the number of the ErsCnt once, and executing step S350 until the ErsCnt > is BlkNum.
Step S350: and the offset addresses are sequentially written into the flash memory by one page of data in the bottom layer firmware program, WtCnt counts once, WtCnt and PageNum are compared, and when WtCnt is smaller than PageNum, the bottom layer program is programmed.
Setting the initial value of WtCnt to 0, calling a write interface function of SPI or LBC, sequentially writing the data of the underlying program backed up in step S320 into FLASH from the offset address, writing one page each time, counting once by WtCnt each time of calling, and executing step S360.
Step S360: and performing read-back verification of the bottom layer program after one page is programmed. Calling a read interface function of the SPI or the LBC, reading back the data written into the FLASH, comparing the read data with system cache data, if the read data are identical with the system cache data, checking to pass, and executing the step S380; otherwise, the verification fails, and step S370 is executed.
Step S370: when the verification fails, since the FLASH erase and write operations have already been performed at this time, the original underlying program in the FLASH is damaged, and the original underlying program needs to be restored, and then step S390 is executed.
Step S380: and (5) successfully checking, returning to execute the step (S350), completing the programming when WtCnt > - [ PageNum ], and executing the step (S390).
Step S390: and feeding back the successful or failed updating information according to the execution condition, and ending.
The embodiment provides a flow diagram of a method for updating a bottom firmware program, including: receiving an update request, and acquiring an object code of a bottom firmware program to be updated; caching the bottom firmware program to be updated; judging a system boot starting mode, and judging whether interface switching is needed or not based on the system boot starting mode; if the interface switching is needed, switching the system interface to a first interface; calling the first interface function to update the bottom layer firmware program to be updated, and verifying the updated bottom layer firmware program; switching the first interface back to the system interface; if the interface switching is not needed, calling an interface function corresponding to the system interface to update the stored bottom layer firmware program, and verifying the updated bottom layer firmware program. The characteristic that the LBC interface and the SPI interface of the Feiteng chip cannot be used simultaneously is combined, two different boot starting modes of the SPI and the LBC are compatible, the boot program or the operating system can be selected to be updated according to the requirements of users, the boot program or the operating system can be restored to the original program when the updating fails, the mutual exclusion semaphore is introduced, the interface mode is unchanged in the program updating process, and the system crash caused by illegal access of the interface is avoided.
Example two
The present embodiment further provides a computer-readable storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory (e.g., SD or DX memory, etc.), a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, an optical disk, a server, an App application mall, etc., on which a computer program is stored, where the computer program, when executed by a processor, may implement the method steps of the first embodiment, and thus, the description of the embodiment is not repeated herein.
EXAMPLE III
The present embodiment provides an electronic device, which includes a memory and a processor, wherein the memory stores a computer program, the memory and the processor are communicatively connected to each other, and the computer program, when executed by the processor, performs the method for updating the underlying firmware program according to the first embodiment.
The Processor may be an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), a Digital Signal Processing Device (DSPD), a Programmable Logic Device (PLD), a Field Programmable Gate Array (FPGA), a controller, a microcontroller, a microprocessor, or other electronic components, and is configured to execute the method for updating the underlying firmware program in the first embodiment.
The Memory may be implemented by any type of volatile or non-volatile Memory device or combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic Memory, flash Memory, magnetic disk, or optical disk.
In summary, the present application provides a method for updating a bottom firmware program, a storage medium, and an electronic device, where the method includes: receiving an update request, and acquiring an object code of a bottom firmware program to be updated; caching the bottom firmware program to be updated; judging a system boot starting mode, and judging whether interface switching is needed or not based on the system boot starting mode; if the interface switching is needed, switching the system interface to a first interface; calling the first interface function to update the bottom layer firmware program to be updated, and verifying the updated bottom layer firmware program; switching the first interface back to the system interface; if the interface switching is not needed, calling an interface function corresponding to the system interface to update the stored bottom layer firmware program, and verifying the updated bottom layer firmware program.
The characteristic that an LBC interface and an SPI interface of a Feiteng chip cannot be used simultaneously is combined, two different boot starting modes of the SPI and the LBC are compatible, a boot program or an operating system can be selected to be updated according to the requirements of a user, the boot program or the operating system can be restored to an original program when the updating fails, mutually exclusive semaphores are introduced, the interface mode is unchanged in the program updating process, system collapse caused by illegal access of the interface is avoided, the bottom firmware program is updated on line, hardware does not need to be disassembled, the operation is simple, the requirement on the professional skill of an operator is not high, and the updating efficiency is high. The method solves the technical problems that the updating method of the bottom firmware program in the related technology is complex in operation, has high requirements on professional skills of operators, is low in updating efficiency and is unreliable in updating mode.
In the embodiments provided in the present application, it should be understood that the disclosed method can be implemented in other ways. The above-described method embodiments are merely illustrative.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
Although the embodiments disclosed in the present application are described above, the above descriptions are only for the convenience of understanding the present application, and are not intended to limit the present application. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the disclosure as defined by the appended claims.
Claims (12)
1. A method for updating an underlying firmware program, the method comprising:
receiving an update request, and acquiring an object code of a bottom firmware program to be updated;
caching the bottom firmware program to be updated;
judging a system boot starting mode, and judging whether interface switching is needed or not based on the system boot starting mode;
if the interface switching is needed, switching the system interface to a first interface;
calling the first interface function to update the bottom layer firmware program to be updated, and verifying the updated bottom layer firmware program;
switching the first interface back to the system interface;
if the interface switching is not needed, calling an interface function corresponding to the system interface to update the stored bottom layer firmware program, and verifying the updated bottom layer firmware program.
2. The method of claim 1, further comprising:
acquiring a mutual exclusion semaphore before interface switching;
and updating the bottom firmware program and releasing the mutual exclusion semaphore after verification is completed.
3. The method of claim 1, wherein the system interface is a local bus control interface, the first interface is a serial peripheral interface, and the underlying firmware program comprises at least one of a boot program and an operating system.
4. The method according to claim 3, wherein the determining whether the interface needs to be switched based on the system boot starting manner includes:
when the system is booted and started from the serial peripheral interface, the bottom layer firmware program is stored in a memory connected with the serial peripheral interface and needs to be switched;
when the system is booted and started from the local bus control interface, the bottom layer firmware program is stored in a memory connected with the local bus control interface, and interface switching is not required.
5. The method of claim 1, wherein switching the system interface to the first interface comprises:
converting a preset IO pin from a high level to a low level;
and when the falling edge of the preset IO pin is detected, controlling the level value of an interface switching pin to be a low level so as to switch the system interface to be the first interface.
6. The method of claim 1, wherein switching the first interface back to the system interface comprises:
converting a preset IO pin from a low level to a high level;
and when the rising edge of the preset IO pin is detected, controlling the level value of an interface switching pin to be a high level so as to switch the first interface to be the system interface.
7. The method of claim 1, wherein the updating the underlying firmware program to be updated and verifying the updated underlying firmware program comprises:
step 1: determining a program programming offset address and the maximum capacity according to the type of the bottom layer firmware program to be updated, and backing up the original bottom layer firmware program of the system;
step 2: calculating the total number of blocks needing to be erased and the total number of pages needing to be written in for updating the bottom layer firmware program, judging whether the total capacity of the bottom layer firmware program is smaller than or equal to a preset maximum capacity, if so, executing the step 3, and if not, exiting the updating;
and step 3: erasing a block to be erased, and enabling a first counter to count once, wherein the initial value of the first counter is set to be zero; judging whether the numerical value recorded by the first counter is smaller than the total number of the blocks needing to be erased or not, if so, executing the step 3 again, and if not, executing the step 4;
and 4, step 4: sequentially writing a page of data of the bottom firmware program into a flash memory from the offset address, and enabling a second counter to count once, wherein the initial value of the second counter is set to be zero;
checking the written bottom firmware program, if the checking is successful, judging whether the number recorded by the second counter is less than the total number of the pages of the bottom firmware program to be written, if so, continuing to execute the step 4 until the number recorded by the second counter is more than or equal to the total number of the pages of the bottom firmware program;
and if the verification fails, restoring the bottom firmware program to be updated through the backed-up bottom firmware program.
8. The method of claim 7, wherein determining a program programming offset address and a maximum capacity based on the type of underlying firmware program to be updated comprises:
judging the type of the bottom firmware program to be updated according to the preset type parameter;
when the preset type parameter is 0, the bottom-layer firmware program is a boot program, the offset address of the boot program is determined to be a first offset address, and the maximum capacity is a first preset capacity;
when the preset type parameter is 1, the bottom firmware program is an operating system, the offset address of the operating system is determined to be a second offset address, and the maximum capacity is a second preset capacity.
9. The method of claim 7, wherein the total number of blocks to be erased comprises a minimum number of blocks required to constitute a capacity not less than a total capacity of the underlying firmware program, and wherein the total number of pages to be written comprises a minimum number of pages required to constitute a capacity not less than the total capacity of the underlying firmware program.
10. The method of claim 7, wherein the verifying the updated underlying firmware program comprises:
and judging whether the bottom firmware program in the flash memory is completely consistent with the bottom firmware program cached by the system, if so, successfully verifying, and if not, failing to verify.
11. A storage medium storing a computer program executable by one or more processors for implementing a method of updating an underlying firmware program as claimed in any one of claims 1 to 10.
12. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, the memory and the processor are communicatively connected, and the computer program, when executed by the processor, performs the method of updating an underlying firmware program as claimed in any one of claims 1 to 10.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010664704.4A CN113918199A (en) | 2020-07-10 | 2020-07-10 | Method for updating underlying firmware program, storage medium and electronic device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010664704.4A CN113918199A (en) | 2020-07-10 | 2020-07-10 | Method for updating underlying firmware program, storage medium and electronic device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113918199A true CN113918199A (en) | 2022-01-11 |
Family
ID=79232283
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010664704.4A Pending CN113918199A (en) | 2020-07-10 | 2020-07-10 | Method for updating underlying firmware program, storage medium and electronic device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113918199A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114579499A (en) * | 2022-01-20 | 2022-06-03 | 飞腾信息技术有限公司 | Control method, device, equipment and storage medium of processor communication interface |
-
2020
- 2020-07-10 CN CN202010664704.4A patent/CN113918199A/en active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114579499A (en) * | 2022-01-20 | 2022-06-03 | 飞腾信息技术有限公司 | Control method, device, equipment and storage medium of processor communication interface |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| TWI515660B (en) | Firmware variable update method | |
| JP5909264B2 (en) | Secure recovery apparatus and method | |
| KR100750132B1 (en) | Method and system for booting, updating software automatically and recovering update error, and computer readable medium recording the method | |
| CN106990958B (en) | Expansion assembly, electronic equipment and starting method | |
| CN110032405B (en) | System boot code memory management method, memory device and electronic system using same | |
| US10216936B2 (en) | Method of preventing computer malfunction, computer program, and computer | |
| JP5575338B2 (en) | Information processing apparatus, information processing method, and computer program | |
| JP2007213571A (en) | Method for starting system using direct memory access in novel memory architecture | |
| JP2002526828A (en) | Protecting boot block code when allowing write access to the boot block | |
| US20080098381A1 (en) | Systems and methods for firmware update in a data processing device | |
| WO2016206514A1 (en) | Startup processing method and device | |
| JP2003316595A (en) | Installation method, file updating method, its program and computer system | |
| US10025670B2 (en) | Information processing apparatus, memory dump method, and storage medium | |
| JP6543122B2 (en) | INFORMATION PROCESSING APPARATUS, METHOD OF INITIALIZING NONVOLATILE STORAGE DEVICE BY THE INFORMATION PROCESSING APPARATUS, AND PROGRAM | |
| CN105786545B (en) | Breakpoint recovery method and system based on heterogeneous hybrid memory | |
| CN109582332B (en) | System upgrading method and device for Internet camera | |
| US20190213012A1 (en) | Method for managing system boot code memory, memory device and electronic system using the same | |
| CN113918199A (en) | Method for updating underlying firmware program, storage medium and electronic device | |
| US7428635B2 (en) | Method of writing non-volatile memory that avoids corrupting the vital initialization code | |
| US10705827B2 (en) | Method for updating system information of a computer device | |
| TWI650646B (en) | Cable data machine and its operation method | |
| TWI743480B (en) | Computer system and a booting method for the same | |
| CN115129384A (en) | Electronic equipment and running method of starting program of electronic equipment | |
| US20030237021A1 (en) | Automatic restoration of software applications in a mobile computing device | |
| US20230069169A1 (en) | Information processing apparatus and control method of the same |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |