Starting method and device, electronic equipment and storage medium

Abstract

The embodiment of the application provides a starting method and device of an automobile open system architecture classic platform, electronic equipment and a storage medium, the method comprises the following steps: starting a main core and a slave core in the early stage of starting, and respectively initializing local per-core non-cache static random access memory of the main core and the slave core; at least part of starting processes of hardware modules which can be initialized by the slave core agent are allocated to the slave core for initialization processing; initialization agent products generated by the slave core for initialization processing are transferred from the local per-core non-cache static random access memory of the slave core to the local per-core non-cache static random access memory of the main core; and the time point of transferring the initialization agent products by the slave core is subjected to synchronization processing. The embodiment of the application can realize the fast starting of the automobile open system architecture classic platform, and realize the fast starting of the ECU.

Description

Technical Field

[0001] This application relates to the field of automotive electronics technology, and in particular to a startup method, apparatus, electronic device, and storage medium for a classic automotive open system architecture platform. Background Technology

[0002] The startup and initialization process of the Automotive Open System Architecture Classic Platform (Autosar CP) affects the startup of the Electronic Control Unit (ECU). The rapid startup of the ECU involves powering on, restarting, and waking up from hibernation. This is an important indicator for evaluating the system because it relates to the overall user experience, such as Bluetooth key unlocking and light flashing.

[0003] Therefore, improving the startup speed of classic open system architecture platforms for automobiles has become an urgent technical problem to be solved.

[0004] Application content

[0005] In view of this, embodiments of this application provide a startup method, apparatus, electronic device, and storage medium for a classic automotive open system architecture platform, which enables rapid startup of the classic automotive open system architecture platform and rapid startup of the ECU.

[0006] According to a first aspect of the embodiments of this application, a startup method for a classic platform of automotive open system architecture is provided. The method includes: starting a master core and a slave core in the early startup phase, and initializing the local per-core uncached static random access memory of the master core and the slave core respectively; allocating at least a portion of the startup process of hardware modules that can be initialized by proxy of the slave core to the slave core for initialization processing; transferring the initialization proxy generator generated by the initialization processing of the slave core from the local per-core uncached static random access memory of the slave core to the local per-core uncached static random access memory of the master core; and synchronizing the timing of the transfer of the initialization proxy generator by the slave core.

[0007] In some embodiments of this application, the step of starting the master core and slave core in the early stage of startup and initializing the local per-core uncached static random access memory of the master core and the slave core respectively includes, before: identifying hardware modules that can be initialized by proxy of the slave core. The hardware modules that can be initialized by proxy of the slave core are modules whose initialization process does not depend on other modules and whose initialization does not involve resources strongly bound to the master core or any of the slave cores.

[0008] In some embodiments of this application, the step of allocating at least a portion of the startup process of the hardware module that can be initialized by the slave core agent to the slave core for initialization processing includes: recording the starting address of the initialization agent generator generated by the initialization processing of the slave core in the local per-core non-cached static random access memory of the slave core and the storage length of the initialization agent generator.

[0009] In some embodiments of this application, the step of transferring the initialization proxy generator generated by the initialization process of the slave core from the local per-core non-cached static random access memory of the slave core to the local per-core non-cached static random access memory of the master core further includes: after transferring the initialization proxy generator to the local per-core non-cached static random access memory of the master core, reclaiming and reusing the storage space from the starting address of the local per-core non-cached static random access memory of the slave core where the initialization proxy generator is located to the length of the storage of the initialization proxy generator.

[0010] In some embodiments of this application, the step of transferring the initialization proxy generated by the initialization process of the slave core from the local per-core non-cached static random access memory of the slave core to the local per-core non-cached static random access memory of the master core includes: if the chip where the master core is located supports global addresses, the master core directly accesses the local per-core non-cached static random access memory of the slave core to obtain the initialization proxy generated; otherwise, the master core accesses the local per-core non-cached static random access memory of the slave core through non-cached global content as an intermediate storage medium to obtain the initialization proxy generated.

