CN109783145B

CN109783145B - Method for creating multi-image-based multifunctional embedded system

Info

Publication number: CN109783145B
Application number: CN201811548125.2A
Authority: CN
Inventors: 潘润宇
Original assignee: Individual
Current assignee: Individual
Priority date: 2018-12-18
Filing date: 2018-12-18
Publication date: 2022-02-08
Anticipated expiration: 2038-12-18
Also published as: CN109783145A

Abstract

The invention discloses a method for creating a multi-image-based multifunctional embedded system, which is characterized in that a common memory protection unit and a base address-length type memory management unit on small embedded hardware of a single chip microcomputer are allowed to be used, the number of memory segments of an application program module is allowed to exceed the number of memory segments directly supported by the hardware, if the memory layout of the application program is complex, descriptors of a part of memory segments are loaded into a hardware register for protection, and the memory layout is stored by using an app _ mem _ trie data structure. The invention has the advantages that the flexibility and the safety of the system are improved; the query and modification of the deterministic worst execution time are allowed while the storage memory is saved, so that the predictability and the real-time performance of the system are improved; the method and the device can ensure that the access of the real-time memory segment cannot generate memory access abnormity to the maximum extent, ensure the predictability and the real-time performance of the system and have strong practical value and practical significance.

Description

Method for creating multi-image-based multifunctional embedded system

Technical Field

The invention belongs to the technical field of Internet of things and embedded systems, and particularly relates to a method for creating a multi-image-based multifunctional embedded system.

Background

At present, functions of an embedded system are more and more diversified, the requirement of application modular loading becomes more and more common, and the requirements on safety and reliability are increased day by day. The current multifunctional embedded system can not meet the requirement of the modularized loading of the embedded system and can not ensure the safety and the reliability of the whole system.

At present, the conventional existing multifunctional embedded system has the following defects:

(1) the isolation between the kernel mode and the user mode is lacked, the operating system and the application program run in the same address space, and once the application program crashes, the data of the operating system can be damaged.

(2) The lack of isolation between applications can compromise the reliability of the overall system should one of the applications fail.

(3) The information security of the application program is poor, and once any one component is broken, data leakage of the whole system can be caused.

(4) The application deployment is cumbersome, and in a traditional embedded system, the whole system needs to be compiled into a single image, which impairs the flexibility of system deployment and burdens the image assembly burden for users.

(5) The memory organization of the application program is tedious, in some application programs which support kernel-state user states and address space isolation among applications, a system designer needs to explicitly specify the setting of each protection domain of each application program, and because the number and the limitation of the protection domains supported by each hardware are different, when the number of the protection domains used by the application is greater than that of the protection domains provided by the hardware, in order to reduce the number of the protection domains, the memory layout of the application program needs to be manually adjusted to merge some protection domains.

(6) Dynamic memory allocation is difficult to perform, once dynamic memory allocation is performed, a new protection domain may be needed, and when the protection domain that can be provided by hardware is used up, the new memory cannot be accessed by an application program.

(7) The system may have a plurality of memories with different access delay or bandwidth or persistence attributes, it is difficult for the interface of the existing operating system to specify the attributes of the allocated memory, for example, an embedded system may have memories with three attributes of SRAM, DRAM and FRAM at the same time, and an application program wants to specify the allocation of storage space on one of the memories.

Disclosure of Invention

The object of the present invention is to provide a method for creating a multi-image based multifunctional embedded system that can overcome the above technical problems, the method of the present invention comprising the steps of:

step 1, creating an operating system module image, and programming the operating system module image into a system memory or placing the operating system module image into a certain server on a network; the operating system module image sys _ image includes, but is not limited to, a boot file, a base BSP, a binary image of an operating system kernel, and a device tree, and a storage medium storing the operating system module image may be continuous or may be discontinuous.

And 2, creating one or more application program module images, and programming the application program module images into a system memory or placing the application program module images into a server on a network, wherein the application program module images app _ image comprise but are not limited to the binary image of the application program and the memory requirement descriptor app _ mem _ desc of the application program, and the storage medium for storing the application program module images is continuous or can be discontinuous.

