Firmware configuration method, Android starting method and electronic equipment

Abstract

The invention discloses a firmware configuration method, an Android starting method and electronic equipment, applied to the Android system starting process of the electronic equipment, the firmware configuration method comprises the steps that a configuration table in an editable format is obtained, and the configuration table comprises the configuration state of hardware; analyzing the configuration table; acquiring partial hardware information corresponding to the hardware with the configured configuration state in the configuration table; and loading the corresponding target firmware according to the partial hardware information. Complete hardware information can be placed in the target firmware, and the target firmware does not need to be independently constructed according to different hardware information of different product parts. For the configuration that only a small part of different hardware can share the same target firmware, the target firmware needing to be loaded is distinguished by storing different configuration tables, and the firmware corresponding to the unconfigured hardware is not loaded in the startup process, so that the firmware is not loaded in the case of realizing firmware reuse, and the firmware loading efficiency is improved. In addition, system errors caused by the fact that unconfigured hardware cannot be loaded can be reduced, and system stability is improved.

Description

Technical Field

[0001] The present invention relates to the field of hardware development, and in particular, to a firmware configuration method, an Android startup method, and an electronic device. Background Art

[0002] During the product development process, there are differences in peripheral devices among products of different models. Therefore, it is necessary to separately develop and produce firmware packages for products with different peripheral devices to adapt to different peripheral devices. However, using this method will result in high development costs and time-consuming and laborious. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a firmware configuration method, an Android startup method, and an electronic device, so as to realize the reuse of the firmware in different devices after a single configuration.

[0004] To solve the above technical problem, a technical solution adopted by the present invention is: A firmware configuration method is applied to an electronic device. The method includes: Obtain a configuration table in an editable format, where the configuration table includes the configuration status of the hardware; Parse the configuration table; Obtain partial hardware information corresponding to the hardware with the configuration status of "configured" in the configuration table; Load a corresponding target firmware according to the partial hardware information.

[0005] To solve the above technical problem, another technical solution adopted by the present invention is: An electronic device includes a memory, a processor, and a computer program stored on the memory and running on the processor. The processor executes each step in the above firmware configuration method when executing the computer program.

[0006] The beneficial effects of the present invention are as follows: The configuration status of whether the hardware is configured is recorded through an editable format configuration table. Since the configuration table of the present application is in an editable format, the configuration status of the hardware can be edited according to the actual situation to adapt to products of different models, and the editable format configuration table can be adjusted according to the peripheral devices of different models of products. Moreover, in the process of starting the Android system, the corresponding target firmware is loaded according to the partial hardware information; different target firmwares can be loaded according to different peripheral devices. During the process of starting the Android system, since the present application does not need to repeatedly set firmware packages according to different peripheral devices, the configuration efficiency can be effectively improved, and it is not necessary to separately develop and produce different firmware packages, which is time-saving and labor-saving. Description of the Drawings

[0007] Figure 1 The flowchart of steps of a firmware configuration method provided by an embodiment of the present invention; Figure 2 The schematic diagram of the Android startup process for reading a configuration table in the boot startup phase provided by an embodiment of the present invention; Figure 3 The schematic diagram of the process for modifying a configuration table provided by an embodiment of the present invention; Figure 4 The flowchart of steps of a firmware configuration method provided by an embodiment of the present invention in a specific implementation scenario; Figure 5 The schematic diagram of a configuration table provided by an embodiment of the present invention; <() Figure 6 The schematic diagram of the process for reading a configuration table in the Android startup process provided by an embodiment of the present invention; Figure 7 The flowchart of steps of an Android startup method provided by an embodiment of the present invention; Figure 8 The schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. Detailed implementation manners