[0011] In some embodiments of this application, the synchronization processing of the timing of the transfer of the initialization agent generator by the slave core includes: if the slave core does not transfer the initialization agent generator to the master core, the master core performs busy waiting through the inter-core synchronization mechanism until it receives the initialization agent generator transferred by the slave core, and the master core executes other actions in the action list; if the slave core does not transfer the initialization agent generator to the master core, the master core executes other actions in the action list.

[0012] According to a second aspect of the embodiments of this application, a startup device for a classic automotive open system architecture platform is provided. The device includes: a startup module, configured to start a master core and a slave core in the early stage of startup, and initialize the local per-core uncached static random access memory of the master core and the slave core respectively; a processing module, configured to allocate at least a portion of the startup processes of hardware modules that can be initialized by proxy by the slave core to the slave core for initialization processing; a transfer module, configured to transfer the initialization proxy generator generated by the initialization processing of the slave core from the local per-core uncached static random access memory of the slave core to the local per-core uncached static random access memory of the master core; and a synchronization module, configured to synchronize the timing of the transfer of the initialization proxy generator by the slave core.

[0013] According to a third aspect of the embodiments of this application, an electronic device is provided, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, which causes the processor to perform an operation corresponding to the startup method of the classic platform of the automotive open system architecture as described in the first aspect.

[0014] According to a fourth aspect of the embodiments of this application, a computer storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the startup method of the classic platform of the automotive open system architecture as described in the first aspect.

[0015] According to a fifth aspect of the embodiments of this application, a computer program product is provided, including computer instructions that instruct a computing device to perform operations corresponding to the service-oriented architecture-based diagnostic method described in the first aspect of the embodiments.

[0016] Based on the above technical solution, the startup scheme of the classic platform of the automotive open system architecture in this application starts the master core and slave core in the early stage of startup, and initializes the local per-core non-cached static random access memory of the master core and slave core respectively. This allows at least a portion of the startup process of hardware modules that can be initialized by the slave core to be allocated to the slave core for initialization processing. In this application embodiment, the initialization proxy generated by the initialization processing of the slave core is transferred from the local per-core non-cached static random access memory of the slave core to the local per-core non-cached static random access memory of the master core, and the timing of the transfer is synchronized. This application embodiment can achieve rapid startup of the classic platform of the automotive open system architecture, thereby achieving rapid startup of the electronic control unit. Without affecting the actual vehicle functions, the startup time of the electronic control unit is significantly shortened, providing a guarantee for vehicle hibernation and rapid wake-up. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram illustrating the implementation of a classic platform for the open system architecture of related automotive technologies.

[0019] Figure 2 A flowchart illustrating a startup method for a classic automotive open system architecture platform applicable to embodiments of this application;

[0020] Figure 3 A schematic diagram illustrating the implementation of a startup method for a classic automotive open system architecture platform applicable to embodiments of this application;

[0021] Figure 4 A schematic diagram illustrating the implementation of step S2 of a startup method for a classic automotive open system architecture platform applicable to embodiments of this application;

[0022] Figure 5 A flowchart of step S3 of a startup method for a classic automotive open system architecture platform applicable to embodiments of this application;

[0023] Figure 6 A flowchart of step S4 of a startup method for a classic automotive open system architecture platform applicable to embodiments of this application;

[0024] Figure 7 A flowchart illustrating a startup method for a classic automotive open system architecture platform, applicable to another embodiment of this application;

[0025] Figure 8 This is a structural diagram of a startup device for a classic automotive open system architecture platform applicable to embodiments of this application. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present application. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without creative effort are within the scope of protection of the present application.

[0027] For ease of explanation, the technical terms used in this application are defined.

[0028] Initialization proxy outputs: The final outputs of a module after it has been transferred to another slave core to complete initialization are handed over to the master core. Initialization proxy outputs include: handles, module states, etc.