And 3, in the system initialization stage, loading an operating system module image from a system memory or a network, initializing the operating system module image, and setting the system to a starting stage.

Step 4, in the system startup phase, the operating system module image loads each application module image from the system memory or the network, and analyzes the app _ mem _ desc, and the loading of sys _ load _ app of one application module image includes the following steps:

step 4.1, analyzing app _ mem _ desc of the application program module image, analyzing the loading virtual address, the actual physical address and the read-write execution authority attribute of each segment of the memory, and the real-time attribute of memory access, wherein the real-time attribute of memory access comprises two types, one is required to be accessed in real time, and the other is not required to be accessed in real time, and the other is called a non-real-time memory segment;

step 4.2, establishing a memory space data structure app _ mem _ trie corresponding to the app _ mem _ desc in the operating system module image, and recording the current address space distribution of the application program module image through the data structure;

step 4.3, generating an address space cache app _ mem _ cache which is corresponding to a hardware register of the application program module image, fills a Memory Protection Unit (Memory Protection Unit) or a Memory Management Unit (Memory Management Unit) based on a base address and a length and is stored in a Management data structure app _ mgmt of the application program module image according to the app _ mem _ trie, and judging which Memory segments are added into the app _ mem _ cache according to a sys _ mem _ cache flow when the number of the Memory segments of the application program module image exceeds the number of slots supported by hardware;

4.4, loading the data section and the code section of the application program module image to finish other related initializations;

the sys _ mem _ chorose in the step 4.3 includes the following steps:

step 4.3.1, finding out all real-time memory segments in the app _ mem _ desc, and preferentially distributing slot positions of the app _ mem _ cache for the real-time memory segments;

step 4.3.2, when the number of the slot positions of the app _ mem _ cache is less than the number of the real-time memory segments in the app _ mem _ desc, the operating system should use all the slot positions of the app _ mem _ cache to meet the requirement of the real-time memory segments;

and 4.3.3, when the slot position of the app _ mem _ cache is left after the real-time memory segment is allocated, allocating each left slot position to the non-real-time memory segment.

And step 5, after the application program module image is loaded, the operating system is switched into a background, each application program is scheduled according to a set scheduling algorithm, more application programs can be dynamically loaded during operation, and the dynamic loading is still executed according to the sys _ load _ app process.

Step 6, the application program module image calls an interface to request more memories (sys _ mem _ add) from the operating system in the running process, and requests to share the memory (sys _ mem _ shared _ add) with some other application program module image, releases the memory (sys _ mem _ rem), or cancels the memory sharing with some application program module image (sys _ mem _ shared _ rem);

the sys _ mem _ shared _ add is equivalent to two or more application program module images which call the sys _ mem _ add at the same time, the same physical address is distributed by an operating system for mapping, and the sys _ mem _ shared _ rem is equivalent to two or more application program module images which call the sys _ mem _ rem at the same time, and the operating system releases the mapping of the corresponding physical memory;

step 6.1, the flow of the sys _ mem _ add operation comprises the following steps:

step 6.1.1, the operating system module image searches a physical memory with matched size and attribute for mapping;

step 6.1.2, under the condition that the application program module image specifies the physical memory, the operating system checks the validity of the address, if the address passes the checking, the operation is carried out according to the step 6.1.3, and if the address does not pass the checking, an error is reported;

step 6.1.3, modifying the content of the app _ mem _ trie, and adding the descriptor corresponding to the physical memory segment into the data structure to reflect the change of the mapping address space of the application program module;

step 6.2, the flow of the sys _ mem _ rem operation comprises the following steps:

step 6.2.1, according to the address provided by the application program module mapping, the operating system module mapping finds a physical memory segment needing to be removed in the app _ mem _ trie;

step 6.2.2, when the address can be found, the operation is carried out according to the step 6.2.3, and if the address does not pass, an error is reported;

