System software starting upgrading method and device and vehicle

Abstract

The invention discloses a system software starting upgrading method and device and a vehicle. The method comprises the following steps: starting a first boot loader in a first application domain; responding to the upgrade mode identifier received by the first boot loader, and if the upgrade mode identifier is a specified character, starting a second boot loader in a second application domain; obtaining the network firmware and storing the network firmware in a second running storage space in response to the fact that the second boot loader analyzes the specified character; starting an upgrade state kernel, calling the upgrade state kernel to start a first format root file system, and obtaining a to-be-upgraded firmware mirror image package through the first format root file system; and performing firmware flashing on the first storage device and the second storage device based on the to-be-upgraded firmware mirror image package so as to start upgrading of operating system software configured in the first application domain and the second application domain. According to the method, the inter-core transmission process of the heteronuclear firmware can be omitted, and the flashing efficiency is improved.

Description

Technical Field

[0001] This application relates to the technical field of in-vehicle system upgrades, and more specifically, to a method, device, and vehicle for starting and upgrading system software. Background Art

[0002] In the automotive field, the in-vehicle operating system we usually refer to specifically refers to the kernel. By managing aspects such as the system's processes, memory, drivers, and network, it provides a high-performance and highly stable operating environment for automotive software. At the same time, as the most fundamental and core part of the in-vehicle system software layer, it is the underlying layer that manages and controls automotive hardware and software resources and is the infrastructure for the vehicle to achieve intelligence. Due to its importance, it is usually also called the underlying operating system.

[0003] The in-vehicle operating system includes multiple different operating systems, and these multiple different operating systems need to cooperate with each other to achieve the intelligent and automated experience of the vehicle. Therefore, to avoid version issues affecting the normal operation of the in-vehicle operating system, these multiple operating systems are usually upgraded synchronously. However, current in-vehicle operating systems mostly use multi-core heterogeneous chips, and different processing cores of multi-core heterogeneous chips occupy different storage media, making it impossible to directly perform a full upgrade of multiple operating systems in a single system, thus affecting the upgrade efficiency of the in-vehicle operating system software. Summary of the Invention

[0004] In view of the above problems, this application proposes a method, device, and vehicle for starting and upgrading system software to improve the above problems.

[0005] In a first aspect, the present application provides a method for starting and upgrading system software, which is applied to a vehicle configured with multiple operating systems. The multiple operating systems include a vehicle operating system configured in a first application domain and a Linux operating system configured in a second application domain. The method includes: starting a first boot loader in the first application domain; in response to the first boot loader receiving an upgrade mode identifier, dumping the upgrade mode identifier to a first operating storage space; if the upgrade mode identifier is a specified character, starting a second boot loader in the second application domain; in response to the second boot loader parsing the specified character in the first operating storage space, obtaining a network firmware from an external storage device and storing it in a second operating storage space, where the network firmware includes an upgraded kernel, a configuration file on which the upgraded kernel depends for startup, and a root file system in a first format; starting the upgraded kernel, and invoking the upgraded kernel to start the root file system in the first format, and obtaining a firmware image package to be upgraded through the root file system in the first format; based on the firmware image package to be upgraded, performing firmware flashing on a first storage device configured in the first application domain and a second storage device configured in the second application domain respectively, so as to perform startup upgrade on the operating system software configured in the first application domain and the operating system software configured in the second application domain.

[0006] In a second aspect, the present application provides a system software startup and upgrade device, which runs on a vehicle configured with multiple operating systems. The multiple operating systems include a vehicle operating system configured in a first application domain and a Linux operating system configured in a second application domain. The device includes: a first program startup module for starting a first bootloader in the first application domain; an identifier dump module for, in response to the first bootloader receiving an upgrade mode identifier, dumping the upgrade mode identifier to a first running storage space; a second program startup module for, if the upgrade mode identifier is a specified character, starting a second bootloader in the second application domain; a network firmware acquisition module for, in response to the second bootloader parsing the specified character in the first running storage space, acquiring network firmware from an external storage device and storing it in a second running storage space, where the network firmware includes an upgraded kernel, a configuration file on which the upgraded kernel depends for startup, and a root file system in a first format; a firmware image package acquisition module for starting the upgraded kernel and invoking the upgraded kernel to start the root file system in the first format, and acquiring a firmware image package to be upgraded through the root file system in the first format; a startup upgrade module for performing firmware flashing on a first storage device configured in the first application domain and a second storage device configured in the second application domain respectively based on the firmware image package to be upgraded, so as to perform startup upgrade on the operating system software configured in the first application domain and the operating system software configured in the second application domain.

[0007] In a third aspect, the present application provides a vehicle, including one or more processors and a memory; one or more programs are stored in the memory and are configured to be executed by the one or more processors, and the one or more programs are configured to execute the above method.

[0008] In a fourth aspect, the present application provides a computer-readable storage medium, in which program code is stored, and when the program code runs, the above method is executed.

[0009] A method, apparatus, and vehicle for starting and upgrading system software provided by the present application. By starting the first bootloader in the first application domain; in response to the first bootloader receiving an upgrade mode identifier, dumping the upgrade mode identifier to the first running storage space; if the upgrade mode identifier is a specified character, starting the second bootloader in the second application domain; in response to the second bootloader parsing the specified character in the first running storage space, obtaining a network firmware from an external storage device and storing it in the second running storage space, the network firmware includes an upgraded kernel, a configuration file on which the upgraded kernel depends for startup, and a root file system in the first format; starting the upgraded kernel, and invoking the upgraded kernel to start the root file system in the first format, obtaining a firmware image package to be upgraded through the root file system in the first format; based on the firmware image package to be upgraded, performing firmware flashing on the first storage device configured in the first application domain and the second storage device configured in the second application domain respectively, so as to perform startup upgrade on the operating system software configured in the first application domain and the operating system software configured in the second application domain. This method realizes entering the software self-upgrade process without introducing external dependencies by controlling the startup of the second bootloader based on the mode identifier; reduces the hardware layout space and device cost during the upgrade process by obtaining the network firmware from the external storage device to construct the upgrade environment; and simplifies the inter-core transfer process of heterogeneous core firmware by having the upgraded kernel in the second application domain fully control the upgrade flashing process of the first storage device and the second storage device, thereby improving the flashing efficiency of the storage device firmware upgrade, further improving the upgrade efficiency of the in-vehicle operating system software, and also reducing the development and maintenance work of the corresponding software. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the accompanying drawings required for the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present application, and those skilled in the art can obtain other drawings without creative efforts based on these drawings.

