Starting method and device of embedded system, equipment and medium

Abstract

The invention relates to a starting method, device and equipment of an embedded system and a medium, and the method comprises the steps that when the embedded system is started, a BSP entry address of a BSP driver executable file is jumped, BSP initialization is executed, a driver list is obtained, and serial numbers of all drivers and corresponding driver functions are recorded in the driver list; transmitting a head address of the drive list to an OS entry address of the OS executable file, and executing OS initialization; and the OS receives the initial address of the driving list from the OS entry address, and calls a driving function corresponding to a corresponding serial number in the driving list according to a pre-agreed driving serial number. Thus, through the mode of the drive axle, effective separation of the BSP and the OS is achieved, and the dependency degree between the BSP and the OS is reduced. Due to the fact that independence between the BSP and the OS is enhanced, developers can independently develop and test the BSP and the OS, the whole system does not need to be recompiled after the BSP is modified every time, and debugging cost is reduced.

Description

Technical Field

[0001] The present application relates to the technical field of embedded systems, and in particular to a startup method, device, equipment and medium for an embedded system. Background Art

[0002] In the field of embedded systems, the interaction between the operating system (OS) and the hardware platform mainly depends on the board support package (BSP), which contains the initialization code and device drivers for a specific hardware platform. The traditional way to integrate BSP with OS is to compile the BSP source code into a static library file (usually a .a file), and then link it with the OS source code to generate executable OS binary code, or directly compile the BSP source code together with the OS source code.

[0003] This approach achieves close integration between BSP and OS, but it also brings the following problems:

[0004] First, because the BSP is statically linked to the OS kernel, the two are highly coupled. This means that any modification of the BSP will trigger the recompilation of the entire OS. Even if the modification only involves a part of the BSP, it will affect the whole system, increasing compilation time and reducing development efficiency and flexibility.

[0005] Second, when the OS needs to adapt to BSPs from multiple different manufacturers, the update of each BSP will lead to the recompilation and testing of the entire OS, significantly increasing the complexity and cost of maintenance work.

[0006] Therefore, a method for starting an embedded system with loose coupling between BSP and OS needs to be provided to solve the above technical problems caused by the integration of BSP and OS. Summary of the invention

[0007] In view of the above problems in the prior art, the present application provides a startup method, device, equipment and medium for an embedded system, which realizes the effective separation of BSP and OS by means of a driver bridge, and reduces the dependence between BSP and OS.

[0008] To achieve the above-mentioned purpose, the first aspect of the present application provides a method for starting an embedded system, comprising:

[0009] When the embedded system starts, it jumps to the BSP entry address of the BSP driver executable file, performs BSP initialization, and obtains a driver list, wherein the driver list records the serial number of each driver and the corresponding driver function;

[0010] Passing the first address of the driver list to the OS entry address of the OS executable file, and performing OS initialization;

[0011] The OS receives the first address of the driver list from the OS entry address, and calls the driver function corresponding to the corresponding number in the driver list according to the pre-agreed driver number.

[0012] Thus, in this application, the BSP is no longer directly compiled into the OS, but is connected to the BSP and OS through a driver list, with the first address of the driver list serving as a bridge, so that the BSP and OS no longer need to directly rely on each other's code for compilation and linking, thus achieving decoupling of the two. In other words, the effective separation of the BSP and the OS is achieved through the driver bridge, reducing the dependency between the BSP and the OS. Due to the enhanced independence between the BSP and the OS, developers can develop and test the BSP and the OS independently, without having to recompile the entire system every time the BSP is modified, thus reducing debugging costs and improving development efficiency and flexibility. On the other hand, when the OS needs to adapt to BSPs from multiple different manufacturers, due to the separation of the BSP and the OS, the update of the BSP will not result in the recompilation and testing of the OS, thus reducing the complexity and cost of maintenance work.

[0013] As a possible implementation manner of the first aspect, the driver list is pre-compiled in the BSP driver executable file; and / or,