step 6.2.3, modify the content of app _ mem _ trie to reflect this change;

step 6.2.4, searching a slot position corresponding to the area in the app _ mem _ cache, and clearing if the slot position is found;

step 6.2.5, if the current operation is the application program module image, the cache entry corresponding to the physical memory segment also needs to be cleared in the hardware register, that is, the app _ mem _ cache is reloaded into the hardware register;

the operating system module image enables application module switching. When the operating system module image switches the application program module image, the context of the execution environment needs to be switched, and the app _ mem _ cache corresponding to the application program module image to be switched is loaded into the hardware register.

Step 7, replacing and updating the memory segment; for some application program modules with a large number of memory segments, the app _ mem _ cache cannot contain all the memory segments at the same time, and when the application program accesses potential memory segments which are not contained, a memory access error exception is generated by hardware. The os module should handle this memory access error exception according to the sys _ mem _ fault flow: the method specifically comprises the following steps:

step 7.1, reading the memory address where the error occurs from the hardware-related register hw _ mmfar, and reading the reason of the memory access error from hw _ mcause;

step 7.2, finding the description corresponding to the address in the app _ mem _ trie corresponding to the current application program module image, and when the descriptor cannot be found or does not contain the access type indicated in the error reason, carrying out error processing according to the real authority, wherein the processing method in the actual application is to terminate the application; when the relevant item is found, continuing to process according to step 7.3;

and 7.3, adding the cache entry corresponding to the memory address where the error occurs into the app _ mem _ cache corresponding to the current application program. Adding the spare position of the app _ mem _ cache on the premise that the app _ mem _ cache has the spare position; preferentially replacing a non-real-time memory segment in the app _ mem _ cache according to a replacement algorithm on the premise that the app _ mem _ cache is full;

and 7.4, loading the updated app _ mem _ cache into a hardware register.

Compared with the traditional multifunctional embedded system, the invention has the advantages that:

(1) the operating system module and the application program module are separated, so that independent compiling is convenient to carry out, differential upgrading of the system is also convenient to carry out, namely, only a part of modules in the system are upgraded, and the flexibility of the system is improved.

(2) The invention allows the use of the common memory protection unit and the base address-length type memory management unit on the small embedded hardware of the singlechip, and the hardware units can provide complete hardware memory protection for the application program, prevent unauthorized access and increase the safety of the system.

(3) The invention allows the memory segment number of the application program module to exceed the memory segment number directly supported by hardware, when the memory layout of the application program is more complex, the descriptor of one part of the memory segment is loaded into the hardware register for protection, and the other part of the memory segment replaces the existing slot position when accessing according to the requirement, thereby phase-changing and amplifying the number of the hardware register, and increasing the universality of the application program module among different hardware.

(4) The invention uses the app _ mem _ trie data structure to store the memory layout, saves the storage memory, allows the query and modification of the deterministic worst execution time, and increases the predictability and the real-time performance of the system.

(5) The app _ mem _ cache data structure used by the present invention provides a shadow copy of the hardware register contents, i.e., cache, which is directly loaded into the hardware register when switching application program modules. Compared with the method that a hardware register is directly used as a cache, the query of the app _ mem _ trie is reduced to the maximum extent, and the predictability and the real-time performance of the system are increased.

(6) The sys _ mem _ fault flow provided by the invention can flexibly schedule the hardware register and simultaneously prevent the real-time memory segment from being replaced to the maximum extent, so that the access exception of the real-time memory segment can not be generated during the access, the predictability and the real-time performance of the system are ensured, and the sys _ mem _ fault flow has strong practical value and practical significance.

(7) The invention uses an abstract interface to uniformly manage the memories with all attributes, allows the application program to map the memories with different attributes into the accessible address space range, and carries out wide authority check in the mapping and accessing processes, thereby increasing the safety and flexibility of the system.

Drawings

FIG. 1 is a schematic diagram of the embedded system workflow of the method of the present invention;

FIG. 2 is a schematic diagram illustrating an operating system module image sys _ image according to the method of the present invention;

FIG. 3 is a schematic diagram illustrating an application module image app _ image according to the method of the present invention;

FIG. 4 is a schematic diagram illustrating a specific structure of the application module management data structure app _ mgmt according to the method of the present invention;

FIG. 5 is a schematic diagram illustrating a specific structure of the memory descriptor app _ mem _ desc of the application module according to the method of the present invention;

FIG. 6 is a schematic diagram of a specific structure of the memory space data structure app _ mem _ trie according to the method of the present invention;

FIG. 7 is a schematic diagram of a specific structure of the address space cache app _ mem _ cache according to the method of the present invention;

FIG. 8 is a schematic flow chart of the memory selection flow sys _ mem _ choose according to the method of the present invention;

FIG. 9 is a schematic flow chart of the memory addition flow sys _ mem _ add according to the method of the present invention;

FIG. 10 is a flow chart illustrating a memory reduction process sys _ mem _ rem according to the method of the present invention;

FIG. 11 is a flow chart of the access exception handling process sys _ mem _ fault according to the method of the present invention;

FIG. 12 is a diagram illustrating a specific structure of a hardware access error address register hw _ mmfar according to the method of the present invention;

FIG. 13 is a specific structural illustration of a hardware access memory error cause register hw _ mcause to which the method of the present invention relates;

FIG. 14A is a schematic diagram of an embedded system of embodiment 1 of the method of the present invention;

FIG. 14B is a schematic flow chart showing the implementation of embodiment 1 of the method of the present invention;

FIG. 15A is a schematic diagram of an embedded system of embodiment 2 of the method of the present invention;

FIG. 15B is a schematic flow chart showing the implementation of embodiment 2 of the method of the present invention;

FIG. 16A is a diagram illustrating an initial memory layout of an embedded system according to embodiment 3 of the method of the present invention;

fig. 16B is a schematic diagram of a memory layout after one-time memory allocation of the embedded system according to embodiment 3 of the method of the present invention;

fig. 16C is a schematic diagram of the layout of the embedded system after secondary memory allocation according to embodiment 3 of the method of the present invention;

fig. 16D is a schematic diagram of a memory layout after three times of memory allocation of the embedded system according to embodiment 3 of the method of the present invention;

fig. 16E is a schematic flow chart of the implementation of embodiment 3 of the method of the present invention.

Detailed Description

Embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Based on the embodiments of the present invention, all other embodiments obtained by a person of ordinary skill in the art without any creative effort belong to the protection scope of the present invention, and it should be noted that "or" in this specification is only a connection word indicating a logical association, and indicates that there are three relationships, for example, "a or B" indicates that a exists alone, B exists alone, and a and B exist in three conditions simultaneously.

In practical applications, the hardware of an embedded system includes a CPU, a memory and various peripherals, wherein the software portion can include an operating system module and an application program module.

The operating system module image is preferentially loaded after being electrified, and the application program module image can be sequentially loaded through a network or a memory, the application program module image is divided into three types, and the first type is a driver module and is used for driving various hardware peripherals; the second type is a service program module used for providing services for other application program module images; the third type is a utility module for running other parts that implement the overall functionality of the system.

Each application module image presents a series of memory requests to the operating system that include access to private memory, which refers to memory that can only be accessed by one application module image, or shared memory, which refers to memory that can be accessed by multiple application module images.

The operating system is responsible for satisfying the memory protection requests of a single application program module image using a limited hardware protection domain, and whether the memory segment needs to be accessed in real time is considered when selecting the region filled in the hardware protection domain.

The operating system can also schedule the application program according to a certain scheduling strategy, and the content of the hardware protection domain is also replaced to be the protection domain content of the current application program during scheduling.

The preferred method of carrying out the method of the present invention is described in detail below with reference to the accompanying drawings.

Example 1; see fig. 14A and 14B for illustration:

referring to fig. 1, 2 and 3, the embedded system 100 includes an operating system module image 110 and two application module images 120 and 130, both stored within a system memory 140.