[0011] Figure 1 The flowchart of a method for starting and upgrading system software according to an embodiment of the present application is shown.

[0012] Figure 2 The flowchart of a method for starting and upgrading system software according to another embodiment of the present application is shown.

[0013] Figure 3 The flowchart of a method for starting and upgrading system software according to still another embodiment of the present application is shown.

[0014] Figure 4 The structural block diagram of a system software startup and upgrade device proposed by an embodiment of the present application is shown.

[0015] Figure 5 The structural block diagram of a vehicle proposed by the present application is shown. Specific embodiments

[0016] Next, the technical solutions in the embodiments of the present application will be clearly and completely described with reference to the accompanying drawings in the embodiments of the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present application without creative efforts shall fall within the protection scope of the present application.

[0017] In an embodiment of the present application, the inventor proposed a system software startup and upgrade method, device, and vehicle. By starting the first bootloader in the first application domain; in response to the first bootloader receiving an upgrade mode identifier, dumping the upgrade mode identifier to the first running storage space; if the upgrade mode identifier is a specified character, starting the second bootloader in the second application domain; in response to the second bootloader parsing the specified character in the first running storage space, obtaining the network firmware from an external storage device and storing it in the second running storage space, where the network firmware includes an upgraded kernel, a configuration file on which the upgraded kernel depends for startup, and a root file system in the first format; starting the upgraded kernel, and calling the upgraded kernel to start the root file system in the first format, and obtaining a firmware image package to be upgraded through the root file system in the first format; based on the firmware image package to be upgraded, performing firmware flashing on the first storage device configured in the first application domain and the second storage device configured in the second application domain respectively, so as to perform startup upgrade on the operating system software configured in the first application domain and the operating system software configured in the second application domain. This method realizes entering the software self-upgrade process without introducing external dependencies by controlling the startup of the second bootloader based on the mode identifier; reduces the hardware layout space and device cost during the upgrade process by obtaining network firmware from an external storage device to construct an upgrade environment; and the upgraded kernel in the second application domain fully controls the upgrade and flashing process of the first storage device and the second storage device, eliminating the inter-core transmission process of heterogeneous core firmware, thereby improving the flashing efficiency of the storage device firmware upgrade, further improving the upgrade efficiency of the in-vehicle operating system software, and at the same time reducing the development and maintenance work of the corresponding software.

[0018] Please refer to Figure 1, a system software startup and upgrade method provided by an embodiment of the present application. This system software startup and upgrade method can be applied to a vehicle configured with multiple operating systems, and can be specifically used for the research and development and upgrade of the software of an in-vehicle multi-core heterogeneous system. The multiple operating systems include an in-vehicle operating system configured in the first application domain and a Linux operating system configured in the second application domain. Among them, the in-vehicle operating system configured in the first application domain can be a FreeRtos (Free Real Time Operating System) system or a Linux system, and the number of operating systems configured in the second application domain is not limited. For example, the number of operating systems configured in the second application domain can be one or more. Optionally, when the number of operating systems configured in the second application domain is one, the operating system configured in the second application domain can be a Linux operating system or an Android operating system; when the number of operating systems configured in the second application domain is multiple, the operating systems configured in the second application domain can include a Linux operating system and an Android operating system. The embodiment of the present application takes the number of operating systems configured in the second application domain being one and being a Linux operating system as an example for description, which does not constitute a limitation on this solution. The method includes:

[0019] Step S110: Start the first boot loader in the first application domain.

[0020] In the embodiment of the present application, the first application domain is the application processor core of the ARM (Advanced RISC Machines) processor, abbreviated as the Cortex-A core; the second application domain is the microcontroller processor core of the ARM processor, abbreviated as the Cortex-M core.

[0021] For the convenience of distinction, the boot loader in the first application domain is the first boot loader, and the boot loader in the second application domain is the second boot loader. The first boot loader in the embodiment of the present application is Bootloader, and the second boot loader is Uboot (Universal Boot Loader).

[0022] When it is necessary to upgrade the multi-operation systems of a vehicle, the first bootloader in the first application domain can be triggered to start. The system software startup upgrade method in this embodiment is in the R & D stage before leaving the factory. When the domain controller of the vehicle powers on, the underlying and application developers can send special characters to the multi-core heterogeneous SOC (System on Chip) software through the serial port. The first bootloader can recognize the content of the special characters and control the second bootloader to start in different ways according to the different recognized content, that is, the special characters can be used to identify the startup mode of the second bootloader.

[0023] Therefore, as an implementation method, the first bootloader can be controlled to start when it is detected that the domain controller powers on, so as to facilitate the timely recognition of the special characters transmitted through the serial port; as another implementation method, the first bootloader can also be started when it is detected that the serial port sends special characters to the multi-core heterogeneous SOC software, so as to avoid the consumption of memory resources caused by premature startup.

[0024] Step S120: In response to the first bootloader receiving the upgrade mode identifier, dump the upgrade mode identifier to the first running storage space.

[0025] After the first bootloader starts, it can quickly recognize the input content (i.e., the content of the special characters) sent to the multi-core heterogeneous SOC software through the serial port. In this embodiment, the upgrade mode identifier is the aforementioned special character (equivalent to representing the special character in the form of an identifier). The upgrade mode identifier includes a first upgrade mode identifier and a second upgrade mode (i.e., normal or regular upgrade mode) identifier. Both the first upgrade mode identifier and the second upgrade mode identifier can be understood as the content of the special characters, and the specific values of the first upgrade mode identifier and the second upgrade mode identifier are different.