[0008] In order to make the technical problems, technical solutions and beneficial effects to be solved by the present application clearer and more understandable, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0009] In the following description, specific details such as specific system structures and technologies are presented for the purpose of illustration rather than limitation, so as to thoroughly understand the embodiments of the present application. However, those skilled in the art should clearly understand that the present application can also be implemented in other embodiments without these specific details. In other cases, the detailed descriptions of well-known systems, devices, circuits and methods are omitted to avoid unnecessary details from interfering with the description of the present application.

[0010] It should be understood that when used in the specification of the present application and the appended claims, the term "comprising" indicates the presence of the described features, wholes, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or their combinations.

[0011] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that specific features, structures, or characteristics described in connection with that embodiment are included in one or more embodiments of this application. Thus, statements such as "in one embodiment", "in some embodiments", "in other some embodiments", "in still other embodiments", etc. that appear in different places in this specification do not necessarily all refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized. The terms "comprising", "including", "having" and their variants all mean "including but not limited to", unless otherwise specifically emphasized.

[0012] In the related art, according to different customer requirements, it is a common product setting method to add or subtract optional peripheral devices to achieve different additional functions in addition to the core functions. The change of peripheral devices requires adapting different hardware drivers, so it is necessary to separately set firmware for different peripheral devices under the same core function.

[0013] For example, product A has a camera, a printer, and a screen, while product B does not have a camera. Then, it is necessary to separately create firmware packages for product A and product B that are adapted to different peripheral hardware. However, the core functions implemented by product A and product B are the same. That is, by separately setting firmware packages for the two, the differences between the firmware packages are very small, but the maintenance cost of the firmware packages is high. For a series of products, when their basic functions are similar, due to different peripheral hardware, multiple firmware packages need to be separately established. In the future, if there are more products, but the differences in peripheral devices are small, there will also be more firmware packages. The more the number of series products, the more difficult and error-prone the maintenance will be.

[0014] At the same time, in the related art, if the peripheral device changes, it is necessary to recompile the kernel and the file system to adapt to the peripheral device.

[0015] This application provides a firmware configuration method, an Android startup method, and an electronic device to solve the above problems. The following specifically introduces a firmware configuration method of this application.

[0016] A firmware configuration method in this application can be used in the firmware development process, especially for the firmware development corresponding to a series of products. The electronic device in this application can be an electronic device that needs to cooperate with peripheral firmware, such as a computer host; in a financial scenario, for example, it is a cash register.

[0017] The following specifically introduces a firmware configuration method in the present invention, which is applied to the Android system startup process of an electronic device. Refer to the attached Figure 1 , and it includes steps 110 - step 140.

[0018] Step 110: Obtain a configuration table in an editable format, where the configuration table includes the configuration status of the hardware.

[0019] In an embodiment of the present application, the format of the configuration table is a text format, such as xml, txt, json, etc. These common formats have strong readability. In this way, only by specifying the path or address, most systems can directly read the corresponding data. The calibration of the hardware configuration status is achieved through the editable configuration table, which is decoupled from the boot process; and the configuration table can be loaded in any stage of the boot stage, kernel startup stage, or initialization process stage during the Android startup process, and the configuration table can be directly read in each process of the boot process to implement the judgment of the hardware configuration status, so that there is no need to separately set firmware packages for products with different hardware configurations.

[0020] In an embodiment of the present application, step 110 includes step 111: perform data verification on the configuration table. If the verification passes, then execute the step of parsing the configuration table. In this way, after obtaining the configuration table, data verification is performed on the configuration table before parsing, and parsing is only performed when the verification passes, avoiding the situation where the configuration table is tampered with, ensuring security while facilitating configuration modification. For example, data verification can be implemented through CRC (Cyclic Redundancy Check) verification or hash value verification.

[0021] Before step 110, there is also step 101: construct a configuration table, create a new configuration partition, and store the configuration table in the configuration partition. In this way, the configuration table is specifically stored in a separate configuration partition, so that the configuration table can be executed and updated separately, facilitating subsequent firmware updates for the device. Then, obtaining the editable configuration table in step 110 includes step 112: obtain the editable configuration table from the configuration partition. Then, only a fixed read address needs to be configured to point to the configuration partition, without caring about the location where the configuration table is stored each time.

[0022] In an embodiment of the present application, the configuration table and the firmware package are stored separately, which facilitates separate modification of the configuration table. The firmware package and various device drivers can also be stored in the configuration partition. Then, during the update, only by updating the configuration partition can the firmware be automatically loaded and updated according to the updated configuration table during the boot process, which can improve the update efficiency and stability in both OTA (Over-the-Air Technology) update and flash update methods.

[0023] Step 120: Parse the configuration table.

[0024] Step 130: Obtain partial hardware information corresponding to the hardware with the configured status in the configuration table.

[0025] Step 140: Load the corresponding target firmware according to the partial hardware information.

[0026] In an embodiment of the present application, please refer to Figure 2 , if step 110 includes obtaining the configuration table in the boot phase, then step 140 includes steps 1411 - 1413.

[0027] Step 1411: Load the corresponding device tree according to the partial hardware information.

[0028] Step 1412: Parse the device tree in the kernel startup phase, and obtain the target firmware driver module according to the description information in the device tree.

[0029] In an embodiment of the present application, after loading the built-in driver with the preset default configuration in the kernel startup phase in step 1412, the target firmware driver module is obtained according to the description information in the device tree. If the driver module conflicts with the built-in driver, the driver module will overwrite the built-in driver; Step 1413: Determine whether the driver module is loaded. If not, load the driver module.

[0030] In this way, in the boot phase, the device tree is selectively loaded according to the partial hardware information, so there is no need to construct device trees for products configured with multiple different peripheral devices respectively. It realizes dynamically loading the content of the device tree according to the partial hardware information in the configuration table in the boot phase. When performing maintenance, only the overall device tree and the corresponding configuration table need to be maintained, with low maintenance difficulty. And in the kernel phase, initialization can be directly performed according to the selectively loaded device tree. Since only the device tree corresponding to the partial hardware information is loaded in the boot phase and it can be determined that there are corresponding peripheral devices, there is no need to poll and judge whether there are corresponding peripheral devices for matching.

[0031] In an embodiment of the present application, if step 110 includes obtaining the configuration table in the kernel startup phase, then step 140 includes steps 1421 - 1423.

[0032] Step 1421: Load the built-in driver with the preset default configuration in the kernel startup phase.

[0033] Step 1422: Obtain the external driver corresponding to the partial hardware information and load the external driver.

[0034] Step 1423: If the external driver conflicts with the built-in driver, overwrite the built-in driver with the external driver.

[0035] In this way, the configuration table is obtained during the kernel startup phase, and the external driver can be dynamically loaded according to some hardware information in the configuration table. The driver corresponding to the firmware configured as none in the configuration table is not loaded, so that an error will not be reported when the corresponding firmware cannot be found subsequently, which speeds up the startup efficiency. It is also set to load the built-in driver with the default configuration first, and then load the external driver according to the configuration table. In this way, even if the configuration table fails to be loaded, the startup process can still be achieved through the default configuration, ensuring that the startup can be successfully performed and improving the stability of the system.

[0036] In an embodiment of the present application, step 110 includes obtaining the configuration table during the initialization process phase, and step 140 includes steps 1431 - 1435.

[0037] Step 1431: Load the preset default system data during the initialization process phase.

[0038] Step 1432: Obtain the extended system data corresponding to some hardware information and load the extended system data.

[0039] Step 1433: If the extended system data conflicts with the default system data, obtain the first priority of the default system data and the second priority of the extended system data.

[0040] Step 1434: If the first priority is greater than the second priority, abandon loading the extended system data.

[0041] Step 1435: If the second priority is greater than the first priority, overwrite the default system data with the extended system data.

[0042] In this way, during the initialization process phase, the corresponding extended system data is loaded according to some hardware information, and when the data of the extended system conflicts with the default system data, it is judged whether the previously loaded default system data needs to be overwritten according to the preset priority, so as to achieve automatic update after the configuration table is updated. Similarly, the method of preloading the default system data ensures that the startup can be successfully achieved even when the configuration table fails to be loaded.

[0043] In an embodiment of the present application, please refer to Figure 3 , and it also includes steps (1) to (4).

[0044] Step (1): Receive update information, where the update information includes updating the configuration table or updating the data value; Step (2): Mount the configuration partition to the file system and obtain the access path of the configuration partition in the file system; Step (3): Update the updated configuration table or data value to the configuration partition according to the access path; Step (4), unmount the configuration partition from the file system.

[0045] In this way, combined with the previous separate setting of the configuration table in the configuration partition, the information in the configuration partition can be updated separately. After rebooting, the configuration file will be automatically obtained from the configuration partition, and the boot process will be re-executed according to the configuration file, thus realizing the update of the product firmware.

[0046] In an embodiment of the present application, the configuration table and differential data are stored in the configuration partition, which can be device drivers, software, data, etc. It will perform overwriting and updating operations on the original data. If it is an update process by burning, the data is directly written into the eMMC (Embedded Multi Media Card) or flash (a kind of non-volatile memory) using a burner; after the system starts up, the configuration partition is mounted to the file system, then the path of the mounted file system is obtained, and then the product configuration table is opened. After that, the data inside is edited and modified, and then saved, and the partition is unmounted from the file system. The modification and addition of drivers can also be updated and overwritten in this way.

[0047] If it is an OTA update, only the data on the remote server (the data such as the configuration table and drivers stored in the configuration partition) needs to be pulled to the local, overwrite the original data in the configuration partition, and then reboot.

[0048] In summary, in different products, the drivers and firmware that may be used are saved. For example, for products with only some different external device configurations in the same series, the drivers and firmware required for the whole series are loaded for each series of products. Further, by the difference in loading different configuration tables for different products, the drivers and firmware required for each product are selectively loaded during the boot process, without the need to configure a separate firmware package for each series of products. Only the configuration table needs to be differentiated, and the generation of the configuration table is simple and the reading is convenient, avoiding the problem of error reporting caused by the inability to load after saving all the drivers and firmware, thus improving the boot efficiency; the configuration items can load the firmware and drivers as needed during the boot process, reducing system storage and improving the stability of the system. At the same time, a separate configuration partition is set to store the information related to the configuration table, which is convenient for reading and subsequent update of the configuration table, so that the drivers and firmware can be loaded according to the new configuration table after rebooting. Through the product configuration table, the peripheral devices can be maximally adapted to make a unified large kernel, and at the same time, the problem that the large kernel is prone to slow down the system boot speed due to errors during the initialization process is avoided. Through the configuration table, each boot stage can achieve loading on demand and reduce the initialization work.

[0049] Please refer to the appendix Figure 4, the application embodiments of the present application are specifically introduced below, including steps S210 - S230.

[0050] S210. Build a configuration table and store the configuration table in the configuration partition. Please refer to the appendix Figure 5 , which is a schematic diagram of the finally obtained configuration table. In the configuration table, each item has a clear definition. When the product does not define the corresponding device, the content of the configuration item is N. When there is a defined corresponding device, the content of the configuration item is Y. This is equivalent to the above step S101.

[0051] S220. Load all drivers and firmware. Here, all drivers and firmware can refer to the drivers and firmware used in a series of products, or can be further expanded according to the available storage space for the possible drivers and firmware to be used. The more drivers and firmware are configured, the more products can share the configuration file as well as the drivers and firmware, and then select and load them during the boot process. All firmware is loaded in the form of a firmware package, so that multiple products can share the same firmware package.

[0052] S230. Start the system and obtain the configuration table. The configuration table can be obtained at any stage of the boot phase, the kernel startup phase, or the initialization process phase, and initialize each parameter according to the content in the configuration table. This is equivalent to the above steps 110 to step 140.

[0053] Please refer to Figure 6 , after reading the configuration table during the startup process of the Android system, data verification such as CRC verification can be performed on the configuration table. If the verification passes, the configuration table is then passed into the kernel. During the kernel startup phase, hardware initialization can be performed according to the configuration table, and system initialization can be performed according to the configuration table during the initialization process phase.

[0054] If the configuration table is obtained during the boot phase, and the specified product device tree structure table is loaded according to the information obtained from it, there is no need to poll each node in the device tree one by one and match it with the hardware information during the kernel phase. This is equivalent to the above steps 1411 to step 1413.

[0055] If the configuration table is obtained during the kernel startup phase, first load the preset default driver, that is, before loading the driver according to the configuration table, first load the default driver to avoid the problem of system startup failure caused by the failure to read or load the configuration file. After loading the default driver, load the external driver as needed according to the configuration table, and when there is a conflict between the external driver and the default driver, overwrite the default driver with the external driver, so as to achieve the loading of the external driver corresponding to the configuration table and avoid the problem of driver conflict. This is equivalent to the above steps 1421 to step 1423.

[0056] If the configuration table is obtained during the initialization process stage, the preset default system data, i.e., the data that can ensure the normal operation of the system, is first loaded. Similarly, in the case of a failed configuration table loading, the Android system can still be normally started, avoiding the situation of failed startup. The system data includes attributes, executable files, software, etc. The system data can be default system data or extended system data. At the same time, when loading the extended system data according to the configuration table, if there is a conflict with the default system data, a priority judgment is made. Usually, the priority of the extended system data is set to be higher than that of the default system data, so as to enable the subsequent system data to be updated according to the configuration file. If you want to prevent the default system data from being tampered with, you can also set the priority of the default system data to be higher to achieve anti-tampering. This is equivalent to steps 1431 to 1435 above.

[0057] In summary, the present application realizes the selective loading of the firmware package in the form of a configuration table, and configures the default loaded data for the kernel startup stage and the initialization process stage. Therefore, in the case of a failed configuration table reading, it will not affect the successful startup of the system. What the configuration table defines is the existence of peripheral devices. Then, according to the update of the configuration table, the data inside the firmware can be modified, such as modifying the original attribute names, nodes, etc. inside the system, so as to achieve personalized loading of the firmware package while sharing the firmware package among products. And in the Android or Linux system, when a peripheral device does not exist, an error indicating that the device does not exist will be reported, which will result in a timeout waiting situation because it is necessary to wait for the peripheral device to respond, thus affecting the startup speed of the system. After adding the configuration table, it is possible to directly know that the peripheral device does not exist by obtaining the configuration table. For example, if the charging module does not exist, the initialization process can be omitted. This helps to speed up the startup speed of the system because the waiting time and the response time when an error occurs are reduced. The problem is solved from the source. And if data modification and update are required, only the configuration table needs to be modified and the system restarted, which is convenient for updating.

[0058] Please refer to the attached Figure 7 , the present invention also provides an Android system startup method, which is implemented based on the above-mentioned firmware configuration method, and includes steps 310 - 330.

[0059] Step 310: Initialize the running environment during the boot phase and boot into the kernel startup stage. The system will load the configuration table, read data from the memory, and then send the data to the kernel.

[0060] Step 320: Initialize the system environment during the kernel startup stage and boot into the initialization process stage. The kernel can read the configuration table by itself or receive the configuration table sent by the boot phase, and perform corresponding initialization operations according to the configuration table.

[0061] Step 330: Initialize the Android system during the initialization process. Configure the corresponding functions according to the configuration table.

[0062] Refer to Table 1 for the descriptions of each stage in the Android system startup process.

[0063] Table 1

[0064] Please refer to the appendix Figure 8 The present invention also provides an electronic device 400, including a memory 401, a processor 402, and a computer program stored on the memory 401 and running on the processor 402. When the processor 402 executes the computer program, it implements each step in the above-mentioned firmware configuration method.

[0065] The beneficial effects of the electronic device of the present invention are the same as those of the above method and will not be elaborated here.

[0066] The above are only embodiments of the present invention, and do not limit the patent scope of the present invention. Any equivalent transformation made by using the description and drawings of the present invention, or directly or indirectly applied in related technical fields, shall be equally included in the patent protection scope of the present invention.

Claims

1. A firmware configuration method, which is applied during the startup process of the Android system of an electronic device, and is characterized in that The method includes: Obtain a configuration table in an editable format, where the configuration table includes the configuration status of hardware; Parse the configuration table; Obtain partial hardware information corresponding to the hardware with the configured status in the configuration table; Load a corresponding target firmware according to the partial hardware information.

2. The firmware configuration method according to claim 1, wherein The Android system startup process includes a boot phase, a kernel startup phase, and an initialization process phase; The obtaining of the configuration table in an editable format includes: Obtain the configuration table in the boot phase; The loading of the corresponding target firmware according to the partial hardware information includes: Load a corresponding device tree according to the partial hardware information; Parse the device tree in the kernel startup phase, and obtain a target firmware driver module according to the description information in the device tree; Determine whether the driver module is loaded. If not, load the driver module.

3. A firmware configuration method according to claim 1, characterized in that The Android system startup process includes a boot phase, a kernel startup phase, and an initialization process phase; The obtaining of the configuration table in an editable format includes: Obtain the configuration table in the kernel startup phase; The loading of the corresponding target firmware according to the partial hardware information includes: Load a built-in driver with a preset default configuration in the kernel startup phase; Obtain an external driver corresponding to the partial hardware information, and load the external driver; If the external driver conflicts with the built-in driver, overwrite the built-in driver with the external driver.

4. A firmware configuration method according to claim 1, characterized in that The Android system startup process includes a boot phase, a kernel startup phase, and an initialization process phase; The obtaining of the configuration table in an editable format includes: Obtain the configuration table in the initialization process phase; The loading of the corresponding target firmware according to the partial hardware information includes: Load preset default system data in the initialization process phase; Obtain extended system data corresponding to the partial hardware information, and load the extended system data; If the extended system data conflicts with the default system data, obtain the first priority of the default system data and the second priority of the extended system data; If the first priority is greater than the second priority, abandon loading the extended system data; If the second priority is greater than the first priority, overwrite the default system data with the extended system data.

5. A firmware configuration method according to any one of claims 1-4, characterized in that The obtaining of the configuration table in an editable format includes: Perform data verification on the configuration table. If the verification passes, execute the step of parsing the configuration table.

6. A firmware configuration method according to claim 1, characterized in that, It further includes: Create a new configuration partition, and store the configuration table in the configuration partition.

7. A firmware configuration method according to claim 6, characterized in that, It further includes receiving update information, where the update information includes an updated configuration table or updated data values; Mount the configuration partition to the file system, and obtain the access path of the configuration partition in the file system; Update the updated configuration table or updated data values to the configuration partition according to the access path; Unmount the configuration partition from the file system.

8. A firmware configuration method according to claim 6, characterized in that, The obtaining of the configuration table in an editable format includes: Obtain a configuration table in an editable format from the configuration partition.

9. A method for starting an Android system, characterized in that, Implemented based on the firmware configuration method according to any one of claims 1-8, the Android system startup method includes: Initialize the running environment in the boot phase, and boot into the kernel startup phase; Initialize the system environment during the kernel startup phase and boot into the initialization process phase; Perform the initialization of the Android system during the initialization process phase.

10. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and running on the processor, wherein, When the processor executes the computer program, it implements each step in any one of the firmware configuration methods described in claims 1-8.

Images