The present embedded system 100 performs hardware memory protection using a memory protection unit 150, which has 2 protection area register sets 151 and 152.

Referring to fig. 5, the application module 120 includes 2 non-real-time memory segments 121 and 122, and the application module 130 includes 1 real-time memory segment 131 and 2 non-real-time memory segments 132 and 133.

Step 500: the embedded system starts up and reads the operating system module image 110 from the system memory 140, forms the operating system module 160 in the memory, and jumps to its entry point to start execution;

step 510: operating system module 160 reads application module image 120 from within system memory 140;

step 520: operating system module 160 loads application module image 120 into memory, forming application module 170 in memory;

step 530: the operating system module 160 scans the app _ mem _ desc segment in the file header of the application module image 120, finds that it has 2 non-real-time memory segments 121 and 122, and establishes a descriptor 171, 171 of the application module 170 in the system with reference to fig. 4, where the descriptor 171 includes the cache 172 shown in fig. 7 and the memory space data structure 173 shown in fig. 6;

step 540: the operating system module 160 adds the descriptions of the memory segments 121 and 122 to the memory space data structure 173 and generates the corresponding cache 172 according to the data structure 173 and the sys _ mem _ cache flow shown in fig. 8. Since the application module 170 only has two memory segments, after the process shown in fig. 8, descriptors of the two memory segments can be placed in the cache 172 at the same time;

step 550: operating system module 160 reads application image 130 from within system memory 140;

step 560: operating system module 160 loads application module image 130 into memory, forming application module 180 in memory;

step 570: the app _ mem _ desc segment in the file header of the application module image 130 of the operating system module 160 is found to have 1 real-time memory segment 131 and 2 non-real-time memory segments 132 and 133, and a descriptor 181 of the application module 180 is established in the system with reference to fig. 4, where the descriptor 181 includes the cache 182 shown in fig. 7 and the memory space data structure 183 shown in fig. 6;

step 580: the os module 160 adds the descriptions of the real-time memory segment 131 and the non-real-time memory segment 132 to the memory space data structure 183, and generates the corresponding cache 182 according to the data structure 183 and the sys _ mem _ cache flow shown in fig. 8. Since the application module 180 has three memory segments, and the cache 182 can only store descriptors of two memory segments at the same time, after the process shown in fig. 8, we select the real-time memory segment 131 and the non-real-time memory segment 132, and the non-real-time memory segment 133 is not added for the time being;

step 590: the os module 160 loads the contents of the cache 172 into the memory protection unit 150, specifically, loads the descriptor of the memory segment 121 into the protection region register set 151, and loads the descriptor of the memory segment 122 into the protection region register set 152. Jump to the entry point of the application module 170 to begin execution;

step 600: the operating system module 160 switches to the application module 180 and loads the contents of the cache 182 into the memory protection unit 150, specifically, loads the descriptor of the memory segment 131 into the protection area register set 151 and loads the descriptor of the memory segment 132 into the protection area register set 152. Jump to the entry point of the application module 180 to begin execution;

step 610: in the operation process of the application module 180, accessing the non-real-time memory segment 133 and generating an access exception, referring to fig. 11, the operating system module 160 reads the register hw _ mmfar shown in fig. 12 to obtain the address of the access exception, then reads hw _ mcause shown in fig. 13 to confirm the type of the access exception, and selects the non-real-time memory segment 132 to be replaced by using the flow sys _ mem _ fault shown in fig. 11, updates the content of the cache 182, adds the descriptor of the non-real-time memory segment 133 to remove the descriptor of the non-real-time memory segment 132, and reloads the content of the cache 182 into the memory protection unit 150 to allow the access to the non-real-time memory segment 133;

in this embodiment, the memory protection unit 150 only provides two sets of registers, and for any application program, only two memory segments can be allowed to be accessed simultaneously, the present invention creatively designs a sys _ mem _ fault processing flow, and when a memory access error occurs, replaces the descriptor of the existing non-real-time memory in the app _ mem _ cache with the descriptor of the memory segment which is actually allowed to be accessed by the application program and has the error in time, and writes the descriptor into the hardware register.