[0026] As a way, if the first bootloader recognizes the upgrade mode identifier, the upgrade mode identifier can be dumped to the first running storage space. Among them, the first running storage space can be Sram (Static Random-Access Memory). The specific values of the first upgrade mode identifier and the second upgrade mode identifier can both be not limited. For example, the value of the first upgrade mode identifier can be "1", and the value of the second upgrade mode identifier can be "0".

[0027] Among them, dumping the upgrade mode identifier to the first running storage space can be understood as dumping the upgrade mode identifier from the first position of the first running storage space to the second position of the first running storage space. Optionally, the first position can be understood as the position visible only to the Cortex-M core in the first running storage space, and the second position can be understood as the position visible to both the Cortex-M core and the Cortex-A core in the first running storage space. By dumping the upgrade mode identifier from the position visible to the M core to the position visible to both the M core and the A core, the upgrade mode identifier can be made visible to the A core.

[0028] Optionally, the second bootloader in the second application domain can also be pre-moved to the first running storage space for operation, so as to quickly parse and identify the content of the upgrade mode identifier subsequently.

[0029] Step S130: If the upgrade mode identifier is a specified character, start the second bootloader in the second application domain.

[0030] In this embodiment, if the upgrade mode identifier is a specified character, it indicates that the current upgrade mode identifier is the first upgrade mode identifier, and the specified character is the specific value of the first upgrade mode identifier; if the upgrade mode identifier is not a specified character, it indicates that the current upgrade mode identifier is the second upgrade mode identifier. Optionally, the specified character can be the above-mentioned "1", and in some other embodiments, the specific value of the specified character can also be adjusted, and the specific value of the specified character can be not limited.

[0031] As an implementation, if the upgrade mode identifier is a specified character, it indicates that the application program of the multi-operating system will be started in the upgrade state mode. At this time, the second bootloader in the second application domain can be directly (triggered) started, without first starting the application program in the first application domain and then triggering the start of the second bootloader in the second application domain by the application program in the first application domain, that is, the start efficiency of the second bootloader can be improved, and then the start and upgrade efficiency of the system software of the multi-operating system can be improved.

[0032] As a specific implementation manner, during the process of triggering the start of the second bootloader in the second application domain, if the upgrade mode identifier is a specified character, the first application domain can be controlled to release the control access right of the first storage device, and the first application domain takes over the control access right of the first storage device, and then triggers the start of the second bootloader in the second application domain. Among them, the first application domain is configured with a first storage device, and the second application domain is configured with a second storage device. The first storage device can be a NOR Flash (non-volatile flash memory), and the second storage device can be an EMMC (Embedded MultiMedia Card). By allowing the Cortex-M core to completely abandon the operation control right of the system during the R & D state upgrade process and allowing the Cortex-A core to fully control the upgrade and flashing process, the inter-core transmission process of heterogeneous core firmware is omitted, the problem that the disk storage resources cannot be shared by heterogeneous cores at the same time is avoided, the overall R & D state flashing process is streamlined (the corresponding software development and maintenance work is reduced), and the R & D state flashing efficiency is improved.

[0033] Step S140: In response to the second bootloader parsing the specified character in the first operating storage space, obtain the network firmware in the external storage device and store it in the second operating storage space. The network firmware includes an upgraded kernel, a configuration file on which the upgraded kernel depends for startup, and a root file system in the first format.

[0034] Optionally, after the second bootloader starts, it can read and parse the upgrade mode identifier stored in the first operating storage space Sram. If the specified character is parsed, in response to the second bootloader parsing the specified character in the first operating storage space, the specified file transfer protocol can be called to obtain the network firmware in the external storage device and store it in the second operating storage space. Among them, the specified file transfer protocol can be the TFTP (Trivial File Transfer Protocol), the external storage device can be an external network connection device such as a computer, the network firmware includes an upgraded kernel (kernel), a configuration file (dtb) on which the upgraded kernel depends for startup, and a root file system (rootfs) in the first format (ramdisk), and the second operating storage space can be a DDR (Double DataRate SDRAM).

[0035] As a specific implementation, the small kernel, small device tree (configuration file on which the small kernel depends for startup), and small root file system in ramdisk format on the computer side can be obtained through the TFTP protocol service and cached in the DDR to form the operating environment required for firmware upgrade, facilitating the full upgrade of subsequent multi-operating system software. Here, "small" can be understood as having a smaller size (compared with related technologies). Optionally, while caching the obtained operating files in the DDR, the environment variables in the global area (preset default environment variable configuration) can also be parsed to construct the environment variables required for the subsequent startup of the root file system.

[0036] Optionally, when the application programs of the multi-operating system in the implementation of this application start in the upgrade state mode, their corresponding root file system is the systemv system; while when the application programs of the multi-operating system in the implementation of this application start in the non-upgrade state mode, their corresponding root file system is the systemd system, which is used for the fast parallel startup of linux operating system services and applications. The systemv system is smaller in size than the systemd system, which can ensure a smaller system space occupancy. The systemv system can also be used to construct the TFTP network firmware acquisition, Norflash erasure, Emmc partitioning, and erasure script environment.

[0037] Step S150: Start the upgrade state kernel, and call the upgrade state kernel to start the first format root file system, and obtain the firmware image package to be upgraded through the first format root file system.

[0038] In the case of caching the obtained network firmware in the DDR, the upgrade state kernel in the network firmware can be started first, and the upgrade state kernel can be called to start the first format root file system, and then the firmware image package to be upgraded can be obtained through the first format root file system. Optionally, the firmware image package to be upgraded includes the firmware required for the full upgrade of the system software of the multi-operating system.