[0029] Per-Core Non-Cacheable SRAM: Each core has an identical, high-speed memory located very close to itself. There is no cache; the current core can directly access it, and its performance is equivalent to L1 cache. Automotive-grade multi-core MCU chips, such as the S32G and TC3xx, have an identical SRAM for each core. Using the same local address, each core accesses its own corresponding SRAM. For example, even when reading the contents of this SRAM through the same address, each core will read different content.

[0030] Master / Slave Core: The core responsible for the overall process of the action list, and it is the same core as the core where the flash drive is located. All other cores are slave cores relative to the master core.

[0031] See Figure 1 The startup initialization process of a classic multi-core automotive open system architecture platform is as follows: The master core (Core0) performs initialization processing, including driver initialization, low-level initialization code, etc., and is responsible for starting other slave cores. The startup time of the master and slave cores exceeds 31ms, and the slave cores are inactive for more than 35ms before being started. This results in a long startup time for the classic automotive open system architecture platform, further affecting the startup time of the electronic control unit.

[0032] The power-on, restart, and sleep / wake-up processes of the electronic control unit (ECU) are all important system metrics because they affect the overall user experience, such as Bluetooth key unlocking and light flashing. The startup and initialization process of a classic open system architecture platform in automobiles influences the startup of the ECU.

[0033] To address the aforementioned technical problems, this application provides a startup method for a classic automotive open system architecture platform. (See attached document.) Figure 2 The methods include:

[0034] Step S1: In the early startup phase, start the master core and slave core, and initialize the local uncached static random access memory of the master core and slave core respectively.

[0035] Specifically, see Figure 3In the early stages of startup, the master core Core0 and slave cores Core1—Core n (where n is a natural number)—start up, meaning the slave cores do not need to wait for the master core to start. When the master core Core0 starts up, it initializes its local per-core uncached static random access memory and starts the slave cores even earlier. When the slave cores start up, they also need to initialize their local per-core uncached static random access memory.

[0036] Step S2: Assign at least a portion of the boot process of the hardware module that can be initialized by the kernel agent to the kernel for initialization processing.

[0037] Specifically, for ease of description, two cores, the master core Core0 and the slave core Core1, are used as an example to describe the allocation of the hardware module.

[0038] exist Figure 1 In the scheme shown, the hardware modules Action 1 to Action 12, which can be initialized from the core agent, run on the main core Core0.

[0039] In the embodiments of this application, Actions 1 to 8, 11 run on the main core Core0.

[0040] Actions 9 and 10 run on Core 1.

[0041] The allocation of hardware modules Action 1 to Action 12 is shown in Table 1. Table 1 is only an illustration of the embodiments of this application and is not intended to limit the embodiments of this application.

[0042] Table 1

[0043]

[0044] Step S3: The initialization agent generated by the initialization process of the slave core is transferred from the slave core's local per-core uncached static random access memory to the master core's local per-core uncached static random access memory.

[0045] For example, see Figure 4 The contents of section 0x60000000~0x60000020 are transferred from Core1 to section 0x60000000~0x60000020 of the main core Core0; the contents of section 0x60000030~0x60000040 are transferred from Core2 to section 0x60000040~0x60000040 of the main core Core0.

[0046] In a specific implementation of Embodiment 1 of this application, step S3 further includes:

[0047] Record the starting address of the initialization agent generated by the initialization process of the slave core in the local non-cached static random access memory of the slave core, as well as the length of the storage of the initialization agent generator.

[0048] Specifically, after the kernel initializes the hardware modules it allocates, since the generated initialization agent generator needs to be transferred from the kernel's local per-core non-cached static random access memory to the master kernel's local per-core non-cached static random access memory, the kernel records the starting address (Sec_i) of the local per-core non-cached static random access memory where the initialization agent generator to be transferred is located and the length of the storage of the initialization agent generator (Len_i).