This procedure increases the number of segments of the hardware registers and increases the flexibility of the memory layout of the application.

The order of the above-described flow is not absolute, and when there is no interdependence between the two steps, it is allowed to exchange the order arbitrarily.

Example 2; see fig. 15A and 15B for illustration:

referring to fig. 1, 2 and 3, the embedded system 200 does not include any image, and the system memory 210 is empty or has only the basic file system 220.

The main board of the embedded system 200 has a network port 230, and the image can be downloaded through the network port 230.

Hardware memory protection is performed using a base-length based memory management unit 240, the memory management unit 240 having 4 protection area register sets 241-244.

Referring to fig. 5, the application module 250 includes 4 non-real-time memory segments 251 and 254, and the application module 260 includes 2 real-time memory segments 261 and 262 and 2 non-real-time memory segments 263 and 264.

Step 700: the embedded system starts and reads the operating system module image 270 through the network port 230, forms the operating system module 280 in the memory, and jumps to the entry point to start execution;

step 710: operating system module 280 reads application module image 250 from network port 230;

step 720: operating system module 280 loads application module image 250 into memory, forming application module 290 in memory;

step 730: the operating system module 280 scans the app _ mem _ desc segment in the file header of the application module image 250, finds that it has 4 non-real-time memory segments 251-;

step 740: the operating system module 280 adds the descriptions of the memory segments 251 and 254 to the memory space data structure 293, generates the corresponding cache 292 according to the data structure 293 and the sys _ mem _ cache flow shown in fig. 8, and loads all the descriptors into the cache 302;

step 750: the operating system module 280 reads the application image 260 through the network port 230;

step 760: the operating system module 280 loads the application module image 260 into memory, forming an application module 300 in memory;

step 770: the operating system module 280 finds that the app _ mem _ desc segment in the file header of the application module image 260 has 2 real-time memory segments 261 and 262 and 2 non-real-time memory segments 263 and 264, and establishes a descriptor 301 of the application module 300 in the system with reference to fig. 4, where the descriptor 301 includes the cache 302 shown in fig. 7 and the memory space data structure 303 shown in fig. 6;

step 780: the operating system module 280 adds the descriptions of the real-time memory segments 261 and 262 and the non-real-time memory segments 263 and 264 to the memory space data structure 303, generates a corresponding cache 302 according to the data structure 303 and the sys _ mem _ cache flow shown in fig. 8, and loads all descriptors into the cache 302;

step 790: the os module 280 loads the contents in the cache 292 into the memory management unit 240, jumps to the entry point of the application module 290, and starts execution;

step 800: the application module 290 calls the sys _ mem _ shared _ add during execution to request an addition of a shared real-time memory segment 310, which is required to be shared between itself 290 and the application module 300, and the operating system module 280 responds to the request;

step 810: the os module 280 checks the permissions of the shared real-time memory segment 310, and finds that the real-time memory segment 310 is mapped to the space of the application modules 290 and 300, that is, the shared real-time memory segment 310 is added to the data structures 293 and 303;

in the following execution process, once the application program module 290 or 300 accesses the shared real-time memory segment 310, an access exception is generated, so that the register hw _ mmfar shown in fig. 12 is read to obtain the address of the access exception, then the hw _ mcause shown in fig. 13 is read to confirm the type of the access exception, and the memory segment 310 is added to its own cache app _ mem _ cache through the flow sys _ mem _ fault shown in fig. 11 and updated to the hardware register.

Due to the design of the sys _ mem _ fault processing flow, the memory segment 310 can never be evicted from the cache app _ mem _ cache in the subsequent access, any access exception can not be generated for the access, and the access real-time performance is ensured.

It can be known from the above embodiments that the method of the present invention can allow a memory segment to be dynamically added or deleted when a program runs, and if the memory segment is to be deleted, the description of the memory segment is removed from the corresponding app _ mem _ cache and app _ mem _ trie by calling the sys _ mem _ rem interface described in fig. 10, so that the application program has the capability of dynamically applying and releasing the memory, and all the memory segments have hardware protection from beginning to end, which cannot be realized on a conventional single-chip embedded system.