[0014] The OS executable file pre-defines a global pointer variable and preset parameters for calling a driver function, wherein the preset parameters for calling a driver function include parameters passed to the driver function and parameters returned by the driver function.

[0015] In this way, by pre-compiling the driver list, it can be directly obtained when the embedded system starts, without the need for an additional process to build the driver list. The pre-defined global pointer variable enables the OS to quickly locate the first address of the driver list, avoiding unnecessary search processes. The preset parameters for calling the driver function clarify the input and output formats of the driver function, which is conducive to the subsequent rapid calling of the driver function.

[0016] As a possible implementation of the first aspect, the OS receives the first address of the driver list from the OS entry address, and calls a driver function corresponding to a corresponding serial number in the driver list according to a pre-agreed driver serial number, including:

[0017] The OS receives the first address of the driver list from the OS entry address according to the global pointer variable;

[0018] Determine the corresponding driver function according to the driver sequence number to be called;

[0019] The parameters to be passed to the driving function are passed to the driving function, and the parameters returned by the driving function are received.

[0020] In this way, the OS can flexibly call the required driver functions according to actual needs without having to understand the specific implementation details of the driver, thereby simplifying the process of OS calling the driver functions.

[0021] As a possible implementation manner of the first aspect, when the MMU is enabled, the driver function address is a virtual address mapped to the physical address of the driver function.

[0022] In this way, when the MMU is enabled, by mapping the addresses used in all BSP drivers (including driver function addresses and peripheral register addresses, etc.) to virtual addresses, it can be ensured that the BSP driver can fully and correctly access these hardware resources, thereby exerting its full functionality. In other words, enabling the MMU and reasonably mapping addresses are important measures to ensure stable system operation and efficient resource management.

[0023] As a possible implementation of the first aspect, the performing BSP initialization includes: running a BSP driver executable file stored at a BSP entry address as a start address;

[0024] The performing of OS initialization includes: running an OS executable file stored at an OS entry address as a starting address from the OS entry address.

[0025] In this way, by storing the BSP and OS as independent executable files (i.e., binary files) and executing them from their respective entry addresses, the BSP and OS can be updated and maintained independently. When the OS needs to be upgraded or replaced, only the OS entry address and the related OS executable files need to be modified without making major changes to the BSP; similarly, when the hardware platform changes, the BSP entry address and the BSP driver executable file can be modified to adapt to the new hardware environment.

[0026] To achieve the above-mentioned object, the second aspect of the present application provides a startup device for an embedded system, wherein the embedded system has a BSP driver executable file and an OS executable file solidified at different addresses, including:

[0027] A first execution unit, configured to jump to the BSP entry address of the BSP driver executable file when the embedded system is started, perform BSP initialization, and obtain a driver list, wherein the driver list records the serial number of each driver and the corresponding driver function;

[0028] A second execution unit, configured to transfer the first address of the driver list to the OS entry address of the OS executable file and perform OS initialization;

[0029] The calling unit is used for the OS to receive the first address of the driver list from the OS entry address, and to call the driver function corresponding to the corresponding serial number in the driver list according to the pre-agreed driver serial number.

[0030] As a possible implementation manner of the second aspect, the driver list is pre-compiled in the BSP driver executable file; and / or,

[0031] The OS executable file pre-defines a global pointer variable and preset parameters for calling a driver function, wherein the preset parameters for calling a driver function include parameters passed to the driver function and parameters returned by the driver function.

[0032] As a possible implementation manner of the second aspect, the calling unit is configured to:

[0033] The OS receives the first address of the driver list from the OS entry address according to the global pointer variable;

[0034] Determine the corresponding driver function according to the driver sequence number to be called;

[0035] The parameters to be passed to the driving function are passed to the driving function, and the parameters returned by the driving function are received.

[0036] To achieve the above object, the third aspect of the present application provides a computing device, including:

[0037] processor, and

[0038] A memory having program instructions stored thereon, wherein when the program instructions are executed by the processor, the processor executes the startup method described in any one of the first aspects above.