[0039] As a specific implementation, after the upgrade state rootfs (i.e., the first format root file system) starts, it can automatically execute a pre-written script to obtain all the firmware to be flashed (i.e., the firmware image package to be upgraded), thereby realizing the firmware flashing upgrade of the storage device. The pre-written script includes the rootfs execution partition in ramdisk format, TFTP firmware acquisition, Nor flash erasure, and EMMC erasure function scripts.

[0040] In the implementation of this application, the kernel of the second storage device (EMMC) only includes the driver of the second storage device, and the upgrade state kernel includes the drivers of the first storage device and the second storage device.

[0041] To ensure a stable upgrade environment, before calling the upgraded kernel to start the first-format root file system, the drivers of the first storage device, the second storage device, and the network driver can be loaded into the upgraded kernel.

[0042] Step S160: Based on the firmware image package to be upgraded, perform firmware flashing on the first storage device configured in the first application domain and the second storage device configured in the second application domain respectively, so as to start the upgrade of the operating system software configured in the first application domain and the operating system software configured in the second application domain.

[0043] As an implementation manner, the firmware flashing can be performed on the first storage device configured in the first application domain and the second storage device configured in the second application domain respectively based on the firmware image package to be upgraded, so as to start the upgrade of the operating system software configured in the first application domain and the operating system software configured in the second application domain.

[0044] In the process of performing firmware flashing on the first storage device configured in the first application domain and the second storage device configured in the second application domain respectively based on the firmware image package to be upgraded, as a specific implementation manner, the firmware flashing can be first performed on the first storage device configured in the first application domain based on the firmware image package to be upgraded; then, the firmware flashing is performed on the second storage device configured in the second application domain based on the firmware image package to be upgraded.

[0045] Optionally, in some other implementation manners, the firmware flashing can also be first performed on the second storage device, and when the firmware flashing of the second storage device is completed, the firmware flashing is performed on the first storage device. Exemplarily, after the first-format root file system obtains the firmware image package to be upgraded, the EMMC can be first formatted and partitioned through the sfdisk instruction of the linux system, and then the Uboot environment variable image, kernel image, rootfs image, and application file system image of the Cortex-A core are flashed to the corresponding address area of the EMMC through the dd instruction; after the EMMC firmware is flashed, according to the storage address of the firmware in the Nor flash, the partition is erased through the flash_erase instruction, and finally the bootloader, app of the Cortex-M core, and the uboot binary image file of the Cortex-A core are flashed to the corresponding address area of the Nor flash through the mtd_debug instruction.

[0046] A method for starting and upgrading system software provided in this embodiment includes starting a first boot loader in the first application domain; in response to the first boot loader receiving an upgrade mode identifier, dumping the upgrade mode identifier to a first running storage space; if the upgrade mode identifier is a specified character, starting a second boot loader in the second application domain; in response to the second boot loader parsing the specified character in the first running storage space, obtaining a network firmware from an external storage device and storing it in a second running storage space, where the network firmware includes an upgraded kernel, a configuration file on which the upgraded kernel depends for startup, and a root file system in the first format; starting the upgraded kernel, and invoking the upgraded kernel to start the root file system in the first format, and obtaining a firmware image package to be upgraded through the root file system in the first format; performing firmware flashing on a first storage device configured in the first application domain and a second storage device configured in the second application domain respectively based on the firmware image package to be upgraded, so as to perform startup upgrade on the operating system software configured in the first application domain and the operating system software configured in the second application domain. This method realizes entering the software self-upgrade process without introducing external dependencies by controlling the startup of the second boot loader based on the mode identifier; constructs an upgrade environment by obtaining network firmware from an external storage device, reducing the hardware layout space and device cost during the upgrade process; the upgraded kernel in the second application domain fully controls the upgrade flashing process of the first storage device and the second storage device, eliminating the inter-core transfer process of heterogeneous core firmware, thereby improving the flashing efficiency of the storage device firmware upgrade, further improving the upgrade efficiency of the in-vehicle operating system software, and at the same time reducing the development and maintenance work of the corresponding software.

[0047] Please refer to Figure 2 , a method for starting and upgrading system software provided in another embodiment of this application, which can be applied to a vehicle configured with multiple operating systems, where the multiple operating systems include an in-vehicle operating system configured in a first application domain and a Linux operating system configured in a second application domain. The method includes:

[0048] Step S210: Start the first boot loader in the first application domain.

[0049] Among them, the specific implementation of step S210 can refer to the relevant description of step S110 in the foregoing embodiment, and will not be elaborated here.

[0050] Step S220: In response to the first boot loader receiving an upgrade mode identifier, dump the upgrade mode identifier to a first running storage space.

[0051] Among them, the specific implementation of step S220 can refer to the relevant description of step S120 in the foregoing embodiments, which will not be elaborated here.

[0052] Step S231: If the upgrade mode identifier is a specified character, start the second bootloader in the second application domain.

[0053] Among them, the specific implementation of step S231 can refer to the relevant description of step S130 in the foregoing embodiments, which will not be elaborated here.

[0054] Step S232: If the upgrade mode identifier is not a specified character, call the first bootloader to start the application in the first application domain.

[0055] The upgrade mode identifier in the embodiments of the present application can be used to control the startup mode of the second bootloader. Optionally, if the upgrade mode identifier is not a specified character, it indicates that the application of the multi-operating system will not be started in the upgrade state mode, but will be started in the normal mode. At this time, the first bootloader can be called to start the application in the first application domain first, that is, call the Bootloader to start the APP application of the Cortex-M core first.

[0056] Step S233: Call the application to start the second bootloader in the second application domain.

[0057] Furthermore, the application in the first application domain can be called to start the second bootloader in the second application domain, that is, call the APP application of the Cortex-M core to start the Uboot software of the Cortex-A core.