[0049] The embodiments of this application facilitate the transfer of initialization proxy products from the core through the above-described method. All cores do not need to disable caching, preventing the entire system lifecycle from being based on non-cached data operations and avoiding a sudden drop in system performance. The embodiments of this application elegantly solve the problem of cache consistency in inter-core communication.

[0050] In a specific implementation of Embodiment 1 of this application, step S3 further includes:

[0051] After transferring the initialization agent generator to the main core's local per-core uncached static random access memory, the storage space from the starting address of the slave core's local per-core uncached static random access memory where the initialization agent generator is located to the length of the storage space of the initialization agent generator is reclaimed.

[0052] In this embodiment, the local per-core non-cached static random access memory in the core can be recycled after the initialization agent generator is transferred, without having to permanently put the initialization agent generator into the non-cached memory area. This prevents the entire lifecycle of the system from being based on non-cached data operations and avoids a sudden drop in system performance.

[0053] In the specific implementation of Embodiment 1 of this application, see [link to implementation details]. Figure 5 Step S3 includes:

[0054] Step S31: If the chip where the main core is located supports global addresses, the main core directly accesses the local non-cached static random access memory of the slave core to obtain the initialization proxy generator.

[0055] Step S32: If the chip where the main core is located does not support global addresses, the main core accesses the local non-cached static random access memory of the slave core through the non-cached global content as an intermediate storage medium to obtain the initialization proxy generator.

[0056] This application employs different transfer methods depending on the chip, making it adaptable to various types of chips. After successful transfer, the variables in this application's embodiments have the same virtual storage address across all cores because they reside in the local non-cached static random access memory (SRAM) and are non-cached memory, which is several times faster than ordinary SRAM. Therefore, the main core can use them immediately.

[0057] Step S4: Synchronize the time point of the transfer of the initialization agent generated from the kernel.

[0058] In the specific implementation of Embodiment 1 of this application, see [link to implementation details]. Figure 6 Step S4 includes:

[0059] Step S41: If the slave core does not transfer the initialization agent generator to the master core, the master core will busy wait through the inter-core synchronization mechanism until it receives the initialization agent generator transferred from the slave core. The master core will then execute other actions in the action list.

[0060] Step S42: If the initialization agent generation is not transferred from the slave core to the master core, the master core executes other actions in the action list.

[0061] Specifically, see Figure 3 When the main core Core0 executes synchronize1, there are two possibilities: the slave core Core1 has not yet handed over the initialization proxy generated to the main core Core0, or the slave core Core1 has handed over the initialization proxy generated to the main core Core0.

[0062] Since the local per-core non-cached static random access memory (SRAM) of Core0 is initialized to 0 upon startup, it's possible to distinguish which of the above scenarios applies. If Core1 has not yet transferred the initialization proxy generator to Core0, Core0 will busy-wait using an inter-core synchronization mechanism (e.g., spinlock) until it receives the complete initialization proxy generator transferred from Core1. After receiving the complete initialization proxy generator from Core1, Core0 continues to execute other actions in its action list. If Core1 has transferred the initialization proxy generator to Core0, Core0 requires no special operation and continues to execute other actions in its action list.

[0063] The embodiments of this application elegantly solve the problem of cache consistency in inter-core communication through the synchronization at the above-mentioned time points.

[0064] In the specific implementation of Embodiment 1 of this application, see [link to implementation details]. Figure 7 Step S1, preceding which also includes:

[0065] Step S0: Identify hardware modules that can be initialized by the slave core agent. Hardware modules that can be initialized by the slave core agent are modules whose initialization process does not depend on other modules and whose initialization does not involve resources that are strongly bound to the master core or any slave core.

[0066] This application embodiment identifies hardware modules that can be initialized independently, and then assigns the initialization of these hardware modules to the slave core for initialization processing, which can make full use of the slave core and reduce the initialization time.