[0039] To achieve the above-mentioned purpose, the fourth aspect of the present application provides a computer-readable storage medium having program instructions stored thereon, and when the program instructions are executed by a computer, the computer implements the startup method described in any one of the above-mentioned first aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0041] Figure 1 This is a flow chart of the main steps of a startup method of an embedded system provided by the present application;

[0042] Figure 2 It is a schematic diagram of the interaction between the BSP and the OS provided by this application;

[0043] Figure 3 It is a structural schematic diagram of a startup device of an embedded system provided by the present application;

[0044] Figure 4 It is a structural schematic diagram of a computing device provided by the present application. DETAILED DESCRIPTION

[0045] The technical solution provided by the present application is further described below with reference to the accompanying drawings and examples. It should be understood that the system structure and business scenarios provided in the examples of the present application are mainly to illustrate the possible implementation methods of the technical solution of the present application and should not be interpreted as the only limitation on the technical solution of the present application. It is known to those of ordinary skill in the art that with the evolution of the system structure and the emergence of new business scenarios, the technical solution provided by the present application is also applicable to similar technical problems.

[0046] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art of the present application. In case of any inconsistency, the meaning described in this specification or the meaning derived from the contents recorded in this specification shall prevail. In addition, the terms used herein are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.

[0047] MMU (Memory Management Unit) is a type of computer hardware responsible for processing memory access requests from the central processing unit (CPU).

[0048] The embodiment of the present application provides a method for starting an embedded system, wherein the embedded system has a BSP driver executable file and an OS executable file solidified at different addresses, such as Figure 1 As shown, including:

[0049] S101, when the embedded system starts, jumps to the BSP entry address of the BSP driver executable file, performs BSP initialization, and obtains a driver list, wherein the driver list records the serial number of each driver and the corresponding driver function;

[0050] S102, transferring the first address of the driver list to the OS entry address of the OS executable file, and performing OS initialization;

[0051] S103, the OS receives the first address of the driver list from the OS entry address, and calls the driver function corresponding to the corresponding number in the driver list according to the pre-agreed driver number.

[0052] Thus, in this application, the BSP is no longer directly compiled into the OS, but is connected to the BSP and OS through a driver list, with the first address of the driver list serving as a bridge, so that the BSP and OS no longer need to directly rely on each other's code for compilation and linking, thus achieving decoupling of the two. In other words, the effective separation of the BSP and the OS is achieved through the driver bridge, reducing the dependency between the BSP and the OS. Due to the enhanced independence between the BSP and the OS, developers can develop and test the BSP and the OS independently, without having to recompile the entire system every time the BSP is modified, thus reducing debugging costs and improving development efficiency and flexibility. On the other hand, when the OS needs to adapt to BSPs from multiple different manufacturers, due to the separation of the BSP and the OS, the update of the BSP will not result in the recompilation and testing of the OS, thus reducing the complexity and cost of maintenance work.

[0053] In some embodiments, the driver list is pre-compiled in the BSP driver executable file; and / or,

[0054] The OS executable file pre-defines a global pointer variable and preset parameters for calling a driver function, wherein the preset parameters for calling a driver function include parameters passed to the driver function and parameters returned by the driver function.

[0055] In this way, by pre-compiling the driver list, it can be directly obtained when the embedded system starts, without the need for an additional process to build the driver list. The pre-defined global pointer variable enables the OS to quickly locate the first address of the driver list, avoiding unnecessary search processes. The preset parameters for calling the driver function clarify the input and output formats of the driver function, which is conducive to the subsequent rapid calling of the driver function.

[0056] In some embodiments, the OS receives the first address of the driver list from the OS entry address, and calls the driver function corresponding to the corresponding number in the driver list according to the pre-agreed driver number, including:

[0057] The OS receives the first address of the driver list from the OS entry address according to the global pointer variable;

[0058] Determine the corresponding driver function according to the driver sequence number to be called;