[0058] Step S240: In response to the second bootloader parsing the specified character in the first running storage space, obtain the network firmware in the external storage device and store it in the second running storage space. The network firmware includes an upgrade state kernel, a configuration file on which the upgrade state kernel depends for startup, and a first format root file system.

[0059] Among them, the specific implementation of step S240 can refer to the relevant description of step S140 in the foregoing embodiments, which will not be elaborated here.

[0060] Step S250: Start the upgrade state kernel, and call the upgrade state kernel to start the first format root file system, and obtain the firmware image package to be upgraded through the first format root file system.

[0061] Among them, the specific implementation of step S250 can refer to the relevant description of step S150 in the foregoing embodiments, which will not be elaborated here.

[0062] Step S260: Based on the firmware image package to be upgraded, perform firmware flashing on the first storage device configured in the first application domain and the second storage device configured in the second application domain respectively, so as to perform startup upgrade on the operating system software configured in the first application domain and the operating system software configured in the second application domain.

[0063] Among them, for the specific implementation of step S260, reference can be made to the relevant description of step S160 in the foregoing embodiments, and details will not be elaborated herein.

[0064] A system software startup upgrade method provided in this embodiment includes: starting the first bootloader in the first application domain; in response to the first bootloader receiving an upgrade mode identifier, dumping the upgrade mode identifier to the first operating storage space; if the upgrade mode identifier is a specified character, starting the second bootloader in the second application domain; if the upgrade mode identifier is not a specified character, calling the first bootloader to start the application in the first application domain; calling the application to start the second bootloader in the second application domain; in response to the second bootloader parsing the specified character in the first operating storage space, obtaining the network firmware in the external storage device and storing it in the second operating storage space, where the network firmware includes an upgraded kernel, a configuration file on which the upgraded kernel depends for startup, and a first-format root file system; starting the upgraded kernel, and calling the upgraded kernel to start the first-format root file system, and obtaining the firmware image package to be upgraded through the first-format root file system; based on the firmware image package to be upgraded, performing firmware flashing on the first storage device configured in the first application domain and the second storage device configured in the second application domain respectively, so as to perform startup upgrade on the operating system software configured in the first application domain and the operating system software configured in the second application domain. This method controls the startup of the second bootloader based on the mode identifier, realizes entering the software self-upgrade process without introducing external dependencies; constructs an upgrade environment by obtaining network firmware from an external storage device, reducing the hardware layout space and device cost during the upgrade process; the upgraded kernel in the second application domain fully controls the upgrade flashing process of the first storage device and the second storage device, eliminating the inter-core transmission process of heterogeneous-core firmware, thereby improving the flashing efficiency of the storage device firmware upgrade, further improving the upgrade efficiency of the in-vehicle operating system software, and at the same time reducing the development and maintenance work of the corresponding software.

[0065] Please refer to Figure 3, a system software startup and upgrade method provided by another embodiment of this application, can be applied to a vehicle configured with multiple operating systems. The multiple operating systems include an in-vehicle operating system configured in the first application domain and a Linux operating system configured in the second application domain. The method includes:

[0066] Step S310: Start the first boot loader in the first application domain.

[0067] Among them, the specific implementation of step S310 can refer to the relevant description of step S110 in the foregoing embodiment, and will not be elaborated here.

[0068] Step S320: In response to the first boot loader receiving an upgrade mode identifier, dump the upgrade mode identifier to the first operating storage space.

[0069] Among them, the specific implementation of step S320 can refer to the relevant description of step S120 in the foregoing embodiment, and will not be elaborated here.

[0070] Step S331: If the upgrade mode identifier is a specified character, start the second boot loader in the second application domain.

[0071] Among them, the specific implementation of step S331 can refer to the relevant description of step S130 in the foregoing embodiment, and will not be elaborated here.

[0072] Step S332: If the upgrade mode identifier is not a specified character, call the first boot loader to start the application in the first application domain.

[0073] Among them, the specific implementation of step S332 can refer to the relevant description of step S232 in the foregoing embodiment, and will not be elaborated here.

[0074] Step S333: Call the application to start the second boot loader in the second application domain.

[0075] Among them, the specific implementation of step S333 can refer to the relevant description of step S233 in the foregoing embodiment, and will not be elaborated here.

[0076] Step S341: In response to the second boot loader parsing the specified character in the first operating storage space, obtain the network firmware in the external storage device and store it in the second operating storage space. The network firmware includes an upgraded kernel, a configuration file on which the upgraded kernel depends for startup, and a root file system in the first format.

[0077] Among them, the specific implementation of step S341 can refer to the relevant description of step S140 in the foregoing embodiment, and will not be elaborated here.

[0078] Step S351: Start the upgraded kernel, and call the upgraded kernel to start the first - format root file system. Obtain the firmware image package to be upgraded through the first - format root file system.

[0079] Among them, the specific implementation of step S351 can refer to the relevant description of step S150 in the foregoing embodiments, and will not be elaborated here.

[0080] Step S361: Based on the firmware image package to be upgraded, perform firmware flashing on the first storage device configured in the first application domain and the second storage device configured in the second application domain respectively, so as to perform startup upgrade on the operating system software configured in the first application domain and the operating system software configured in the second application domain.

[0081] Among them, the specific implementation of step S361 can refer to the relevant description of step S160 in the foregoing embodiments, and will not be elaborated here.

[0082] Step S342: In response to the second bootloader not parsing the specified character in the first running storage space, call the second bootloader to start the kernel of the second storage device configured in the second application domain, and call the kernel to start the second - format root file system in the second storage device. Obtain the first firmware upgrade package and the second firmware upgrade package through the second - format root file system. The first firmware upgrade package is the firmware upgrade package corresponding to the first storage device, and the second firmware upgrade package is the firmware upgrade package corresponding to the second storage device.

[0083] Optionally, if the second bootloader does not parse the specified character in the first running storage space, it indicates that both the first bootloader and the second bootloader have mis - identified the upgrade mode identifier. At this time, the application programs of the multi - operating system can be started in the normal mode.

