CN106708542B - Method and device for loading codes of embedded operating system - Google Patents
Method and device for loading codes of embedded operating system Download PDFInfo
- Publication number
- CN106708542B CN106708542B CN201510420963.1A CN201510420963A CN106708542B CN 106708542 B CN106708542 B CN 106708542B CN 201510420963 A CN201510420963 A CN 201510420963A CN 106708542 B CN106708542 B CN 106708542B
- Authority
- CN
- China
- Prior art keywords
- code
- region
- memory
- memory sub
- loading
- 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.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The invention provides a method and a device for loading codes of an embedded operating system, wherein the method comprises the following steps: acquiring a current use scene of the embedded operating system; according to the corresponding relation between the use scene and the code address, acquiring the code address of the code needing to be recovered in the first memory area corresponding to the current use scene; acquiring a code to be recovered and a calling function according to the code address of the code to be recovered; and loading the code needing to be recovered, and loading other codes corresponding to the current use scene from the second memory area according to the calling function. The invention ensures the normal operation of the embedded operating system and simultaneously ensures the real-time performance and the high-efficiency operation of the system.
Description
Technical Field
The present invention relates to the field of communications, and in particular, to a method and an apparatus for loading codes of an embedded operating system.
Background
In an embedded system, when a program is executed, the assignment operation of a variable is actually a write operation of an internal memory. If the program is executed in a ROM, the assignment of variables is not possible, and a RAM can support random address reading and writing, so the program code is usually executed in RAM, while the memory is typically RAM, so that the code needs to be copied from ROM to memory.
After the system selects to start from the Nandflash, the CPU automatically maps 0x0 address to the steppingstone, and simultaneously copies the former 4K code of the Nandflash to the steppingstone, because the size of the steppingstone is only 4K, and the size of the system starting program is often more than 4K, all starting codes need to be carried to a memory with larger space for operation. After the code in the Steppingstone sets relevant hardware (such as an external memory controller) in the carrying process, namely after the relevant action of initialization is carried out, the program is carried to the external memory controller, namely a double-rate synchronous dynamic random access memory DDR, and then the program jumps into the DDR to continue to operate. The embedded system is also internally provided with an Inter Ram which is a memory area used for storing the flow codes frequently scheduled by the system, and the size of the memory area is 256 k. In order to ensure that the power consumption of the system is reduced to the minimum and meet the requirements, the system is designed to be in periodic power-off dormancy and awaken a power-on running system. And code flows under certain specific scenes after power-on is awakened, for example, the specific flows after power-on is awakened and stored in the Inter Ram.
To this end, the code memory space consists of an external DDR and an internal Inter Ram. The two codes are uniformly scheduled to ensure the normal operation of the system. The instruction access difference between the DDR and the internal Inter Ram is that the internal Inter Ram instruction access speed is higher, the bus does not need to be passed through, the DDR instruction access needs to be passed through the bus, the access speed is lower, and data are not lost after power failure. It is for this reason that frequently scheduled flow code is placed in Inter Ram. However, the internal Inter Ram characteristic cannot guarantee normal use of the code data after the system is powered off, and because the internal Inter Ram data is lost due to power failure, the internal data cannot be normally restored before the system is powered off and dormant and the internal data cannot be normally restored before the system is powered on and awakened. But as a real-time embedded system, the code data of 256k in the Inter Ram needs to be recovered each time the system is powered on and woken up, which is a great challenge for the real-time performance of the system. The design aim of the system is based on the fact that how to ensure the normal running of codes after the system is electrified and recovered does not affect the real-time performance of the system, and the running of the system is ensured more efficiently.
Disclosure of Invention
The invention provides a method and a device for loading codes of an embedded operating system, which aim to ensure the normal operation of the embedded operating system and simultaneously ensure the real-time performance of the system and the efficient operation of the system.
In order to achieve the above object, the present invention provides a method for loading codes of an embedded operating system, wherein the method comprises:
acquiring a current use scene of the embedded operating system;
according to the corresponding relation between the use scene and the code address, acquiring the code address of the code needing to be recovered in the first memory area corresponding to the current use scene;
acquiring a code to be recovered and a calling function according to the code address of the code to be recovered;
and loading the code needing to be recovered, and loading other codes corresponding to the current use scene from the second memory area according to the calling function.
Optionally, the first memory area is a memory area for storing frequent scheduling codes in the embedded operating system, and the second memory area is an external storage controller.
Optionally, before the obtaining a code address that needs to be restored in the first memory area corresponding to the current usage scenario, the method further includes: the first memory area divides a plurality of memory sub-areas according to the calling frequency of the codes, wherein the calling frequency of the codes corresponding to each memory sub-area is different, and the interval value between the virtual addresses mapped by the adjacent memory sub-areas is at least 32 MB.
Optionally, the first memory region is divided into a first memory sub-region, a second memory sub-region and a third memory sub-region, where codes are stored in both the first memory sub-region and the second memory sub-region, the third memory sub-region is a reserved region, and a code calling frequency in the first memory sub-region is greater than a code calling frequency in the second memory sub-region.
Optionally, the loading, according to the call function, other codes corresponding to the current usage scenario from the second memory area includes: compiling the calling function corresponding to the memory sub-region to generate an LDR instruction, wherein the LDR instruction link address is located in the memory sub-region corresponding to the calling function, and the LDR instruction can jump in a full address range.
According to another aspect of the present invention, the present invention further provides an apparatus for loading codes of an embedded operating system, the apparatus comprising:
the first acquisition module is used for acquiring the current use scene of the embedded operating system;
the second obtaining module is used for obtaining a code address which corresponds to the current use scene and needs to recover the code in the first memory area according to the corresponding relation between the use scene and the code address;
the third obtaining module is used for obtaining the code needing to be recovered and the calling function according to the code address of the code needing to be recovered;
and the loading module is used for loading the code needing to be recovered and loading other codes corresponding to the current use scene from the second memory area according to the calling function.
Optionally, the first memory area is a memory area for storing frequent scheduling codes in the embedded operating system, and the second memory area is an external storage controller.
Optionally, the apparatus further includes a dividing module, configured to divide the first memory region into a plurality of memory sub-regions according to a call frequency of the code, where the call frequency of the code corresponding to each memory sub-region is different, and an interval value between virtual addresses mapped by adjacent memory sub-regions is at least 32 MB.
Optionally, the first memory region is divided into a first memory sub-region, a second memory sub-region and a third memory sub-region, where codes are stored in both the first memory sub-region and the second memory sub-region, the third memory sub-region is a reserved region, and a code calling frequency in the first memory sub-region is greater than a code calling frequency in the second memory sub-region.
Optionally, the load module is further configured to compile the call function corresponding to the memory sub-region, and then generate an LDR instruction, where the LDR instruction link address is located in the memory sub-region corresponding to the call function, and the LDR instruction can jump in a full address range.
The invention has the beneficial effects that:
the invention provides a method for loading codes of an embedded operating system, which comprises the steps of firstly obtaining a current use scene of the embedded operating system, obtaining a code address of a code needing to be recovered in a first memory area corresponding to the current use scene according to the corresponding relation between the use scene and the code address, then obtaining the code needing to be recovered and a calling function according to the code address of the code needing to be recovered, finally loading the code needing to be recovered, and loading other codes corresponding to the current use scene from a second memory area according to the calling function. The method and the device can restore the codes and call functions as required, and directly load other codes corresponding to the current use scene from the second memory area, namely, the codes are restored as required according to the use scene without restoring all the codes in the first memory area, so that the normal operation of the embedded operating system is ensured, and simultaneously, the real-time performance of the system and the efficient operation of the system are ensured.
Drawings
FIG. 1 is a flow chart illustrating the main steps of a method for loading code for an embedded operating system in an embodiment of the present invention;
FIG. 2 is a flowchart illustrating the detailed steps of a method for code loading of an embedded operating system in an embodiment of the present invention;
FIG. 3 is a diagram illustrating a mapping relationship between each of the memory sub-regions and the virtual address space in an embodiment of the invention; and
fig. 4 is a block diagram of an apparatus for loading codes of an embedded operating system according to an embodiment of the present invention.
Detailed Description
Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
As shown in fig. 1, which is a flowchart of main steps of a method for loading an embedded operating system code in an embodiment of the present invention, the method mainly includes the following steps:
In this step, the current usage scenario of the embedded operating system is obtained. Specifically, the current usage scenario of the embedded operating system may be a scenario in which the system is awakened from power down sleep to power up. It should be noted here that the current usage scenario of the embedded operating system is not limited to the scenario from power down sleep to power up wake-up.
102, according to the corresponding relation between the use scene and the code address, obtaining the code address which corresponds to the current use scene and needs to recover the code in the first memory area.
In this step, specifically, before acquiring a code address of a code that needs to be restored in the first memory area and corresponds to the current usage scenario, a correspondence between the usage scenario and the code address is first established, and then, according to the correspondence between the usage scenario and the code address, a code address of the code that needs to be restored in the first memory area and corresponds to the current usage scenario is acquired.
And 103, acquiring the code needing to be recovered and a calling function according to the code address of the code needing to be recovered.
In this step, after the code address of the code to be restored is obtained, the code to be restored and the function to be called are obtained from the code address.
And 104, loading the codes needing to be recovered, and loading other codes corresponding to the current use scene from the second memory area according to the calling function.
In this step, specifically, since the code to be restored corresponding to the current usage scenario exists in both the first memory area and the second memory area, the code to be restored needs to be loaded, and then the other code corresponding to the current usage scenario is loaded from the second memory area according to the call function.
According to the method and the device, codes and calling functions can be recovered according to the needs in the acquired memory addresses, the acquired memory addresses are directly jumped to the second memory area, and other codes corresponding to the current use scene are loaded from the second memory area, namely, all codes in the first memory area do not need to be recovered, but the codes are recovered according to the use scene, so that the normal running of the codes of the embedded operating system is ensured, and the real-time performance of the system and the efficient operation of the system are ensured.
As shown in fig. 2, which is a detailed step flowchart of the method for loading the code of the embedded operating system in the embodiment of the present invention, the method mainly includes the following steps:
in step 201, the first memory area is divided into a plurality of memory sub-areas according to the calling frequency of the code.
In this step, specifically, the first memory area is a memory area for storing frequently scheduled codes in the embedded operating system, and the memory of the first memory area is small, and is usually only 256 KB. In addition, the first memory region may be divided into a plurality of memory sub-regions according to the call frequency of the code, where the call frequency of the code corresponding to each memory sub-region is different, and the interval value between the virtual addresses mapped by adjacent memory sub-regions is at least 32 MB.
Optionally, the memory area may be divided into a first memory sub-area, a second memory sub-area, and a third memory sub-area, where both the first memory sub-area and the second memory sub-area are used for storing codes, the third memory sub-area is used as a reserved area, that is, the third memory sub-area is a blank area, and the code calling frequency in the first memory sub-area is greater than the code calling frequency in the second memory sub-area. In addition, specifically, after the memory area is divided into the first memory sub-area, the second memory sub-area and the third memory sub-area, and when the memory of the first memory region is 256KB, the region space of the first memory sub-region may be the first 128KB space of the first memory region, and the region space of the second memory sub-region and the region space of the third memory sub-region may be both 68KB, at this time, the virtual address spaces mapped by the first memory sub-region, the second memory sub-region and the third memory sub-region may be all 1MB, and the separation between the virtual address of the first memory sub-region map and the virtual address of the second memory sub-region map is at least 32MB, and the separation between the virtual address of the second memory sub-region map and the virtual address of the third memory sub-region map is at least 32M, specifically, see fig. 3 for a mapping relationship between each memory sub-region and the virtual address space.
102, according to the corresponding relation between the use scene and the code address, obtaining the code address which corresponds to the current use scene and needs to recover the code in the first memory area.
In this step, specifically, before acquiring a code address of a code that needs to be restored in the first memory area and corresponds to the current usage scenario, a correspondence between the usage scenario and the code address is first established, and then, according to the correspondence between the usage scenario and the code address, a code address of the code that needs to be restored in the first memory area and corresponds to the current usage scenario is acquired. This step will be described below by way of example.
The current use scene is assumed to be the use scene after the system is awakened from power-down sleep to power-up. The correspondence between the usage scenario and the code address may be: in the use scenario, a first memory sub-region in the first memory region may be used to store a code which has the highest system scheduling frequency and needs to be called immediately after the system is awakened from power-down sleep to power-up; the second memory area memory subarea is used for storing codes which have the scheduling frequency smaller than that of the first memory subarea and are not called immediately after the system is awakened from power-down dormancy to power-up dormancy; the third sub-area is used as a reserved area. According to the correspondence between the use scenario after the system is woken up from power down to power up and the code address, the code address of the code to be restored in the first memory area corresponding to the use scenario can be obtained, specifically, in this example, the code address to be restored in the first memory area corresponding to the use scenario is the first memory sub-area in the first memory area.
And 103, acquiring the code needing to be recovered and a calling function according to the code address of the code needing to be recovered.
In this step, after the code address of the code to be restored is obtained, the code to be restored and the function to be called can be obtained from the code address according to the code address of the code to be restored.
The description continues with the example in step 102.
And after the address of the first memory sub-area in the first memory area is acquired, acquiring the code needing to be recovered and the function needing to be called from the first memory sub-area.
And 104, loading the codes needing to be recovered, and loading other codes corresponding to the current use scene from the second memory area according to the calling function.
In this step, if the code to be restored corresponding to the current usage scenario exists in both the first memory area and the second memory area, the code to be restored is loaded, and then other codes corresponding to the current usage scenario are loaded from the second memory area according to the call function. Specifically, the second memory area is an external memory controller, and preferably, the external memory controller may be a double data rate synchronous dynamic random access memory DDR.
Specifically, during the running of the embedded operating system, the codes stored in the first memory area and the codes stored in the second memory area form a certain logical relationship, and the logical relationship enables the system to be scheduled in a specific use scene so as to ensure the normal running of the system. Next, the description is continued by way of example in step 102.
In this example, the code to be executed after the system is powered on and woken up is placed in a first memory sub-area in the first memory area. Because the attribute of the code segment is that the code needs to be recovered after power-on wakeup to ensure the normal operation of the code, the method is used for preventing the program from losing control, namely preventing the code from 'running away', and if the code segment is not recovered, the generated illegal address access can cause the system paralysis. However, since the memory of the first memory area is small (typically only 256KB), only limited codes which need to be recovered can be placed in the first memory area, and then other codes corresponding to the system after the system is woken up from power down sleep are placed in the second memory area, that is, in the external storage controller. At this time, in order to ensure normal operation of the system, after the codes to be recovered are loaded in the first memory sub-area, other codes corresponding to the codes from the power-down sleep to the power-on wake-up are loaded in the second memory sub-area according to the call function in the first memory sub-area.
In this step, specifically, the calling function can generate an executable file and be called normally because the program must go through compiling, assembling and linking processes, and the linking process needs to relocate the target file, establish a symbol reference rule, and allocate an operation address to a variable, a function, and the like. When a program is executed, the system must load codes into an address space specified in the link to ensure that the program correctly refers to symbols such as variables, functions and the like in the execution process, so that the program can normally run. In the process, a call function corresponding to the first memory sub-region is compiled to generate an LDR instruction, the link address of the LDR instruction is located in the memory region corresponding to the call function, and the LDR instruction can operate in a full address range, and an interval between virtual addresses mapped by adjacent memory sub-regions in the first memory region is at least 32MB, so that the first memory sub-region can be linked to the second memory region according to the LDR instruction to ensure normal operation of the system.
In this embodiment, the first memory region is divided into a plurality of memory sub-regions, and the interval between the virtual addresses mapped by the adjacent memory sub-regions is at least 32MB, so that the system can directly link from the first memory sub-region in the first memory region to the second memory region according to the LDR instruction. Therefore, the real-time performance and the efficient operation of the system are ensured under the condition of ensuring the normal operation of the system.
Fig. 4 is a block diagram of an apparatus for loading codes of an embedded operating system according to an embodiment of the present invention, where the apparatus includes:
a first obtaining module 301, configured to obtain a current usage scenario of the embedded operating system;
a second obtaining module 302, configured to obtain, according to a correspondence between a usage scenario and a code address, corresponding to a current usage scenario, of a code that needs to be restored in a first memory area;
a third obtaining module 303, configured to obtain a code to be restored and a call function according to a code address of the code to be restored;
and the loading module 304 is configured to load the code that needs to be restored, and load other codes corresponding to the current usage scenario from the second memory area according to the call function.
Optionally, the first memory area is a memory area for storing frequent scheduling codes in the embedded operating system, and the second memory area is an external memory controller.
Optionally, the apparatus further includes a dividing module, configured to divide the first memory region into a plurality of memory sub-regions according to a call frequency of the code, where the call frequency of the code corresponding to each memory sub-region is different, and an interval value between virtual addresses mapped by adjacent memory sub-regions is at least 32 MB.
Optionally, the first memory region is divided into a first memory sub-region, a second memory sub-region and a third memory sub-region, wherein codes are stored in both the first memory sub-region and the second memory sub-region, the third memory sub-region is a reserved region, and a code calling frequency in the first memory sub-region is greater than a code calling frequency in the second memory sub-region.
Optionally, the loading module 304 is further configured to compile a call function corresponding to the memory sub-region, and then generate an LDR instruction, where a link address of the LDR instruction is located in the memory sub-region corresponding to the call function, and the LDR instruction can jump within a full address range.
While the preferred embodiments of the present invention have been described, it will be understood by those skilled in the art that various changes and modifications may be made without departing from the spirit and scope of the invention as defined in the following claims.
Claims (10)
1. A method for embedded operating system code loading, the method comprising:
acquiring a current use scene of the embedded operating system;
according to the corresponding relation between the use scenes and the code addresses, the code addresses of the codes which need to be recovered in the first memory area and correspond to the current use scenes are obtained, and in the corresponding relation between the use scenes and the code addresses, the code addresses corresponding to any use scene are partial areas in the first memory area;
acquiring a code to be recovered and a calling function according to the code address of the code to be recovered;
and loading the code needing to be recovered, and loading other codes corresponding to the current use scene from the second memory area according to the calling function.
2. The method of claim 1, wherein the first memory area is a memory area for storing frequently scheduled code in an embedded operating system, and wherein the second memory area is an external memory controller.
3. The method according to claim 2, wherein before said obtaining a code address requiring recovery in a first memory region corresponding to the current usage scenario, the method further comprises:
dividing the first memory area into a plurality of memory sub-areas according to the calling frequency of the codes, wherein the calling frequency of the codes corresponding to each memory sub-area is different, and the interval value between the virtual addresses mapped by the adjacent memory sub-areas is at least 32 MB.
4. The method of claim 3, wherein the first memory region is divided into a first memory sub-region, a second memory sub-region and a third memory sub-region, wherein the first memory sub-region and the second memory sub-region both store codes, the third memory sub-region is a reserved region, and a frequency of code calls in the first memory sub-region is greater than a frequency of code calls in the second memory sub-region.
5. The method according to claim 3, wherein the loading other codes corresponding to the current usage scenario from the second memory area according to the calling function comprises:
compiling the calling function corresponding to the memory sub-region to generate an LDR instruction, wherein the LDR instruction link address is located in the memory sub-region corresponding to the calling function, and the LDR instruction can jump in a full address range.
6. An apparatus for embedded operating system code loading, the apparatus comprising:
the first acquisition module is used for acquiring the current use scene of the embedded operating system;
a second obtaining module, configured to obtain, according to a correspondence between usage scenarios and code addresses, a code address of a code that needs to be restored in a first memory area and corresponds to the current usage scenario, where in the correspondence between the usage scenarios and the code addresses, a code address corresponding to any usage scenario is a partial area in the first memory area;
the third obtaining module is used for obtaining the code needing to be recovered and the calling function according to the code address of the code needing to be recovered;
and the loading module is used for loading the code needing to be recovered and loading other codes corresponding to the current use scene from the second memory area according to the calling function.
7. The apparatus of claim 6, wherein the first memory area is a memory area for storing frequently scheduled code in an embedded operating system, and the second memory area is an external memory controller.
8. The apparatus according to claim 7, further comprising a dividing module, configured to divide the first memory region into a plurality of memory sub-regions according to a call frequency of a code, where the call frequency of the code corresponding to each memory sub-region is different, and a distance value between virtual addresses mapped by adjacent memory sub-regions is at least 32 MB.
9. The apparatus of claim 8, wherein the first memory region is divided into a first memory sub-region, a second memory sub-region and a third memory sub-region, wherein the first memory sub-region and the second memory sub-region both store code, the third memory sub-region is a reserved region, and a frequency of code calls in the first memory sub-region is greater than a frequency of code calls in the second memory sub-region.
10. The apparatus as claimed in claim 8, wherein the loading module is further configured to compile the call function corresponding to the memory sub-region to generate an LDR instruction, where the LDR instruction link address is located in the memory sub-region corresponding to the call function, and the LDR instruction can jump in a full address range.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510420963.1A CN106708542B (en) | 2015-07-17 | 2015-07-17 | Method and device for loading codes of embedded operating system |
| PCT/CN2015/094702 WO2016131313A1 (en) | 2015-07-17 | 2015-11-16 | Code loading method and apparatus for embedded operating system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510420963.1A CN106708542B (en) | 2015-07-17 | 2015-07-17 | Method and device for loading codes of embedded operating system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN106708542A CN106708542A (en) | 2017-05-24 |
| CN106708542B true CN106708542B (en) | 2020-10-13 |
Family
ID=56688663
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201510420963.1A Active CN106708542B (en) | 2015-07-17 | 2015-07-17 | Method and device for loading codes of embedded operating system |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN106708542B (en) |
| WO (1) | WO2016131313A1 (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113625995A (en) * | 2020-05-07 | 2021-11-09 | 武汉斗鱼网络科技有限公司 | Method and device for self-adaptively acquiring data |
| CN111580831A (en) * | 2020-05-14 | 2020-08-25 | 深圳忆联信息***有限公司 | Method and device for improving code running efficiency, computer equipment and storage medium |
| CN118276763A (en) * | 2022-12-30 | 2024-07-02 | 华为技术有限公司 | Program storage position adjusting method and related device |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080201604A1 (en) * | 2007-02-20 | 2008-08-21 | Mall Michael G | Kernel Error Recovery Disablement and Shared Recovery Routine Footprint Areas |
| WO2011103652A1 (en) * | 2010-02-25 | 2011-09-01 | Shlomo Argoetti | System and method for facility management and operational monitoring and control |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1737755A (en) * | 2005-06-13 | 2006-02-22 | 浙江大学 | Modeling and code generating method of embedded real-time operating system |
| CN100362472C (en) * | 2005-12-06 | 2008-01-16 | 海信集团有限公司 | Method for dynamic guiding of inserted equipment system |
| CN100535870C (en) * | 2006-12-29 | 2009-09-02 | 中兴通讯股份有限公司 | Embedded system progress abnormal tracking position-finding method |
| CN101593116A (en) * | 2008-05-26 | 2009-12-02 | 北京摩软科技有限公司 | A kind of loading method, portable terminal that is applied to embedded real-time operating system |
| CN101510160B (en) * | 2009-03-26 | 2013-10-16 | 北京中星微电子有限公司 | Program operation control method of embedded equipment applying function and embedded equipment |
| CN101539883B (en) * | 2009-05-05 | 2011-11-16 | 北京和利时***工程有限公司 | Error tracking method of embedded system and device thereof |
| TWI486877B (en) * | 2013-09-26 | 2015-06-01 | Wistron Corp | Method of firmware upgrade |
| CN104166523B (en) * | 2014-08-08 | 2018-04-20 | 上海新储集成电路有限公司 | A kind of memory and the method for improving computer system loading data rate |
-
2015
- 2015-07-17 CN CN201510420963.1A patent/CN106708542B/en active Active
- 2015-11-16 WO PCT/CN2015/094702 patent/WO2016131313A1/en active Application Filing
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080201604A1 (en) * | 2007-02-20 | 2008-08-21 | Mall Michael G | Kernel Error Recovery Disablement and Shared Recovery Routine Footprint Areas |
| WO2011103652A1 (en) * | 2010-02-25 | 2011-09-01 | Shlomo Argoetti | System and method for facility management and operational monitoring and control |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2016131313A1 (en) | 2016-08-25 |
| CN106708542A (en) | 2017-05-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101551780B (en) | Television and data storage method and device thereof | |
| CN102779072B (en) | Embedded system and dormancy and wake-up method of application process thereof | |
| CN102841674B (en) | Embedded system based on novel memory and hibernation and awakening method for process of embedded system | |
| CN106708542B (en) | Method and device for loading codes of embedded operating system | |
| TW201502764A (en) | Specialized boot path for speeding up resume from sleep state | |
| CN104798058B (en) | Efficient storage/recovery status information method and apparatus during power state transition | |
| WO2016165597A1 (en) | Processing method and device for data storage | |
| CN101840345A (en) | Configuration parameter-identifying method, system and embedded equipment | |
| CN103927145B (en) | System sleeping and awakening method and device based on hybrid memory | |
| CN101552840B (en) | A method to reduce the power consumption of mobile terminals and the mobile terminals | |
| US20140297928A1 (en) | Electronic Circuit for and Method of Executing an Application Program Stored in a One-Time-Programmable (OTP) Memory in a System on Chip (SoC) | |
| US20170364449A1 (en) | Process running method and apparatus | |
| CN103425605A (en) | Solid-state disk power failure protection and quick start method and system | |
| CN109683983B (en) | Method and equipment for generating and loading mirror image file | |
| CN103955389B (en) | System starting method based on PCM | |
| CN115113814B (en) | Neural network model online method and related device | |
| CN105739982B (en) | A kind of method and device of system suspend mode | |
| CN112863582A (en) | Data power failure holding method and device, computer equipment and storage medium | |
| CN103631677B (en) | A kind of method that PLC device power-down data keeps | |
| CN103412829A (en) | Method and device for expanding MCU (Micro-programmed Control Unit) program address space | |
| US11307642B2 (en) | Method for managing power supply state of memory and chip | |
| CN103150191A (en) | Terminal equipment | |
| CN112015258B (en) | Processing system and control method | |
| CN103761118A (en) | Intelligent card and method for deploying applications in same | |
| CN110673956A (en) | Recovery thread creating method and device, computer equipment and storage medium |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |