CHIP SYSTEM WITH PROGRAM INSTALLATION SOFTWARE

Description

[0001] Embodiments and implementations relate to systems-on-chip, and more particularly to updating programs installed on a system-on-chip.

[0002] A system-on-chip typically incorporates program installation software. This installation software is stored in non-volatile memory of the system-on-chip during its manufacture. For example, the installation software may be included in "firmware" installed on the system-on-chip. This installation software is used to install a user's programs. Once the user's programs are installed, the installation software may also be used to update the installed programs. For example, the installation software may be configured to store different versions of a program in non-volatile memory. A communication protocol between the installation software and the non-volatile memory is defined by the system-on-chip manufacturer.

[0003] A user of the system-on-chip can configure the system-on-chip according to communication protocols that may be different from those provided for the installation software.

[0004] Once user programs are installed on the system-on-chip, the installation software provided during manufacturing may not be usable because: the installation software operates using the communication protocol(s) defined by the manufacturer, the installation software uses a hardware interface appropriate to its production environment which is not necessarily the one chosen by the user.

[0005] Additionally, it is necessary to change the SoC configuration (i.e., exit the user configuration) to use the manufacturer's installation software. However, changing the configuration has the disadvantage of blocking the execution of user programs and requiring a reboot of the SoC.

[0006] The user therefore generally provides their own installation software to update their programs. The user's installation software is then configured to work with the user-defined communication protocols to update their programs. In this way, the user does not have to modify the system-on-chip configuration to update their programs.

[0007] However, such a solution has the disadvantage of requiring additional memory space to store the user-developed installation software, in addition to the memory space occupied by the installation software initially integrated into the system-on-chip. Such a solution is therefore expensive.

[0008] The paper "A design and implementation of IAP based on HTTP" by QINGQING XU, published on June 27, 2011 at the international conference COMPUTER SCIENCE AND SERVICE SYSTEM (CSSS), 2011, IEEE, pages 1918-1922, DOI: 10.1109 / CSSS.2011.5974104 ISBN: 978-1-4244-9762-1, describes a technique for updating firmware within embedded components. In particular, program data is received using the HTTP protocol by an HTTP web server implemented within an STM32F107 MCU processor. This data is then transmitted to the "IAP" firmware which performs the update by saving the data in flash memory.

[0009] The paper "Bluetooth wireless monitoring, diagnosis and calibration interface for control system of fuel cell bus in Olympic demonstration" by HUA J ET AL, published on January 15, 2009, in the JOURNAL OF POWER SOURCES, ELSEVIER, AMSTERDAM, NL, vol. 186, no. 2, pages 478-484, ISSN: 0378-7753, DOI: 10.1016 / J.JPOWSOUR.2008.10.013 relates to an embedded programming technique for online updating of an ECU via Bluetooth. In particular, the technique disclosed by this paper uses a dedicated section of RAM as a data buffer to receive the entire update binary file before it is burned into flash memory.

[0010] Therefore, it is appropriate to propose a solution to simplify the updating of programs installed on a system on a chip.

[0011] The invention is set forth in the attached set of claims.

[0012] According to one aspect, there is provided a system-on-chip comprising: a non-volatile memory, a processor configured to execute: o an operating system configured to receive data according to a first communication protocol, o program installation software configured to communicate with the non-volatile memory according to a second communication protocol in order to be able to record data of a program in this non-volatile memory, in which the operating system is also configured to: determine whether data received according to said first communication protocol are program data intended for the installation software, make available to the installation software the program data received and intended for the latter, inform the installation software that program data intended for it have been received,and wherein the installation software is configured to record the program data made available to it in said non-volatile memory according to the second communication protocol.

[0013] Thus, the program data is received by the operating system using the first communication protocol and then made available to the installation software for storage in non-volatile memory using its own communication protocol. The system-on-chip therefore allows the installation software to be used without having to change the configuration of the system-on-chip.

[0014] In this way, the installation software installed on the system-on-chip by the manufacturer can be used simply to perform updates of the installed programs. It is therefore no longer necessary for the user to develop their own installation software. Only one installation software is thus installed in the non-volatile memory of the system-on-chip.

[0015] Additionally, the operating system may continue to run a program while the installation software is updating.

[0016] The data is encapsulated in a frame having a format defined according to the first communication protocol.

[0017] The frame comprises a header followed by said encapsulated data and ends with a postamble, the header being configured to indicate whether the data is intended for the installation software.

[0018] Advantageously, the installation software is configured to verify the authenticity of the data made available by the operating system.

[0019] In an advantageous embodiment, the program data received by the operating system is encrypted. The installation software is then configured to decrypt the data before saving it to the non-volatile memory.