[0084] As a specific implementation manner, in response to the second bootloader not parsing the specified character in the first running storage space, call the second bootloader to start the kernel of the second storage device configured in the second application domain, and call the kernel to start the second - format root file system in the second storage device. Obtain the first firmware upgrade package and the second firmware upgrade package through the second - format root file system. The first firmware upgrade package is the firmware upgrade package corresponding to the first storage device, and the second firmware upgrade package is the firmware upgrade package corresponding to the second storage device. Among them, the second - format root file system is an Ext4 - format root file system. The first firmware upgrade package can be used to perform flashing upgrade on the firmware of the first storage device, and the second firmware upgrade package can be used to perform flashing upgrade on the firmware of the second storage device.

[0085] Optionally, in the process of obtaining the first firmware upgrade package and the second firmware upgrade package through the second-format root file system, the first firmware upgrade package and the second firmware upgrade package can be obtained from an external network device through the second-format root file system. Optionally, the external network device here can be a computer, or an external storage device such as a USB flash drive, an SD (Secure Digital Card) card, or a USB. The specific type of the external network device may not be limited.

[0086] Step S352: Send the first firmware upgrade package to the first storage device, and control the first application domain to perform firmware flashing on the first storage device based on the first firmware upgrade package, so as to start and upgrade the operating system software configured in the first application domain.

[0087] When the application programs of the multi-operating system start in the normal mode, the second application domain does not have the control right over the first storage device. The first application domain needs to control the first storage device. Therefore, in order not to affect the normal operation of the multi-operating system and to upgrade the application programs of the multi-operating system at the same time, the first firmware upgrade package can be sent to the first storage device, and the first application domain can be controlled to perform firmware flashing on the first storage device based on the first firmware upgrade package, so as to start and upgrade the operating system software configured in the first application domain.

[0088] Step S362: Perform firmware flashing on the second storage device based on the second firmware upgrade package, so as to start and upgrade the operating system software configured in the second application domain.

[0089] Optionally, in the process of starting and upgrading the operating system software of the first application domain, the second application domain can be synchronously controlled to perform firmware flashing on the second storage device based on the second firmware upgrade package, so as to start and upgrade the operating system software configured in the second application domain.

[0090] A system software startup and upgrade method provided in this embodiment includes: starting a first bootloader in the first application domain; in response to the first bootloader receiving an upgrade mode identifier, dumping the upgrade mode identifier to a first running storage space; if the upgrade mode identifier is a specified character, starting a second bootloader in the second application domain; if the upgrade mode identifier is not the specified character, calling the first bootloader to start an application in the first application domain; calling the application to start the second bootloader in the second application domain; in response to the second bootloader parsing the specified character in the first running storage space, obtaining a network firmware from an external storage device and storing it in a second running storage space, where the network firmware includes an upgraded kernel, a configuration file on which the upgraded kernel depends for startup, and a root file system in a first format; starting the upgraded kernel, and calling the upgraded kernel to start the root file system in the first format, obtaining a firmware image package to be upgraded through the root file system in the first format; based on the firmware image package to be upgraded, performing firmware flashing on a first storage device configured in the first application domain and a second storage device configured in the second application domain respectively, for startup and upgrade of the operating system software configured in the first application domain and the operating system software configured in the second application domain; in response to the second bootloader not parsing the specified character in the first running storage space, calling the second bootloader to start the kernel of the second storage device configured in the second application domain, and calling the kernel to start the root file system in a second format in the second storage device, obtaining a first firmware upgrade package and a second firmware upgrade package through the root file system in the second format, where the first firmware upgrade package is a firmware upgrade package corresponding to the first storage device, and the second firmware upgrade package is a firmware upgrade package corresponding to the second storage device; sending the first firmware upgrade package to the first storage device, and controlling the first application domain to perform firmware flashing on the first storage device based on the first firmware upgrade package, for startup and upgrade of the operating system software configured in the first application domain; performing firmware flashing on the second storage device based on the second firmware upgrade package, for startup and upgrade of the operating system software configured in the second application domain.

[0091] This method realizes entering the software self-upgrade process without introducing external dependencies by controlling the startup of the second bootloader based on a pattern identifier; obtains network firmware from an external storage device to construct an upgrade environment, reducing the hardware layout space and device cost during the upgrade process; and has the upgraded kernel in the second application domain fully control the upgrade and flashing process of the first storage device and the second storage device, eliminating the inter-core transfer process of heterogeneous firmware, thereby improving the flashing efficiency of the storage device firmware upgrade, further enhancing the upgrade efficiency of the in-vehicle operating system software, and also reducing the development and maintenance work of the corresponding software.

[0092] Meanwhile, a functional software environment of a multi-modal startup control mechanism is proposed, realizing that the upgrade and flashing system no longer depends on an external storage medium for startup, thus saving the hardware layout space and device cost.

[0093] Please refer to Figure 4 , a system software startup and upgrade device 400 provided by this application runs on a vehicle configured with multiple operating systems. The multiple operating systems include an in-vehicle operating system configured in the first application domain and a Linux operating system configured in the second application domain. The device 400 includes a first program startup module 410, an identifier dump module 420, a second program startup module 430, a network firmware acquisition module 440, a firmware image package acquisition module 450, and a startup and upgrade module 460:

[0094] The first program startup module 410 is used to start the first bootloader in the first application domain.

[0095] The identifier dump module 420 is used to dump the upgrade mode identifier to the first running storage space in response to the first bootloader receiving the upgrade mode identifier.

[0096] The second program startup module 430 is used to start the second bootloader in the second application domain if the upgrade mode identifier is a specified character.

[0097] As an implementation, the second program startup module 430 can be used to control the first application domain to release the control access right of the first storage device and trigger the startup of the second bootloader in the second application domain if the upgrade mode identifier is a specified character.

