A Customized Operation Method for ODM Manufacturers Based on SMBIOS Type 165

Abstract

The application discloses an ODM manufacturer customization operation method based on SMBIOS Type 165, which comprises the following steps: S1, BIOS constructs Type 165 data and stores the Type 165 data in a DIM, wherein the Type 165 data stores identification information of an ODM manufacturer and operating system characteristic data; S2, SDK analyzes the Type 165 and transmits the analysis result to a system application layer; and S3, the system application acquires the characteristic data of the Type 165 and performs self operation logic judgment. The application defines a data structure and an interaction flow of the Type 165, and hardware manufacturers and operating systems OS are designed according to the agreed data structure, so that the ODM manufacturer customization operation system function problem is solved, and the operating system does not need to do more adaptation work for the same problem.

Description

Technical Field

[0001] This invention relates to the field of operating system technology, and in particular to a custom operating method for ODM manufacturers based on SMBIOS Type 165. Background Technology

[0002] SMBIOS information is a piece of data stored in the BIOS. Its internal information is classified by type number. The standard SMBIOS defines general data types from Type 0 to Type 127. Type numbers outside this range are used for manufacturer-defined purposes. Type 165 is one such custom type.

[0003] In standard SMBIOS information, Type 2 is used to store motherboard information, including the motherboard manufacturer ID, motherboard name, and motherboard serial number. ODM manufacturers are responsible for device development and mass production, and subsequently supply the same device to multiple OEM manufacturers for rebranding and resale. Based on the OEM manufacturers' customization requirements, ODM manufacturers need to modify and overwrite the original motherboard information in SMBIOS Type 2, replacing it with the corresponding OEM manufacturer's brand, model, and other information. This results in Type 2 data only reflecting the rebranded OEM manufacturer's information and failing to retain the ODM manufacturer's original device identifier.

[0004] Operating systems typically use Type 2 data to determine the motherboard information and identify the device, thus customizing operating system functions accordingly. However, the Type 2 data for the same ODM device can vary depending on the OEM manufacturer, effectively making it appear as multiple different device models to the operating system. Operating system vendors must repeatedly perform the determination and function customization work for each set of Type 2 information corresponding to each OEM, significantly increasing development costs and preventing ODM manufacturers from covering all OEM-branded models with a single customization, resulting in extremely low adaptation efficiency.

[0005] Take computer manufacturer ZY as an example: A device developed and mass-produced by ZY originally used Type 2 to write its own manufacturer information. The operating system could recognize the ZY model and complete specific problem adaptation and function debugging. When this device was supplied to two OEM manufacturers, LC and LX, for rebranding, both manufacturers requested that the manufacturer information in Type 2 be replaced with their own brand logo. The operating system could not recognize the device's native ZY model attributes, and all previously completed adaptation solutions became invalid. It was necessary to redevelop adaptation solutions for LC and LX's Type 2 information, resulting in redundant research and development. Summary of the Invention

[0006] To address the aforementioned issues, this invention provides a customized operation method for ODM manufacturers based on SMBIOS Type 165, which solves the problem of repeated operating system adaptation caused by the overwriting of SMBIOS Type 2 information when ODM models are sold to different OEM manufacturers.

[0007] This invention is implemented as follows: This invention provides a method for ODM vendor customization based on SMBIOS Type 165, comprising the following steps: S1. The BIOS constructs Type 165 data and stores it in the DIM. The Type 165 data stores the identification information of the ODM manufacturer and the operating system feature data. S2 and SDK parse Type 165 and pass the parsing result to the system application layer; S3. The system application obtains the characteristic data of Type 165 and performs its own operation logic judgment.

[0008] The Type 165 data structure includes: a type identifier field, a data length field, a handle field, a manufacturer identifier field, a motherboard identifier field, a feature quantity field, and at least one set of feature key-value pairs.

[0009] Each set of feature key-value pairs includes a feature identifier field and a feature value field.

[0010] Among them, the feature quantity field is the number of feature data, the feature identifier field indicates the type of feature, and the feature value field indicates the specific value of the corresponding feature.

[0011] Among them, the characteristic identification field is the hardware type code, application code, or special characteristic code.

[0012] The manufacturer identification field and the motherboard identification field are pre-agreed upon by the operating system and the ODM manufacturer.

[0013] The operating system reads DMI information using the dmidecode command, extracts Type 165 content from the DMI information, and parses it.

[0014] The beneficial effects of this invention are: This invention presents an ODM-customized operation method based on SMBIOS Type 165. It defines the Type 165 data structure and interaction flow, allowing hardware manufacturers and operating systems (OS) to design according to the agreed-upon data structure, thus resolving the issue of ODM-customized OS functionality. When adapting the operating system to ODM manufacturers, even if sold to OEM manufacturers, the problem will not recur due to Type 2 information being overwritten, as Type 165 is designed separately. Therefore, the operating system does not need to perform additional adaptation work for the same issue. Attached Figure Description

[0015] Figure 1 This is a schematic diagram illustrating the relationship between the computer hardware layer and the OS layer of this invention; Figure 2 This is a flowchart illustrating how the various components of this invention process Type 165. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art can make similar extensions without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0017] Please refer to Table 1 for an explanation of the technical terms used in this invention.

[0018] Table 1. Explanation of Technical Terms

[0019] For a diagram showing the relationship between the computer hardware layer and the OS layer, please refer to [link / reference]. Figure 1 As shown, the computer hardware layer and the operating system (OS layer) are two independent layers. Different operating systems can be installed on different hardware; the same operating system can also be deployed on multiple hardware platforms. Replacing or reinstalling the operating system will not change the hardware itself. The BIOS is firmware within the hardware and is also unaffected by the installation or replacement of the operating system. Specifically, regardless of what operating system is installed, the hardware layer remains unchanged.

[0020] The OS layer is the software layer, including the SDK and system applications. System applications are various programs and software running on the system, while the SDK is a software development kit that provides development interfaces for system applications and interfaces with the underlying hardware layer, acting as an intermediary bridge between system applications and the underlying hardware layer. The hardware layer includes physical hardware and firmware. Firmware is the BIOS, and physical hardware includes the CPU, hard drive, and other physical devices.

[0021] To address the needs of ODM manufacturers for customized operating system functionality, this application proposes Type 165, which is used to store the ODM manufacturer's identification information. In this way, problems solved during the ODM manufacturer adaptation phase will not reappear even after the operating system is sold to OEM manufacturers, as Type 165 is separately designed and will not be overwritten by Type 2 information. Therefore, the operating system does not need to perform further adaptation work for the same problem.

[0022] Therefore, this invention defines the data structure for Type 165, as detailed in Table 2.

[0023] Table 2 Type 165 Data Structure Table

[0024] The data structure of Table 2 is described in detail below. Table 2 shows the distribution of contiguous memory data. The first row is the byte sequence number, and the first column is the offset. In the first column, 0x0000 represents memory address 0, and the subsequent 0-7 are byte sequences relative to 0x0000. 0x0008 represents the starting address of the second row as 8, and 0x0010 represents the starting address of the third row as 16. The FeatureNum field represents the number of feature data; the FeatureID field represents the feature type ID, which can be a code for a certain hardware type, an application, or a special feature; the Feature value field, Feature, is the specific value of this feature, with a length of 2 bytes. The FeatureNum is followed by a specified number of FeatureIDs and Features stored sequentially. FeatureIDs and Features are the core data for achieving the Type 165 interaction expectation. FeatureIDs and Features are a set of key-value pairs. The entire Type 165 data structure contains 0 or more key-value pairs, the number of which is FeatureNum. The address is the position after FeatureNum, and they are stored sequentially. The ellipsis at the end indicates that there can be more FeatureIDs and Features after FeatureID3 and Feature3.

[0025] Specifically, the first byte of this data structure is byte 0, which is the Type number, fixed at 165. The first byte is the length of the Type 165 data structure. Bytes 2-3 are the handle value, a necessary field required by SMBIOS and defined by the manufacturer. Bytes 4-5 are the manufacturer ID, agreed upon by the operating system (OS) and the manufacturer to indicate which manufacturer it belongs to. Bytes 6-7 are the motherboard ID, also agreed upon by the operating system (OS) and the manufacturer to indicate a specific motherboard ID. Bytes 8-9 are the number of Features. Bytes 10-11 are FeatureID1, and bytes 12-13 are the corresponding Feature1 values. If there are more FeatureIDs and Features, they can be stored at subsequent addresses as FeatureID2, Feature2, FeatureID3, Feature3, etc. For example, if there are two sets of FeatureIDs and Features, FeatureNum is set to 2, followed by FeatureID1, Feature1, FeatureID2, and Feature2.

[0026] In addition, this invention provides a more detailed definition of the Type 165 field based on the format defined in the SMBIOS specification, as detailed in Table 3.

[0027] Table 3 Type 165 Field Definitions

[0028] like Figure 2 The flowchart shown is for each component processing Type 165, specifically including the following steps: Step S1: Hardware manufacturers (mainly ODM vendors) store their identification information and system feature data requiring OS customization in the DMI data structure, designated as Type 165, ensuring that the dmidecode command can correctly output Type 165 content. DMI data contains hardware configuration information maintained by the BIOS, such as motherboard and memory information. The operating system can read this information through an interface to run its own code logic. Therefore, DMI information is a means of interaction between the operating system and hardware. The dmidecode command is a command-line tool in the operating system used to parse DMI information and can format the output of DMI information.

[0029] Step S2: The SDK parses the information output by dmidecode, constructs a type 165 data structure, and provides it to the application layer. The SDK is a collection of interfaces provided by the operating system to applications to simplify application development.

[0030] After the BIOS constructs the above data structure, it proceeds to step S3: The application layer obtains the feature data stored in Type 165 through the SDK, performs logical judgments during its own runtime, and runs according to the specified features. Specifically, after the BIOS constructs the above data structure, the system SDK reads and parses the above data structure and passes the result to the application program, which then runs its own judgment logic based on the result.

[0031] This invention defines the Type 165 data structure and interaction flow. Hardware manufacturers and operating systems (OS) design based on the agreed-upon data structure, solving the problem of ODM manufacturers customizing OS functions. The BIOS constructs Type 165 information according to the data structure defined in this invention. The OS SDK parses the Type 165 data constructed by the BIOS according to the data structure defined in this solution. The system application executes the corresponding business logic based on the result parsed by the SDK. In this invention, a set of data is pre-agreed with the hardware manufacturer and stored in the BIOS according to a specified format. This data can be parsed by the OS layer SDK, which then returns the parsed result to the system application. The system application then executes its own judgment logic based on the result.

[0032] To illustrate this solution in detail, the present invention provides an example of setting a default bitrate for a camera application: Hardware manufacturers and operating systems agree that the FeatureID for camera applications is 0x2011, and the Feature data uses 0x0002 to indicate that the camera's default bitrate is high. Hardware manufacturers construct the above data structure according to this agreement, saving it as Type165, as shown in Table 4, in byte order.

[0033] Table 4. Type 165 Data Structure Table of the Example

[0034] The data structure is as follows: Byte 0 is the hexadecimal representation of the Type number, 0xa5, which is 165; Byte 1 is the data length, which is 14 bytes in total, hence the hexadecimal representation of 14, 0x0e; Bytes 2-3 are the Handle value, a necessary field required by SMBIOS and defined by the manufacturer, here set to 0x1001; Bytes 4-5 are the manufacturer ID, agreed upon by the OS and the manufacturer, used to indicate which manufacturer it is, here set to 0x1002; Bytes 6-7 are the motherboard ID, also agreed upon by the OS and the manufacturer, indicating a specific motherboard ID, here set to 0x1003; Byte 8 is the number of Features, here there is only one pair of Features, so it is 0x0001; Byte 10 is the FeatureID value 0x2011; and Byte 12 is the corresponding Feature value 0x0002. After the operating system's camera application runs, it parses the DMI data information through the SDK interface, finds the Type 165 data, checks if the Feature list contains a FeatureID of 0x2011, and retrieves the corresponding Feature value 0x0002. Therefore, it runs in high bitrate mode according to the convention. Thus, the ODM vendor successfully customized the camera application functionality within the operating system.

[0035] In the above embodiments, even if the ODM model is sold to different OEM manufacturers and the motherboard information in Type 2 is modified and overwritten by the OEM manufacturers, the operating system can still identify the ODM manufacturer and the corresponding feature data through Type 165 without needing to re-adapt for each OEM manufacturer.

[0036] While the present invention discloses preferred embodiments to achieve the above objectives, these are not intended to limit the structural features of the invention. Anyone skilled in the art should know that any easily conceived variations or modifications are possible within the technical spirit of the invention and are covered by the claims of the present invention.

Claims

1. A customized operation method for ODM manufacturers based on SMBIOS Type 165, characterized in that, Includes the following steps: S1. The BIOS constructs Type 165 data and stores it in the DIM. The Type 165 data stores the identification information of the ODM manufacturer and the operating system feature data. S2 and SDK parse Type 165 and pass the parsing result to the system application layer; S3. The system application obtains the characteristic data of Type 165 and performs its own operation logic judgment.

2. The ODM manufacturer customization operation method based on SMBIOS Type 165 according to claim 1, characterized in that, The Type 165 data structure includes: a type identifier field, a data length field, a handle field, a manufacturer identifier field, a motherboard identifier field, a feature quantity field, and at least one set of feature key-value pairs.

3. The ODM manufacturer customization operation method based on SMBIOS Type 165 according to claim 2, characterized in that, Each set of feature key-value pairs includes a feature identifier field and a feature value field.

4. The ODM manufacturer customization operation method based on SMBIOS Type 165 according to claim 3, characterized in that, The Attribute Quantity field indicates the quantity of attribute data, the Attribute Identifier field indicates the type of attribute, and the Attribute Value field indicates the specific value of the corresponding attribute.

5. The ODM manufacturer customization operation method based on SMBIOS Type 165 according to claim 4, characterized in that, The feature identifier field can be a hardware type code, application code, or special feature code.

6. The ODM manufacturer customization operation method based on SMBIOS Type 165 according to claim 2, characterized in that, The manufacturer identification field and the motherboard identification field are pre-defined by the operating system and the ODM manufacturer.

7. The ODM manufacturer customization operation method based on SMBIOS Type 165 according to claim 1, characterized in that, The operating system reads DMI information using the dmidecode command, extracts Type 165 content from the DMI information, and parses it.

Images