[0059] The parameters to be passed to the driving function are passed to the driving function, and the parameters returned by the driving function are received.

[0060] In this way, the OS can flexibly call the required driver functions according to actual needs without having to understand the specific implementation details of the driver, thereby simplifying the process of OS calling the driver functions.

[0061] The specific description is as follows.

[0062] Among them, driver numbers 0 to 9 in the driver list are assigned to the display driver function, driver numbers 10 to 19 are assigned to the audio driver function, and driver number 20 is assigned to the serial port initialization driver function.

[0063] Example 1: When the OS needs to call the display driver function, it can perform the following steps:

[0064] Step 1: Determine the driver number to be called, that is, 0 to 9, because the display driver functions are assigned numbers 0 to 9.

[0065] Step 2: Determine the parameters to be passed to the display driver function, such as the address of the image buffer and the position coordinates of the update area.

[0066] Step 3: After receiving these parameters, the display driver function will parse them and update the image at the specified position on the screen.

[0067] Step 4: After completion, the display driver function returns a parameter to the OS, which indicates the success or failure status so that the OS knows whether further action is required.

[0068] In some embodiments, when the MMU is enabled, the driver function address is a virtual address mapped to the physical address of the driver function.

[0069] Specifically, the MMU can implement the mapping of virtual addresses to physical addresses through page tables, where a page table is a special data structure that stores the one-to-one correspondence between virtual addresses and physical addresses. When the CPU accesses a virtual address, the MMU will automatically look up the page table and convert the virtual address into the corresponding physical address, and then the CPU will access the memory or external device based on the physical address.

[0070] In this way, when the MMU is enabled, by mapping the addresses used in all BSP drivers (including driver function addresses and peripheral register addresses, etc.) to virtual addresses, it can be ensured that the BSP driver can fully and correctly access these hardware resources, thereby exerting its full functionality. In other words, enabling the MMU and reasonably mapping addresses are important measures to ensure stable system operation and efficient resource management.

[0071] It is worth noting that when the MMU is enabled, the access rights of these mappings are set according to the mapping between the virtual address and the physical address, for example, but not limited to, being set to readable, writable, non-cacheable or readable, writable, write-back, cacheable.

[0072] In some embodiments, the performing BSP initialization includes: running a BSP driver executable file stored at a BSP entry address as a start address;

[0073] The performing of OS initialization includes: running an OS executable file stored at an OS entry address as a starting address from the OS entry address.

[0074] Specifically, BSP initialization starts running the BSP driver executable file from the BSP entry address. This process mainly includes the initialization of hardware devices, such as CPU, memory, peripherals, etc. This ensures that the hardware is in a known and stable state before the OS takes over, providing the necessary underlying support for the operation of the OS.

[0075] OS initialization starts running the OS executable file from the OS entry address, indicating the official startup of the OS. This process mainly includes the OS taking over hardware resources and starting to perform its scheduled tasks, such as memory management, process scheduling, device drivers, etc.

[0076] In this way, by storing the BSP and OS as independent executable files (i.e., binary files) and executing them from their respective entry addresses, the BSP and OS can be updated and maintained independently. When the OS needs to be upgraded or replaced, only the OS entry address and the related OS executable files need to be modified without making major changes to the BSP; similarly, when the hardware platform changes, the BSP entry address and the BSP driver executable file can be modified to adapt to the new hardware environment.

[0077] In some embodiments, the BSP driver executable file also includes a driver entity. The driver entity is a bridge between the embedded system and the hardware device. Without these driver entities, the embedded system cannot directly control the hardware device. For example, if it is necessary to print characters through the serial port, if there is no serial port driver, the software in the embedded system cannot directly interact with the serial port hardware to send data. Through the serial port driver provided by the BSP driver executable file, the software can indirectly send serial port data through the driver.

[0078] In order to more clearly illustrate the above method, the present application provides two specific embodiments.

[0079] Embodiment 1:

[0080] like Figure 2As shown, an embodiment of the interaction between BSP and OS through a drive bridge is shown.