[0098] As an implementation, the second program startup module 430 can also be used to call the first bootloader to start the application in the first application domain and call the application to start the second bootloader in the second application domain if the upgrade mode identifier is not a specified character.

[0099] A network firmware acquisition module 440, configured to acquire network firmware from an external storage device and store it in a second operating storage space in response to the second bootloader parsing a specified character in the first operating storage space, where the network firmware includes an upgraded kernel, a configuration file on which the upgraded kernel depends for startup, and a root file system in a first format.

[0100] A firmware image package acquisition module 450, configured to start the upgraded kernel, call the upgraded kernel to start the root file system in the first format, and acquire a firmware image package to be upgraded through the root file system in the first format.

[0101] Wherein, before calling the upgraded kernel to start the root file system in the first format, the drivers of the first storage device, the drivers of the second storage device, and network drivers may be loaded into the upgraded kernel.

[0102] A startup upgrade module 460, configured to perform firmware flashing on a first storage device configured in the first application domain and a second storage device configured in the second application domain respectively based on the firmware image package to be upgraded, so as to perform startup upgrade on the operating system software configured in the first application domain and the operating system software configured in the second application domain.

[0103] In an embodiment of the present application, if the second bootloader does not parse the specified character in the first operating storage space, the firmware image package acquisition module 450 may be configured to, in response to the second bootloader not parsing the specified character in the first operating storage space, call the second bootloader to start the kernel of the second storage device configured in the second application domain, and call the kernel to start the root file system in the second format in the second storage device, and acquire a first firmware upgrade package and a second firmware upgrade package through the root file system in the second format, where the first firmware upgrade package is a firmware upgrade package corresponding to the first storage device, and the second firmware upgrade package is a firmware upgrade package corresponding to the second storage device. In this way, the startup upgrade module 460 may be configured to send the first firmware upgrade package to the first storage device, and control the first application domain to perform firmware flashing on the first storage device based on the first firmware upgrade package, so as to perform startup upgrade on the operating system software configured in the first application domain; perform firmware flashing on the second storage device based on the second firmware upgrade package, so as to perform startup upgrade on the operating system software configured in the second application domain.

[0104] In an embodiment of the present application, the kernel of the second storage device includes the driver of the second storage device, and the upgraded kernel includes the driver of the first storage device and the driver of the second storage device.

[0105] As an implementation, the startup upgrade module 460 can be used to first perform firmware flashing on the first storage device configured in the first application domain based on the firmware image package to be upgraded; and then perform firmware flashing on the second storage device configured in the second application domain based on the firmware image package to be upgraded.

[0106] Next, a vehicle provided by the present application will be described in conjunction with Figure 5 the following.

[0107] Please refer to Figure 5 , based on the above system software startup upgrade method and device, another vehicle 100 that can execute the foregoing system software startup upgrade method is further provided in an embodiment of the present application. The vehicle 100 includes one or more (only one is shown in the figure) processors 102, a memory 104, and a data acquisition module 106 that are coupled to each other. Among them, a program that can execute the content in the foregoing embodiment is stored in the memory 104, and the processor 102 can execute the program stored in the memory 104.

[0108] Among them, the processor 102 may include one or more processing cores. The processor 102 connects various parts within the entire vehicle 100 through various interfaces and lines, and executes various functions of the vehicle 100 and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 104, and by calling data stored in the memory 104. Optionally, the processor 102 may be implemented in at least one hardware form of a network processor (Neural network Processing Unit, NPU), a digital signal processing (Digital Signal Processing, DSP), a field programmable gate array (Field-Programmable GateArray, FPGA), and a programmable logic array (Programmable Logic Array, PLA). The processor 102 may integrate one or several combinations of a central processing unit (Central Processing Unit, CPU), a graphics processing unit (Graphics Processing Unit, GPU), a network processor (Neural network Processing Unit, NPU), and a modem. Among them, the CPU mainly processes the operating system, user interface, application programs, etc.; the GPU is responsible for rendering and drawing the displayed content; the NPU is responsible for processing multimedia data such as videos and images; the modem is responsible for processing wireless communications. It can be understood that the above modem may not be integrated into the processor 102 and may be implemented separately through a communication chip.

[0109] The memory 104 may include a Random Access Memory (RAM), or may also include a Read-Only Memory. The memory 104 can be used to store instructions, programs, codes, code sets, or instruction sets. The memory 104 may include a program storage area and a data storage area. Among them, the program storage area can store instructions for implementing the operating system, instructions for implementing at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing each of the following method embodiments, etc. The data storage area can also store data created during the use of the vehicle 100 (such as phone books, audio-video data, chat record data), etc.

[0110] The data acquisition module 106 can be used to obtain the driving state information of the vehicle 100. The data acquisition module 106 can be a lidar, a camera, a sensor, a GPS (Global Positioning System) navigation, etc.

[0111] An embodiment of the present application provides a computer-readable storage medium. Program code is stored in the computer-readable storage medium, and the program code can be called by a processor to execute the methods described in the above method embodiments.

[0112] The computer-readable storage medium can be an electronic memory such as a flash memory, an EEPROM (Electrically Erasable Programmable Read-Only Memory), an EPROM, a hard disk, or a ROM. Optionally, the computer-readable storage medium includes a non-transitory computer-readable storage medium. The computer-readable storage medium has a storage space for the program code for executing any method step in the above methods. These program codes can be read out from or written into one or more computer program products. The program codes can be compressed in an appropriate form, for example.