The order of the above steps of the method of the present invention is not absolute, and when there is no interdependence between the two steps, the two steps can be allowed to exchange the order with each other arbitrarily.

Example 3; see fig. 16A, 16B, 16C, 16D and 16E for illustration: the embedded system 900 includes three types of system memory: static random access memory 910, dynamic random access memory 920, and ferroelectric memory 930.

The embedded system 900 has completed the power-on loading operation, and the static random access memory has an operating system module 940 and an application program module 950 therein, and the memory layout of the system is shown in fig. 16A, in which system components not directly related to the system components have been omitted.

Step 990: the application module 950 requests a memory region with low latency and high bandwidth by calling the sys _ mem _ add interface;

step 991: the os module 940 checks the permission of the application module 950, confirms that it has the capability of applying for the memory, and allocates a memory block 960 to the application module 950, where the memory block 960 is located in the sram 910, and the memory layout of the system is as shown in fig. 16B;

step 992: the application module 950 requests a larger memory area with higher latency and lower bandwidth by calling the sys _ mem _ add interface shown in fig. 9;

step 993: the os module 940 checks the permission of the application module 950, confirms that it has the capability of applying for the memory, and allocates a memory block 970 to which the application module 950 is allowed to access, where the memory block 970 is located in the sram 920, and the memory layout of the system is as shown in fig. 16C;

step 994: the application module 950 requests a request for a memory area that can be persisted after power-off by calling the sys _ mem _ add interface shown in fig. 9;

step 995: the os module 940 checks the authority of the application module 950, confirms that it has the capability of applying for the memory, and allocates the memory block 980 to the application module 950, where the memory block 980 is located in the sram 930, and the memory layout of the system is shown in fig. 16D;

it can be seen from the embodiments that the present invention allows dynamic allocation of memory segments with different attributes during program running, which greatly improves the flexibility of using different types of memories in the system and the flexibility of writing application programs, and the sys _ mem _ add interface shown in fig. 9 does not directly operate the underlying data structure maintained by the operating system module or the underlying hardware of the embedded system, which is easy to use.

The above description is only for the specific embodiment of the present invention, but the scope of the present invention is not limited thereto, and any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the present disclosure should be covered within the scope of the present invention claimed in the appended claims.

Claims

1. A method of creating a multi-image based multifunction embedded system, comprising the steps of:

step 1, creating an operating system module image, and programming the operating system module image into a system memory or placing the operating system module image into a certain server on a network; the operating system module image sys _ image comprises a boot file, a board level support package (BSP), a binary image of an operating system kernel and a device tree, and a storage medium for storing the operating system module image can be continuous or discontinuous;

step 2, creating one or more application program module images, and programming the application program module images into a system memory or placing the application program module images into a certain server on a network, wherein the application program module image app _ image comprises an application program binary image and an application program memory requirement descriptor app _ mem _ desc, and a storage medium for storing the application program module images is continuous or can be discontinuous;

step 3, in the system initialization stage, loading an operating system module image from a system memory or a network, initializing the operating system module image, and setting the system to a starting stage;

step 4, in the system starting stage, loading each application program module image from a system memory or a network by the operating system module image, and analyzing the app _ mem _ desc; loading a sys _ load _ app of an application module image includes the steps of:

step 4.3, generating an address space cache app _ mem _ cache which corresponds to the application program module image, fills a hardware register of a memory protection unit or a base address-length-based memory management unit and is stored in a management data structure app _ mgmt of the application program module image according to the app _ mem _ trie, and when the number of memory segments of the application program module image exceeds the number of slots supported by hardware, judging which memory segments are added into the address space cache app _ mem _ cache according to a memory selection flow sys _ mem _ cache; the memory selection flow sys _ mem _ choose comprises the following steps:

