CN100389389C - Method for implementing hot-update of bootstrap program in flush bonding system - Google Patents
Method for implementing hot-update of bootstrap program in flush bonding system Download PDFInfo
- Publication number
- CN100389389C CN100389389C CNB031374220A CN03137422A CN100389389C CN 100389389 C CN100389389 C CN 100389389C CN B031374220 A CNB031374220 A CN B031374220A CN 03137422 A CN03137422 A CN 03137422A CN 100389389 C CN100389389 C CN 100389389C
- Authority
- CN
- China
- Prior art keywords
- module
- bootrom
- master boot
- program
- basic
- 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.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims abstract description 31
- 230000006870 function Effects 0.000 claims description 17
- 238000003860 storage Methods 0.000 claims description 10
- 230000005055 memory storage Effects 0.000 claims description 5
- 238000013507 mapping Methods 0.000 claims description 2
- 239000004065 semiconductor Substances 0.000 claims 1
- 238000010586 diagram Methods 0.000 description 7
- 239000000047 product Substances 0.000 description 5
- 238000012795 verification Methods 0.000 description 5
- 230000008569 process Effects 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 230000006837 decompression Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 239000006227 byproduct Substances 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000010304 firing Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 238000007639 printing Methods 0.000 description 1
- 238000007634 remodeling Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Images
Abstract
The present invention discloses a method for hot upgrading embedded steering programs. The method has the procedures that a steering program module of the system is divided into a basic steering module and a non-solidified main steering module, the basic steering module steers after a host machine is powered or reset, and the underlayer hardware of the system is initialized. Then, the basic steering module judges whether the main steering module needs to be updated, and the basic steering module downloads the updated main steering module from external data equipment if upgrading is needed. Finally, the downloaded main steering module is started, and the dynamic upgrading of the steering programs is completed.
Description
Invention field
The present invention relates to a kind of programme upgrade method, particularly a kind of method that in embedded system, realizes the upgrading of boot heat.
Background technology
In embedded system, (boot in the embedded system is solidificated in the rom chip to need the BootRom program of curing, system's power down or reset after do not lose and can not be destroyed, when system start-up, carry out this program at first, and guide other programs to load and operation.) guide master routine.In the program development stage, or in the program use, find to need boot is made an amendment after the serious problems, revising the BootRom program needs again amended program to be fired in the BootRom chip, if long-term so frequent modification program curing, can cause very big impact to product stable, bring great inconvenience for user's use.On the other hand, based on the restriction of understanding face, the continuous change of user's request, and the different demands of different user, curing BootRom program can not can not be accomplished unalterable, to adapt to various demands.Like this, the stability of product, practicality, convenience and satisfy between the BootRom program of multiple demand characteristics and curing and just produced contradiction.
In embedded system, the program of BootRom and application program all are to be based upon on the embedded OS, and the inconsistent program that causes that operating system adopts can not be shared.The realization of this programme is only relevant with the concrete type of hardware of bottom, does not relate to any Embedded Operating System, and program compilation can be any real-time system compiler, and this programme recommends to adopt GCC (a kind of general C/C++ compiler) compiling connector.
Fig. 1 is the structural representation of conventional embedded software.As shown in Figure 1, existing embedded software is based upon on the embedded OS, and bottom hardware is support package shielding between embedded board by BSP, and application module is positioned at the outside of BSP.Application module major function in the BootRom program is to finish the loading of application program, for example the application program with needs is loaded in curing chip or storage medium such as the hard disk, simultaneously the hardware of needs is provided the initialization and the processing of a series of necessity, and application code called in the internal memory, give application program with control at last.
Fig. 2 is the synoptic diagram that conventional embedded program starts boot flow.As shown in Figure 2, the mutual relationship of BootRom program and application program and operational scheme are as follows:
1. after powering on or resetting, the bootstrapping of BootRom program.
2. bottom hardware is done necessary initialization, the installing operating system kernel, and program booted move in the internal memory.
3. enable file or data transmission module for example tftp (general file transfer protocol (FTP)), ftp (file transmits [failing] agreement), xmodem (a kind of agreement of utilizing serial ports to carry out file transfer, protocol module is divided into Server (server) end and Client (client) end, the file that the application of Client end will load, Server end is replied and is become data packet delivery to hold file division to Client) protocol module, obtain application program or other load document that needs and be stored on the corresponding storage medium from corresponding server by connecting line or network.
4.BootRom program will be installed to internal memory such as stored application program in the storage medium of FLASH (flash memory) or hard disk.If program is compressed, also need to decompress.
5.BootRom program will be moved control and give application program, finish its task mission.
In actual applications, real time operating system can adopt different operating system, and commercial operation system Psos (a kind of commercial embedded OS) for example, shares the open operating system Linux of source code etc. at Vxworks (a kind of commercial embedded OS).
But in the prior art, at the large software that is structured on the commercial operation system, the BootRom program need be made a lot of extra works, and these work are determined according to different product specification and demands.The BootRom program has very big dependence to concrete operating system and bottom hardware, like this, if operating system self has Bug (program error) or hardware design defectiveness, so, the BootRom program run is just unreliable, will occur the demand of changing upgrading or upgrading upgrading BootRom program like this in exploitation, test, the use of reality are verified.But the BootRom program has the singularity of boot, that is, it can not at will be changed.Change then will be fired program among the ROM again if desired, and in the reality, firing of ROM program will rely on other instrument, and be very inconvenient, and complicated operation, make mistakes easily, bring great obstruction for the development efficiency of product application program and user's ease of use.
Summary of the invention
At the above-mentioned shortcoming that exists in the prior art, the object of the present invention is to provide a kind of can Real-time and Dynamic load or the upgrading embedded system in the method for curing boot.
To achieve these goals, the invention provides a kind of method that in embedded system, realizes the upgrading of boot heat, the bootstrap program module of described system comprises the master boot module of basic bootstrap module and non-curing, described basic bootstrap module and master boot module all move in internal memory, being distributed in the basic bootstrap module of internal memory specified, and the memory field of basic bootstrap module and the memory field of master boot module are not overlapping, this method may further comprise the steps: 1) described basic bootstrap module powers on or the back guiding that resets at main frame, and the bottom hardware of described system is carried out initialization; 2) set a judge mark between described basic module and the master boot module, described basic module judges whether under the needs described bootstrap module to be upgraded according to judge mark; 3) upgrade the master boot module of then described basic bootstrap module down loading updating from the external data equipment if desired; And 4) master boot module of described download starts to finish dynamic update.
The basic bootstrap module of described curing and the master boot module of described non-curing can be kept in the same memory storage of embedded system, also can be kept at respectively in the different memory storages.
Above-mentioned steps 3) comprises the step that connects the master boot module of down loading updating from the external data equipment by the simple outside port that contains serial ports or network interface at least in.
Above-mentioned steps 4) comprises the step that the described master boot module of downloading is decompressed in.
In said method, described basic bootstrap module also provides supports the various types of interface functions that contain the chip that solidifies boot of read-write.
Also specified the first address of described master boot module in memory mapping in the described basic bootstrap module.
In said method, the distribution and the utilization of described memory field have time phase, can utilize the memory field of basic bootstrap module after master boot module starts.
By utilizing method of the present invention, just can realize the Real-time and Dynamic of the boot in the embedded system is loaded or upgrading.The Real-time and Dynamic here is meant and is directly relying on simple outside port connection (for example serial ports, network interface etc.) that the program file transmission also is cured on the predetermined curing storage medium on the product erasablely.This upgrade method is abbreviated as the heat upgrading herein.Above-mentioned hot upgrade method is simple, practicality, dependable performance, extensibility and can use continuity strong, does not rely on any operating system, and the degree of dependence of bottom hardware is reached minimum.
Description of drawings
Fig. 1 is the structural representation of conventional embedded software;
Fig. 2 is the synoptic diagram that conventional embedded program starts boot flow;
Fig. 3 is the synoptic diagram that the BootRom chip space is divided in the embodiment of the invention;
Fig. 4 is a Memory Allocation synoptic diagram of supporting the operation of heat upgrading embedded software program in the embodiment of the invention;
Fig. 5 is the synoptic diagram according to the described heat upgrading of embodiment of the invention flow process.
Embodiment
Below with reference to accompanying drawing embodiments of the invention are elaborated.
Fig. 3 is the synoptic diagram that the BootRom chip space of boot in the embodiment of the invention is divided.As shown in Figure 3, in the described hot upgrade method of the embodiment of the invention, the BootRom module is divided into two parts: little BootRom module and main BootRom module, its medium and small BootRom module is a binary file that compiling link is good, and the burning sheet program of process chip burner transforms the file that the back generation can Gong fire; Main BootRom module be the good program file of compiling link through overcompression (Arj for example, high speed, reliably, extremely popular order line File Compress instrument, here embedded system is transplanted it.) also add the self-defining load document that file header forms later on self-defining load document form Core Generator, contain version information.Little BootRom module resides in the space of BootRom chip, finishes CPU initialization, internal memory initialization, serial ports initialization, serial communication and decompression (Arj) function etc. are provided.The characteristics of little BootRom module are function singlenesses, and are simple to operate, and program does not rely on any operating system in addition, and only the minimal hardware system to bottom relies on to some extent.Code compile adopts unified GCC compiling link device compiling link.In BootRom chip remaining space (following this space is called the Magic number space), preserve a Magic number (BOOTROM_MAGIC_WORD), whether this Magic number is used for judging needs to load main BootRom module from loading Server, its specific implementation will make a detailed description in the back.Remaining space is used to deposit main BootRom module in the BootRom chip.Main BootRom module is moved behind the internal memory decompress(ion) execution of contracing, the loading and the bootstrapping of the initialization of complete operation system, each module of operating system.Like this, because what little BootRom module was finished is most basic function, the main BootRom module section of only need upgrading when needs upgradings or when upgrading BootRom, improved the security of BootRom upgrading effectively, still can be even once upgrading is unsuccessful by re-powering or Reset Board, little BootRom module restarts, and veneer carries out the second time and even loads till success for the third time.Simultaneously, in order to preserve the program code of loading, also must the provide support interface function of read-write all kinds BootRom chip of BootRom submodule (say definitely be among the little BootRom submodule), for example: be used to provide erase feature the erase function, be used to provide the write data function the write function, be used to provide the verify function of the data function that verification writes, or the like.Value-added tax function (for example XModem serial ports) is a key property in the system support module, it resides in the branch space of BootRom, and (the branch allocation of space of BootRom as shown in Figure 4, wherein the space between address 1 and the address 2 is BootRom branch space, address 1 and address 2 are specifically set by demand) in, be the important means that realizes the hot upgrade feature of BootRom.Finish in little BootRom module after the work such as hardware initialization, serial ports initialization, serially printing driving, this value-added tax function will be carried out the loading of main BootRom program.
Little BootRom module and main BootRom module all need to move in the internal memory to move, and the distribution of internal memory appointment in little BootRom module.Fig. 4 is a Memory Allocation synoptic diagram of supporting the operation of heat upgrading embedded software program in the embodiment of the invention.As shown in Figure 4, the memory field of the memory field of little BootRom module and main BootRom module can not be overlapping.Main BootRom module can be utilized the employed memory field of little BootRom module after starting.Noting, is free interim for the distribution and the utilization of memory field, when the memory field of little Bootrom at main Bootrom program start and after finishing mission, its shared internal memory can discharge and use it for anything else.The shared internal memory of corresponding main Bootrom also can be released after mainframe program moves.
In addition, the code image internal memory first address of main BootRom module need be specified in little BootRom module.
Next will be elaborated with reference to the described heat upgrading of 5 pairs of embodiment of the invention of figure flow process.As shown in Figure 5, in the present embodiment, heat upgrading flow process mainly may further comprise the steps:
Step 1: power on or reset, all modules of hardware this moment are in original state, the ROM start address instruction fetch operation of CPU from setting.Notice that the instruction that read this moment is exactly the instruction of little Bootrom program.
Step 2: in little Bootrom program, the hardware such as internal memory, pci bus (X86) is done simple and necessary initialization.Also need among the PPC (Power PC) some modules are carried out initial configuration.In addition, if in little Bootrom, load, also need corresponding reception hardware is done initialization.
By the way, except the module that is used for the initiating hardware system, other module in the little BootRom module (for example serial communication modular, Arj module, hot updating operation tfi module, or the like) all is designed to share the formula module.The bottom difference adopts adaptable interface can easily be transplanted in the framework of different hardware system, for example X86 framework, PPC framework etc.Because these modular programs do not relate to operating system, therefore can easily be transplanted.But then will be for the hardware initialization part at processing, this can not skip.
Step 3: by the data of little Bootrom module reading and saving within above-mentioned Magic number space (by the Magic Word space representation among Fig. 3).If (annotate: this Magic number is one or one group of specific data for the data of reading and a predefined Magic number, these group data are more special, 0x96695aa5 for example, the probability that general other data are by chance identical with these data is very little) inequality, represent that then main Bootrom program does not have, perhaps wrong.Load-on module among the little Bootrom of needs startup this moment is with request of loading master Bootrom program (for example, simply directly loading by the Xmodem serial communication modular).Note, though above-mentioned data are kept in the Magic number space, but the data of the inside are not necessarily identical with described predefined Magic number, for example do not load before the main Bootrom program, perhaps main Bootrom program is destroyed after loading, then all can cause data and described predefined Magic number to be misfitted, just can think that at this moment main Bootrom program is illegal.In fact, whether legal described predefined Magic number be exactly a main Bootrom program of check sign.On the other hand, if the data of reading are identical with described predefined Magic number, then expression has had main Bootrom program (representing that perhaps main Bootrom program is legal).At this moment, little Bootrom program will be sent information, whether need to reload new main Bootrom program with the prompting user, if the user does not make a response within a certain period of time, the step 5 that then directly enters the back is moved so that existing main Bootrom program is called in the internal memory.If user's input information is represented to reload new main Bootrom program, then enter step 4.
Step 4: when need load new main Bootrom program from little Bootrom the time, little Bootrom will call load-on module, and for example serial port protocol XModem load-on module loads main Bootrom program from the Sever end.Main Bootrom program adopts compress mode, can save the space like this, can certainly not compress.After loading is finished, the program that loads will obtain verification, if do not make mistakes, then call memory module (module that can provide the erasable verifying function that solidifies the space was provided in the front), program is write fixing main Bootrom interval and (for example: can define the Magic number 0x96695aa5 of nybble length or longer Magic number writes a predefined Magic number in described Magic number space, but the word length of Magic number is subjected to storage space limitations), expression has loaded main Bootrom program.If make mistakes, then re-execute step 4.
Step 5: when not needing from little Bootrom to load new main Bootrom program, little Bootrom will read existing main Bootrom program and it be carried out verification (annotate: before being called in internal memory from storage medium, main Bootrom program need be passed through certain verification means, make mistakes to prevent content, because concrete method of calibration all is a known prior art, so omit explanation), if verification makes mistakes, then jump into step 4; If quite right, then call decompression module and it is unziped in the main Bootrom running space in the internal memory (certainly, be not under the situation of condensing routine, just need not it is decompressed) at main Bootrom.Then, little Bootrom gives main Bootrom program with control, and finishes mission.
Step 6: after main Bootrom starts, it will finish the other function, and (these functions are decided by product demand, for example: different startup settings, the mainframe program of operation different editions, can carry out the configuration of specific hardware, automatic hardware detection etc. in addition), and take out mainframe program from the mainframe program shelf space and be discharged into mainframe program running space the internal memory.
Step 7: main Bootrom program is given mainframe program with control, and finishes mission.
Load-on module in the host application module can load in real time to little BootRom module and main BootRom module, and this load-on module can adopt the centralized control distributed way to provide and manage unified load document demand.In loading configuration, type, title, demand module No. and storage mode and the memory address of file all there is precise definition.Like this, when software need be revised or upgrade, the ROMPaq file is loaded into the concentrated controling management module from Server, and administration module is distributed to it on module of demand of main BootRom again, and it is write by loading configuration determines the place of good predetermined storage.When program is reset or during power-off restarting, the new boot after upgrading or the change will be moved.Like this, with regard to complete realization the heat upgrading of boot.
Though should be noted that explanation of the present invention is carried out according to its specific embodiment, it does not also mean that limitation of the present invention.To those skilled in the art, under the situation that does not break away from the spirit and scope of the present invention, can make various modifications and conversion to it.For example, though in an embodiment of the present invention, main BootRom module and little BootRom module leave in the BootRom chip simultaneously, in actual applications, also they can be left in respectively in the different curing storer (as the Flash storer).The size of Flash storer is general all more than 4M, and common BootRom storage chip amount of capacity is fixed as 512K, so the Flash storer is enough to meet the demands.In addition, the main frame load-on module also can adopt other modes to load, the distributed concentrated forward mode that for example can adopt each demand module application message to E-Packet and directly load from Server then by load-on module.In a word, do not deviate from the various remodeling of spirit of the present invention all within the protection domain of the appended claim of the present invention.
Claims (9)
1. in embedded system, realize the hot method of upgrading of boot for one kind, the bootstrap program module of described system comprises the master boot module of basic bootstrap module and non-curing, described basic bootstrap module and master boot module all move in internal memory, being distributed in the basic bootstrap module of internal memory specified, and the memory field of basic bootstrap module and the memory field of master boot module are not overlapping, and this method may further comprise the steps:
1) described basic bootstrap module powers on or the back guiding that resets at main frame, and the bottom hardware of described system is carried out initialization;
2) set a judge mark between described basic module and the master boot module, described basic module judges whether under the needs described bootstrap module to be upgraded according to judge mark;
3) upgrade described master boot module if desired, the master boot module of then described basic bootstrap module down loading updating from the external data equipment; And
4) master boot module of described download starts to finish dynamic update.
2. method according to claim 1 is characterized in that, described basic bootstrap module and described master boot module are kept in the same memory storage.
3. method according to claim 1 is characterized in that, described basic bootstrap module is with in described master boot module is kept at different memory storages.
4. according to claim 2 or 3 described methods, it is characterized in that described memory storage is a semiconductor storage.
5. method according to claim 4, it is characterized in that, further comprise in the described step 3) by described basic bootstrap module connecting step with the master boot module of down loading updating from external data equipment by the simple outside port that contains serial ports or network interface at least.
6. method according to claim 4 is characterized in that, further comprises the step that the described master boot module of downloading is decompressed in the described step 4).
7. method according to claim 4 is characterized in that, described basic bootstrap module also provides supports the various types of interface functions that contain the chip that solidifies boot of read-write.
8. method according to claim 4 is characterized in that, specifies in the described basic bootstrap module and states the first address of master boot module in memory mapping to some extent.
9. method according to claim 4 is characterized in that, the distribution and the utilization of described memory field have time phase, can utilize the memory field of basic bootstrap module after master boot module starts.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB031374220A CN100389389C (en) | 2003-06-20 | 2003-06-20 | Method for implementing hot-update of bootstrap program in flush bonding system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB031374220A CN100389389C (en) | 2003-06-20 | 2003-06-20 | Method for implementing hot-update of bootstrap program in flush bonding system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1567195A CN1567195A (en) | 2005-01-19 |
| CN100389389C true CN100389389C (en) | 2008-05-21 |
Family
ID=34470402
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB031374220A Expired - Lifetime CN100389389C (en) | 2003-06-20 | 2003-06-20 | Method for implementing hot-update of bootstrap program in flush bonding system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100389389C (en) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN100359469C (en) * | 2005-07-22 | 2008-01-02 | 上海华为技术有限公司 | Upgrading method for one-chip computer |
| CN100373337C (en) * | 2006-01-20 | 2008-03-05 | 北京朗通环球科技有限公司 | Guide system of embedded system |
| CN100386728C (en) * | 2006-03-24 | 2008-05-07 | 清华大学 | On-line software updating method of implantation medical equipment |
| CN100561433C (en) * | 2006-09-30 | 2009-11-18 | 四川长虹电器股份有限公司 | Embedded system and upgrade method thereof |
| CN102135894B (en) * | 2010-10-13 | 2015-11-25 | 华为技术有限公司 | A kind of online patch method of multinuclear and device |
| CN102467397A (en) * | 2010-11-17 | 2012-05-23 | 中兴通讯股份有限公司 | Boot method and device of embedded system |
| CN102830986A (en) * | 2011-06-17 | 2012-12-19 | 中兴通讯股份有限公司 | Method and device for turning on system in double-BOOT program condition |
| US9261932B2 (en) * | 2013-03-15 | 2016-02-16 | Microchip Technology Incorporated | Minimizing switchover time in a hot swappable program memory |
| CN105677376A (en) * | 2014-11-19 | 2016-06-15 | 中兴通讯股份有限公司 | Bootstrap program transmission method, embedded system and bootstrap program transmission system |
| CN104965744A (en) * | 2015-07-10 | 2015-10-07 | 上海斐讯数据通信技术有限公司 | System upgrading method and embedded system |
| CN106155752A (en) * | 2016-08-03 | 2016-11-23 | 北京蛙视通信技术股份有限公司 | A kind of method and device of starting of embedded operation system |
| CN108304200B (en) * | 2017-01-12 | 2022-02-22 | 阿里巴巴集团控股有限公司 | Method and device for upgrading driving program and electronic equipment |
| CN106990982B (en) * | 2017-03-20 | 2021-07-02 | 北京新能源汽车股份有限公司 | Program updating method and device |
| CN107203796A (en) * | 2017-06-09 | 2017-09-26 | 张晶婕 | A kind of fructose machine control system and its control method for automatically controlling out sugar |
| CN111488168B (en) * | 2019-12-25 | 2023-09-12 | 湖北航天飞行器研究所 | Weapon system control software safety upgrading method based on boot secondary loading |
| CN111258604A (en) * | 2020-01-14 | 2020-06-09 | 深圳市有为信息技术发展有限公司 | Bootloader upgrading system and method |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6128734A (en) * | 1997-01-17 | 2000-10-03 | Advanced Micro Devices, Inc. | Installing operating systems changes on a computer system |
| US6275931B1 (en) * | 1998-06-22 | 2001-08-14 | Elsag International N.V. | Method and apparatus for upgrading firmware boot and main codes in a programmable memory |
-
2003
- 2003-06-20 CN CNB031374220A patent/CN100389389C/en not_active Expired - Lifetime
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6128734A (en) * | 1997-01-17 | 2000-10-03 | Advanced Micro Devices, Inc. | Installing operating systems changes on a computer system |
| US6275931B1 (en) * | 1998-06-22 | 2001-08-14 | Elsag International N.V. | Method and apparatus for upgrading firmware boot and main codes in a programmable memory |
Also Published As
| Publication number | Publication date |
|---|---|
| CN1567195A (en) | 2005-01-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN100389389C (en) | Method for implementing hot-update of bootstrap program in flush bonding system | |
| RU2439678C2 (en) | Initial download of operating system in separate stages | |
| US7908466B2 (en) | Method and apparatus for booting a microprocessor system using boot code stored on a serial flash memory array having a random-access interface | |
| CN100561433C (en) | Embedded system and upgrade method thereof | |
| RU2419839C2 (en) | Software update system and method for portable ota supporting mobile terminal | |
| CN101751273B (en) | Safety guide device and method for embedded system | |
| US20060075284A1 (en) | Method for over-the-air firmware update of NAND flash memory based mobile devices | |
| JP2007213571A (en) | Method for starting system using direct memory access in novel memory architecture | |
| US20020065958A1 (en) | System and method for implementing a self-activating embedded application | |
| WO2011116621A1 (en) | Electronic device, configurable component and configuration information storage method thereof | |
| CN101145107B (en) | Maintaining early hardware configuration state | |
| CN101615128B (en) | Online upgrade method and device of singlechip | |
| CN103365696A (en) | BIOS (Basic Input Output System) image file obtaining method and device | |
| CN102880498A (en) | Method of virtual SD (Security Digital) card on device with android system | |
| CN108762797A (en) | A kind of SSD firmwares online updating method, system and SSD | |
| CN101872306B (en) | Embedded system for realizing software updating and software backup and implementation method thereof | |
| WO2012071852A1 (en) | Method and apparatus for upgrading bootstrap program | |
| WO2022105595A1 (en) | Method and apparatus for upgrading system of embedded device, and embedded device | |
| WO2022227409A1 (en) | Embedded terminal remote software updating method | |
| CN104035757A (en) | MIPS-based (microprocessor without interlocked piped stages-based) U-boot (universal boot loader) transplantation implementing method | |
| KR100729525B1 (en) | Method and system for updating firmware | |
| CN101615129B (en) | Updating method and edition management client end applied in distributed system | |
| CN102681858A (en) | VxWorks operation system as well as method and device for configuring start waiting time thereof | |
| CN116501357A (en) | Online upgrade method of singlechip | |
| CN114416031B (en) | Operating system for supporting RISC-V processor facing AIoT scene |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20170928 Address after: 053000 No. 126, Yanggu village, Zaoqiang Town, Zaoqiang County, Hengshui, Hebei Patentee after: Duan Hongxin Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen Patentee before: HUAWEI TECHNOLOGIES Co.,Ltd. |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20180524 Address after: 518000 Baoan District Xin'an street, Shenzhen, Guangdong, No. 625, No. 625, Nuo platinum Plaza, Patentee after: SHENZHEN SHANGGE INTELLECTUAL PROPERTY SERVICE Co.,Ltd. Address before: 053000 Yanggu town 126, Zaoqiang Town, Zaoqiang, Hengshui, Hebei Patentee before: Duan Hongxin |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20180628 Address after: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen Patentee after: HUAWEI TECHNOLOGIES Co.,Ltd. Address before: 518000 Baoan District Xin'an street, Shenzhen, Guangdong, No. 625, No. 625, Nuo platinum Plaza, Patentee before: SHENZHEN SHANGGE INTELLECTUAL PROPERTY SERVICE Co.,Ltd. |
|
| CX01 | Expiry of patent term | ||
| CX01 | Expiry of patent term |
Granted publication date: 20080521 |