RU2815184C1 - Method of changing firmware - Google Patents

Abstract

FIELD: computer engineering.

SUBSTANCE: technical result is achieved due to the fact that a given number of bits is distributed between the number of modules significant for VMPO and their properties in the structure of the descriptor code; setting the service marker (K) to a value of one; selecting a field from the body of the descriptor code corresponding to the first module, by value from which modules corresponding to parameters of this module are configured; checking the value of the service marker for compliance with the total number of adjustable modules (M), wherein in case the value of the service marker (K) is less than the value of the total number of adjustable modules (M), the value of the service marker (K) is increased and the next adjustable module (M) is adjusted, in case the value of the service marker (K) becomes corresponding to the total number of tunable modules (M), the last tunable module (M) is adjusted; and performing installation and/or updating of VMPO in accordance with the variable parameters of the composition of the device.

EFFECT: reduced probability of errors when updating devices taking into account changes in their hardware features.

1 cl, 2 dwg

Description

Field of technology

The claimed technical solution relates to application software for controlling devices based on microprocessor systems and is intended to adapt programs to hardware changes.

State of the art

All household and industrial devices that have built-in microprocessor-based control devices require an appropriate control program, usually loaded into the device’s memory at the manufacturing stage. Over time, the control program is improved by the manufacturer and updated on the device located at the consumer. This is done both to maintain a high level of functioning of the devices and to eliminate problems and errors in the program identified during operation. In the context of constant development of technology and increasing complexity of software products, the need for constant updating of embedded firmware (VMPO) arises more and more often and becomes one of the constant tasks of service departments to ensure the life cycle of devices. Most of the problems associated with the formation of VMPO update packages for specific devices, their delivery and installation to end users have already been solved by existing technical methods and means.

For example, a method and device for updating firmware for projection television is known (CN106101841 “Firmware upgrading method and device for projection television”, HISENSE BROADBAND MULTIMEDIA TECHNOLOGY CO LTD, published 11/09/2016, [1]). The firmware update method includes the following steps:

- the TV control module receives an update descriptor in the television code stream, wherein the update descriptor contains information about updating the projection control module;

- The TV control module analyzes the update information from the update descriptor and downloads the firmware update package through the TV code stream;

- the TV control module sends the firmware update package to the projector control module;

- The projector control module receives the firmware update package from the TV control module and performs the update operation according to the firmware update package.

The disadvantage of analogue [1] is that the structure of the descriptor code and the structure of the software mechanism for decrypting the descriptor code are unknown. The description does not indicate the ability to use updates when changing hardware modules.

There is also a known method for updating software (US10474448 “METHOD AND SYSTEM FOR PROVIDING SOFTWARE UPDATES TO LOCAL MACHINES” (SOPHOS LTD [GB], published 11/12/2019), [2]). As in the claimed technical solution, a descriptor file is provided in the method. The descriptor file includes a hash code for each of the plurality of update subfiles and indicates the order in which the plurality of update subfiles are combined into a software update. The descriptor file is transmitted to a plurality of local computing devices. One of a plurality of update subfiles is downloaded to one of a plurality of local computing devices. All hash codes of the update subfiles present in the descriptor file are compared with the hash codes for the subfiles stored in the memory of at least one of the plurality of local computing devices. If all subfiles are found, the software update is assembled in its memory from the plurality of update subfiles and the software update is installed.

At least one of the plurality of local computing devices may determine whether a software update is relevant to resident software on the computing device by matching a software update identifier contained in a descriptor file with identifiers of resident software on the computing device.

The disadvantage of analogue [2] is that the structure of the software mechanism for decrypting the descriptor code is unknown. Because of this, it is difficult to determine the possibility of using this method for devices with a variable composition of modules.

The specified analogue [2] is, in terms of the totality of essential features, the closest analogue of the same purpose to the claimed technical solution. Therefore, it is accepted as a prototype.

The technical problem being solved is that during the mass production of a number of devices with microprocessor control, there is a wide variety of options for completing the same type of device with various identical units from different manufacturers, which have differences and features in their program control. Each such device variant requires its own special version of VMPO, which takes into account the management features of the configured version of the device blocks. If there are several similar variable blocks in a device, the number of VMPO versions increases many times, which requires significant effort and money not only to administer the repository of these VMPO versions, their distribution among devices corresponding to them by version, but also to constantly keep this entire array of VMPO up to date state - after all, any change made to the code must be properly reflected in all versions of VMPO in use.

Thus, there is a need for a way to adapt VMPO to the configuration version of a specific device, so that one single working version of VMPO can function correctly on all modifications of the device.

Disclosure of the proposed technical solution

The technical result provided by the claimed technical solution is to ensure the adaptation of VMPO to the configuration version of a specific device in such a way that one single working version of VMPO can function correctly on all modifications of the device. At the same time, the administration of VMPO versions is significantly simplified (there is no need to maintain and track a version registry for all possible combinations of hardware) and the likelihood of errors during updates due to hardware features is reduced.

The essence of the claimed technical solution is that

The method for changing firmware (VMPO) includes the following steps:

- activate the control code responsible for interaction with hardware modules;

- receive a descriptor code containing device data on its critical modules for VMPO;

- read the hardware registers on which the switches have generated a code sequence from the control code in accordance with the received descriptor code;

- distribute a given number of bits between the number of modules that are significant for VMPO and their properties in the structure of the descriptor code;

- set the service marker (K) to the value of one;

