Startup methods, devices, electronic devices and storage media
By sharing peripheral initialization artifacts with the application during the boot loading phase and avoiding repeated initialization, the problem of slow startup speed of classic automotive open system architecture platforms is solved, achieving fast startup and rapid vehicle response.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Z-ONE TECH CO LTD
- Filing Date
- 2024-12-23
- Publication Date
- 2026-06-30
AI Technical Summary
In existing technologies, the startup speed of classic open system architecture platforms in automobiles is relatively slow, which affects the rapid startup of electronic control units and consequently impacts the overall vehicle experience.
During the boot loading phase, the same main core is used as in classic automotive open system architecture platform applications. The low-latency communication engine firmware and power management IC are moved in, and peripheral initialization is completed in this phase. Peripheral initialization artifacts are shared to the same fixed address space, and application initialization operations are deleted to avoid duplicate initialization.
It enables rapid startup of classic automotive open system architecture platforms, shortens the startup time of electronic control units, ensures rapid sleep and wake-up of the entire vehicle, and does not affect the actual vehicle functions.
Smart Images
Figure CN122308926A_ABST
Abstract
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 automotive open system architecture platform is provided. The method applies to the same main core in the boot loading phase and the classic automotive open system architecture platform application. The method includes: moving low-latency communication engine firmware loading and power management integrated circuits into the boot loading phase, and starting the system during the main core's concurrent idle period in the boot loading phase; completing peripheral initialization in the boot loading phase to obtain shared peripheral initialization artifacts, the shared peripheral initialization artifacts including: code segment, data segment, and uninitialized data segment; mapping the shared peripheral initialization artifacts to the same fixed address space in the boot loading phase and the classic automotive open system architecture platform application; deleting the initialization operation of the classic automotive open system architecture platform application, and allowing the classic automotive open system architecture platform application to operate on the shared peripheral initialization artifacts.
[0007] In some embodiments of this application, mapping the shared peripheral initialization artifacts to the same fixed address space in the boot loading stage and the classic automotive open system architecture platform application includes: identifying target peripherals and storing the shared peripheral initialization artifacts of the target peripherals in a physical contiguous random access memory (PRAM) region, wherein the PRAM region is not affected by direct memory access during the boot loading stage; identifying non-target peripherals, and during the compilation stage, separating the shared peripheral initialization artifacts of the non-target peripherals in the same manner as in the boot loading stage and the classic automotive open system architecture platform application; and setting a fixed first virtual memory address and a fixed first loadable memory address, as well as a fixed second virtual memory address and a fixed second loadable memory address, for the shared peripheral initialization artifacts during the linking stage of the boot loading stage and the linking stage of the classic automotive open system architecture platform application, respectively.
[0008] In some embodiments of this application, the fixed first virtual memory address and the fixed first loadable memory address are recorded as: boot loading stage virtual memory address code, boot loading stage loadable memory address code, boot loading stage virtual memory address data, boot loading stage loadable memory address data, boot loading stage uninitialized data segment of virtual memory address, and boot loading stage uninitialized data segment of loadable memory address; the fixed second virtual memory address and the fixed second loadable memory address are recorded as: application virtual memory address code, application loadable memory address code, application virtual memory address data, application loadable memory address data, application virtual memory address uninitialized data segment of virtual memory address, and application loadable memory address uninitialized data segment of virtual memory address; wherein, the application virtual memory address code is equal to or not equal to the boot loading stage virtual memory address code; the application virtual memory address data must be equal to the boot loading stage virtual memory address data, and the application virtual memory address uninitialized data segment must be equal to the boot loading stage uninitialized data segment of virtual memory address; it is not necessary to set the boot loading stage uninitialized data segment of loadable memory address and the application loadable memory address uninitialized data segment.
[0009] In some embodiments of this application, the initialization startup code of the classic platform application of the automotive open system architecture cannot perform initialization copying of the application virtual memory address encoding, the application loadable memory address encoding, the application virtual memory address data, the application loadable memory address data, and the application virtual memory address uninitialized data segment; the initialization startup code of the classic platform application of the automotive open system architecture cannot perform initialization zeroing of the application virtual memory address uninitialized data segment and the application loadable memory address uninitialized data segment.
[0010] In some embodiments of this application, the microcontroller abstraction layer configuration is adjusted during the boot loading stage: in the port configuration, the initialization configuration of the corresponding peripheral is added or retained; in the integrated circuit interconnect configuration, the initialization configuration of the corresponding peripheral is added or retained; in the power management integrated circuit configuration, the initialization configuration of the corresponding peripheral is added or retained.
[0011] In some embodiments of this application, the microcontroller abstraction layer configuration of the classic platform application of the automotive open system architecture is adjusted as follows: in the port configuration, the initialization configuration related to the corresponding peripheral is removed; in the integrated circuit interconnect configuration, the initialization configuration related to the corresponding peripheral is retained; in the power management integrated circuit configuration, the initialization configuration related to the corresponding peripheral is retained.
[0012] According to a second aspect of the embodiments of this application, a boot device for a classic automotive open system architecture platform is provided. The device is applied to the same main core in the boot loading phase and the classic automotive open system architecture platform application. The device includes: a communication and power loading module, used to move low-latency communication engine firmware loading and power management integrated circuit into the boot loading phase, and to start the system during the main core's concurrent idle period in the boot loading phase; a boot loading initialization module, used to complete peripheral initialization in the boot loading phase and obtain shared peripheral initialization artifacts, the shared peripheral initialization artifacts including: code segment, data segment, and uninitialized data segment; an address mapping setting module, used to map the shared peripheral initialization artifacts to the same fixed address space in the boot loading phase and the classic automotive open system architecture platform application; and an application sharing module, used to delete the initialization operation of the classic automotive open system architecture platform application, allowing the classic automotive open system architecture platform application to operate on the shared peripheral initialization artifacts.
[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 automotive open system architecture platform in this application embodiment applies the same main core to the boot loading stage and the classic automotive open system architecture application. The low-latency communication engine firmware loading and power management integrated circuit are moved into the boot loading stage and start during the main core's concurrent idle period. Peripheral initialization is completed during the boot loading stage, obtaining shared peripheral initialization artifacts. These shared peripheral initialization artifacts are mapped to the same fixed address space, and the initialization operation of the classic automotive open system architecture application is deleted, allowing the classic automotive open system architecture application to operate on the shared peripheral initialization artifacts. This application embodiment enables the classic automotive open system architecture application to reuse the shared peripheral initialization artifacts from the boot loading stage, avoiding repeated peripheral initialization, thereby achieving rapid startup of the electronic control unit and avoiding repeated loading of peripheral initialization artifacts, reducing the overall code size. This application embodiment facilitates the estimation of startup acceleration performance data before implementation and is simple and reliable. Without affecting the actual vehicle functions, this application embodiment significantly shortens the startup time of the electronic control unit, 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 1This 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 flowchart of step S3 of a startup method for a classic automotive open system architecture platform applicable to embodiments of this application;
[0022] Figure 5 A schematic diagram illustrating the implementation of a startup method for a classic automotive open system architecture platform applicable to embodiments of this application;
[0023] Figure 6 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
[0024] 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.
[0025] For ease of explanation, the technical terms used in this application are defined.
[0026] Bootloader Stage Figure 3 It is divided into two stages, with the bootloader stage being the upper stage.
[0027] Automotive Open System Architecture Classic Platform Application (Autosar CP Application) is Figure 3 The next stage.
[0028] Shared peripheral initialization artifacts: These can be understood as structures, including the complete context of a particular peripheral, such as code segments, data segments, and uninitialized data segments. Taking the I2C interfacedwatchdog (PMIC) as an example, it includes: the state of the IMIC watchdog module itself, the state of the related port modules, the state of the related I2C modules, and so on.
[0029] Initialization Copy: Before an application runs on a classic automotive open system architecture platform, a small piece of startup code is responsible for copying the code segment or data segment to be executed from Flash Memory to RAM Memory. The source address of the copy is determined by the Loadable Memory Address (LMA), the destination address is determined by the Virtual Memory Address (VMA), and the number of bytes copied is determined by the length. The Loadable Memory Address, Virtual Memory Address, and length are obtained during the program linking stage.
[0030] Initialization and zeroing: Before an application runs on a classic platform of the automotive open system architecture, a small piece of startup code is responsible for zeroing out the uninitialized data segment (BSS segment) to be used. The destination address for zeroing is determined by the virtual memory address, and the number of bytes to be zeroed is determined by the length. The virtual memory address and length can be obtained during the program linking stage.
[0031] See Figure 1 In classic automotive open system architecture platforms where bootloading is essential, the system initialization process typically involves jumping from bootloader to application, during which all resources change: code segment, data segment, uninitialized data segment, interrupt vector table, instruction pointer, stack pointer, other context elements, exception handling, etc. Therefore, after jumping from bootloader to application, resources must be re-initialized according to the application's driver init action list. (Comparison) Figure 1 In the Bootloader Driver InitializationContext and Application Driver InitializationContext, it can be observed that some initialization tasks are duplicated in the driver initialization task list.
[0032] Figure 1The time consumption of each function in the driver initialization task list is shown in Table 1. The initialization tasks in Table 1 are just examples, and this application embodiment does not limit them.
[0033] Table 1
[0034]
[0035] As shown in Table 1, the total time spent on bootloader driver initialization and application driver initialization is very long, resulting in a long startup initialization time for the classic automotive open system architecture platform.
[0036] 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.
[0037] This application embodiment accelerates the startup of the electronic control unit by reusing the results of the initialization during the boot loading stage of the classic platform application of the automotive open system architecture without repeating the initialization of peripherals.
[0038] To address the aforementioned technical issues, this application provides a startup method for a classic automotive open system architecture platform, wherein the method is applied to the same main core during the boot loading phase and in the application of the classic automotive open system architecture platform.
[0039] If the bootloader phase and the application in the classic platform of the automotive open system architecture are not applied to the same master core, the master core and slave core are started in the early stage of startup, and their local per-core uncached static random access memory (SRAM) are initialized respectively. At least a portion of the startup process of hardware modules that can be initialized by the slave core is allocated to the slave core for initialization processing. The initialization proxy generated by the initialization processing of the slave core is transferred from the local per-core uncached SRAM of the slave core to the local per-core uncached SRAM of the master core. The timing of the transfer of the initialization proxy generated by the slave core is synchronized. The embodiments of this application use multi-core parallel implementation of initialization processing, which can realize the fast startup of the classic platform of the automotive open system architecture, and thus realize the fast startup of the electronic control unit. Without affecting the actual vehicle function, the startup time of the electronic control unit is significantly shortened, providing a guarantee for the vehicle's hibernation and fast wake-up.
[0040] See Figure 2 The methods include:
[0041] Step S1: Move the low-latency communication engine firmware loading and power management integrated circuit into the boot loading stage, and start it during the main core's concurrent idle period in the boot loading stage.
[0042] Specifically, see Figure 3 By moving the low-latency communication engine firmware loading and power management IC to the boot loading stage, the system ensures that the low-latency communication engine firmware loading and power management IC starts during the boot loading stage. This avoids the inability to initialize the low-latency communication engine firmware loading and power management IC in classic automotive open system architecture platform applications if the low-latency communication engine firmware loading and power management IC fails to start during the boot loading stage. Furthermore, since the startup time of the low-latency communication engine firmware loading and power management IC is relatively long, starting the low-latency communication engine firmware loading and power management IC during the main core's concurrent idling period during the boot loading stage further saves startup time on classic automotive open system architecture platforms.
[0043] Step S2: Complete peripheral initialization during the boot loading phase and obtain shared peripheral initialization artifacts, which include: code segment, data segment, and uninitialized data segment.
[0044] Step S3: During the boot loading phase, map the shared peripheral initialization artifacts to the same fixed address space as the classic platform application of the automotive open system architecture.
[0045] In this embodiment, during the boot loading phase and in the classic automotive open system architecture platform application, shared peripheral initialization artifacts must be mapped to the same fixed address space. This ensures that the virtual memory address and loadable memory address of the shared peripheral initialization artifacts are the same in both the boot loading phase and the classic automotive open system architecture platform application. Furthermore, the shared peripheral initialization artifacts must not be out of order and must employ strict data alignment.
[0046] In the specific view of Embodiment 1 of this application, see... Figure 4 Step S3 includes:
[0047] Step S31:
[0048] Identify the target peripheral device;
[0049] The shared peripheral initialization artifacts of the target peripheral are stored in the physical contiguous random access memory region, which is not affected by direct memory access and transport during the boot loading phase.
[0050] Specifically, the target peripheral is a peripheral that depends on few other modules, takes a long time to initialize, and is permanently fixed on the electronic control unit.
[0051] For example, the Integrated Circuit Interconnect Interface Watchdog (PMIC) module is only related to the port module in the microcontroller abstraction layer, the integrated circuit interconnect module, and the integrated circuit interconnect interface watchdog module itself. It takes 7.6ms to start up and is permanently fixed on the ECU.
[0052] The Physically Continuous RAM Region (PRAM Region) is a physically contiguous RAM area used to store shared peripheral initialization artifacts, namely the code segment, data segment, and uninitialized data segment. The PRAM Region is unaffected by direct memory access during the bootloader phase. While the bootloader phase initializes the PRAM Region, the Automotive Open System Architecture Classic Platform application does not initialize it. After startup, during runtime, the Automotive Open System Architecture Classic Platform application can perform read, write, and execute operations on the PRAM Region.
[0053] Step S32:
[0054] Identify non-target peripherals;
[0055] During the compilation phase, the shared peripheral initialization artifacts are separated in the same way as those in the boot loading phase of non-target peripherals and in classic platform applications of automotive open system architecture.
[0056] During the linking phase of the bootloader phase and the linking phase of the classic platform application of the automotive open system architecture, a first virtual memory address and a first loadable memory address with fixed addresses, as well as a second virtual memory address and a second loadable memory address with fixed addresses, are respectively set for the shared peripheral initialization artifacts.
[0057] Specifically, during the compilation phase, the bootloader phase, and the classic platform application of the automotive open system architecture, these fields (segments) are separated from the original code in exactly the same way, and they must not be out of order internally, and must be aligned with strict data alignment.
[0058] During the linking phase of the bootloader phase and the linking phase of the classic platform application of the automotive open system architecture, these fields are respectively assigned a fixed first virtual memory address and a fixed first loadable memory address, as well as a fixed second virtual memory address and a fixed second loadable memory address.
[0059] The fixed first virtual memory address and the fixed first loadable memory address are recorded as: boot load stage virtual memory address code (BL_VMA_Code), boot load stage loadable memory address code (BL_LMA_Code), boot load stage virtual memory address data (BL_VMA_Data), boot load stage loadable memory address data (BL_LMA_Data), boot load stage uninitialized virtual memory address data segment (BL_VMA_BSS), and boot load stage loadable memory address uninitialized data segment (BL_LMA_BSS).
[0060] The fixed-address second virtual memory address and the fixed-address second loadable memory address are recorded as: Application Virtual Memory Address Code (APP_VMA_Code), Application Loadable Memory Address Code (APP_LMA_Code), Application Virtual Memory Address Data (APP_VMA_Data), Application Loadable Memory Address Data (APP_LMA_Data), Application Virtual Memory Address Uninitialized Data Segment (APP_VMA_BSS), and Application Loadable Memory Address Uninitialized Data Segment (APP_LMA_BSS).
[0061] Among them, the application virtual memory address code may or may not be equal to the virtual memory address code of the boot loading stage; the application virtual memory address data must be equal to the virtual memory address data of the boot loading stage, and the application virtual memory address uninitialized data segment must be equal to the virtual memory address uninitialized data segment of the boot loading stage; it is not necessary to set the loadable memory address uninitialized data segment of the boot loading stage and the loadable memory address uninitialized data segment of the application.
[0062] Specifically, in this embodiment of the application, after the application on the classic platform of the automotive open system architecture is successfully compiled during the boot loading stage, their mapping files are checked to ensure that the above conditions are fully met.
[0063] Step S4: Delete the initialization operation of the classic platform application of the automotive open system architecture, and allow the classic platform application of the automotive open system architecture to operate on the shared peripheral initialization artifacts.
[0064] See Figure 1 In related technologies, the bootstrap phase and the classic platform application of the automotive open system architecture each complete their respective peripheral initialization phases. Therefore, there is a possibility of duplicate initialization of certain peripherals in related technologies. See also Figure 5 In this embodiment of the application, the peripheral initialization is completed during the boot loading stage. The classic platform application of the automotive open system architecture can reuse the results of the initialization during the boot loading stage without having to re-initialize the peripherals.
[0065] This embodiment avoids both repeated initialization and loading of peripherals because the code segment, data segment, and uninitialized data segment are completely identical in the bootloader phase and the classic automotive open system architecture platform application—that is, they are the same copy. In other words, the shared peripheral initialization artifacts generated during the bootloader phase mean that subsequent operations on these peripherals by the classic automotive open system architecture platform application will be based on these shared peripheral initialization artifacts for reading, writing, and execution.
[0066] In this embodiment, duplicate fields (e.g., code segment, data segment, uninitialized data segment) share the same copy, whereas in related technologies, the boot loading stage and the classic platform application of the automotive open system architecture each maintain a private copy, meaning that in related technologies, the flash memory needs to store an extra copy of the fields (e.g., code segment, data segment, uninitialized data segment).
[0067] In a specific implementation of Embodiment 1 of this application, the initialization startup code of the classic platform application of the automotive open system architecture cannot perform initialization copying of the application virtual memory address encoding, the application loadable memory address encoding, the application virtual memory address data, the application loadable memory address data, and the application virtual memory address uninitialized data segment.
[0068] The embodiments of this application ensure that the shared peripheral initialization artifacts generated during the boot loading stage are not destroyed, and the classic platform application of the automotive open system architecture can continue to reuse the shared peripheral initialization artifacts.
[0069] There are two possible implementations for initializing and copying applications on classic automotive open system architecture platforms:
[0070] One approach is to copy data and code from flash memory to the physical contiguous random access memory region by linking the startup code in crt0.o of the toolchain and then using a copy table.
[0071] Another approach is to implement the initial copy yourself within the classic platform application of the automotive open system architecture.
[0072] Regardless of the initialization copy method used by the classic platform application of the automotive open system architecture, the initialization copy of the above-mentioned application virtual memory address encoding, application loadable memory address encoding, application virtual memory address data, application loadable memory address data, and application virtual memory address uninitialized data segment must be ignored.
[0073] In a specific implementation of Embodiment 1 of this application, the initialization startup code of the classic platform application of the automotive open system architecture cannot perform initialization and zeroing of the uninitialized data segment of the application's virtual memory address and the uninitialized data segment of the application's loadable memory address.
[0074] The startup code for the classic platform application of the automotive open system architecture cannot perform initialization and zeroing of the uninitialized data segments of the application's virtual memory address and the uninitialized data segments of the application's loadable memory address. This ensures that the shared peripheral initialization artifacts generated during the boot loading stage are not destroyed, and the application of the classic platform application of the automotive open system architecture can continue to reuse the shared peripheral initialization artifacts.
[0075] There are two possible implementations for zeroing out and initializing applications on classic automotive open system architecture platforms:
[0076] One method is to use the startup code in the linker toolchain's crt0.o file and then clear the list (clear_table) to achieve the clearing.
[0077] Another approach is to implement initialization and zeroing yourself within the classic platform application of the automotive open system architecture.
[0078] Regardless of the initialization and zeroing method used by the classic platform application of the automotive open system architecture, the initialization and zeroing of the uninitialized data segments of the application's virtual memory address and the uninitialized data segments of the application's loadable memory address must be ignored.
[0079] In the specific implementation of Embodiment 1 of this application, the microcontroller abstraction layer configuration is adjusted during the boot loading stage:
[0080] In the port configuration, add or retain the initialization configuration of the corresponding peripheral;
[0081] In the configuration of integrated circuit interconnect (I2C), add or retain the initialization configuration of the corresponding peripheral;
[0082] In the configuration of the power management integrated circuit (PMIC), add or retain the initialization configuration of the corresponding peripheral.
[0083] For example, if the power management integrated circuit is started at an earlier stage, an unexpected reboot may occur if the dongle is not fed in time. If the dongle is not fed during the boot load stage, the dongle is fed by the classic platform application of the automotive open system architecture. If the default timeout threshold for dongle feeding of the power management integrated circuit is relatively long, no special handling is required. If the default timeout threshold for dongle feeding is relatively short, this application embodiment suggests adjusting the power management integrated circuit to a slow dongle during the boot load stage; and adjusting the power management integrated circuit to a fast dongle at an appropriate time in the classic platform application of the automotive open system architecture (e.g., after the evaluation point of fast startup).
[0084] In a specific implementation of Embodiment 1 of this application, the microcontroller abstraction layer configuration of the classic platform application of the automotive open system architecture is adjusted:
[0085] In the port configuration, remove the corresponding peripheral-related initialization configuration;
[0086] In the configuration of integrated circuit interconnects, the initialization configuration related to the corresponding peripherals is retained;
[0087] In the configuration of the power management integrated circuit, the initialization configuration related to the corresponding peripherals is retained.
[0088] Specifically, the bootloader phase has already completed the configuration of the port related to this peripheral. When the classic platform application of the automotive open system architecture reinitializes this port, it may cause a change in the signal on the PIN, which is undesirable.
[0089] Integrated circuit interconnect buses are susceptible to deadlock, and one step in addressing this deadlock is reinitializing the interconnects. If a 2C bus deadlock occurs in an automotive open system architecture classic platform application, then the application may need to reinitialize the interconnects. Therefore, the peripheral-related integrated circuit bus initialization configuration must be retained within the automotive open system architecture classic platform application. Because the relevant fields of the integrated circuit associated with this peripheral are fixedly stored in a physically contiguous random access memory area during the linking phase, reinitializing this interconnect during the operation of the automotive open system architecture classic platform application will not pose a risk to compatibility or consistency.
[0090] The power management integrated circuit's dog-feeding function, dog-feeding notification function, and other functions all use these configurations. Furthermore, all of its fields are completely shared in the classic platform application and boot loading phase of the automotive open system architecture. Therefore, the configurations must be exactly the same. This ensures that the source code generated by codegen is exactly the same, but ultimately only the same shared copy is maintained in flash memory and static random access memory.
[0091] This application's embodiments are applied to the electronic control unit of a real vehicle. Without affecting the vehicle's functionality, the startup time of the electronic control unit is significantly reduced, ensuring the vehicle's ability to go into sleep mode and quickly wake up.
[0092] Device
[0093] See Figure 6 This application also provides a boot device for a classic automotive open system architecture platform. The device is used on the same main core as the classic automotive open system architecture platform application during the boot loading phase. The device includes:
[0094] The communication and power loading module 601 is used to move the low-latency communication engine firmware loading and power management integrated circuit into the boot loading stage, and to start during the main core concurrent idling period of the boot loading stage;
[0095] The bootloader initialization module 602 is used to complete peripheral initialization during the bootloader phase and obtain shared peripheral initialization artifacts, which include: code segment, data segment, and uninitialized data segment.
[0096] Address mapping setting module 603 is used to map the shared peripheral initialization artifacts to the same fixed address space as the classic platform application of automotive open system architecture during the boot loading stage;
[0097] Application sharing module 604 is used to delete the initialization operations of the classic platform application of the automotive open system architecture, and to allow the classic platform application of the automotive open system architecture to operate on the shared peripheral initialization artifacts.
[0098] 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.
[0099] Computer storage media
[0100] 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.
[0101] 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.
[0102] 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.
[0103] Computer program products
[0104] 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.
[0105] 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.
[0106] 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.
[0107] 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.
[0108] 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.
[0109] 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.
[0110] 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.
[0111] 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, wherein the method is applied to the same main core as the classic automotive open system architecture platform application during the boot loading phase, the method comprising: The low-latency communication engine firmware loading and power management IC are moved into the boot loading stage and start during the main core's concurrent idle period in the boot loading stage; During the boot loading phase, peripheral initialization is completed, and shared peripheral initialization artifacts are obtained. The shared peripheral initialization artifacts include: code segment, data segment, and uninitialized data segment. The shared peripheral initialization artifacts are mapped to the same fixed address space in the classic platform application of the automotive open system architecture during the boot loading phase; The initialization operation of the classic platform application of the automotive open system architecture is deleted, and the classic platform application of the automotive open system architecture is allowed to operate on the shared peripheral initialization artifacts.
2. The method according to claim 1, wherein, The step of mapping the shared peripheral initialization artifacts to the same fixed address space in the boot loading phase and in the classic platform application of the automotive open system architecture includes: Identify the target peripheral device and store the shared peripheral initialization artifacts of the target peripheral device in a physical contiguous random access memory region, wherein the physical contiguous random access memory region is not affected by the direct memory access transport during the boot loading stage; To identify non-target peripherals, during the compilation phase, the shared peripheral initialization artifacts are separated in the same way as those in the boot loading phase and the classic platform application of the automotive open system architecture. In the linking phase of the boot loading phase and the linking phase of the classic platform application of the automotive open system architecture, a first virtual memory address and a first loadable memory address with fixed addresses, as well as a second virtual memory address and a second loadable memory address with fixed addresses, are respectively set for the shared peripheral initialization artifacts.
3. The method according to claim 2, wherein, The fixed first virtual memory address and the fixed first loadable memory address are recorded as: boot loading stage virtual memory address code, boot loading stage loadable memory address code, boot loading stage virtual memory address data, boot loading stage loadable memory address data, boot loading stage virtual memory address uninitialized data segment, and boot loading stage loadable memory address uninitialized data segment. The fixed-address second virtual memory address and the fixed-address second loadable memory address are recorded as: application virtual memory address code, application loadable memory address code, application virtual memory address data, application loadable memory address data, application virtual memory address uninitialized data segment, and application loadable memory address uninitialized data segment. Wherein, the application virtual memory address code is equal to or not equal to the boot loading stage virtual memory address code; the application virtual memory address data must be equal to the boot loading stage virtual memory address data, and the application virtual memory address uninitialized data segment must be equal to the boot loading stage virtual memory address uninitialized data segment; it is not necessary to set the boot loading stage loadable memory address uninitialized data segment and the application loadable memory address uninitialized data segment.
4. The method according to claim 3, wherein, The initialization startup code of the classic platform application of the automotive open system architecture cannot perform initialization copying of the application's virtual memory address encoding, the application's loadable memory address encoding, the application's virtual memory address data, the application's loadable memory address data, and the application's uninitialized virtual memory address data segment; The initialization startup code of the classic platform application of the automotive open system architecture cannot perform initialization and zeroing of the uninitialized data segment of the application's virtual memory address and the uninitialized data segment of the application's loadable memory address.
5. The method according to claim 4, wherein, The microcontroller abstraction layer configuration is adjusted during the boot loading phase. In the port configuration, add or retain the initialization configuration of the corresponding peripheral; In the configuration of integrated circuit interconnects, add or retain the initialization configuration of the corresponding peripherals; In the configuration of the power management integrated circuit, add or retain the initialization configuration of the corresponding peripheral.
6. The method according to claim 5, wherein, The microcontroller abstraction layer configuration of the classic platform application in the automotive open system architecture is adjusted as follows: In the port configuration, remove the corresponding peripheral-related initialization configuration; In the configuration of integrated circuit interconnects, the initialization configuration related to the corresponding peripherals is retained; In the configuration of the power management integrated circuit, the initialization configuration related to the corresponding peripherals is retained.
7. A boot device for a classic automotive open system architecture platform, wherein the device is applied to the same main core as the classic automotive open system architecture platform application during the boot loading phase, the device comprising: The communication and power loading module is used to move the low-latency communication engine firmware loading and power management integrated circuit into the boot loading stage, and to start during the main core's concurrent idling period in the boot loading stage; The bootloader initialization module is used to complete peripheral initialization during the bootloader phase and obtain shared peripheral initialization artifacts, which include: code segment, data segment, and uninitialized data segment. The address mapping setting module is used to map the shared peripheral initialization artifacts to the same fixed address space in the boot loading phase and in the classic platform application of the automotive open system architecture. The application sharing module is used to delete the initialization operation of the classic platform application of the automotive open system architecture, and to allow the classic platform application of the automotive open system architecture to operate on the shared peripheral initialization artifacts.
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.