[0081] The length of the driver list is 100, where driver numbers 0-9 correspond to xx driver functions (eg, general hardware initialization driver functions), driver numbers 10-19 correspond to xx driver functions (eg, communication interface driver functions), and driver number 20 corresponds to the serial port initialization driver function.

[0082] Step 1: BSP passes the first address of the driver list to the entry address of the OS executable file;

[0083] Step 2: OS receives the first address of the driver list according to the global pointer variable g_bspDevBridge;

[0084] Step 3: Preset parameters for calling the driver function are predefined in the OS executable file, wherein the preset parameters for calling the driver function include parameters passed to the driver function and parameters returned by the driver function;

[0085] Specifically, the preset parameter for calling the driver function can be a function type named T_RS_Init, which requires two input parameters (such as channel number p1 and baud rate p2) and returns an unsigned integer data. In other words, the T_RS_Init function type includes two parameters passed to the driver function (such as channel number p1 and baud rate p2) and a parameter returned by the driver function (such as an unsigned integer data).

[0086] In addition, the return value can determine the execution status of the function, such as success or failure.

[0087] Step 4: OS calls the serial port initialization driver function according to the driver serial number 20 corresponding to the serial port initialization driver function that needs to be called, as well as the channel number p1 and the baud rate p2.

[0088] The calling example is as follows: ((T_RS_Init)g_bspDevBridge

[20] )(p1,p2).

[0089] Among them, g_bspDevBridge

[20] can be understood as: accessing the driver function corresponding to the serial number 20 in the driver list, that is, the serial port initialization driver function, through the pointer g_bspDevBridge (which points to the first address of the driver list).

[0090] (T_RS_Init) can be understood as: cast the above address to a function pointer of type T_RS_Init. This is to ensure that the parameters and return types of the function call match the T_RS_Init type.

[0091] (p1, p2) can be understood as: calling the converted function pointer and passing the channel number p1 and baud rate p2 as parameters.

[0092] Embodiment 2:

[0093] This embodiment is described by taking the BSP entry address of 0x800000 and the OS entry address of 0xa00000 as an example.

[0094] Before the embedded system is started, the BSP and OS are two independent executable programs, namely, the BSP driver executable file and the OS executable file, and the BSP driver executable file and the OS executable file are respectively fixed to the storage locations of the physical addresses 0x800000 and 0xa00000.

[0095] Step 1: When the embedded system starts, it jumps to the BSP entry address, which is 0x800000, and runs the BSP driver executable file from this address;

[0096] Step 2: Get a driver list, which records the serial number of each driver and the corresponding driver function;

[0097] The driver list is as follows:

[0098]

[0099] In the above example, the bspDevList array has 5 elements, and the driver function address of sequence number 0 is NULL, indicating that this position is not used to store the address of any driver function, or the position is reserved for future use;

[0100] The driver function address of sequence number 1 is set to the address of the rs_init function. Assuming that rs_init is the serial port initialization function, when the system starts, the OS can call rs_init through this address to initialize the corresponding hardware;

[0101] The driver function address of sequence number 2 is set to the address of the rs_read function, which is used to read data from the serial port;

[0102] The driver function address of sequence number 3 is set to the address of the rs_write function, which is used to write data to the serial port;

[0103] The rest of the driver list may contain more similar driver function addresses, each corresponding to a specific hardware operation or function.

[0104] Step 3: Pass the first address of the driver list to the OS entry address, i.e. 0xa00000, and run the OS executable file from this address;

[0105] The code is as follows:

[0106] (*(void(*)(unsigned int*))(0xa00000))(bspDevList)

[0107] Among them, (*(void(*)(unsigned int*))(0xa00000)) is a type conversion expression, which can be interpreted in several parts:

[0108] 0xa00000: indicates the OS entry address.

[0109] (void(*)(unsigned int*)): is a type conversion of a function pointer. It interprets the address 0xa00000 as a pointer to a function that receives a parameter of type unsigned int* and returns void (i.e., does not return any value).