[0020] Preferably, the system-on-chip includes volatile memory. The operating system is then configured to make the program data available to the installation software in the volatile memory.

[0021] According to another aspect, there is provided a method of installing a program comprising: a transmission of the program data to a system-on-chip as described above, according to the first communication protocol, a reception by the operating system of the system-on-chip of the program data, a verification by the operating system that the received data is indeed program data intended for the installation software, a provision by the operating system of the program data for the installation software, an indication by the operating system to the installation software that program data has been received, a recording of the program data by the installation software in the non-volatile memory according to the second communication protocol.

[0022] The data received by the operating system is encapsulated in a frame having a format defined according to the first communication protocol. The frame comprises a header followed by said encapsulated data and ends with a postamble, the header being configured to indicate whether the data is intended for the installation software.

[0023] Advantageously, the method further comprises a verification by the installation software of the authenticity of the data made available by the operating system.

[0024] In an advantageous embodiment, the program data received by the operating system is encrypted, the method further comprising decryption by the installation software of the data made available by the operating system before saving them in the non-volatile memory.

[0025] In an advantageous embodiment, the program data is made available to the installation software by the operating system in volatile memory.

[0026] Other advantages and characteristics of the invention will appear on examining the detailed description of modes of implementation and embodiment, which are in no way limiting, and the appended drawings in which: [ Fig 1 ] [ Fig 2 ] [ Fig 3 ] schematically illustrate embodiments and implementations of the invention.

[0027] There figure 1 illustrates a system on chip SOC according to one embodiment. The system on chip SOC comprises a processor PROC, a non-volatile memory MNV and a volatile memory MV.

[0028] An operating system OS and SFT installation software are stored in the non-volatile memory MNV. The SFT installation software is defined by a manufacturer of the system-on-chip SOC and the operating system OS is defined by a user of the system-on-chip SOC.

[0029] A portion of the MNV non-volatile memory can be reserved for the SoC manufacturer. This portion of the non-volatile memory can then be used to store the SFT installation software. Another portion of the MNV non-volatile memory can be reserved for the SoC user. This portion can then be used to store the user's operating system. This same portion of the MNV non-volatile memory can also be used to store user PRG programs.

[0030] The operating system OS is configured to receive data according to a first communication protocol defined by the user.

[0031] In particular, data is transmitted to the operating system OS in frames. These frames have a user-defined format. An example of a TRM frame is shown in figure 2 Each TRM frame begins with an HDR header followed by DAT data and ends with a TRL trailer. DAT data can be of different types. The operating system is configured to handle certain data types. Thus, the HDR header includes information about the DAT data in the TRM frame, including the data type of the frame. The TRL trailer is used to signal the end of a TRM frame. The DAT data in the frame can be encrypted.

[0032] In addition, certain types of DAT data may be intended for the SFT installation software. The DAT data intended for the installation software may be program data. This program data may be intended for the SFT installation software for an update of a program installed on the system-on-chip. The program data then corresponds to a new version of a program stored in the non-volatile memory of the system-on-chip.

[0033] DAT data for the SFT installation software is transmitted to the OS in the same format as data that can be processed by the OS. Data for the SFT installation software is therefore encapsulated in a format that can be read by the OS. The HDR header of a TRM frame can then be used to indicate to the OS that this TRM frame is intended for the SFT installation software.

[0034] In particular, the OS operating system is configured to read the HDR header of each received TRM frame to determine whether the received TRM frame is intended for the SFT installation software from its HDR header.

[0035] When the OS identifies that a frame is intended for the SFT installation software, the OS is configured to extract the DAT data from the TRM frame and then save it to the volatile memory MV.

[0036] Once the data is stored in the volatile memory MV, the operating system OS is configured to call the SFT installation software so that the latter can process the said DAT data intended for it.

[0037] In particular, the SFT installation software is configured to first verify the authenticity of the data. This authentication is made possible by the presence of secret data stored in the non-volatile memory MNV and known to the user.

[0038] Once the data authenticity is verified, the SFT installation software is configured to decrypt the DAT data. Then, after decrypting the DAT data, the installation software is configured to save the data to the MNV non-volatile memory using its own communication protocol to perform the program update.

[0039] There figure 3 illustrates an embodiment of a method for updating a PRG program installed on a system-on-chip, such as that described previously.

[0040] The method comprises a step 30 in which the system on chip SOC receives program data in frames. This data can be encrypted. This data corresponds to a new version of the program installed on the system on chip.

[0041] These frames are then read successively by the operating system OS installed on the system on chip.

