CN117215656A - Linux system-based self-adaptive vehicle chip method and device, electronic equipment and vehicle - Google Patents
Linux system-based self-adaptive vehicle chip method and device, electronic equipment and vehicle Download PDFInfo
- Publication number
- CN117215656A CN117215656A CN202311089382.5A CN202311089382A CN117215656A CN 117215656 A CN117215656 A CN 117215656A CN 202311089382 A CN202311089382 A CN 202311089382A CN 117215656 A CN117215656 A CN 117215656A
- Authority
- CN
- China
- Prior art keywords
- vehicle
- parameter
- parameters
- chip
- memory
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 49
- 230000002093 peripheral effect Effects 0.000 claims abstract description 20
- 230000002159 abnormal effect Effects 0.000 claims abstract description 12
- 238000013507 mapping Methods 0.000 claims abstract description 8
- 230000005856 abnormality Effects 0.000 claims abstract description 6
- 238000005192 partition Methods 0.000 claims description 91
- 238000004891 communication Methods 0.000 claims description 17
- 230000003044 adaptive effect Effects 0.000 claims description 14
- 238000004590 computer program Methods 0.000 claims description 8
- 238000010586 diagram Methods 0.000 description 9
- 238000012545 processing Methods 0.000 description 9
- 230000008569 process Effects 0.000 description 7
- 230000006870 function Effects 0.000 description 5
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 238000004883 computer application Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 238000000802 evaporation-induced self-assembly Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Landscapes
- Stored Programmes (AREA)
Abstract
The application discloses a method for self-adapting vehicle chip based on a Linux system, a self-adapting vehicle chip device based on the Linux system, an electronic device, a storage medium and a vehicle, wherein the method comprises the steps of starting the vehicle system, including starting a boot program of the vehicle system, initializing hardware equipment and establishing memory space mapping; judging the parameter compatibility of the vehicle-mounted chip and the chip peripheral according to the parameter data of the memory space; if the parameter is abnormal, refreshing the data according to the parameter pointed by the current parameter compatibility abnormality; if the parameter compatibility is normal, operating the vehicle-mounted system according to the parameter data of the current memory space; the chip peripheral equipment comprises a screen. By the scheme, the existing parameters and the parameters of the peripheral devices of the current chip are compared in the starting stage, the part with the abnormal compatibility is found, the new starting and the data refreshing are carried out according to the abnormal compatibility, and therefore the self-adaptive replacement of the chip is realized.
Description
Technical Field
The application relates to the field of self-adaption, in particular to a Linux system-based self-adaption vehicle chip method, a Linux system-based self-adaption vehicle chip device, electronic equipment, a storage medium and a vehicle.
Background
At present, the market of vehicle chips is dynamic, and the scheduled chips of the same vehicle type host machine can influence the delivery of the vehicle due to the reasons of power failure and the like. However, if the car machine chips of different models are changed, a developer is required to set different software system versions according to different chip parameters. In order to ensure the consistency of the software system platform, a new version cannot be set for all host chips at will, but the same software version is directly adapted to different host chips, and compatibility problems, such as common problems, can cause the problems of screen display, screen blackout and the like of a vehicle computer screen, can exist.
Therefore, a scheme of automatically detecting the chip and automatically adapting the chip is needed, and the same software version is reduced when different host chips are adapted, so that the conditions of screen display and screen blacking of a vehicle screen occur due to the adaptation of different chips.
Disclosure of Invention
The application aims to provide a Linux system-based self-adaptive vehicle chip method, a Linux system-based self-adaptive vehicle chip device, electronic equipment, a storage medium and a vehicle, and at least one technical problem is solved.
The application provides the following scheme:
according to one aspect of the present application, there is provided a Linux system-based self-adaptive vehicle chip method, including:
the method comprises the steps of starting a vehicle machine system, including a boot program of the vehicle machine system, initializing hardware equipment and establishing memory space mapping;
judging the parameter compatibility of the vehicle-mounted chip and the chip peripheral according to the parameter data of the memory space;
if the parameter is abnormal, refreshing the data according to the parameter pointed by the current parameter compatibility abnormality;
if the parameter compatibility is normal, operating the vehicle-mounted system according to the parameter data of the current memory space;
the chip peripheral equipment comprises a screen.
Further, the starting vehicle machine system includes:
starting a Linux system, including BootLoader starting, and loading parameters in a parameter partition of a param into a vehicle memory;
parameters in the param parameter partition comprise serializer parameters;
r7, starting the kernel, reading the parameters of the serializer in the memory of the vehicle, and configuring the screen frame rate;
the Kernel of Kernel starts to inquire the chip of the vehicle, obtains the parameters of the string former, compares the parameters of the current string former in the memory of the vehicle;
wherein,
if the string former parameter comparison is correct, the starting of the vehicle-mounted system is completed;
if the comparison of the string forming parameters is wrong, starting and inquiring the vehicle-to-vehicle chip according to the Kernel of Kernel, obtaining the string forming parameters, and updating the string forming parameters in the parameter partition of the parameter.
Further, the R7 kernel is started, and reads the serializer parameters in the memory of the vehicle, and the configuring the screen frame rate includes:
if the string former parameter in the memory of the vehicle is not read or the string former parameter in the memory of the vehicle is not read, setting the screen frame rate according to the preset default parameter;
if the string former parameters in the memory of the vehicle are successfully read and the parameter comparison is correct, setting the screen frame rate according to the read string former parameters in the memory of the vehicle.
Further, the Kernel of Kernel starts to inquire the vehicle engine chip, obtains the parameters of the string former, and comparing the parameters of the current string former in the vehicle engine memory comprises:
if the string former parameters in the memory of the vehicle are not read, the Kernel of the Kernel is restarted to inquire the vehicle chip according to the preset period, and the string former parameters are obtained.
Further, the param parameter partition comprises a param parameter A partition and a param parameter B partition;
BootLoader is started, and the string builder parameters in the param parameter A partition are loaded into the memory of the vehicle;
r7, starting the kernel, reading the parameters of the serializer in the memory of the vehicle, and configuring the screen frame rate;
the Kernel of Kernel starts to inquire the car machine chip, obtain the parameters of the string former, compare the parameters of the string former in the partition of parameter A of param;
if the string former parameters are in error contrast, writing the parameters acquired by the string former of the vehicle engine chip into the param parameter A partition, and sending a request for restarting the vehicle engine system;
before sending a request for restarting the vehicle machine system, synchronizing the serializer parameter data in the partition of the parameter A and the partition of the parameter B of the parameter A.
Further, the restarting vehicle system includes:
the BootLoader is started, and the string builder parameters in the param parameter B partition are loaded into the memory of the vehicle;
r7, starting the kernel, reading the parameters of the serializer in the memory of the vehicle, and configuring the screen frame rate;
the Kernel of Kernel starts to inquire the car machine chip, obtain the parameters of the string former, compare the parameters of the string former in the partition of parameter A of param;
if the comparison of the serializer parameters is correct, the serializer parameters in the parameter partition of the param are updated successfully.
According to two aspects of the present application, there is provided a Linux system-based self-adaptive vehicle chip device, the Linux system-based self-adaptive vehicle chip device comprising:
the starting guide module is used for starting the vehicle machine system, comprises a guide program for starting the vehicle machine system, initializes the hardware equipment and establishes memory space mapping;
the compatibility judging module is used for judging the parameter compatibility of the vehicle-mounted computer chip and the chip peripheral according to the parameter data of the memory space;
the exception handling module is used for refreshing data according to the parameters pointed by the current parameter compatibility exception if the parameters are compatible with the exception;
and the vehicle-mounted operation module is used for operating the vehicle-mounted system according to the parameter data of the current memory space if the parameter compatibility is normal.
According to three aspects of the present application, there is provided an electronic apparatus including: the device comprises a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory are communicated with each other through the communication bus;
the memory stores a computer program which, when executed by the processor, causes the processor to perform the steps of the Linux-based system-self-adaptive vehicle chip method.
According to four aspects of the present application, there is provided a computer-readable storage medium comprising: the method comprises the steps of storing a computer program executable by the electronic device, and enabling the electronic device to execute the self-adapting vehicle chip method based on the Linux system when the computer program runs on the electronic device.
According to five aspects of the present application, there is provided a vehicle including:
the electronic equipment is used for realizing the Linux system-based self-adaptive vehicle chip method;
the processor runs a program, and when the program runs, the data output from the electronic equipment executes the step of the self-adaptive vehicle chip method based on the Linux system;
and the storage medium is used for storing a program, and the program executes the Linux system-based self-adaptive vehicle chip method for the data output from the electronic device when in running.
Through the scheme, the following beneficial technical effects are obtained:
the application compares the existing parameters with the parameters of the peripheral of the current chip in the starting stage to find out the part with abnormal compatibility, and performs the new starting and data refreshing according to the abnormal compatibility, thereby realizing the self-adaptive replacement of the chip.
According to the application, the data in the param parameter A, B partition is updated from the new start by synchronizing the data in the param parameter A, B partition, so that a self-adaptive replacement chip is realized, and the self-adaptive replacement chip is compatible with a screen.
According to the application, default parameters are adopted temporarily, the screen is started temporarily, conditions are created for subsequent man-machine operation, the system is restarted, the self-adaptive replacement of the chip is completed, and the screen is compatible.
The application starts the inquiry car machine chip through the Kernel of Kernel to acquire the parameters of the serializer, thereby creating conditions for completing the self-adaptive replacement of the chip after starting, being compatible with a screen.
Drawings
Fig. 1 is a flowchart of a Linux system-based adaptive vehicle chip method according to one or more embodiments of the present application.
Fig. 2 is a block diagram of a Linux system-based self-adaptive vehicle chip device according to one or more embodiments of the present application.
Fig. 3 is a schematic flow chart of a vehicle system start-up adaptive chip according to an embodiment of the application.
FIG. 4 is a first flow chart illustrating the processing of an adaptive chip exception according to an embodiment of the present application.
FIG. 5 is a second flow diagram of processing an adaptive chip exception according to an embodiment of the present application.
FIG. 6 is a schematic diagram of a third flow for processing an adaptive chip exception according to an embodiment of the present application.
Fig. 7 is a block diagram of an electronic device according to a Linux system-based adaptive vehicle chip method according to one or more embodiments of the present application.
Detailed Description
The following description of the embodiments of the present application will be made apparent and fully in view of the accompanying drawings, in which some, but not all embodiments of the application are shown. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
Fig. 1 is a flowchart of a Linux system-based adaptive vehicle chip method according to one or more embodiments of the present application.
As shown in fig. 1, the Linux system-based self-adaptive vehicle chip method includes:
step S1, starting a vehicle-mounted system, including starting a boot program of the vehicle-mounted system, initializing hardware equipment and establishing memory space mapping;
step S2, judging the parameter compatibility of the vehicle-mounted chip and the chip peripheral according to the parameter data of the memory space;
step S3, if the parameter is compatible with the abnormality, refreshing the data according to the parameter pointed by the current parameter compatibility abnormality;
step S4, if the parameter compatibility is normal, operating the vehicle-mounted system according to the parameter data of the current memory space;
and S5, wherein the chip peripheral device comprises a screen.
Through the scheme, the following beneficial technical effects are obtained:
the application compares the existing parameters with the parameters of the peripheral of the current chip in the starting stage to find out the part with abnormal compatibility, and performs the new starting and data refreshing according to the abnormal compatibility, thereby realizing the self-adaptive replacement of the chip.
According to the application, the data in the param parameter A, B partition is updated from the new start by synchronizing the data in the param parameter A, B partition, so that a self-adaptive replacement chip is realized, and the self-adaptive replacement chip is compatible with a screen.
According to the application, default parameters are adopted temporarily, the screen is started temporarily, conditions are created for subsequent man-machine operation, the system is restarted, the self-adaptive replacement of the chip is completed, and the screen is compatible.
The application starts the inquiry car machine chip through the Kernel of Kernel to acquire the parameters of the serializer, thereby creating conditions for completing the self-adaptive replacement of the chip after starting, being compatible with a screen.
Specifically, a bootstrap program of the vehicle machine system, namely BootLoader starting, is started, data are imported in batches, and system starting is achieved. After the boot process is initiated, the hardware environment is new, possibly with a new chip, and the hardware device needs to be initialized to establish a memory space map for subsequent data storage and addressing.
To achieve compatibility, the current data of the peripheral devices need to be compared if the parameter data of the current peripheral devices are different from the initial parameter data. The data can be updated by refreshing the parameter of the current peripheral device by the parameter partition, and when the vehicle machine system is started again, the vehicle machine system can use the adapted data for starting and guiding due to the updated parameter partition, so that the self-adaptation of the system and the chip is realized after the new chip is replaced.
In this embodiment, the starting vehicle system includes:
starting a Linux system, including BootLoader starting, and loading parameters in a parameter partition of a param into a vehicle memory;
parameters in the parameter partition include serializer parameters;
r7, starting the kernel, reading the parameters of the serializer in the memory of the vehicle, and configuring the screen frame rate;
the Kernel of Kernel starts to inquire the chip of the vehicle, obtains the parameters of the string former, compares the parameters of the current string former in the memory of the vehicle;
wherein,
if the string former parameter comparison is correct, the starting of the vehicle-mounted system is completed;
if the comparison of the string forming parameters is wrong, starting and inquiring the vehicle-to-vehicle chip according to the Kernel of Kernel, obtaining the string forming parameters, and updating the string forming parameters in the parameter partition of the parameter.
Specifically, bootLoader, also known as a boot loader, is located on a computer or other computer application and is a program that directs the operating system to boot. The boot program start method and program are different depending on the type of the application model. Briefly, a BootLoader is a piece of applet that runs before the operating system kernel runs. Through the applet, the hardware device can be initialized, and a mapping diagram of the memory space can be built, so that the software and hardware environment of the system is brought into a proper state, and the correct environment is prepared for finally calling the kernel of the operating system.
Because of the influence of the system upgrading function, the system partition is divided into a param parameter AB double partition, an A partition is started by default, and a B partition is used as a backup partition. If the parameter information of the two partitions is not synchronous, abnormal conditions of the content of the parameter partitions may occur.
The R7 kernel refers to a quick reversing system of the vehicle, and after the whole vehicle is electrified, the R7 kernel is started and completed before the Android system of the vehicle is not started; and after the R7 kernel is started, reading the serializer parameters in the memory, configuring the screen frame rate, inquiring the parameters for comparison after the Android system is started, and normally starting after the comparison is correct.
The serializer can be regarded as a tool for converting data into a format, and is used for converting data in a memory, and unifying data such as system peripherals, system partitions and the like into data or parameters stored in the memory.
Kernel Kernel is the most basic part of the operating system, and is the core of an operating system. The system is based on the first layer of software expansion of hardware, provides the most basic function of an operating system, is the basis of the operation of the operating system, and is responsible for managing the processes, the memory, the kernel architecture, the device driver, the file and the network system of the system, and determining the performance and the stability of the system.
The two sources of the serializer parameters are a chip and a param parameter partition respectively, if comparison is successful, the starting of the vehicle-mounted system can be normalized, each time the system is started according to the data in the param parameter partition, and if comparison is failed, the data in the param parameter partition needs to be updated so as to be suitable for a newly replaced host chip.
In this embodiment, the R7 kernel is started, and reads the serializer parameters in the memory of the vehicle, and the configuring the screen frame rate includes:
if the string former parameter in the memory of the vehicle is not read or the string former parameter in the memory of the vehicle is not read, setting the screen frame rate according to the preset default parameter;
if the string former parameters in the memory of the vehicle are successfully read and the parameter comparison is correct, setting the screen frame rate according to the read string former parameters in the memory of the vehicle.
Specifically, the R7 kernel starts, thereby starting the use of the screen, the serializer parameter fails to read, and the screen frame rate is set with default parameters. The default parameters are measures for sacrificing performance to obtain compatibility, when no better screen configuration data exists in the starting process, the system is enabled to be used, and then the system is restarted and updated through the later data read from the new screen, so that the matched parameters are finally obtained.
In this embodiment, the Kernel starts to query the vehicle engine chip to obtain the serializer parameters, and comparing the current serializer parameters in the vehicle engine memory includes:
if the string former parameters in the memory of the vehicle are not read, the Kernel of the Kernel is restarted to inquire the vehicle chip according to the preset period, and the string former parameters are obtained.
Specifically, the Kernel of Kernel is used as the Kernel of the operating system, is a first layer of software expansion based on hardware, provides the most basic function of the operating system, and is the basis for the operation of the operating system. The device is used for inquiring the chip of the vehicle to obtain the parameters of the serializer of the chip.
In this embodiment, the param parameter partition includes a param parameter a partition and a param parameter B partition;
BootLoader is started, and the string builder parameters in the param parameter A partition are loaded into the memory of the vehicle;
r7, starting the kernel, reading the parameters of the serializer in the memory of the vehicle, and configuring the screen frame rate;
the Kernel of Kernel starts to inquire the car machine chip, obtain the parameters of the string former, compare the parameters of the string former in the partition of parameter A of param;
if the string former parameters are in error contrast, writing the parameters acquired by the string former of the vehicle engine chip into the param parameter A partition, and sending a request for restarting the vehicle engine system;
before sending a request for restarting the vehicle machine system, synchronizing the serializer parameter data in the partition of the parameter A and the partition of the parameter B of the parameter A.
Specifically, the param parameter A partition is enabled by default, and the param parameter B partition is used as a backup partition. And if the param parameter A is not successfully started, the param parameter B partition data is covered on the A partition. So that the next start-up can be successful.
In this embodiment, the restarting vehicle system includes:
BootLoader is started, and string builder parameters in the param parameter B partition are loaded into the memory of the vehicle;
r7, starting the kernel, reading the parameters of the serializer in the memory of the vehicle, and configuring the screen frame rate;
the Kernel of Kernel starts to inquire the car machine chip, obtain the parameters of the string former, compare the parameters of the string former in the partition of parameter A of param;
if the comparison of the serializer parameters is correct, the serializer parameters in the parameter partition of the param are updated successfully.
Specifically, after the data of the partition of the param parameter B is updated to the partition of the param parameter A, loading the serializer parameter in the partition of the param parameter B into the memory of the vehicle, comparing the param parameter A, and if the comparison is correct, successfully partitioning the data from the partition of the param parameter B to the partition of the param parameter A.
Fig. 2 is a block diagram of a Linux system-based self-adaptive vehicle chip device according to one or more embodiments of the present application.
The Linux system-based self-adaptive vehicle chip device shown in fig. 2 comprises: the system comprises a starting guide module, a compatibility judging module, an abnormality processing module and a vehicle machine running module;
the starting guide module is used for starting the vehicle machine system, comprises a guide program for starting a vehicle machine chip, initializes hardware equipment and establishes memory space mapping;
the compatibility judging module is used for judging the parameter compatibility of the vehicle-mounted computer chip and the chip peripheral according to the parameter data of the memory space;
the exception handling module is used for refreshing data according to the parameters pointed by the current parameter compatibility exception if the parameters are compatible with the exception;
and the vehicle-mounted operation module is used for operating the vehicle-mounted system according to the parameter data of the current memory space if the parameter compatibility is normal.
It should be noted that, although the system only discloses the start-up guiding module, the compatibility judging module, the exception handling module and the vehicle running module, the present application is not meant to limit the present device to the basic functional modules, but rather, the present application is meant to express that, based on the basic functional modules, one or more functional modules can be added arbitrarily by a person skilled in the art in combination with the prior art to form infinite embodiments or technical solutions, that is, the system is open rather than closed, and the scope of protection of the claims of the present application is not limited to the basic functional modules disclosed above because the present embodiment only discloses individual basic functional modules.
Fig. 3 is a schematic flow chart of a vehicle system start-up adaptive chip according to an embodiment of the application.
FIG. 4 is a first flow chart illustrating the processing of an adaptive chip exception according to an embodiment of the present application.
FIG. 5 is a second flow diagram of processing an adaptive chip exception according to an embodiment of the present application.
FIG. 6 is a schematic diagram of a third flow for processing an adaptive chip exception according to an embodiment of the present application.
In one embodiment, bootLoader is started, and the param parameter partition is loaded into the memory; r7 kernel starts, reads the serializer parameters in the memory, and configures the screen frame rate; starting a Kernel of Kernel, inquiring a serializer to obtain parameters, and comparing the parameters with the existing parameters; the parameters are correctly compared and normally started; the screen may be displayed normally. During this time, parameter partition anomalies may occur, and parameter configuration errors may occur. A refresh of the number partition, a reboot of the system, etc. are required.
In another embodiment, as shown in FIG. 3, an exception occurs in a parameter partition. For example, due to the influence of the system upgrade function, the system partition is divided into an AB double partition, an A partition is started by default, and a B partition is used as a backup partition. If the parameter information of the two partitions is not synchronous, abnormal conditions of the content of the parameter partitions may occur.
In another embodiment, (the abnormal parameter partition should be taken into account in case 1) based on the assumption, the case is shown in fig. 4, the parameter contrast configuration is wrong, new parameters are written into the parameter a partition of the param, the vehicle is restarted, the screen type in the AB parameter partition is detected before restarting, and synchronization is completed; bootLoader is started, and the param parameter B is loaded into the memory in a partitioned mode; r7 kernel starts, reads the serializer parameters in the memory, and configures the screen frame rate; the Kernel starts. Inquiring a serializer to obtain parameters, and comparing the parameters A of the param with the partitions; the parameters are correctly compared and normally started; the screen is displayed normally.
In another embodiment, (parameter partition exception handling case 2) in case of system exception or in case of write operation abort, a param partition loss or a param partition existence but no specified field data situation may occur. Based on the assumption, the application is started by a BootLoader as shown in fig. 5, and the param parameter partition is loaded into the memory; if the specified parameters are not read or the parameters are not read, adopting default configuration to configure the screen frame rate to be 30 frames; starting a Kernel of Kernel, inquiring a serializer to obtain parameters, and comparing the parameters with the existing parameters; the parameter acquisition fails, the normal starting is carried out, and the parameter is acquired again at regular time; the parameters are correctly compared and normally started, and the screen is normally displayed; and (3) comparing the parameters with errors, writing the parameters read to the param partition at the current time, and applying for restarting.
In another embodiment, it is contemplated that IIC communication is not as reliable as product differentiation using EOL configuration or other serial codes. Parameter configuration errors caused by IIC accidental communication faults or IIC communication failures can occur. Based on the above consideration, the parameter acquisition failure response case is shown in fig. 6, bootLoader is started, and the param parameter partition is loaded into the memory; if the specified parameters are not read or the parameters are not read, configuring screen frames to be 30 frames by adopting default configuration; the parameter acquisition fails, the normal starting is carried out, and the parameter is acquired again at regular time; inquiring a serializer, successfully acquiring parameters, comparing the parameters with the existing parameters, comparing the parameters with errors, writing the current read parameters into the param partition, and applying for restarting; the screen is normally displayed but there is a jump risk.
In another embodiment, after the original chip DS949 is replaced by the DS929 due to the reasons of the part of the vehicle, the bandwidth limit of the DS929 cannot meet the requirement of 60 frames of stable display of the original display screen, so that the new and old software needs to be distinguished and processed, and the software and the hardware are not compatible. According to the methods shown in fig. 3, 4, 5 and 6, the compiling software is tested, and the formal version is incorporated through the test.
Fig. 7 is a block diagram of an electronic device according to a Linux system-based adaptive vehicle chip method according to one or more embodiments of the present application.
As shown in fig. 7, the present application provides an electronic apparatus including: the device comprises a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory are communicated with each other through the communication bus;
the memory stores a computer program which, when executed by the processor, causes the processor to perform the steps of a Linux-based system-self-adapting vehicle chip method.
The present application also provides a computer readable storage medium storing a computer program executable by an electronic device, which when run on the electronic device causes the electronic device to perform the steps of a Linux system based self-adapting vehicle chip method.
The present application also provides a vehicle including:
the electronic equipment is used for realizing the self-adapting vehicle chip method based on the Linux system;
the processor runs a program, and when the program runs, the data output from the electronic equipment execute the step of the self-adaptive vehicle chip method based on the Linux system;
and the storage medium is used for storing a program, and the program executes the step of the Linux system-based self-adaptive vehicle chip method on the data output from the electronic device when in operation.
The communication bus mentioned above for the electronic devices may be a peripheral component interconnect standard (Peripheral Component Interconnect, PCI) bus or an extended industry standard architecture (Extended Industry Standard Architecture, EISA) bus, etc. The communication bus may be classified as an address bus, a data bus, a control bus, or the like. For ease of illustration, the figures are shown with only one bold line, but not with only one bus or one type of bus.
The electronic device includes a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on top of the operating system. The hardware layer includes hardware such as a central processing unit (CPU, central Processing Unit), a memory management unit (MMU, memory Management Unit), and a memory. The operating system may be any one or more computer operating systems that implement electronic device control via processes (processes), such as a Linux operating system, a Unix operating system, an Android operating system, an iOS operating system, or a windows operating system, etc. In addition, in the embodiment of the present application, the electronic device may be a handheld device such as a smart phone, a tablet computer, or an electronic device such as a desktop computer, a portable computer, which is not particularly limited in the embodiment of the present application.
The execution body controlled by the electronic device in the embodiment of the application can be the electronic device or a functional module in the electronic device, which can call a program and execute the program. The electronic device may obtain firmware corresponding to the storage medium, where the firmware corresponding to the storage medium is provided by the vendor, and the firmware corresponding to different storage media may be the same or different, which is not limited herein. After the electronic device obtains the firmware corresponding to the storage medium, the firmware corresponding to the storage medium can be written into the storage medium, specifically, the firmware corresponding to the storage medium is burned into the storage medium. The process of burning the firmware into the storage medium may be implemented by using the prior art, and will not be described in detail in the embodiment of the present application.
The electronic device may further obtain a reset command corresponding to the storage medium, where the reset command corresponding to the storage medium is provided by the provider, and the reset commands corresponding to different storage media may be the same or different, which is not limited herein.
At this time, the storage medium of the electronic device is a storage medium in which the corresponding firmware is written, and the electronic device may respond to a reset command corresponding to the storage medium in which the corresponding firmware is written, so that the electronic device resets the storage medium in which the corresponding firmware is written according to the reset command corresponding to the storage medium. The process of resetting the storage medium according to the reset command may be implemented in the prior art, and will not be described in detail in the embodiments of the present application.
For convenience of description, the above devices are described as being functionally divided into various units and modules. Of course, the functions of the units, modules may be implemented in one or more pieces of software and/or hardware when implementing the application.
It will be understood by those skilled in the art that all terms (including 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 unless defined otherwise. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the prior art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.
For the purposes of simplicity of explanation, the methodologies are shown and described as a series of acts, it is to be understood and appreciated by one of ordinary skill in the art that the methodologies are not limited by the order of acts, as some acts may, in accordance with the methodologies, take place in other order or concurrently. Further, those skilled in the art will appreciate that the embodiments described in the specification are presently preferred embodiments, and that the acts are not necessarily required by the embodiments of the application.
From the above description of embodiments, it will be apparent to those skilled in the art that the present application may be implemented in software plus a necessary general hardware platform. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., including several instructions for causing a computer device (which may be a personal computer, a server or a network device, etc.) to perform the method according to the embodiments or some parts of the embodiments of the present application.
Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present application, and not for limiting the same; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some or all of the technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the application.
Claims (10)
1. The Linux system-based self-adaptive vehicle chip method is characterized by comprising the following steps of:
the method comprises the steps of starting a vehicle machine system, including a boot program of the vehicle machine system, initializing hardware equipment and establishing memory space mapping;
judging the parameter compatibility of the vehicle-mounted chip and the chip peripheral according to the parameter data of the memory space;
if the parameter is abnormal, refreshing the data according to the parameter pointed by the current parameter compatibility abnormality;
if the parameter compatibility is normal, operating the vehicle-mounted system according to the parameter data of the current memory space;
the chip peripheral equipment comprises a screen.
2. The Linux system-based self-adaptive vehicle chip method of claim 1, wherein the starting vehicle system comprises:
starting a Linux system, including BootLoader starting, and loading parameters in a parameter partition of a param into a vehicle memory;
parameters in the param parameter partition comprise serializer parameters;
r7, starting the kernel, reading the parameters of the serializer in the memory of the vehicle, and configuring the screen frame rate;
the Kernel of Kernel starts to inquire the chip of the vehicle, obtains the parameters of the string former, compares the parameters of the current string former in the memory of the vehicle;
wherein,
if the string former parameter comparison is correct, the starting of the vehicle-mounted system is completed;
if the comparison of the string forming parameters is wrong, starting and inquiring the vehicle-to-vehicle chip according to the Kernel of Kernel, obtaining the string forming parameters, and updating the string forming parameters in the parameter partition of the parameter.
3. The Linux system-based self-adaptive vehicle chip method according to claim 2, wherein the R7 kernel is started, the serializer parameters in the vehicle memory are read, and the configuring the screen frame rate includes:
if the string former parameter in the memory of the vehicle is not read or the string former parameter in the memory of the vehicle is not read, setting the screen frame rate according to the preset default parameter;
if the string former parameters in the memory of the vehicle are successfully read and the parameter comparison is correct, setting the screen frame rate according to the read string former parameters in the memory of the vehicle.
4. The Linux system-based self-adaptive vehicle chip method according to claim 3, wherein the Kernel of Kernel starts to query the vehicle chip, obtains the serializer parameters, and comparing the current serializer parameters in the vehicle memory comprises:
if the string former parameters in the memory of the vehicle are not read, the Kernel of the Kernel is restarted to inquire the vehicle chip according to the preset period, and the string former parameters are obtained.
5. The Linux system-based self-adaptive vehicle chip method of claim 4, wherein said param parameter partitions include a param parameter a partition and a param parameter B partition;
BootLoader is started, and the string builder parameters in the param parameter A partition are loaded into the memory of the vehicle;
r7, starting the kernel, reading the parameters of the serializer in the memory of the vehicle, and configuring the screen frame rate;
the Kernel of Kernel starts to inquire the car machine chip, obtain the parameters of the string former, compare the parameters of the string former in the partition of parameter A of param;
if the comparison of the string former parameters is wrong, writing the string former parameters acquired by the query vehicle machine chip into the param parameter A partition, and sending a request for restarting the vehicle machine system;
before sending a request for restarting the vehicle machine system, synchronizing the serializer parameter data in the partition of the parameter A and the partition of the parameter B of the parameter A.
6. The Linux system-based self-adapting vehicle chip method of claim 5, wherein said restarting vehicle system comprises:
the BootLoader is started, and the string builder parameters in the param parameter B partition are loaded into the memory of the vehicle;
r7, starting the kernel, reading the parameters of the serializer in the memory of the vehicle, and configuring the screen frame rate;
the Kernel of Kernel starts to inquire the car machine chip, obtain the parameters of the string former, compare the parameters of the string former in the partition of parameter A of param;
if the comparison of the serializer parameters is correct, the serializer parameters in the parameter partition of the param are updated successfully.
7. The utility model provides a self-adaptation car chip device based on Linux system which characterized in that, self-adaptation car chip device based on Linux system includes:
the starting guide module is used for starting the vehicle machine system, comprises a guide program for starting the vehicle machine system, initializes the hardware equipment and establishes memory space mapping;
the compatibility judging module is used for judging the parameter compatibility of the vehicle-mounted computer chip and the chip peripheral according to the parameter data of the memory space;
the exception handling module is used for refreshing data according to the parameters pointed by the current parameter compatibility exception if the parameters are compatible with the exception;
and the vehicle-mounted operation module is used for operating the vehicle-mounted system according to the parameter data of the current memory space if the parameter compatibility is normal.
8. An electronic device, comprising: the device comprises a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory are communicated with each other through the communication bus;
the memory has stored therein a computer program which, when executed by the processor, causes the processor to perform the steps of the Linux system based adaptive vehicle chip method of any of claims 1 to 6.
9. A computer-readable storage medium, comprising: which stores a computer program executable by an electronic device for causing the electronic device to perform the steps of the Linux system-based adaptive vehicle chip method of any of claims 1 to 6 when the computer program is run on the electronic device.
10. A vehicle, characterized by comprising:
an electronic device for implementing the Linux system-based self-adaptive vehicle chip method of any one of claims 1 to 6;
a processor that runs a program, and data output from the electronic device when the program runs performs the steps of the Linux system-based self-adaptive vehicle chip method according to any one of claims 1 to 6;
a storage medium storing a program which, when run, performs the steps of the Linux system-based self-adaptive vehicle chip method of any one of claims 1 to 6 on data output from an electronic device.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311089382.5A CN117215656A (en) | 2023-08-28 | 2023-08-28 | Linux system-based self-adaptive vehicle chip method and device, electronic equipment and vehicle |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311089382.5A CN117215656A (en) | 2023-08-28 | 2023-08-28 | Linux system-based self-adaptive vehicle chip method and device, electronic equipment and vehicle |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117215656A true CN117215656A (en) | 2023-12-12 |
Family
ID=89037982
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311089382.5A Pending CN117215656A (en) | 2023-08-28 | 2023-08-28 | Linux system-based self-adaptive vehicle chip method and device, electronic equipment and vehicle |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117215656A (en) |
-
2023
- 2023-08-28 CN CN202311089382.5A patent/CN117215656A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8423991B2 (en) | Embedded network device and firmware upgrading method | |
| CN107179909A (en) | Method for upgrading software, device and computer-readable recording medium | |
| CN101807152B (en) | Basic output and input system for self verification of selection read only memory and verification method thereof | |
| WO2017202338A1 (en) | Method and system for loading drive to set-top box | |
| US11314665B2 (en) | Information processing system, information processing device, BIOS updating method for information processing device, and BIOS updating program for information processing device | |
| US20210294593A1 (en) | Method, apparatus, device, and storage medium for upgrading vehicle-mounted tbox | |
| US20040153778A1 (en) | Method, system and software for configuring a graphics processing communication mode | |
| CN103577201A (en) | Embedded dual system updating method and system | |
| CN111414285A (en) | Test method, test device and test equipment for starting function of server system | |
| US20050039081A1 (en) | Method of backing up BIOS settings | |
| CN108345464A (en) | A kind of the startup method and Android vehicle device of Android system | |
| CN115934447A (en) | Display information acquisition method and device, electronic equipment and storage medium | |
| CN115291946A (en) | Hongmong system transplanting method, device, electronic equipment and readable medium | |
| CN113377586A (en) | Automatic server detection method and device and storage medium | |
| US11061689B2 (en) | Synchronization method for performing bi-directional data synchronization for bios | |
| CN117687695A (en) | Information processing method, information processing device, electronic equipment and storage medium | |
| CN106484442B (en) | Server system and method for updating startup mapping file | |
| CN112433769A (en) | BMC starting method and device, computer equipment and storage medium | |
| CN117215656A (en) | Linux system-based self-adaptive vehicle chip method and device, electronic equipment and vehicle | |
| CN116088945A (en) | System firmware starting method, device, equipment and computer storage medium | |
| CN115766429A (en) | Matching method and device of system and edge computing gateway | |
| CN111459564B (en) | boot stage initialization compatible implementation method, system and computer equipment | |
| CN113766554A (en) | Method and device for acquiring WiFi calibration data and WiFi equipment calibration test system | |
| CN114265608A (en) | Method and device for upgrading TF card firmware, computer equipment and storage medium | |
| CN112667444A (en) | System upgrading method, storage medium and terminal equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |