Hardware adaptation method, platform, storage medium and computer device

Abstract

The application discloses a hardware adaptation method, platform, storage medium and computer equipment. The method comprises the following steps: obtaining hardware basic information of hardware to be adapted; based on the hardware basic information, searching and matching historical similar cases in a preset knowledge base, and extracting a reference adaptation path; performing compatibility evaluation on the hardware basic information based on the preset knowledge base, and generating a compatibility evaluation result; generating an adaptation scheme based on the historical similar cases and the compatibility evaluation result; generating a step-by-step operation guide based on the reference adaptation path and the adaptation scheme; and calling an automatic tool chain according to the step-by-step operation guide to perform adaptation processing on the hardware to be adapted. Through the above method, the utilization rate of hardware adaptation knowledge and the overall adaptation efficiency can be improved, non-expert users can also complete the adaptation work regularly and accurately, the reliability risk is effectively reduced, the reliability and quality of the hardware adaptation result are guaranteed, and the scale landing of the intelligent hardware ecology is promoted.

Description

Technical Field

[0001] This application relates to the field of operating system technology, and in particular to a hardware adaptation method, platform, storage medium, and computer device. Background Technology

[0002] In the ecosystem development of open-source operating systems such as OpenHarmony, southbound adaptation between the operating system and underlying chips and hardware circuits is a fundamental link supporting the operation of the entire industry chain. Currently, the industry generally adopts a human expert-based technical solution for smart hardware adaptation. Its standard operating procedure typically includes: First, hardware engineers manually review and understand the datasheets and circuit schematics provided by the chip manufacturer, manually extracting hardware information such as pin definitions, register base addresses, offsets, and interrupt logic; Second, developers manually write configuration files to describe hardware resources according to the hardware driver framework requirements of the operating system; Third, driver engineers manually write driver code based on existing experience to handle underlying logic such as clock, power, and peripheral protocols; Finally, in the debugging phase, the system is debugged and errors are checked mainly by relying on tools such as serial port logs and oscilloscopes through repeated modification and verification.

[0003] However, this existing technology, which relies on human experts, has significant limitations and drawbacks. First, hardware adaptation heavily depends on highly specialized engineers performing manual analysis and writing adaptation solutions, resulting in lengthy adaptation cycles, repetitive work, and a severe mismatch between R&D costs and benefits. Second, faced with the massive amounts of hexadecimal register addresses and complex hardware parameters in datasheets, manual review and input are prone to errors such as incorrect offsets and pin configuration conflicts. These human errors can lead to system instability or, in severe cases, burn out hardware prototypes due to abnormal current configurations, posing a high reliability risk. Furthermore, existing adaptation experience is highly dependent on individual engineers, and the industry lacks standardized knowledge bases and automated conversion tools. This makes it difficult to reuse historical experience across different chips and projects, hindering knowledge accumulation and preventing engineering efficiency from scaling with project volume. Summary of the Invention

[0004] This application mainly provides a hardware adaptation method, platform, storage medium, and computer device, aiming to solve the technical problem of low adaptation efficiency in existing hardware adaptation methods.

[0005] To address the aforementioned technical problems, this application adopts the following technical solution: providing a hardware adaptation method. This hardware adaptation method includes: acquiring basic hardware information of the hardware to be adapted; based on the basic hardware information, retrieving and matching historical similar cases in a preset knowledge base, and extracting a reference adaptation path; performing a compatibility assessment on the basic hardware information based on the preset knowledge base, and generating a compatibility assessment result; generating an adaptation scheme based on the historical similar cases and the compatibility assessment result; generating a step-by-step operation guide based on the reference adaptation path and the adaptation scheme; and invoking an automated toolchain according to the step-by-step operation guide to perform adaptation processing on the hardware to be adapted.

[0006] In some embodiments, after the automated toolchain is invoked according to the step-by-step operation to adapt the hardware to be adapted, the method further includes: generating a verification task list and executing preset test cases based on the verification task list; tracking the execution status of the test cases and generating an adaptation quality report.

[0007] In some embodiments, after the automated toolchain is invoked according to the step-by-step operation to perform adaptation processing on the hardware to be adapted, the method further includes: depositing the adaptation knowledge generated during the adaptation process into the preset knowledge base; depositing the adaptation knowledge generated during the adaptation process into the preset knowledge base includes: obtaining key adaptation information generated during the adaptation process; extracting structured fields from the key adaptation information to obtain the adaptation knowledge; updating the adaptation knowledge based on the knowledge correction instruction when a knowledge correction instruction is received; and recording the adaptation knowledge into the preset knowledge base.

[0008] In some embodiments, after generating an adaptation scheme based on the historical similar cases and the compatibility assessment results, the method further includes: receiving natural language interaction instructions input by the user; and providing detailed explanations, scheme comparisons, or scheme adjustments based on the natural language interaction instructions.

[0009] In some embodiments, the step of performing a compatibility assessment on the hardware basic information based on the preset knowledge base and generating a compatibility assessment result includes: retrieving compatibility data corresponding to the hardware basic information from the preset knowledge base; performing rule verification and reasoning on the hardware basic information based on the compatibility data, and generating the compatibility assessment result.

[0010] In some embodiments, the process of guiding the invocation of an automated toolchain according to the step-by-step operation to adapt the hardware to be adapted further includes: identifying whether an abnormal situation occurs; wherein, the abnormal situation includes at least one of the following: hardware driver framework loading failure, hardware configuration source code parsing error, driver entry binding failure, register configuration conflict, power configuration conflict, and peripheral protocol mismatch; the abnormal situation is identified by at least one of the following methods: built-in driver loading simulator, serial port log parsing, system monitoring tools, or user reporting; if an abnormal situation is identified, a solution suggestion and code patch are generated based on the abnormal situation, and an automatic repair process is initiated; the automatic repair process is used to repair the abnormal situation based on the solution suggestion and code patch.

[0011] In some embodiments, the hardware adaptation method is applied to the open-source HarmonyOS operating system; the step of generating an adaptation scheme based on the historical similar cases and the compatibility assessment results includes: automatically generating configuration files and driver entry templates that conform to the hardware driver framework standard of the open-source HarmonyOS operating system; the step of calling an automated toolchain according to the step-by-step operation guidance to adapt the hardware to be adapted includes: calling an automated toolchain that has the configuration parsing and driver loading process simulation built into the hardware driver framework, interfacing with the build toolchain of the open-source HarmonyOS operating system, and generating an adaptation package.

[0012] To address the aforementioned technical problems, another technical solution adopted in this application is to provide a hardware adaptation platform. This hardware adaptation platform is used to implement the hardware adaptation method described above. The platform includes a business interaction layer, a platform capability layer, and a technical support layer. The business interaction layer is used to: obtain basic hardware information of the hardware to be adapted; the platform capability layer is used to: based on the basic hardware information, retrieve and match historical similar cases in a preset knowledge base of the technical support layer, and extract a reference adaptation path; perform a compatibility assessment on the basic hardware information based on the preset knowledge base, and generate a compatibility assessment result; generate an adaptation scheme based on the historical similar cases and the compatibility assessment result; generate a step-by-step operation guide based on the reference adaptation path and the adaptation scheme; and invoke the automated toolchain of the technical support layer according to the step-by-step operation guide to perform adaptation processing on the hardware to be adapted; the technical support layer is used to: provide the preset knowledge base, the automated toolchain, and a data processing engine; the data processing engine is used to support the generation of the compatibility assessment result, the generation of the adaptation scheme, and the generation of the step-by-step operation guide.

[0013] To address the aforementioned technical problems, another technical solution adopted in this application is to provide a storage medium. This storage medium stores program data, which, when executed by a processor, implements the steps of the hardware adaptation method described above.

[0014] To address the aforementioned technical problems, another technical solution adopted in this application is to provide a computer device. This computer device includes a processor and a memory interconnected, the memory storing a computer program, and when the processor executes the computer program, it implements the steps of the hardware adaptation method described above.

[0015] The beneficial effects of this application are as follows: Unlike existing technologies, this application discloses a hardware adaptation method, platform, storage medium, and computer device. This application retrieves and matches historical similar cases based on a preset knowledge base and extracts reference adaptation paths. It then performs compatibility assessments using the knowledge base, and automatically generates adaptation schemes and step-by-step operation guides based on historical cases and compatibility assessment results. An automated toolchain is then invoked to execute the adaptation process. On the one hand, by utilizing the knowledge base to reuse historical adaptation experience, it replaces the purely manual manual review, configuration writing, and trial-and-error debugging methods of existing technologies, significantly reducing repetitive work, shortening the adaptation cycle, and improving the utilization rate of historical knowledge and overall adaptation efficiency. On the other hand, the automatic generation of adaptation schemes and step-by-step operation guides lowers the professional technical threshold for hardware adaptation, avoiding basic errors such as incorrect offset writing and pin configuration conflicts that are prone to occur during manual review and data entry. This allows non-expert users to complete the adaptation work in a standardized and accurate manner, effectively reducing reliability risks. Furthermore, the cooperation between compatibility assessment and the automated toolchain ensures the standardization of the adaptation process, which is conducive to ensuring the reliability and quality of hardware adaptation results and promoting the large-scale implementation of the smart hardware ecosystem. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, wherein: Figure 1 This is a flowchart illustrating an embodiment of the hardware adaptation method provided in this application; Figure 2 This is a schematic diagram of the structure of an embodiment of the hardware adaptation platform provided in this application; Figure 3 This is a schematic diagram of the structure of an embodiment of the storage medium provided in this application; Figure 4 This is a schematic diagram of the structure of an embodiment of the computer device provided in this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0018] The terms "first," "second," and "third" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0019] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0020] This application provides a hardware adaptation method, see reference. Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the hardware adaptation method provided in this application. The hardware adaptation method includes: Step 10: Obtain the basic hardware information of the hardware to be adapted.

[0021] In this embodiment, the hardware to be adapted refers to hardware devices that require southbound operating system adaptation, i.e., chips, development boards, or hardware modules that need driver adaptation with the operating system (such as the open-source HarmonyOS) to enable the operating system to run normally on the hardware platform. Its basic hardware information refers to a set of information describing the core technical parameters and functional characteristics of the hardware to be adapted. This information may include one or more of the following hardware parameters: chip model, chip architecture, peripheral list, pin definitions, register base address and offset, interrupt logic, clock configuration parameters, power management parameters, and peripheral communication protocol type. This basic hardware information constitutes the foundational input data for subsequent compatibility assessment, adaptation scheme generation, and step-by-step operation guidance generation. The completeness and accuracy of the basic hardware information directly affect the reliability of the adaptation scheme.

[0022] In this embodiment, this basic hardware information can be obtained by reading external technical documents (such as datasheets, circuit diagrams, and hardware design documents provided by the chip manufacturer), or by receiving user input (such as receiving basic hardware information manually entered by the user through form input boxes, drop-down selection boxes, or text editing areas in the interactive interface), or by parsing the unstructured or semi-structured hardware description text uploaded by the user through content parsing (such as using a large language model to conduct multi-round natural language question-and-answer sessions with the user to guide the user to gradually describe the chip model, peripheral list, and key configuration parameters of the hardware to be adapted, and automatically completing missing or uncertain hardware parameter fields; or using intelligent parsing engines such as document parsing models, optical character recognition engines, or structured data extraction tools to identify and extract key hardware parameters from datasheets, circuit diagrams, or hardware description documents). The specific method of obtaining basic hardware information can be flexibly selected according to the actual application scenario and user needs. As long as the core technical parameters and functional characteristics of the hardware to be adapted can be accurately obtained, it is understandable that it is within the scope of protection of this application.

[0023] In this embodiment, the basic hardware information can be stored in a structured data format to facilitate subsequent retrieval and matching in a preset knowledge base. The structured data format can be JSON. For example, a single record of basic hardware information can include fields such as "chip_model" (chip model), "chip_arch" (chip architecture), "peripherals" (peripheral list), "register_base" (register base address), "interrupt_config" (interrupt configuration), and "power_config" (power configuration). This structured storage makes the basic hardware information searchable and comparable, providing a standardized data foundation for subsequent knowledge base-based case matching and compatibility assessment.

[0024] This embodiment acquires the basic hardware information of the hardware to be adapted, enabling the unified collection and standardized organization of hardware parameters that were originally scattered from different sources such as datasheets and circuit schematics. This achieves structured input of hardware information, providing an accurate and complete data foundation for subsequent case retrieval, compatibility assessment, and adaptation scheme generation based on a preset knowledge base. This replaces the inefficient mode of manually consulting manuals and extracting parameters in the prior art, reducing errors such as incorrect offset writing and pin configuration conflicts caused by manual consulting and input from the source.

[0025] Optionally, in some embodiments, a multi-role collaboration mechanism is also supported during the process of acquiring basic hardware information of the hardware to be adapted. Specifically, the basic hardware information can be provided by multiple different user roles (such as hardware engineers, driver engineers, and project administrators), with different roles having different operating permissions. For example, hardware engineers are responsible for entering basic hardware information such as chip models and peripheral lists, driver engineers are responsible for confirming driver-related configuration parameters, and project administrators are responsible for task allocation and progress monitoring. During the specific acquisition of basic hardware information, a role-based permission control mechanism can be used to assign corresponding operating permissions and data access scopes to different user roles, realizing role-based entry and collaborative confirmation of basic hardware information. At the same time, the execution progress of the adaptation task and the completion status of each role can be visualized using a visual interface to display the task allocation, the completion progress of each stage, and pending items, so that users of each role can understand their own pending items and the progress of the overall adaptation work in a timely manner. In addition, in subsequent stages such as adaptation solution generation, adaptation processing execution, and adaptation quality verification, this multi-role collaboration mechanism can also be used to realize multi-role review of the adaptation solution, collaborative troubleshooting of problems during the adaptation process, and joint acceptance of the adaptation results. This multi-role collaboration mechanism allows for the reasonable allocation of tasks from different professional fields to users with corresponding roles, improving the professionalism and collaboration efficiency of the adaptation work. At the same time, the design of task allocation and progress visualization makes project management more transparent and controllable.

[0026] Step 20: Based on the basic hardware information, search and match historical similar cases in the preset knowledge base, and extract reference adaptation paths.

[0027] In this embodiment, the preset knowledge base refers to a database storing structured knowledge such as hardware specifications, driver source code snippets, historical adaptation cases, troubleshooting experience, and compatibility data. The historical adaptation cases in the preset knowledge base record complete process information for each previous hardware adaptation task, including but not limited to the adapted chip model, chip architecture, peripheral list, Hardware Driver Foundation (HDF) configuration, adaptation path, problems encountered and solutions during the adaptation process, compatibility score, and applicable operating system version. By storing historical adaptation experience in the form of structured cases in the preset knowledge base, adaptation experience across different chips and projects can be effectively accumulated and reused, avoiding the problem in existing technologies where adaptation experience highly depends on individual engineers and knowledge cannot be effectively accumulated and passed on.

[0028] In this embodiment, each historical adaptation case can be stored in a structured data format, such as JSON. A historical adaptation case record can include fields such as "case_id" (case identifier), "chip_model" (chip model), "chip_arch" (chip architecture), "peripherals" (peripheral list), "hdf_config" (hardware driver framework configuration content, including configuration file content and driver entry code), "compatibility_score" (compatibility score), "adaptation_path" (adaptation path, recording the entire process sequence from hardware information collection to adaptation completion), "logs_patches" (logs and patch records, recording problems encountered during adaptation and corresponding solutions), and "oh_version" (operating system version). Among them, the hardware parameter fields such as chip model, chip architecture, and peripheral list correspond to the hardware basic information fields mentioned in step 10, so that similarity calculation can be performed based on the hardware basic information and the hardware parameters of historical cases to achieve accurate case matching.

[0029] In this embodiment, after obtaining the basic hardware information of the hardware to be adapted, a search is performed in a preset knowledge base based on this basic hardware information to match the most similar historical adaptation cases. Specifically, the basic hardware information can be converted into a vector representation, and the historical adaptation cases closest to the current hardware basic information in the feature space can be found in the preset knowledge base using vector similarity retrieval. Simultaneously, the search results can be further filtered and sorted using hardware driver framework feature matching. For example, key fields such as the peripheral list and chip architecture in the basic hardware information can be extracted and compared with the corresponding fields of each historical adaptation case in the preset knowledge base to calculate a comprehensive similarity score. Candidate cases are then sorted from high to low according to their similarity scores, and one or more historical adaptation cases with the highest similarity scores are selected as the matching results. Vector similarity retrieval can be achieved using nearest neighbor search technology based on vector embedding models. This technology serves as a core retrieval component in the Retrieval-Augmented Generation (RAG) architecture. Combined with the generative capabilities of Large Language Models (LLMs), it enables retrieval-enhanced solution generation. This involves converting basic hardware information into high-dimensional vectors using a pre-trained text embedding model, and then performing nearest neighbor search within a pre-defined knowledge base's vector index to quickly locate the most semantically relevant historical cases. This hybrid retrieval strategy, combining vector similarity retrieval with hardware-driven framework feature matching, captures the semantic relationships between hardware parameters while ensuring substantial similarity in technical features, thereby improving the accuracy and reliability of case matching.

[0030] In this embodiment, after matching historical similar cases, a reference adaptation path needs to be extracted from those cases. The reference adaptation path refers to the complete operational path from hardware information acquisition to adaptation completion recorded in the historical similar cases. For example, a reference adaptation path can be represented as a sequence of steps such as "acquisition → pre-evaluation → configuration file generation → driver entry function filling → verification," which records the execution order and key operation nodes of each adaptation stage in historical successful cases. Specifically, the reference adaptation path can be extracted from the matched "adaptation_path" field, or it can be obtained by semantically parsing and reconstructing the step records of historical adaptation cases using a large language model. Furthermore, in this embodiment, after extracting the reference adaptation path, it can be dynamically adjusted based on the basic hardware information of the hardware to be adapted, making it more suitable for the actual needs of the current adaptation task. For example, when the list of peripherals for the current hardware to be adapted differs from historical similar cases, the adaptation steps related to the peripherals can be added or removed; when the operating system version of the current hardware to be adapted differs from historical similar cases, the generation rules and verification standards of the configuration file can be adjusted. Dynamic adjustments to the reference adaptation path can be achieved using the reasoning capabilities of a large language model. Specifically, the large language model automatically generates the adjusted adaptation path based on the differences between the current hardware's basic information and historical similar cases, and outputs it as a visual flowchart and step list, allowing users to intuitively understand the overall process of subsequent adaptation work and the expected output of each step.

[0031] This embodiment leverages historical similar cases retrieved from a pre-defined knowledge base and extracts reference adaptation paths. This allows for the full utilization of historical adaptation experience to provide reference and guidance for the current adaptation task, avoiding the problem of reinventing the wheel and starting from scratch for each adaptation, as is common in existing technologies. Furthermore, the hybrid retrieval strategy combining vector similarity retrieval and hardware-driven framework feature matching ensures the accuracy and relevance of case matching. This enables the reference adaptation paths to provide valuable process guidance for the current adaptation task, laying an experiential foundation for the generation of subsequent adaptation solutions.

[0032] Step 30: Perform a compatibility assessment on the basic hardware information based on the preset knowledge base and generate a compatibility assessment result.

[0033] In this embodiment, compatibility assessment refers to the process of systematically evaluating the compatibility between the basic hardware information of the hardware to be adapted and the target operating system. The compatibility assessment results are used to identify potential compatibility risks and precautions that the hardware to be adapted may face when running on the target operating system, providing a basis for decision-making in the subsequent generation of adaptation solutions. The dimensions of compatibility assessment may include, but are not limited to: whether the chip architecture matches the operating system's support scope, whether each peripheral in the peripheral list has corresponding driver support, whether the register configuration is consistent with the operating system's hardware abstraction layer definition, whether the power management parameters are within the operating system's power supply strategy range, and whether the interrupt configuration is compatible with the operating system's interrupt allocation mechanism. By systematically assessing these multiple dimensions, the compatibility risks that the hardware to be adapted may face during the adaptation process can be comprehensively identified, avoiding rework and resource waste caused by discovering compatibility issues only during the adaptation execution phase.

[0034] In this embodiment, compatibility assessment is performed based on a preset knowledge base. The preset knowledge base stores a large amount of compatibility data from historical adaptation cases, including the success rate of each chip model under different operating system versions, known compatibility issues and corresponding solutions, and recommended configuration ranges for hardware parameters. When performing compatibility assessment on basic hardware information based on the preset knowledge base, compatibility data related to the current basic hardware information can be retrieved first. For example, historical adaptation records for the same or similar chip models, driver compatibility information for the same peripheral types, etc., can be retrieved. Then, based on the retrieved compatibility data, combined with preset assessment rules and reasoning logic, each dimension of the basic hardware information is evaluated one by one, ultimately generating a compatibility assessment result. The compatibility assessment result can be presented in a structured form, such as including scores for each assessment dimension, risk level indicators (e.g., high risk, medium risk, low risk), specific risk descriptions, and suggested countermeasures. By using compatibility assessment based on the preset knowledge base, compatibility experience scattered across various historical adaptation cases can be centrally utilized, providing comprehensive and accurate compatibility risk warnings for the current adaptation task.

[0035] In this embodiment, compatibility assessment can be achieved by combining the reasoning capabilities of a large language model with compatibility data in a pre-defined knowledge base. Specifically, basic hardware information and retrieved compatibility data can be used as context input to the large language model. The large language model then performs comprehensive reasoning analysis on various dimensions of the basic hardware information based on historical experience in the compatibility data and pre-defined assessment rules, generating a compatibility assessment result that includes risk level, risk description, and recommended measures. Simultaneously, the compatibility assessment can also be validated using the hardware driver framework's rule engine. For example, the rule engine can verify whether configuration parameters meet the hardware driver framework's specification requirements and whether the driver interface is consistent with the hardware driver framework's standard interface. By combining rule validation with large language model reasoning, the compatibility assessment result ensures both rule-level rigor and experience-level intelligence.

[0036] This embodiment performs a compatibility assessment of basic hardware information based on a preset knowledge base, which can identify potential compatibility risks in advance before the adaptation is executed. This allows users to develop response strategies for high-risk items during the adaptation solution development stage, avoiding the inefficient mode in the prior art where compatibility issues are only discovered during the debugging stage and troubleshooting is done through repeated trial and error. This effectively shortens the adaptation cycle and improves the adaptation success rate.

[0037] Optionally, in some embodiments, a compatibility assessment of the hardware basic information is performed based on a preset knowledge base to generate a compatibility assessment result, including: retrieving compatibility data corresponding to the hardware basic information from the preset knowledge base; performing rule verification and reasoning on the hardware basic information based on the compatibility data to generate a compatibility assessment result.

[0038] In this optional embodiment, retrieving compatibility data corresponding to basic hardware information from a preset knowledge base refers to searching for relevant historical compatibility records in the preset knowledge base based on key fields (such as chip model, chip architecture, peripheral list, etc.) within the basic hardware information. Specifically, vector retrieval can be used to convert the basic hardware information into a vector representation, and a nearest neighbor search can be performed in the compatibility data vector index of the preset knowledge base to obtain the most semantically relevant compatibility data entries. Alternatively, keyword matching can be used to directly perform precise or fuzzy searches in the preset knowledge base using key fields such as chip model and peripheral type to obtain corresponding historical compatibility records. By combining vector retrieval with keyword matching, it is possible to ensure that the retrieval of compatibility data has both semantic breadth and technical feature precision, thereby providing comprehensive and accurate reference data for subsequent rule verification and reasoning.

[0039] In this optional embodiment, performing rule verification and reasoning on basic hardware information based on compatibility data to generate a compatibility assessment result refers to combining the retrieved compatibility data with preset assessment rules to systematically verify and reason about various dimensions of the basic hardware information. Rule verification may include: verifying whether the chip architecture is in the operating system's support list; verifying whether each peripheral in the peripheral list has corresponding driver support; verifying whether the register base address and offset conflict with the operating system's hardware abstraction layer definition; verifying whether the power management parameters are within the operating system's power supply strategy range; and verifying whether the interrupt configuration is compatible with the operating system's interrupt allocation mechanism. Reasoning analysis may include: inferring the overall compatibility probability of the current basic hardware information based on the adaptation success rate of the same or similar chip models in historical compatibility data; and inferring the compatibility risks and suggested countermeasures that the current basic hardware information may face based on known compatibility issues and solutions in historical compatibility data. Reasoning analysis can be implemented using the reasoning capabilities of a large language model, i.e., the large language model performs comprehensive reasoning on various dimensions of the basic hardware information based on the retrieved compatibility data and preset assessment rules to generate a compatibility assessment result that includes risk level, risk description, and suggested measures. By combining rule validation with reasoning analysis, we can ensure that the compatibility assessment results have both the rigor of the rule level and the intelligence of the experience level, thus providing comprehensive and reliable decision support for the generation of subsequent adaptation solutions.

[0040] Step 40: Generate an adaptation solution based on historical similar cases and compatibility assessment results.

[0041] In this embodiment, the adaptation scheme refers to the specific adaptation strategy and implementation plan for the hardware to be adapted. Its content may include, but is not limited to: the type and content template of the configuration file to be generated, the driver code framework and key functions to be written, the hardware parameters to be configured and their recommended value ranges, the risk points to be noted during the adaptation process and corresponding countermeasures, the priority order of adaptation, and the dependencies between each stage. The generation of the adaptation scheme is based on two core inputs: first, the historical similar cases matched in step 20; and second, the compatibility assessment results generated in step 30. Historical similar cases provide practically verified adaptation paths and successful experiences, while the compatibility assessment results provide compatibility risks and precautions for the current hardware to be adapted. Combining these two can generate an adaptation scheme that is both experientially valuable and has targeted risk response capabilities.

[0042] In this embodiment, the specific process of generating an adaptation solution may include: First, extracting reference information such as adaptation paths, configuration file templates, and driver code frameworks from historical similar cases; second, adjusting and optimizing the reference information based on the risk items and precautions identified in the compatibility assessment results, such as adding additional configuration verification steps or alternative solutions for dimensions with high compatibility risks, and pre-developing avoidance strategies for known issues indicated in the compatibility assessment; third, integrating the adjusted reference information into a complete adaptation solution, which covers the entire process from configuration file generation to driver code writing and verification testing. The adaptation solution can be presented in a structured format, such as including sections on solution overview, detailed steps, configuration parameter list, and risk mitigation measures, so that users can fully understand the overall planning of the adaptation work and the specific requirements of each stage.

[0043] In this embodiment, the adaptation scheme can be generated using the content generation capabilities of a large language model. Specifically, reference information from historical similar cases and compatibility assessment results can be used as contextual input. A preset prompt word template guides the large language model to generate the adaptation scheme. Alternatively, retrieval-enhanced generation technology can be used to inject matched historical similar cases and compatibility assessment results into the generation process. Based on successful experiences from historical similar cases and risk warnings from compatibility assessment results, the large language model automatically generates a personalized adaptation scheme for the current hardware to be adapted. This adaptation scheme may include specific configuration file content, driver code snippets, recommended parameter values, etc., providing users with a practical execution reference. This avoids the subjectivity and uncertainty of manually writing adaptation schemes based on engineers' personal experience in existing technologies, improving the standardization and reliability of the adaptation scheme.

[0044] This embodiment generates adaptation solutions based on historical similar cases and compatibility assessment results. It can organically combine historical adaptation experience with the compatibility characteristics of current hardware to generate adaptation solutions that have both experience reference value and targeted risk response capabilities. This replaces the inefficient mode of manually writing adaptation solutions based on the personal experience of engineers in the prior art, and improves the quality and generation efficiency of adaptation solutions.

[0045] Optionally, in some embodiments, after generating an adaptation scheme based on historical similar cases and compatibility assessment results, the method further includes: receiving natural language interaction instructions input by the user; and providing detailed explanations, scheme comparisons, or scheme adjustments based on the natural language interaction instructions.

[0046] In this optional embodiment, natural language interaction commands refer to questions, comparisons, or modification requests for the adaptation scheme input by the user in natural language. For example, the user can input natural language interaction commands such as "Why is this configuration parameter value range recommended?", "What are the advantages and disadvantages of this scheme compared to another scheme?", and "Please adjust the clock configuration in the scheme to the specified frequency". By supporting natural language interaction, users do not need to master professional configuration syntax or coding skills to gain a deep understanding of the adaptation scheme and make flexible adjustments, thus lowering the professional technical threshold for hardware adaptation.

[0047] In this optional embodiment, providing detailed answers to adaptation solutions based on natural language interaction commands means that for user questions about specific technical details in the adaptation solution, accurate and easy-to-understand answers are generated by combining reference information from similar historical cases, compatibility assessment results, and relevant knowledge from a preset knowledge base. For example, when a user asks about the recommended value for a certain configuration parameter, the actual value of the same parameter in similar historical cases and relevant analysis from compatibility assessment results can be cited to provide an answer. Comparing adaptation solutions based on natural language interaction commands means that when multiple candidate adaptation solutions exist, each solution is compared and analyzed according to the user's requirements in terms of adaptation complexity, compatibility risk, performance impact, etc., and the comparison results are presented in a structured form to assist the user in making a solution selection. Adjusting adaptation solutions based on natural language interaction commands means adjusting and updating specific content in the adaptation solution according to the user's modification request, such as adjusting the value of configuration parameters, changing the driver implementation method, adding or removing adaptation steps, etc., and generating an adjusted adaptation solution for the user's confirmation.

[0048] In this optional embodiment, the processing of natural language interaction commands can be achieved using the natural language understanding and generation capabilities of a large language model. Specifically, the user's natural language interaction commands, along with contextual information such as the current adaptation scheme, historical similar cases, and compatibility assessment results, can be input into the large language model. The large language model then understands the user's intent and generates corresponding answers, comparisons, or adjustments. Through the natural language interaction mechanism driven by the large language model, intelligent adaptation scheme consultation and adjustment services can be provided to users, enabling non-expert users to deeply understand and flexibly adjust adaptation schemes, further lowering the professional threshold for hardware adaptation.

[0049] Step 50: Generate step-by-step operation guidance based on the reference adaptation path and adaptation scheme.

[0050] In this embodiment, step-by-step operation guidance refers to a structured execution guide formed by decomposing the adaptation plan into multiple ordered steps according to the execution sequence, and configuring corresponding operation content, input requirements, expected outputs, and precautions for each step. Each step in this step-by-step operation guidance includes clearly defined operation content, input requirements, expected outputs, and precautions. The generation of step-by-step operation guidance is based on two core inputs: the reference adaptation path extracted in step 20 and the adaptation plan generated in step 40. The reference adaptation path provides a process framework based on historical successful cases, while the adaptation plan provides a specific strategy for the current adaptation task. The combination of the two can generate step-by-step operation guidance that both follows an experience-verified process framework and fits the needs of the current task.

[0051] In this embodiment, the specific content of the step-by-step operation guidance may include: the step number and name of each step, the specific operations to be performed in this step (such as the path and content of the configuration file to be edited, the name and implementation logic of the driver function to be written, the command line instructions to be executed, etc.), the input requirements and preconditions for this step, the expected output and verification criteria for this step, and the precautions and common questions for this step. For key steps, explanatory text and sample code can also be included to help users understand the operation intent and correct execution method. For example, in the configuration file generation step, a complete example of the configuration file and an explanation of the meaning of each field can be included; in the driver entry function writing step, function templates and comments on key code segments can be included; in the verification step, expected test output and judgment criteria can be included, etc.

[0052] In this embodiment, the generation of step-by-step operation guidance can be achieved using the content generation capabilities of a large language model. Specifically, a reference adaptation path and adaptation scheme can be used as context input. The large language model generates detailed operation content for each step based on the step framework of the reference adaptation path and the specific strategies and parameters in the adaptation scheme. Simultaneously, the large language model can automatically generate precautions and common problem prompts for each step based on relevant knowledge in a preset knowledge base, such as prompts for common configuration error types and troubleshooting methods in a certain step. Generating step-by-step operation guidance through a large language model transforms complex adaptation schemes into clear and executable operation steps, enabling users to complete the adaptation work step by step according to the guidance, avoiding the problem of not knowing where to start when faced with complex technical details.

[0053] In this embodiment, the step-by-step operation guidance can be presented to the user in a visual manner. For example, the sequence and dependencies between steps can be displayed in the form of a flowchart in the interactive interface, the detailed operation content and precautions of each step can be displayed in the form of a step card, and the completion progress of the current adaptation task can be displayed in the form of a progress bar. Through visual step-by-step operation guidance, users can intuitively understand the overall process of the adaptation work and the current stage, reducing the cognitive burden of the adaptation work.

[0054] This embodiment generates step-by-step operation guidance based on reference adaptation paths and adaptation schemes, which can decompose the complex hardware adaptation work into a clear and executable sequence of steps. Each step contains clear operation content and expected output, enabling non-expert users to complete the adaptation work accurately according to the guidance specifications, effectively reducing the professional threshold and operation difficulty of hardware adaptation.

[0055] Step 60: Follow the step-by-step instructions to invoke the automated toolchain to perform adaptation processing on the hardware to be adapted.

[0056] In this embodiment, the automated toolchain refers to a collection of software tools capable of automatically performing adaptation processing-related operations. This includes, but is not limited to, one or more of the following: configuration file generation tools, driver code generation tools, configuration parsing tools, driver loading simulation tools, and toolchain interface builders. The invocation of the automated toolchain is based on the step-by-step operation guide generated in step 50; that is, according to the operation content of each step in the step-by-step operation guide, the corresponding tools are automatically invoked to perform the corresponding adaptation processing operations.

[0057] In this embodiment, the specific process of calling the automated toolchain according to the step-by-step operation guidance can include: for the step-by-step operation guidance involving configuration file generation, calling the configuration file generation tool to automatically generate a configuration file conforming to the target operating system hardware driver framework standard based on the configuration parameters in the adaptation scheme; for the step involving driver code writing, calling the driver code generation tool to automatically generate driver code templates and key code segments based on the driver framework and key function definitions in the adaptation scheme; for the step involving configuration parsing and verification, calling the configuration parsing tool to perform syntax and logic verification on the generated configuration file; and for the step involving driver loading testing, calling the driver loading simulation tool to perform loading tests on the generated driver in a simulated environment to verify the correctness and stability of the driver. By calling the automated toolchain, the operations of each step in the step-by-step operation guidance can be executed automatically, significantly reducing the workload of manually writing configuration files and driver code, and improving the efficiency and accuracy of adaptation processing.

[0058] In this embodiment, the automated toolchain can also interface with the target operating system's build toolchain. For example, after the adaptation process is complete, the automated toolchain can automatically call the target operating system's build toolchain to compile and package the generated configuration files, driver code, and other adaptation artifacts, generating an adaptation package that can be directly used for hardware deployment. Through seamless integration between the automated toolchain and the build toolchain, the entire process from adaptation solution to deployable adaptation package is automated, further improving adaptation efficiency.

[0059] This embodiment guides the invocation of an automated toolchain to perform adaptation processing according to step-by-step operation instructions. This automatically transforms various strategies in the adaptation scheme into specific configuration files, driver code, and adaptation artifacts, replacing the inefficient mode of manually writing configuration files and driver code in the prior art. This significantly improves the efficiency and accuracy of adaptation processing, while reducing configuration errors and code defects caused by manual writing.

[0060] Optionally, in some embodiments, the process of calling the automated toolchain according to the step-by-step operation to perform adaptation processing on the hardware to be adapted further includes: identifying whether an abnormal situation has occurred; wherein, the abnormal situation includes at least one of the following: hardware driver framework loading failure, hardware configuration source code parsing error, driver entry binding failure, register configuration conflict, power configuration conflict, and peripheral protocol mismatch; the abnormal situation is identified by at least one of the following methods: built-in driver loading simulator, serial port log parsing, system monitoring tools, or user reporting; if an abnormal situation is identified, a solution suggestion and code patch are generated based on the abnormal situation, and an automatic repair process is initiated; the automatic repair process is used to repair the abnormal situation based on the solution suggestion and code patch.

[0061] In this optional embodiment, the identification of abnormal situations is carried out throughout the entire adaptation process. Specifically: Hardware driver framework loading failure refers to the target operating system's hardware driver framework failing to correctly load the generated configuration file or driver module during the adaptation process. The reasons may include configuration file syntax errors, driver module interface mismatch, missing dependencies, etc. Common hardware driver framework loading failures include HCS (HDF Configuration Source) file parsing errors and driver entry function (DriverEntry) binding failures. Such exceptions can be pre-detected in a simulated environment using the built-in driver loading simulator. That is, before deploying the configuration file and driver module to the actual hardware, the driver loading process is executed in the simulator to check for loading failures. Hardware configuration source code parsing errors refer to syntax or semantic errors encountered by automated toolchains when parsing hardware configuration source code (such as hardware description files, device tree files, etc.). Such exceptions can be automatically detected and reported by configuration parsing tools during the parsing process, along with the error location and type. Driver entry binding failure means that the entry function of the driver module cannot be correctly bound to the driver service node of the hardware driver framework. The reasons may include entry function signature mismatch, service name conflict, etc. This type of exception can be detected by the built-in driver loading simulator during the driver registration stage. Register configuration conflict refers to a conflict between the register address or offset in the generated configuration file and the existing register configuration in the system. This is common in scenarios where the parameter description in the datasheet is inconsistent with the configuration specifications of the hardware driver framework. This type of exception can be detected by system monitoring tools at runtime to detect abnormal register access behavior, or by configuration parsing tools to perform pre-checks during the generation phase. A power configuration conflict refers to a mismatch between the generated power management configuration and the system's power supply strategy or the electrical characteristics of the hardware. Such anomalies can be detected by monitoring changes in power status through system monitoring tools or reported by the user during hardware debugging. Peripheral protocol mismatch refers to the inconsistency between the peripheral communication protocol configuration (such as I2C timing parameters, SPI clock frequency, etc.) in the generated driver code and the peripheral protocol specification of the actual hardware. This type of exception can be determined by parsing serial port logs to detect abnormal logs such as communication timeout or data verification errors, or by information reported by the user (such as feedback after the user identifies the exception with external testing equipment such as an oscilloscope, or information actively reported during hardware debugging).

[0062] In this optional embodiment, the identification of abnormal situations can employ a strategy combining multiple methods. A built-in driver loading simulator can simulate the driver loading process in the early stages of adaptation processing (such as after configuration file generation and driver code writing), identifying potential loading and binding failures in advance. Serial port log parsing can collect and intelligently analyze the serial port logs output by the hardware device in real time during the actual operation of adaptation processing, automatically identifying error messages and abnormal patterns in the logs through a combination of keyword matching and large language model log analysis. System monitoring tools can continuously monitor the system's operating status during adaptation processing, including register access status, power status, and peripheral communication status, automatically triggering alarms when abnormal behavior is detected. User reporting allows users to proactively report abnormal situations encountered during adaptation processing, serving as an effective supplement to automatic identification methods. This strategy of combining multiple identification methods ensures timely detection and comprehensive coverage of abnormal situations, avoiding omissions by a single identification method.

[0063] In this optional embodiment, if an anomaly is detected, a solution suggestion and code patch are generated based on the anomaly, and an automatic repair process is initiated. Specifically, based on the type of the anomaly and the specific error information, similar historical anomaly records and corresponding solutions can be retrieved from a preset knowledge base. Combined with the reasoning capabilities of the large language model, a solution suggestion and code patch for the current anomaly are generated. The solution suggestion may include an analysis of the cause of the anomaly, suggested repair steps, and verification methods after repair. The code patch may include differences in configuration file content that need modification, driver code snippets that need adjustment, etc. The automatic repair process refers to automatically modifying the configuration file or driver code involved in the anomaly based on the generated solution suggestion and code patch, and re-executing the corresponding verification steps after modification to confirm whether the anomaly has been successfully repaired. If the automatic repair is successful, the adaptation process continues to the subsequent steps; however, if the automatic repair fails to resolve the anomaly after multiple attempts, the automatic repair process can be paused, and the user can be notified through natural language interaction for manual investigation and handling. The user can communicate with the large language model through natural language to obtain more detailed anomaly analysis information and repair suggestions, or directly manually modify the configuration file and driver code.

[0064] This optional embodiment identifies anomalies in real time during the adaptation process and automatically generates solution suggestions and code patches. This provides targeted repair solutions as soon as an anomaly occurs, avoiding the inefficient method of relying on manual code backtracking and manual review in existing technologies. Furthermore, the automated repair process can automatically complete repairs in most common anomaly cases, further reducing the need for manual intervention and improving the automation level and overall efficiency of the adaptation process.

[0065] Optionally, in some embodiments, after invoking the automated toolchain according to the step-by-step operation guide to perform adaptation processing on the hardware to be adapted, the method further includes: generating a verification task list and executing preset test cases based on the verification task list; tracking the execution status of the test cases and summarizing and generating an adaptation quality report.

[0066] In this optional embodiment, the verification task list refers to a list of test tasks used to verify whether the adaptation results meet the expected requirements after the adaptation process is completed. The generation of the verification task list can automatically identify the functional points and test items that need to be verified based on the adaptation scheme and the verification requirements in the step-by-step operation guide. For example, the verification task list may include: configuration file syntax verification, driver module loading test, peripheral communication function test, interrupt response test, power management function test, performance benchmark test, and other test items. Each test item can be associated with one or more preset test cases, and the test cases define specific test steps, input data, expected output, and judgment criteria.

[0067] In this optional embodiment, executing preset test cases based on the verification task list means executing the associated test cases sequentially according to the order of the test items in the verification task list. The execution of test cases can be automated, meaning that the test execution module in the automation toolchain automatically runs each test case, collects test results, and records the execution status of each test case (e.g., pass, fail, blocked). For test cases that need to be executed on actual hardware, the test program can be deployed to the hardware to be adapted and run, and test results can be collected via serial communication or network communication.

[0068] In this optional embodiment, tracking the execution status of test cases and generating a compatibility quality report means that during the execution of test cases, the execution status and test results of each test case are tracked in real time, and a compatibility quality report is generated after all test cases have been executed. The compatibility quality report may include: a summary of test results for each test item (number of passes, number of failures, number of blocked tests), detailed error information and logs of failed test cases, an overall compatibility quality score, risk items requiring attention, and suggested improvement measures. The compatibility quality report can be presented visually, such as displaying the pass rate of each test item in chart form, or displaying detailed information of failed test cases in list form, so that users and administrators can intuitively understand the compatibility quality.

[0069] This optional embodiment, by generating a verification task list and executing preset test cases, can systematically verify and evaluate the adaptation results, ensuring that the adapted hardware driver meets the expected requirements in terms of functionality, performance, and stability. Simultaneously, the visualized presentation of the adaptation quality report makes the adaptation quality transparent and controllable, facilitating project managers' understanding of the overall progress and risks, and providing strong support for quality control of the adaptation work.

[0070] Optionally, in some embodiments, after invoking the automated toolchain according to the step-by-step operation guide to perform adaptation processing on the hardware to be adapted, the method further includes: accumulating the adaptation knowledge generated during the adaptation process into a preset knowledge base.

[0071] In this optional embodiment, adaptation knowledge refers to experiential knowledge generated during the adaptation process that has reusable value. This knowledge may include, but is not limited to: problems encountered during adaptation and their solutions, optimal value ranges for configuration parameters, key implementation logic of the driver code, strategies for addressing compatibility risks, execution results of test cases, and optimization suggestions. Accumulating adaptation knowledge into a pre-defined knowledge base means that after the adaptation task is completed and the verification regression is passed, the aforementioned adaptation knowledge is entered into the pre-defined knowledge base in a structured form, making it a knowledge asset that can be retrieved and reused in subsequent adaptation tasks.

[0072] In this optional embodiment, the accumulation of adaptation knowledge can employ a combination of automatic extraction and user confirmation. Specifically, key adaptation information, including adaptation logs, configuration file change records, driver code change records, exception handling and repair records, and test case execution results, can be automatically collected during the adaptation process. Then, a large language model is used to automatically extract reusable knowledge items from this key adaptation information and organize them in a structured format. Simultaneously, users can also interact with the large language model using natural language, describing specific problems encountered during the adaptation process and their solutions (e.g., describing a hardware driver framework loading failure and its solution steps). The large language model automatically extracts structured fields from the dialogue content and generates knowledge items. The extracted knowledge items can be presented to the user for confirmation and correction. A standardized form can also be provided for users to modify, supplement, or delete automatically extracted knowledge items, ensuring the accuracy and completeness of the adaptation knowledge entered into the preset knowledge base. This combination of automatic extraction and user confirmation reduces the workload of manual knowledge entry for users while ensuring knowledge quality.

[0073] This optional embodiment forms a closed loop for the continuous accumulation of adaptation experience by storing the adaptation knowledge generated during the adaptation process in a preset knowledge base. After each adaptation task is completed, the newly generated adaptation knowledge is entered into the preset knowledge base, enriching its content. This allows subsequent adaptation tasks to retrieve more and more accurate historical similar cases and compatibility data, thereby continuously improving the quality of the adaptation solution and the efficiency of adaptation processing. This positive cycle mechanism of knowledge accumulation allows the preset knowledge base to be continuously optimized as the number of adaptation tasks increases, achieving the effect of continuous value enhancement as the frequency of use increases. This solves the problem in existing technologies where adaptation experience cannot be effectively stored and reused.

[0074] Optionally, in some embodiments, the adaptation knowledge generated during the adaptation process is stored in a preset knowledge base, including: obtaining key adaptation information generated during the adaptation process; extracting structured fields from the key adaptation information to obtain adaptation knowledge; updating the adaptation knowledge based on the knowledge correction instruction when a knowledge correction instruction is received; and recording the adaptation knowledge into the preset knowledge base.

[0075] In this optional embodiment, acquiring key adaptation information generated during the adaptation process refers to continuously collecting and recording key information related to the adaptation work throughout the entire adaptation process. Sources of this key adaptation information may include: execution logs of each step in the adaptation process, generation and modification records of configuration files, generation and modification records of driver code, identification and repair records of abnormal situations, execution and result records of test cases, and adaptation experience and problem feedback provided by users through natural language interaction. This key adaptation information exists in the form of raw logs or unstructured text and requires further processing to be transformed into reusable structured knowledge.

[0076] In this optional embodiment, extracting structured fields from adaptation key information to obtain adaptation knowledge refers to using natural language processing technology to extract key entities and relationships from unstructured adaptation key information and organize them into structured knowledge entries. For example, entity-relationship pairs such as "chip model-peripheral type-hardware driver framework node-risk type-solution" can be extracted from adaptation logs to generate structured knowledge entries. Specifically, a large language model can be used to intelligently analyze adaptation key information, automatically identifying key entities (such as chip model, peripheral name, configuration parameter name, etc.) and key relationships (such as causal relationships, dependency relationships, conflict relationships, etc.), and organizing them in a structured manner according to a preset knowledge entry template. For example, the log of a certain adaptation task records the problem of "GPIO initialization failed due to register offset error" and the corresponding repair operation. The large language model engine can extract and generate structured knowledge entries from it, including fields such as chip model (e.g., RK3568), peripheral type (e.g., GPIO), hardware driver framework node (e.g., device0), risk type (e.g., offset conflict), and solution (e.g., modifying the offset in the HCS file to 0x1004). After the knowledge entries are added to the preset knowledge base, they can be directly retrieved and referenced by subsequent adaptation tasks involving the same chip or the same peripheral, realizing a product enhancement closed loop of "the more you use it, the smarter it becomes".

[0077] In this optional embodiment, updating the adapted knowledge based on the knowledge correction instruction upon receiving it means allowing the user to correct and supplement the adapted knowledge before or after it is entered into the preset knowledge base. The knowledge correction instruction can be input by the user through an interactive interface. For example, if a user finds inaccurate or incomplete information in the automatically extracted adapted knowledge, they can submit a knowledge correction instruction through form editing or natural language description to modify, supplement, or delete the corresponding adapted knowledge item. After updating the adapted knowledge based on the knowledge correction instruction, the updated adapted knowledge is entered into the preset knowledge base to ensure the accuracy and timeliness of the adapted knowledge stored in the preset knowledge base.

[0078] In this optional embodiment, inputting adaptation knowledge into a preset knowledge base means storing the extracted and corrected adaptation knowledge in a structured data format within the preset knowledge base. The adaptation knowledge input into the preset knowledge base can be retrieved and reused in subsequent adaptation tasks. For example, when searching for historical similar cases in step 20, newly input adaptation knowledge can serve as candidate cases for matching; when performing compatibility evaluation in step 30, the compatibility data in the newly input adaptation knowledge can enrich the evaluation reference. By systematically inputting adaptation knowledge into a preset knowledge base, the transformation of adaptation experience from personal tacit knowledge to organizational explicit knowledge is realized, providing continuously growing knowledge support for subsequent adaptation tasks.

[0079] Optionally, in some embodiments, the hardware adaptation method is applied to the open-source HarmonyOS operating system; based on historical similar cases and compatibility assessment results, an adaptation scheme is generated, including: automatically generating configuration files and driver entry templates that conform to the hardware driver framework standard of the open-source HarmonyOS operating system; according to the step-by-step operation guidance, an automated toolchain is invoked to perform adaptation processing on the hardware to be adapted, including: invoking an automated toolchain with built-in hardware driver framework configuration parsing and driver loading process simulation, interfacing with the build toolchain of the open-source HarmonyOS operating system, and generating an adaptation package.

[0080] In this optional embodiment, the open-source HarmonyOS adopts a hardware driver framework as the standardized framework for its hardware driver development, management, and release. This framework defines the driver configuration file format (such as HCS files), the writing specifications for driver entry functions, the driver loading and binding process, and the driver service management mechanism. The hardware adaptation method in this optional embodiment is deeply adapted to the characteristics of the open-source HarmonyOS hardware driver framework. It can automatically generate configuration files and driver entry templates that conform to the hardware driver framework standard, and call an automated toolchain with built-in hardware driver framework configuration parsing and driver loading process simulation. This toolchain interfaces with the open-source HarmonyOS build toolchain to generate an adaptation package that can be directly used for hardware deployment.

[0081] In this optional embodiment, configuration files and driver entry templates conforming to the hardware driver framework standard of the open-source HarmonyOS operating system are automatically generated. Specifically, this includes: automatically generating a configuration file conforming to the hardware driver framework configuration syntax based on the hardware parameters in the adaptation scheme. This configuration file describes the device node information, attribute configurations, and service binding relationships of the hardware resources. Based on the driver framework requirements in the adaptation scheme, a driver entry code template conforming to the driver entry specification of the hardware driver framework is automatically generated. This template contains the framework code and key comments for standard entry functions such as driver binding functions, driver initialization functions, and driver release functions. Users only need to fill in the device-specific logic according to the specific hardware characteristics. By automatically generating configuration files and driver entry templates conforming to the hardware driver framework standard, the generated adaptation artifacts can directly interface with the driver framework of the open-source HarmonyOS operating system, eliminating the need for users to manually understand and follow the hardware driver framework's writing specifications, thus lowering the adaptation threshold.

[0082] In this optional embodiment, an automated toolchain with built-in hardware driver framework configuration parsing and driver loading process simulation is invoked and interfaced with the open-source HarmonyOS build toolchain to generate an adaptation package. Specifically, the automated toolchain includes a built-in configuration parser for the hardware driver framework, capable of performing syntax and semantic verification on the generated configuration files to ensure they conform to the hardware driver framework's specifications. The toolchain also includes a built-in driver loading process simulator, capable of executing the hardware driver framework's driver loading process in a simulated environment, including configuration file parsing, driver module registration, driver entry function binding, and driver service deployment, to proactively identify potential problems during driver loading (such as driver registration failures and message interaction anomalies common in the open-source HarmonyOS ecosystem). After adaptation processing, the automated toolchain automatically interfaces with the open-source HarmonyOS build toolchain to compile and package the generated configuration files, driver code, and other adaptation artifacts to generate the adaptation package. This adaptation package can be directly used for building system images of the open-source HarmonyOS or flashing firmware on hardware devices, achieving full-process automation from adaptation solution to deployable adaptation package.

[0083] This optional embodiment deeply adapts to the hardware driver framework characteristics of the open-source HarmonyOS operating system, automatically generating configuration files and driver entry templates that conform to the hardware driver framework standard. Through built-in configuration parsing and driver loading process simulation, it can discover ecosystem-specific issues such as driver registration and message interaction in advance. This allows hardware manufacturer engineers to quickly complete the adaptation work in the open-source HarmonyOS ecosystem without having to deeply understand the framework specifications, significantly reducing the adaptation threshold for entering the open-source HarmonyOS ecosystem. This is an ecosystem-specific value that other general operating system adaptation solutions cannot provide.

[0084] This application, through the above-described embodiments and optional embodiments, achieves intelligent reuse of historical adaptation experience by retrieving and matching historical similar cases based on a preset knowledge base and extracting reference adaptation paths, avoiding repetitive work that requires starting from scratch for each adaptation; it achieves early identification and warning of adaptation risks by conducting compatibility assessments of basic hardware information based on a preset knowledge base, avoiding the inefficient mode of discovering compatibility issues only during the debugging phase; it achieves automated formulation of adaptation strategies by generating adaptation schemes based on historical similar cases and compatibility assessment results, replacing the subjective mode of manually writing adaptation schemes based on engineers' personal experience; it achieves interactive optimization of adaptation schemes by supporting natural language interactive commands for detailed explanations, scheme comparisons, or scheme adjustments, lowering the threshold for non-expert users to understand and adjust adaptation schemes; and it achieves step-by-step operation guidance based on reference adaptation paths and adaptation schemes by breaking down complex adaptation work into steps and presenting them visually, enabling users to... The system guides users step-by-step through the adaptation process. By invoking an automated toolchain based on step-by-step instructions, it automates the entire process of configuration file generation, driver code writing, and adaptation artifact packaging, significantly improving efficiency and accuracy. Real-time anomaly identification and automatic generation of solutions and code patches during adaptation enable timely detection and intelligent repair, reducing manual troubleshooting. The generation of verification task lists and execution of pre-defined test cases ensures systematic verification and quality assessment of adaptation results, guaranteeing reliability and quality. The accumulation of adaptation knowledge into a pre-defined knowledge base facilitates continuous accumulation of experience and large-scale growth of knowledge assets, forming a positive feedback loop driven by knowledge. Deep adaptation to the hardware driver framework characteristics of the open-source HarmonyOS ecosystem provides ecosystem-specific automated adaptation capabilities, offering strong support for the large-scale deployment of the open-source HarmonyOS ecosystem.

[0085] This application, through its hardware adaptation method, constructs a dual-loop linkage mechanism that mutually promotes business execution and knowledge accumulation. Specifically: The first closed loop is the business external loop path driven by user adaptation tasks: users create adaptation tasks and go through the stages of compatibility assessment, adaptation solution generation, step-by-step operation guidance and execution, and automated verification regression in sequence, thereby completing a single hardware adaptation operation in a standardized manner; after the task is completed, the experience data such as problem handling records, configuration parameters and verification results generated during the adaptation process will be structured into adaptation knowledge and deposited into a preset knowledge base, forming a value closed loop for a single business node.

[0086] The second closed loop is an intelligent internal loop path driven by continuous logical enhancement of the knowledge base. This path is automatically triggered by the large language model engine. Its triggering mechanism includes immediate triggering after each adaptation task is completed, and periodic triggering based on the platform capability layer's scheduled task service according to a preset cycle (e.g., 24 hours, which can be configured according to actual application needs). After triggering, the large language model engine first performs deduplication, format standardization, and entity-relation extraction on the newly added unstructured data in the knowledge base. Then, it stores the processing results in the vector index of the preset knowledge base. When a new adaptation task is initiated, the system performs reasoning and generation based on this continuously optimized knowledge base, providing accurate intelligent decision support for compatibility assessment, solution recommendation, and other links, and realizing the automated enhancement of the knowledge base as the task scale grows.

[0087] This application achieves a synergistic effect by combining the aforementioned external business loop path with the intelligent internal loop path. This ensures the quality and efficiency of each hardware adaptation task at the business execution level, while simultaneously ensuring the effective accumulation and large-scale reuse of adaptation experience at the knowledge accumulation level. This comprehensively improves the reliability and scalability of hardware adaptation.

[0088] See Figure 2 , Figure 2 This is a schematic diagram of the structure of an embodiment of the hardware adaptation platform provided in this application.

[0089] The hardware adapter platform 70 is used to achieve, for example... Figure 1 The hardware adaptation method described herein. The hardware adaptation platform 70 includes a business interaction layer 71, a platform capability layer 72, and a technical support layer 73; The business interaction layer 71 is used to: obtain basic hardware information of the hardware to be adapted; The platform capability layer 72 is used for: retrieving and matching historical similar cases in the preset knowledge base of the technical support layer 73 based on basic hardware information, and extracting reference adaptation paths; performing compatibility assessment on the basic hardware information based on the preset knowledge base and generating compatibility assessment results; generating adaptation schemes based on historical similar cases and compatibility assessment results; generating step-by-step operation guidance based on reference adaptation paths and adaptation schemes; and calling the automated toolchain of the technical support layer according to the step-by-step operation guidance to perform adaptation processing on the hardware to be adapted. The technical support layer 73 is used to: provide a preset knowledge base, an automated toolchain, and a data processing engine; the data processing engine is used to support the generation of compatibility assessment results, the generation of adaptation solutions, and the generation of step-by-step operation guidance.

[0090] In this embodiment, a hardware adaptation platform is provided. Specifically, the hardware adaptation platform can be a software platform system deployed on a cloud server or local server, a browser / server architecture application built on Web technology, or a client / server architecture application built on a desktop application framework, or a combination of the above forms. The hardware adaptation platform decouples user interaction, business logic, and underlying technical support through a layered architecture design. Each layer communicates with each other through an application programming interface, supports independent deployment and elastic expansion, and can adapt to different deployment environments and user scale requirements.

[0091] In the hardware adaptation platform of this embodiment: The business interaction layer 71 serves as the direct interaction point between the user and the platform, responsible for receiving user operation commands and displaying processing results. Specifically, this layer 71 can be presented as an interactive interface, including functional modules such as an adaptation task center, a natural language interaction interface, a knowledge base management interface, and a verification and regression management interface. The adaptation task center supports users in creating, managing, and tracking the entire lifecycle of hardware adaptation tasks, including task creation, task allocation, progress viewing, and task archiving. The natural language interaction interface supports users in communicating with the platform in natural language, including adaptation solution consultation, anomaly troubleshooting, and operation guidance; it can be a dialog box for an intelligent assistant or an embedded dialogue component. The knowledge base management interface allows users to view, retrieve, edit, and manage adaptation knowledge in a preset knowledge base. The verification and regression management interface allows users to view the verification task list, track test case execution status, and view adaptation quality reports.

[0092] Platform Capability Layer 72, as the core business logic layer of the hardware adaptation platform, is responsible for the full lifecycle management and intelligent decision-making of adaptation tasks. Platform Capability Layer 72 encapsulates the complete business process from hardware information collection, compatibility assessment, adaptation solution generation, execution guidance to verification and regression, and achieves collaborative operation of business execution and knowledge accumulation through a dual-loop interaction mechanism. Platform Capability Layer 72 can be deployed using a microservice architecture, with each business function module running as an independent service, achieving business collaboration through inter-service communication, and supporting on-demand expansion and independent upgrades.

[0093] The technical support layer 73, as the underlying infrastructure layer of the hardware adaptation platform, is responsible for providing the core technical capabilities to support the operation of business logic. The technical support layer 73 includes core components such as a data processing engine, a pre-built knowledge base, and an automated toolchain. Specifically, the data processing engine may employ a large language model engine, providing intelligent capabilities such as natural language understanding, content generation, knowledge extraction, and reasoning analysis, supporting business functions such as generating compatibility assessment results, adaptation solutions, step-by-step operation guidance, and processing natural language interaction commands. The pre-built knowledge base stores and manages structured knowledge such as hardware specification information, driver source code snippets, historical adaptation cases, fault handling experience, and compatibility data, supporting multiple retrieval methods such as vector retrieval and keyword retrieval. The automated toolchain provides automated execution capabilities such as configuration file generation, driver code generation, configuration parsing, driver loading simulation, and toolchain integration, supporting the automated execution of adaptation processing.

[0094] In this embodiment, the three layers mentioned above are, from top to bottom, the business interaction layer, the platform capability layer, and the technical support layer. The layers communicate with each other through application programming interfaces (APIs). The upper layer calls the functional interfaces of the lower layer to implement business logic, and the lower layer provides technical capability support to the upper layer. Through the layered and decoupled architecture design, each layer can evolve and expand independently. For example, the large language model engine of the technical support layer can be independently upgraded to a more advanced model without affecting the business logic of the upper layer. The business interaction layer can adapt to different front-end technology frameworks without affecting the underlying business processing capabilities, thereby improving the maintainability and scalability of the hardware adaptation platform.

[0095] Optionally, in some embodiments, the platform capability layer 72 is further configured to: retrieve compatibility data corresponding to basic hardware information from a preset knowledge base; perform rule verification and reasoning on the basic hardware information based on the compatibility data, and generate a compatibility assessment result.

[0096] In this optional embodiment, when the platform capability layer 72 performs the compatibility assessment function, it calls the retrieval interface of the preset knowledge base in the technical support layer 73 to retrieve compatibility data based on basic hardware information. It then calls the rule verification and reasoning functions of the data processing engine in the technical support layer 73 to systematically verify and reason about the retrieved compatibility data, generating a structured compatibility assessment result. The compatibility assessment result is presented to the user in a visual manner through the business interaction layer 71, including information such as the risk level, risk description, and recommended measures for each assessment dimension.

[0097] Optionally, in some embodiments, the platform capability layer 72 is further configured to: receive natural language interaction instructions input by the user; and, based on the natural language interaction instructions, provide detailed explanations, compare solutions, or adjust solutions for the adaptation scheme.

[0098] In this optional embodiment, the natural language interaction interface of the business interaction layer 71 receives the natural language interaction instructions input by the user and forwards them to the platform capability layer 72. The platform capability layer 72 submits the natural language interaction instructions along with contextual information such as the current adaptation scheme, historical similar cases, and compatibility assessment results to the large language model engine of the technical support layer 73. The large language model engine understands the user's intent and generates corresponding answers, comparisons, or adjustment results. The platform capability layer 72 then returns the processing results to the user through the business interaction layer 71.

[0099] Optionally, in some embodiments, the platform capability layer 72 is further used to: identify whether an abnormal situation has occurred; if an abnormal situation is identified, generate a solution suggestion and code patch based on the abnormal situation, and enter an automatic repair process.

[0100] In this optional embodiment, during the adaptation process, the platform capability layer 72 monitors the running status of the adaptation process in real time and identifies any abnormal situations by calling the built-in driver loading simulator, serial port log parsing module, and system monitoring tools in the automated toolchain of the technical support layer 73. If an abnormal situation is identified, the platform capability layer 72 calls the reasoning capabilities of the large language model engine in the technical support layer 73 and the historical abnormal records in the preset knowledge base to generate a solution suggestion and code patch for the current abnormal situation, and executes an automatic repair process through the automated toolchain. If the automatic repair is successful, the platform capability layer 72 continues to advance the adaptation process to subsequent steps; if the automatic repair fails after multiple attempts, the user is notified through the business interaction layer 71 to require manual intervention.

[0101] Optionally, in some embodiments, the platform capability layer 72 is further configured to: generate a verification task list and execute preset test cases based on the verification task list; track the execution status of the test cases and generate an adaptation quality report.

[0102] In this optional embodiment, after the adaptation process is completed, the platform capability layer 72 automatically generates a verification task list based on the verification requirements in the adaptation scheme and step-by-step operation guidance, and calls the test execution module of the automation toolchain in the technical support layer 73 to execute each test case sequentially. The platform capability layer 72 tracks the execution status of each test case in real time, and generates an adaptation quality report after all test cases have been executed, which is then presented to the user in a visual manner through the verification regression management interface of the business interaction layer 71.

[0103] Optionally, in some embodiments, the platform capability layer 72 is further configured to: deposit the adaptation knowledge generated during the adaptation process into a preset knowledge base.

[0104] In this optional embodiment, after the adaptation task is completed and the verification regression is passed, the platform capability layer 72 automatically collects the key adaptation information generated during the adaptation process and calls the knowledge extraction function of the large language model engine in the technical support layer 73 to extract structured fields from the key adaptation information and generate adaptation knowledge. The platform capability layer 72 presents the generated adaptation knowledge to the user for confirmation and correction through the knowledge base management interface of the business interaction layer 71. After the user confirms or receives a knowledge correction instruction and completes the update, the adaptation knowledge is entered into the preset knowledge base of the technical support layer 73 to achieve continuous accumulation of adaptation experience.