[0113] In summary, a method, apparatus, and vehicle for starting and upgrading system software provided by this application include: starting a first bootloader in the first application domain; in response to the first bootloader receiving an upgrade mode identifier, dumping the upgrade mode identifier to a first operating storage space; if the upgrade mode identifier is a specified character, starting a second bootloader in the second application domain; in response to the second bootloader parsing the specified character in the first operating storage space, obtaining a network firmware from an external storage device and storing it in a second operating storage space, where the network firmware includes an upgraded kernel, a configuration file on which the upgraded kernel depends for startup, and a root file system in a first format; starting the upgraded kernel and invoking the upgraded kernel to start the root file system in the first format, and obtaining a firmware image package to be upgraded through the root file system in the first format; based on the firmware image package to be upgraded, performing firmware flashing on a first storage device configured in the first application domain and a second storage device configured in the second application domain, respectively, for starting and upgrading the operating system software configured in the first application domain and the operating system software configured in the second application domain. This method controls the startup of the second bootloader based on a mode identifier, achieving entry into the software self-upgrade process without introducing external dependencies; by obtaining a network firmware from an external storage device to construct an upgrade environment, it reduces the hardware layout space and device costs during the upgrade process; by having the upgraded kernel in the second application domain fully control the upgrade flashing process of the first storage device and the second storage device, it eliminates the inter-core transmission process of heterogeneous kernels, thereby improving the flashing efficiency of the storage device firmware upgrade, further improving the upgrade efficiency of the in-vehicle operating system software, and also reducing the development and maintenance work of the corresponding software.

[0114] 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 of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the various embodiments of this application.

Claims

1. A method for starting and upgrading system software, characterized in that, Applied to a vehicle configured with multiple operating systems, the multiple operating systems include a vehicle operating system configured in a first application domain and a Linux operating system configured in a second application domain. The method includes: Start the first bootloader in the first application domain; In response to the first bootloader receiving an upgrade mode identifier, dump the upgrade mode identifier to the first operating storage space; If the upgrade mode identifier is a specified character, start the second bootloader in the second application domain; In response to the second bootloader parsing the specified character in the first operating storage space, obtain the network firmware in the external storage device and store it in the second operating storage space. The network firmware includes an upgraded kernel, a configuration file on which the upgraded kernel depends for startup, and a root file system in the first format; Start the upgraded kernel, and call the upgraded kernel to start the root file system in the first format. Obtain the firmware image package to be upgraded through the root file system in the first format; Based on the firmware image package to be upgraded, perform firmware flashing on the first storage device configured in the first application domain and the second storage device configured in the second application domain respectively, so as to perform startup upgrade on the operating system software configured in the first application domain and the operating system software configured in the second application domain.

2. The method according to claim 1, characterized in that, The "If the upgrade mode identifier is a specified character, start the second bootloader in the second application domain" includes: If the upgrade mode identifier is a specified character, control the first application domain to release the control access right of the first storage device; Start the second bootloader in the second application domain.

3. The method according to claim 1, wherein Before the "In response to the second bootloader parsing the specified character in the first operating storage space, obtain the network firmware in the external storage device and store it in the second operating storage space", the method further includes: If the upgrade mode identifier is not a specified character, call the first bootloader to start the application program in the first application domain; Call the application program to start the second bootloader in the second application domain.

4. The method according to claim 1 or 3, characterized in that, The method further includes: In response to the second bootloader not parsing the specified character in the first operating storage space, call the second bootloader to start the kernel of the second storage device configured in the second application domain, and call the kernel to start the root file system in the second format in the second storage device. Obtain a first firmware upgrade package and a second firmware upgrade package through the root file system in the second format. The first firmware upgrade package is a firmware upgrade package corresponding to the first storage device, and the second firmware upgrade package is a firmware upgrade package corresponding to the second storage device; Send the first firmware upgrade package to the first storage device, and control the first application domain to perform firmware flashing on the first storage device based on the first firmware upgrade package, so as to perform startup upgrade on the operating system software configured in the first application domain; Perform firmware flashing on the second storage device based on the second firmware upgrade package for starting and upgrading the operating system software configured in the second application domain.

5. The method according to claim 4, wherein The kernel of the second storage device includes the driver of the second storage device, and the upgraded kernel includes the drivers of the first storage device and the second storage device.

6. The method according to claim 1, characterized in that Before invoking the upgraded kernel to start the first format root file system, the method further includes: Loading the drivers of the first storage device, the drivers of the second storage device, and the network driver into the upgraded kernel.

7. The method according to any one of claims 1 to 6, characterized in that The performing firmware flashing on the first storage device configured in the first application domain and the second storage device configured in the second application domain respectively based on the firmware image package to be upgraded includes: Performing firmware flashing on the first storage device configured in the first application domain based on the firmware image package to be upgraded; Performing firmware flashing on the second storage device configured in the second application domain based on the firmware image package to be upgraded.

8. A system software startup and upgrade device, characterized in that, Running on a vehicle configured with multiple operating systems, the multiple operating systems including an in-vehicle operating system configured in a first application domain and a Linux operating system configured in a second application domain, the apparatus includes: A first program startup module for starting a first boot loader in the first application domain; An identifier dump module for, in response to the first boot loader receiving an upgrade mode identifier, dumping the upgrade mode identifier to a first running storage space; A second program startup module for, if the upgrade mode identifier is a specified character, starting a second boot loader in the second application domain; A network firmware acquisition module for, in response to the second boot loader parsing the specified character in the first running storage space, acquiring network firmware from an external storage device and storing it in a second running storage space, the network firmware including an upgraded kernel, a configuration file on which the upgraded kernel depends for startup, and a first format root file system; A firmware image package acquisition module for starting the upgraded kernel and invoking the upgraded kernel to start the first format root file system, and acquiring a firmware image package to be upgraded through the first format root file system; A startup upgrade module for performing firmware flashing on the first storage device configured in the first application domain and the second storage device configured in the second application domain respectively based on the firmware image package to be upgraded for starting and upgrading the operating system software configured in the first application domain and the operating system software configured in the second application domain.

9. A vehicle, characterized in that, Including one or more processors and a memory; One or more programs are stored in the memory and are configured to be executed by the one or more processors, and the one or more programs are configured to execute the method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, Program code is stored in the computer-readable storage medium, and when the program code is run by a processor, the method according to any one of claims 1-7 is executed.

Images