[0067] The embodiments of this application enable the rapid startup of classic platforms with open automotive system architecture, thereby enabling the rapid startup of electronic control units. Without affecting the actual vehicle functions, the startup time of the electronic control units will be significantly shortened, providing a guarantee for the vehicle's hibernation and rapid wake-up.

[0068] In the specific implementation of Embodiment 1 of this application, the kernel only performs the initialization of the corresponding module and does not delegate the services of subsequent modules. The startup time of the electronic control unit will be greatly shortened and will not affect the overall performance of the system.

[0069] Device

[0070] See Figure 8 This application embodiment also provides a startup device for a classic automotive open system architecture platform, the device comprising:

[0071] The startup module 801 is used to start the master core and slave core in the early stage of startup, and initialize the local per-core uncached static random access memory of the master core and the slave core respectively.

[0072] Processing module 802 is used to allocate at least a portion of the startup process of a hardware module that can be initialized by the slave core agent to the slave core for initialization processing.

[0073] The transfer module 803 is used to transfer the initialization proxy generated by the initialization process of the slave core from the local per-core uncached static random access memory of the slave core to the local per-core uncached static random access memory of the master core.

[0074] The synchronization module 804 is used to synchronize the time point at which the slave core transfers the initialization agent generated.

[0075] The embodiments of this application enable the rapid startup of classic platforms with open automotive system architecture, thereby enabling the rapid startup of electronic control units. Without affecting the actual vehicle functions, the startup time of the electronic control units will be significantly shortened, providing a guarantee for the vehicle's hibernation and rapid wake-up.

[0076] Computer storage media

[0077] In this embodiment, a computer-readable storage medium is provided, storing instructions for causing a machine to execute a service-oriented architecture-based diagnostic method as described herein. Specifically, a system or apparatus equipped with a storage medium storing software program code that implements the functions of any of the embodiments described above, and enabling the computer (or CPU or MPU) of the system or apparatus to read and execute the program code stored in the storage medium.

[0078] In this case, the program code read from the storage medium can itself implement the function of any of the above embodiments, and therefore the program code and the storage medium storing the program code constitute part of this application.

[0079] Examples of storage media used to provide program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer via a communication network.

[0080] Computer program products

[0081] In this embodiment, a computer program product is provided, including computer instructions that instruct a computing device to perform any corresponding operation in the above-described plurality of method embodiments.

[0082] It should be noted that, depending on the implementation needs, the various components / steps described in the embodiments of this application can be broken down into more components / steps, or two or more components / steps or parts of the operation of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of this application.

[0083] The methods described in the embodiments of this application can be implemented in hardware, firmware, or as software or computer code that can be stored in a recording medium (such as a CD-ROM, RAM, floppy disk, hard disk, or magneto-optical disk), or as computer code downloaded over a network that is originally stored in a remote recording medium or a non-transitory machine-readable medium and will be stored in a local recording medium. Thus, the methods described herein can be processed by software stored on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware (such as an ASIC or FPGA). It is understood that the computer, processor, microprocessor controller, or programmable hardware includes storage components (e.g., RAM, ROM, flash memory, etc.) capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods described herein. Furthermore, when a general-purpose computer accesses code used to implement the methods shown herein, the execution of the code transforms the general-purpose computer into a dedicated computer for executing the methods shown herein.

[0084] It should be noted that in the description of this application, the terms "first" and "second" are used only for convenience in describing different components or names, and should not be construed as indicating or implying a sequential relationship, relative importance, or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features.

[0085] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0086] It should be noted that although specific embodiments of this application have been described in detail with reference to the accompanying drawings, this should not be construed as limiting the scope of protection of this application. Various modifications and variations that can be made by those skilled in the art without inventive effort within the scope described in the claims still fall within the scope of protection of this application.

[0087] The examples of the embodiments in this application are intended to concisely illustrate the technical features of the embodiments in this application, so that those skilled in the art can intuitively understand the technical features of the embodiments in this application, and are not intended to be improper limitations on the embodiments in this application.

[0088] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A startup method for a classic automotive open system architecture platform, the method comprising: In the early stages of startup, the master core and slave core are started, and the local uncached static random access memory of the master core and the slave core are initialized respectively. At least a portion of the boot process of the hardware module that can be initialized by the slave agent is assigned to the slave core for initialization processing; The initialization proxy generated by the initialization process of the slave core is transferred from the local per-core uncached static random access memory of the slave core to the local per-core uncached static random access memory of the master core. The timing of the transfer of the initialization proxy generator from the slave core is synchronized between cores.

2. The method according to claim 1, wherein, The process of starting the master and slave cores in the early stages of startup and initializing their respective local per-core uncached static random access memory (SRAM) includes, prior to: Identify hardware modules that can be initialized by the slave core proxy, wherein the hardware modules that can be initialized by the slave core proxy are modules whose initialization process does not depend on other modules and whose initialization does not involve resources strongly bound to the master core or any of the slave cores.

3. The method according to claim 1 or 2, wherein, The step of allocating at least a portion of the boot process of the hardware module that can be initialized by the slave agent to the slave core for initialization processing further includes: Record the starting address of the initialization proxy generated by the initialization process of the slave core in the local per-core non-cached static random access memory of the slave core, as well as the storage length of the initialization proxy generated.

4. The method according to claim 3, wherein, The step of transferring the initialization proxy generated by the initialization process of the slave core from the local per-core uncached static random access memory of the slave core to the local per-core uncached static random access memory of the master core further includes: After transferring the initialization agent generator to the local per-core uncached static random access memory of the master core, the storage space from the starting address to the length of the storage of the initialization agent generator in the local per-core uncached static random access memory of the slave core where the initialization agent generator is located is reclaimed and reused.

5. The method according to claim 4, wherein, The step of transferring the initialization proxy generated by the initialization process of the slave core from the slave core's local per-core uncached static random access memory to the master core's local per-core uncached static random access memory includes: If the chip where the master core is located supports global addresses, the master core directly accesses the local non-cached static random access memory of the slave core to obtain the initialization proxy generator; Otherwise, the master core uses the non-cached global content as an intermediate storage medium to access the local non-cached static random access memory of the slave core to obtain the initialization agent generator.

6. The method according to claim 5, wherein, The synchronization process for the timing of the transfer of the initialization proxy generator from the slave core includes: If the slave core fails to transfer the initialization agent generator to the master core, the master core will busy-wait through the inter-core synchronization mechanism until it receives the initialization agent generator transferred from the slave core, and then the master core will execute other actions in the action list. If the slave core transfers the initialization agent generator to the master core, the master core executes other actions in the action list.

7. A startup device for a classic automotive open system architecture platform, the device comprising: The startup module is used to start the master core and slave core in the early stage of startup, and initialize the local uncached static random access memory of the master core and the slave core respectively; A processing module is configured to allocate at least a portion of the startup process of a hardware module that can be initialized by the slave core agent to the slave core for initialization processing; The transfer module is used to transfer the initialization proxy generated by the initialization process of the slave core from the local per-core uncached static random access memory of the slave core to the local per-core uncached static random access memory of the master core. The synchronization module is used to perform inter-core synchronization processing on the time point when the slave core performs the transfer of the initialization agent generation.

8. An electronic device, comprising: The processor, communication interface, memory, and communication bus communicate with each other through the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the operation corresponding to the startup method of the classic platform of the automotive open system architecture as described in any one of claims 1-6.

9. A computer storage medium having a computer program stored thereon, which, when executed by a processor, implements the startup method of the classic platform of the automotive open system architecture as described in any one of claims 1-6.

10. A computer program product comprising computer instructions that instruct a computing device to perform an operation corresponding to the startup method of the classic automotive open system architecture platform as described in any one of claims 1-6.

Images