[0105] Optionally, in some embodiments, the hardware adaptation platform is applied to the open-source HarmonyOS operating system; the platform capability layer 72 is also used to: automatically generate configuration files and driver entry templates that conform to the hardware driver framework standard of the open-source HarmonyOS operating system; call the automated toolchain with built-in hardware driver framework configuration parsing and driver loading process simulation, and interface with the build toolchain of the open-source HarmonyOS operating system to generate an adaptation package.

[0106] In this optional embodiment, the automated toolchain of the technical support layer 73 has built-in dedicated tool components for the open-source HarmonyOS hardware driver framework, including a hardware driver framework configuration parser, a driver loading process simulator, and a build toolchain interface. When generating an adaptation solution, the platform capability layer 72 calls the configuration file generation tool and driver code generation tool of the automated toolchain to automatically generate configuration files and driver entry templates that conform to the hardware driver framework standard. When performing adaptation processing, it calls the configuration parser and driver loading simulator of the automated toolchain to verify the generated configuration files and driver code. After successful verification, it calls the build toolchain interface to connect with the build toolchain of the open-source HarmonyOS to compile and package an adaptation package that can be directly used for hardware deployment.

[0107] This embodiment effectively decouples user interaction, business logic, and underlying technical support through the aforementioned layered architecture design. Each layer has clearly defined responsibilities and standardized interfaces, ensuring both the functional integrity and operational stability of the hardware adaptation platform, while also providing a flexible architectural foundation for its continuous evolution and functional expansion. Furthermore, the implementation of a dual-loop interaction mechanism at the platform level enables the user-task-driven external business loop and the automatic knowledge enhancement within the intelligent internal loop to work synergistically, comprehensively improving the hardware adaptation platform's adaptation efficiency, knowledge accumulation capabilities, and scalable service capabilities.

[0108] Since the embodiments of the platform part correspond to the embodiments of the above methods, the description of the hardware adaptation platform 70 provided in this application embodiment should refer to the above method embodiments. The embodiments of this application will not be repeated here, but they have the same beneficial effects as the above hardware adaptation methods.

[0109] See Figure 3 , Figure 3 This is a schematic diagram of an embodiment of the storage medium provided in this application.

[0110] The storage medium 80 stores program data 81, which, when executed by the processor, implements, as follows: Figure 1 The hardware adaptation method described.

[0111] The program data 81 is stored in a storage medium 80 and includes several instructions for causing a network device (such as a router, personal computer, or server) or processor to execute all or part of the steps of the methods described in the various embodiments of this application.

[0112] Optionally, the storage medium 80 can be any medium capable of storing program data 81, such as a USB flash drive, portable hard drive, read-only memory (ROM), random access memory (RAM), disk, or optical disc.

[0113] See Figure 4 , Figure 4 This is a schematic diagram of the structure of an embodiment of the computer device provided in this application.

[0114] The computer device 90 includes a processor 92 and a memory 91 interconnected. The memory 91 stores a computer program, and when the processor 92 executes the computer program, it implements, for example, Figure 1 The hardware adaptation method described herein. The memory 91 may include the storage medium 80, or it may be another separately developed memory.

[0115] Unlike existing technologies, this application discloses a hardware adaptation method, platform, storage medium, and computer device. By retrieving and matching historical similar cases based on a preset knowledge base and extracting reference adaptation paths, and combining this with a compatibility assessment using the knowledge base, an adaptation scheme and step-by-step operation guidance are automatically generated based on historical cases and the compatibility assessment results. An automated toolchain is then invoked to execute the adaptation process. On the one hand, by utilizing the knowledge base to reuse historical adaptation experience, the existing technology's purely manual manual review, configuration writing, and trial-and-error debugging mode is replaced, significantly reducing repetitive work, shortening the adaptation cycle, and improving the utilization rate of historical knowledge and overall adaptation efficiency. On the other hand, the automatic generation of adaptation schemes and step-by-step operation guidance lowers the professional technical threshold for hardware adaptation, avoiding basic errors such as incorrect offset writing and pin configuration conflicts that are prone to occur during manual review and data entry. This allows non-expert users to complete the adaptation work in a standardized and accurate manner, effectively reducing reliability risks. Furthermore, the cooperation between compatibility assessment and the automated toolchain ensures the standardization of the adaptation process, which is conducive to ensuring the reliability and quality of hardware adaptation results and promoting the large-scale implementation of the smart hardware ecosystem.

[0116] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the hardware adaptation platform embodiments, storage medium embodiments, and computer device embodiments are basically similar to the hardware adaptation method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of those hardware adaptation method embodiments.

[0117] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A hardware adaptation method, characterized in that, include: Obtain basic hardware information of the hardware to be adapted; Based on the aforementioned basic hardware information, historical similar cases are retrieved and matched in a preset knowledge base, and reference adaptation paths are extracted. Based on the preset knowledge base, a compatibility assessment is performed on the basic hardware information to generate a compatibility assessment result. Based on the aforementioned historical similar cases and the compatibility assessment results, an adaptation solution is generated; Based on the reference adaptation path and the adaptation scheme, a step-by-step operation guide is generated; The step-by-step operation guides the invocation of an automated toolchain to perform adaptation processing on the hardware to be adapted.

2. The hardware adaptation method according to claim 1, characterized in that, After the step-by-step operation guides the invocation of the automated toolchain to perform adaptation processing on the hardware to be adapted, the method further includes: Generate a verification task list and execute preset test cases based on the verification task list; Track the execution status of the test cases and generate an adaptation quality report.

3. The hardware adaptation method according to claim 1, characterized in that, After the automated toolchain is invoked according to the step-by-step operation to adapt the hardware to be adapted, the method further includes: accumulating the adaptation knowledge generated during the adaptation process into the preset knowledge base. The step of accumulating the adaptation knowledge generated during the adaptation process into the preset knowledge base includes: acquiring key adaptation information generated during the adaptation process; extracting structured fields from the key adaptation information to obtain the adaptation knowledge; updating the adaptation knowledge based on the knowledge correction instruction when a knowledge correction instruction is received; and recording the adaptation knowledge into the preset knowledge base.

4. The hardware adaptation method according to claim 1, characterized in that, After generating the adaptation solution based on the historical similar cases and the compatibility assessment results, the method further includes: Receive natural language interaction commands from the user; Based on the natural language interaction instructions, the adaptation scheme is explained in detail, compared, or adjusted.

5. The hardware adaptation method according to claim 1, characterized in that, The process of performing a compatibility assessment on the basic hardware information based on the preset knowledge base and generating a compatibility assessment result includes: Retrieve compatibility data corresponding to the basic hardware information from the preset knowledge base; Based on the compatibility data, rule verification and reasoning are performed on the basic hardware information to generate the compatibility assessment result.

6. The hardware adaptation method according to claim 1, characterized in that, The process of guiding the invocation of an automated toolchain according to the step-by-step operation to perform adaptation processing on the hardware to be adapted also includes: Identify whether any abnormal situations occur; wherein, the abnormal situations include at least one of the following: hardware driver framework loading failure, hardware configuration source code parsing error, driver entry binding failure, register configuration conflict, power configuration conflict, and peripheral protocol mismatch; the abnormal situations are identified through at least one of the following methods: built-in driver loading simulator, serial port log parsing, system monitoring tools, or user reporting; If an anomaly is detected, a solution suggestion and code patch are generated based on the anomaly, and an automatic repair process is initiated; the automatic repair process is used to repair the anomaly based on the solution suggestion and code patch.

7. The hardware adaptation method according to claim 1, characterized in that, The hardware adaptation method is applied to the open-source HarmonyOS operating system; The adaptation scheme is generated based on the historical similar cases and the compatibility assessment results, including: automatically generating configuration files and driver entry templates that conform to the hardware driver framework standard of the open-source HarmonyOS operating system; The step-by-step operation guides the invocation of an automated toolchain to adapt the hardware to be adapted, including: invoking an automated toolchain that has a built-in hardware driver framework for configuration parsing and driver loading process simulation, interfacing with the build toolchain of the open-source HarmonyOS operating system, and generating an adaptation package.

8. A hardware adaptation platform, characterized in that, The hardware adaptation platform is used to implement the hardware adaptation method as described in any one of claims 1-7, and the hardware adaptation platform includes a business interaction layer, a platform capability layer, and a technical support layer. The business interaction layer is used to: obtain basic hardware information of the hardware to be adapted; The platform capability layer is used to: search and match historical similar cases in the preset knowledge base of the technical support layer based on the basic hardware information, and extract reference adaptation paths; perform compatibility assessment on the basic hardware information based on the preset knowledge base, and generate compatibility assessment results; Based on the aforementioned historical similar cases and the compatibility assessment results, an adaptation solution is generated; Based on the reference adaptation path and the adaptation scheme, a step-by-step operation guide is generated; And according to the step-by-step operation, the automated toolchain of the technical support layer is invoked to perform adaptation processing on the hardware to be adapted; The technical support layer is used to: provide the preset knowledge base, the automation toolchain, and the data processing engine; The data processing engine is used to support the generation of the compatibility assessment results, the adaptation scheme, and the step-by-step operation guidance.

9. A storage medium storing program data thereon, characterized in that, When the program data is executed by the processor, it implements the steps of the hardware adaptation method as described in any one of claims 1 to 7.

10. A computer device, characterized in that, It includes an interconnected processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the steps of the hardware adaptation method as described in any one of claims 1 to 7.

Images