[0110] (*(...)): This is the dereference operator, which converts a function pointer into the function itself, making it callable like a normal function.

[0111] And, (bspDevList) is the parameter passed to the function when the function is called. It is the first address of the driver list and the parameter type is unsigned int*.

[0112] Combining the above two parts, the purpose of this line of code is to call the function at address 0xa00000 as a function, that is, jump to the OS entry address to run the OS executable file, and pass the first address of the bspDevList array (as an unsigned int* type) as a parameter to the function so that the OS can receive the driver list.

[0113] Step 4: OS receives the first address of the driver list from the OS entry address, i.e., 0xa00000, according to the global pointer variable;

[0114] The code is as follows: unsigned int*g_bspDevBridge=NULL;

[0115] void sys_init(unsigned int*bspDevList)

[0116] {

[0117] g_bspDevBridge=bspDevList;

[0118] …

[0119] }

[0120] Among them, the global pointer variable g_bspDevBridge, which is used to store the first address of the driver list, is initially set to NULL, indicating that it does not point to any valid memory address.

[0121] In addition, a function named sys_init is defined, which receives a pointer bspDevList of type unsigned int* as a parameter. This parameter is expected to be the first address of the driver list passed by BSP to OS. In the function body, g_bspDevBridge is assigned to bspDevList. The global pointer g_bspDevBridge points to the first address of the driver list provided by BSP.

[0122] Step 5: The OS defines preset parameters for calling the driver function, wherein the preset parameters for calling the driver function include parameters passed to the driver function and parameters returned by the driver function.

[0123] Among them, there are two parameters passed to the driver function, the first parameter is the channel number, and the second parameter is the baud rate;

[0124] The code is as follows: typedefunsigned int(*T_RS_Init)(unsigned int, unsigned int);

[0125] Among them, typedef is used to define a function pointer type.

[0126] unsigned int is the return type of the function.

[0127] (*T_RS_Init) is the name of the newly defined function pointer type.

[0128] (unsigned int, unsigned int) means that the function receives two parameters, namely the channel number and the baud rate.

[0129] Step 6: OS determines the driver serial number of the driver function type to be called;

[0130] The code is as follows: #define BCALL_BSP_RS_Init(1)

[0131] In the driver function list provided by BSP, the function with call number 1 is the serial port initialization function.

[0132] Step 7: Call the driver function according to the channel number, baud rate and driver serial number.

[0133] The code is as follows:

[0134] unsigned int ret=0

[0135] ret=(T_RS_Init)(g_bspDevBridge[BCALL_BSP_RS_Init])(0,115200)

[0136] The purpose of the above code is to obtain the pointer of driver number 1 (corresponding to the serial communication initialization function) from the g_bspDevBridge array, use the correct function pointer type T_RS_Init for type conversion, and then call the function and pass in channel number 0 and baud rate 115200 as parameters to complete the initialization of the serial port.

[0137] Step 8. After the call is completed, an unsigned integer data is returned.

[0138] The return value can be used to determine the execution status of the function, such as success or failure.

[0139] Figure 3 2 is a structural schematic diagram of a startup device 200 of an embedded system provided in an embodiment of the present application. The embodiment of the present application provides a startup device of an embedded system, wherein the embedded system has BSP driver executable files and OS executable files solidified at different addresses, including:

[0140] The first execution unit 301 is used to jump to the BSP entry address of the BSP driver executable file when the embedded system starts, perform BSP initialization, and obtain a driver list, wherein the driver list records the serial number of each driver and the corresponding driver function;

[0141] The second execution unit 302 is used to transfer the first address of the driver list to the OS entry address of the OS executable file and perform OS initialization;

[0142] The calling unit 303 is used for the OS to receive the first address of the driver list from the OS entry address, and to call the driver function corresponding to the corresponding serial number in the driver list according to the pre-agreed driver serial number.

[0143] In some embodiments, the driver list is pre-compiled in the BSP driver executable file; and / or,

[0144] The OS executable file pre-defines a global pointer variable and preset parameters for calling a driver function, wherein the preset parameters for calling a driver function include parameters passed to the driver function and parameters returned by the driver function.

[0145] In some embodiments, the calling unit 303 is used to:

[0146] The OS receives the first address of the driver list from the OS entry address according to the global pointer variable;

[0147] Determine the corresponding driver function according to the driver sequence number to be called;

[0148] The parameters to be passed to the driving function are passed to the driving function, and the parameters returned by the driving function are received.

[0149] Figure 4 4 is a schematic diagram of a computing device 400 provided in an embodiment of the present application. The computing device executes the above method, such as Figure 4 As shown, the computing device 400 includes: a processor 410 , a memory 420 , and a communication interface 430 .

[0150] It should be understood that Figure 4 The communication interface 430 in the computing device 400 shown may be used to communicate with other devices, and may specifically include one or more transceiver circuits or interface circuits.

[0151] The processor 410 may be connected to a memory 420. The memory 420 may be used to store the program code and data. Therefore, the memory 420 may be a storage unit inside the processor 410, or an external storage unit independent of the processor 410, or a component including a storage unit inside the processor 410 and an external storage unit independent of the processor 410.

[0152] Optionally, the computing device 400 may further include a bus. The memory 420 and the communication interface 430 may be connected to the processor 410 via the bus. The bus may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 A line without an arrow is used to represent the bus, but this does not mean that there is only one bus or one type of bus.

[0153] It should be understood that in the embodiment of the present application, the processor 410 may adopt a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. Alternatively, the processor 410 may adopt one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiment of the present application.

[0154] The memory 420 may include a read-only memory and a random access memory, and provides instructions and data to the processor 410. A portion of the processor 410 may also include a nonvolatile random access memory. For example, the processor 410 may also store information on the device type.

[0155] When the computing device 400 is running, the processor 410 executes the computer-executable instructions in the memory 420 to perform any operation step of the above method and any optional embodiment thereof.

[0156] It should be understood that the computing device 400 according to the embodiment of the present application can correspond to the corresponding subjects in the methods according to the embodiments of the present application, and the above-mentioned and other operations and / or functions of each module in the computing device 400 are respectively for implementing the corresponding processes of each method of the present embodiment, which will not be repeated here for the sake of brevity.

[0157] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0158] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0159] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0160] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0161] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0162] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0163] An embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, it is used to execute the above method, which includes at least one of the solutions described in the above embodiments.

[0164] The computer storage medium of the embodiment of the present application can adopt any combination of one or more computer-readable media. Computer-readable media can be computer-readable signal media or computer-readable storage media. Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or devices, or any combination of the above. More specific examples (non-exhaustive lists) of computer-readable storage media include: electrical connections with one or more wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In this document, computer-readable storage media can be any tangible medium containing or storing programs, which can be used by instruction execution systems, devices or devices or used in combination with them.

[0165] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0166] The program code embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0167] Computer program code for performing the operation of the present application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., using an Internet service provider to connect through the Internet).

[0168] In addition, the words "first, second, third, etc." or module A, module B, module C and other similar terms in the specification and claims are only used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that the specific order or sequence can be interchanged where permitted so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0169] In the above description, the numbers representing the steps, such as S110, S120, etc., do not necessarily mean that the steps will be executed in this manner. If permitted, the order of the steps can be interchanged or they can be executed simultaneously.

[0170] The term "comprising" as used in the description and claims should not be interpreted as being limited to what is listed thereafter; it does not exclude other elements or steps. Therefore, it should be interpreted as specifying the presence of the features, integers, steps or components mentioned, but does not exclude the presence or addition of one or more other features, integers, steps or components and groups thereof. Therefore, the expression "a device comprising means A and B" should not be limited to a device consisting of components A and B only.