[0042] In particular, for each received frame, the method comprises a step 31 in which the operating system OS analyzes the HDR header of the TRM frame. The analysis of the HDR header of the TRM frame allows the operating system OS to determine whether the DAT data of the TRM frame is intended for the SFT installation software.

[0043] If the operating system OS determines that the DAT data of a TRM frame is intended for the SFT installation software, the method comprises a step 32 in which the operating system extracts the DAT data from the TRM frame and saves it in the volatile memory MV.

[0044] In the latter case, the method also comprises a step 33 in which the operating system OS calls the installation software SFT in order to indicate to it that DAT data intended for it are available in the volatile memory MV.

[0045] Then, the method comprises a step 34 in which the SFT installation software processes the data intended for it in the volatile memory MV. In particular, the SFT installation software verifies the authenticity of the data present in the volatile memory MV. If the SFT installation software considers that the data is authentic, the software then decrypts the data before saving it in the non-volatile memory MNV according to its own communication protocol. The SFT installation software will finally verify the integrity of the update (by verifying a signature provided by the user via the DAT data as well). Saving the DAT data of the new version of the program in the non-volatile memory MNV makes it possible to update the program installed on the system on chip SOC.

[0046] The SOC system-on-chip allows the installation software to be used without having to modify the system-on-chip configuration to install or update a program. In fact, the program data is encapsulated according to the first communication protocol defined for the operating system, then made available to the installation software to be stored in non-volatile memory according to its own communication protocol.

[0047] In this way, the installation software installed on the system-on-chip by the manufacturer can be used simply to perform updates of the installed programs. It is therefore no longer necessary for the user to develop his own installation software. A single installation software is thus installed in the non-volatile memory of the system-on-chip. In addition, since the operating system retains control over the management of the reception of frames intended for the installation software, this allows it to establish an order of priority for its tasks so that it can execute a program during the update if necessary.

Claims

1. A chip system comprising - a non-volatile memory (MNV), - a processor (PROC) configured to execute: o an operating system (OS) configured to receive data according to a first communication protocol, o a program installation software (SFT) configured to communicate with the non-volatile memory (MNV) according to a second communication protocol in order to be able to record data of a program (PRG) in this non-volatile memory, wherein the operating system is also configured to: - determine whether data received according to said first communication protocol are program data intended for the installation software - make available to the installation software (SFT) the program data which are received and intended for the latter, - inform the installation software that program data which are intended therefor have been received, wherein the installation software (SFT) is configured to record the program data made available thereto in said non-volatile memory (MNV) according to the second communication protocol and wherein the data are encapsulated in a frame (TRM) having a format defined according to the first communication protocol, the frame (TRM) comprising a header (HDR) followed by said encapsulated data (DAT) and ends with a postamble (TRL), the header (HDR) being configured to indicate whether the data (DAT) is intended for the installation software (SFT).

2. The system according to claim 1, wherein the installation software (SFT) is configured to check an authenticity of the data (DAT) made available by the operating system (OS).

3. The system according to any one of claims 1 or 2, wherein the program data (DAT) received by the operating system (OS) are encrypted and wherein the installation software (SFT) is configured to decrypt the data (DAT) before recording them in the non-volatile memory (MNV).

4. The system according to one of claims 1 to 3, further comprising a volatile memory, and wherein the operating system (OS) is configured to make the program data (DAT) available to the installation software (SFT) in the volatile memory (MV).

5. A method for installing a program (PRG) on a chip system according to one of claims 1 to 4, comprising: - a transmission of data (DAT) from the program to the chip system, according to the first communication protocol, - a reception by the operating system of the chip system of the program data (DAT), - a check by the operating system (OS) that the received data is program data (PRG) intended for the program installation software (SFT), - a provision, by the operating system (OS), of the received program data for the installation software (SFT), - an indication by the operating system (OS) to the installation software (SFT) that program data has been received, - a recording of the program data (DAT) by the installation software (SFT) in the non-volatile memory according to the second communication protocol, and wherein the data received by the operating system are encapsulated in a frame (TRM) having a format defined according to the first communication protocol, the frame (TRM) comprising a header (HDR) followed by said encapsulated data (DAT) and ends with a postamble (TRL), the header (HDR) being configured to indicate whether the data (DAT) is intended for the installation software (SFT).

6. The method according to claim 5, further comprising a check by the installation software of an authenticity of the data (DAT) made available by the operating system (OS).

7. The method according to any one of claims 5 or 6, wherein the program data (DAT) received by the operating system (OS) are encrypted, the method further comprising a decryption by the installation software (SFT) of the data made available by the operating system before recording them in the non-volatile memory (MNV).

8. The method according to one of claims 5 to 7, the program data (DAT) is made available to the installation software (SFT) by the operating system (OS) in a volatile memory (MV).