step 4.3.1, finding out all real-time memory segments in app _ mem _ desc, and preferentially allocating slot positions of address space cache for the real-time memory segments;

step 4.3.2, when the number of the slot positions cached in the address space is less than the number of the real-time memory segments in the memory descriptor of the application program module, the operating system should use the address space to cache all the slot positions to meet the real-time memory segments;

4.3.3, after the slot positions cached in the address space are distributed to the real-time memory segment, remaining slot positions are distributed to the non-real-time memory segment;

step 5, after the application program module image is loaded, the operating system is switched into a background, each application program is scheduled according to a set scheduling algorithm, more application program module images can be dynamically loaded in operation, and the application program module images are still loaded according to the process sys _ load _ app for loading one application program module image;

step 6, calling an interface to request more memories from an operating system by the application program module image in the running process, requiring memory sharing with some other application program module image, releasing the memories, or canceling memory sharing with some application program module image;

the sys _ mem _ shared _ add is equivalent to two or more application program module images which simultaneously call the memory increasing flow sys _ mem _ add and the same physical address is allocated by the operating system for mapping, and the sys _ mem _ shared _ rem is equivalent to two or more application program module images which simultaneously call the memory decreasing flow sys _ mem _ rem and the operating system releases the mapping of the corresponding physical memory; the memory increment flow sys _ mem _ add and the memory decrement flow sys _ mem _ rem include the following steps:

step 6.1, adding a flow of sys _ mem _ add operation to the memory; the method comprises the following steps:

step 6.1.3, modifying the content of the memory space data structure app _ mem _ trie, and adding the descriptor corresponding to the physical memory segment into the data structure to reflect the change of the mapping address space of the application program module;

step 6.2, reducing the flow of the operation sys _ mem _ rem in the memory; the method comprises the following steps:

step 6.2.1, according to the address provided by the application program module mapping, the operating system module mapping finds a physical memory segment needing to be removed in a memory space data structure app _ mem _ trie;

step 6.2.3, modifying the content of the memory space data structure app _ mem _ trie to reflect the change;

step 6.2.4, searching a slot position corresponding to the area in the address space cache app _ mem _ cache, and clearing if the slot position is found;

step 6.2.5, if the currently running application program module is mapped, the cache entry corresponding to the physical memory segment also needs to be cleared in the hardware register, that is, the address space cache app _ mem _ cache is reloaded into the hardware register;

the operating system module image enables application module switching; when the mapping of the application program module is switched by the mapping of the operating system module, the context of the execution environment needs to be switched, and the address space cache app _ mem _ cache corresponding to the mapping of the application program module to be switched is loaded into a hardware register;

step 7, replacing and updating the memory segment; for some application program modules with more memory segments, the address space cache app _ mem _ cache cannot contain all the memory segments at the same time, and when the application program accesses potential memory segments which are not contained, hardware generates a memory access error exception; the operating system module should process the memory access error exception according to the memory access exception processing flow sys _ mem _ fault; the access exception handling process sys _ mem _ fault comprises the following steps:

step 7.1, reading a memory address with an error from a hardware access memory error address register hw _ mmfar, and reading a reason of the memory access error from a hardware access memory error reason register hw _ mcause;

step 7.2, finding the description corresponding to the address in the memory space data structure app _ mem _ trie corresponding to the current application program module image, and when the descriptor cannot be found or does not contain the access type indicated in the error reason, carrying out error processing according to the real authority, wherein the processing method in the actual application is to terminate the application; when the relevant item is found, continuing to process according to step 7.3;

step 7.3, adding the cache entry corresponding to the memory address where the error occurs into the address space cache app _ mem _ cache corresponding to the current application program; on the premise that the address space cache app _ mem _ cache has a spare position, adding the spare position of the address space cache app _ mem _ cache; preferentially replacing a non-real-time memory segment in the address space cache app _ mem _ cache according to a replacement algorithm on the premise that the address space cache app _ mem _ cache is filled;

and 7.4, loading the updated address space cache app _ mem _ cache into a hardware register.