[0171] References to "one embodiment" or "an embodiment" in this specification mean that a particular feature, structure, or characteristic described in conjunction with the embodiment is included in at least one embodiment of the present application. Therefore, the phrases "in one embodiment" or "in an embodiment" appearing in various places in this specification do not necessarily refer to the same embodiment, but may refer to the same embodiment. In addition, in one or more embodiments, the particular features, structures, or characteristics can be combined in any appropriate manner, as would be apparent to one of ordinary skill in the art from this disclosure.

[0172] Note that the above are only preferred embodiments of the present application and the technical principles used. Those skilled in the art will understand that the present application is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present application. Therefore, although the present application is described in more detail through the above embodiments, the present application is not limited to the above embodiments, and may also include more other equivalent embodiments without departing from the concept of the present application, all of which belong to the scope of protection of the present application.

Claims

1. A startup method for an embedded system, characterized in that: The embedded system has BSP driver executable files and OS executable files solidified at different addresses, and the method includes: When the embedded system starts, it jumps to the BSP entry address of the BSP driver executable file, performs BSP initialization, and obtains a driver list, wherein the driver list records the serial number of each driver and the corresponding driver function; Passing the first address of the driver list to the OS entry address of the OS executable file, and performing OS initialization; The OS receives the first address of the driver list from the OS entry address, and calls the driver function corresponding to the corresponding number in the driver list according to the pre-agreed driver number.

2. The startup method according to claim 1, characterized in that: The driver list is pre-compiled in the BSP driver executable file; and / or, The OS executable file pre-defines a global pointer variable and preset parameters for calling a driver function, wherein the preset parameters for calling a driver function include parameters passed to the driver function and parameters returned by the driver function.

3. The startup method according to claim 2, characterized in that: The OS receives the first address of the driver list from the OS entry address, and calls the driver function corresponding to the corresponding serial number in the driver list according to the pre-agreed driver serial number, including: The OS receives the first address of the driver list from the OS entry address according to the global pointer variable; Determine the corresponding driver function according to the driver sequence number to be called; The parameters to be passed to the driving function are passed to the driving function, and the parameters returned by the driving function are received.

4. The startup method according to claim 1, characterized in that: When the MMU is enabled, the driver function address is a virtual address mapped to the physical address of the driver function.

5. The startup method according to claim 1, characterized in that: The performing of BSP initialization includes: running a BSP driver executable file stored at a BSP entry address as a start address; The performing of OS initialization includes: running an OS executable file stored at an OS entry address as a starting address from the OS entry address.

6. A startup device for an embedded system, characterized in that: The embedded system has BSP driver executable files and OS executable files fixed at different addresses, including: A first execution unit, configured to jump to the BSP entry address of the BSP driver executable file when the embedded system is started, execute BSP initialization, and obtain a driver list, wherein the driver list records the serial number of each driver and the corresponding driver function; A second execution unit, configured to transfer the first address of the driver list to the OS entry address of the OS executable file and perform OS initialization; The calling unit is used for the OS to receive the first address of the driver list from the OS entry address, and to call the driver function corresponding to the corresponding serial number in the driver list according to the pre-agreed driver serial number.

7. The starting device according to claim 6, characterized in that: The driver list is pre-compiled in the BSP driver executable file; and / or, The OS executable file pre-defines a global pointer variable and preset parameters for calling a driver function, wherein the preset parameters for calling a driver function include parameters passed to the driver function and parameters returned by the driver function.

8. The starting device according to claim 7, characterized in that: The calling unit is used for: The OS receives the first address of the driver list from the OS entry address according to the global pointer variable; Determine the corresponding driver function according to the driver sequence number to be called; The parameters to be passed to the driving function are passed to the driving function, and the parameters returned by the driving function are received.

9. A computing device, characterized in that include: processor, and A memory having program instructions stored thereon, wherein when the program instructions are executed by the processor, the processor executes the startup method according to any one of claims 1 to 5.

10. A computer-readable storage medium, characterized in that: Program instructions are stored thereon, and when the program instructions are executed by a computer, the computer is caused to execute the startup method according to any one of claims 1 to 5.

Images