- select a field from the body of the descriptor code corresponding to the first module by value from which modules corresponding to the parameters of this module are configured;

- check the value of the service marker for compliance with the total number of customizable modules (M), and if the value of the service marker (K) is less than the value of the total number of customizable modules (M), then the value of the service marker (K) is increased and the next customizable one is configured module (M), 6 if the value of the service marker (K) becomes corresponding to the total number of custom modules (M), then the last custom module (M) is configured, and - the VMPO is installed and/or updated in accordance with the changed parameters composition of the device.

The above essence is a set of essential features of the claimed technical solution, ensuring the achievement of the declared technical result.

In a particular case, in the structure of the descriptor code, the first three bits are allocated for the first module, which makes up eight combinations for properties, for the second module - a pair of bits, which covers four combinations of properties, for the first module a bit field is allocated next to the J bit, with this is the last one bit N is allocated to the last module (M).

The author of the claimed technical solution produced a prototype of this solution, tests of which confirmed the achievement of the technical result.

Brief description of drawings

In fig. Figure 1 shows the structure of a descriptor code containing information about the composition of a specific device in blocks critical for VMPO. In fig. 2 – block diagram of the algorithm of the VMPO adaptation software module according to the descriptor code data.

Implementation of technical solution

The method uses one universal working version of VMPO to install and/or update the control program for a number of similar devices that differ in the composition of a number of their blocks, which generally require significant modification of the control program code.

In this case, a descriptor code is generated and used, which reflects the composition of the device according to its critical modules for VMPO. For example, for television receivers, the critical variable module is the LCD panel, which for types from different manufacturers can have different operating modes and parameters (refresh rate, scan parameters, data formats, etc.).

The descriptor code is formed as at least an eight-digit binary code. In special cases, the code can be twelve digits or more. Individual bits of the descriptor code are associated with various significant parameters of the device composition (modules, operating modes, parameters, etc.).

An example of the structure of the descriptor code (10) is shown in Fig. 1, where a given number of bits is distributed between the number of modules that are significant for VMPO and their properties.

In general, for the first Module 1 (18) the first three bits (11,12,13) can be allocated, which is 8 combinations for properties, for the second Module 2 (19) - a pair of bits (14,15) which will cover four combination of properties, for the I-th module (20) allocate a few bits next to Bit J (16), and so on until the last bits, including Bit N (17), which are allocated to Module M. Or the above bits can be left in reserve - for possibilities for system expansion. With such a distribution, each significant property of each device module can be assigned a code sequence that uniquely determines its state (or value) in a given device. This allows you to digitally encode information about the hardware features of a specific device for storage and subsequent analysis. When changing any device module to another type (as a result of repair or maintenance), the descriptor code is rewritten to the one corresponding to the new hardware composition of the device.

For proper adaptation of the universal VMware to the specific hardware composition of the device, at the stage of activating the control code responsible for interaction with certain hardware modules, the required section of the descriptor code corresponding to this module is obtained and decrypted according to the algorithm, the block diagram of which is presented in Fig. 2. where, after the necessary preparatory operations, stage (30) of adapting the VMPO to the hardware environment begins.

In general, the process begins by obtaining the descriptor code (31), in any way provided for this:

a) reading hardware registers on which the code sequence is formed by switches,

b) reading the value from memory cells where the code was previously written during the production of the device,

c) reading data from a special file from removable media connected to the device at this stage, etc.

Then the cycle of sequential programming of the module parameters begins, for which the service marker is set to one (32) and the field corresponding to the first module (33) is extracted from the body of the descriptor code, according to the value from which the program modules (34) corresponding to the parameters of this module are configured. Subsequent checking of the marker value (35) for equality to the total number of customizable modules allows you to branch the program - if the result is negative, the marker value increases (36) and the program begins processing the next module (33, 34, 35) until a positive result is achieved - processing the data of the last module, after which work on installing and/or updating VMPO continues (37).

As follows from the description, the loaded VMPO must initially contain control data for all types of modules used in the device, from which a subset of the required ones is selected at the adaptation stage. However, with today's typical VMPO size, the share of applied data on module management is absolutely insignificant and the proposed mechanism greatly facilitates the administration of VMPO updates for mass-produced products.

Claims (12)

1. A method for changing firmware (VMPO), characterized by the fact that it includes the following steps: - activate the control code responsible for interaction with hardware modules; - receive a descriptor code containing device data on its critical modules for VMPO; - read the hardware registers on which the switches have generated a code sequence from the control code in accordance with the received descriptor code; - distribute a given number of bits between the number of modules that are significant for VMPO and their properties in the structure of the descriptor code; - set the service marker (K) to the value of one; - select a field from the body of the descriptor code corresponding to the first module, by the value from which modules corresponding to the parameters of this module are configured; - check the value of the service marker for compliance with the total number of custom modules (M), while if the value of the service marker (K) is less than the value of the total number of configurable modules (M), the value of the service marker (K) is increased and the next configurable module (M) is configured, if the value of the service marker (K) becomes corresponding to the total number of customizable modules (M), the last customizable module (M) is configured; And - install and/or update VMPO in accordance with the changing parameters of the device composition. 2. The method according to claim 1, characterized in that in the structure of the descriptor code the first three bits are allocated for the first module, which is eight combinations for properties, for the second module - a pair of bits, which is four combinations of properties, for the first module allocate a field of bits next to the J bit, with the last N bit allocated to the last configurable module (M).