Method of loading software code, corresponding system and vehicle equipped with such a system

Abstract

A method for method of setting up a processing system includes determining availability of user-provided platform information indicative of a first memory platform out of a plurality of memory platforms. In response to determining that the user-provided platform information is available at the first memory platform, a boot loader code is read from the first memory platform. In response to determining that the user-provided platform information is not available, test availability of the boot loader code in another memory platform of the plurality of memory platforms, and read the boot loader code from the another memory platform upon testing the availability of the boot loader code in the another memory platform.

Claims

1. A method of setting up a processing system, the method comprising: determining availability of platform information indicative of a first memory platform out of a plurality of memory platforms; in response to determining that the platform information is available at the first memory platform, reading a boot loader code from the first memory platform; and in response to determining that the platform information is not available, testing whether the boot loader code is available from another memory platform of the plurality of memory platforms, and reading the boot loader code from the another memory platform upon testing the availability of the boot loader code in the another memory platform, wherein the boot loader code comprises a boot loader header and a boot loader body, wherein reading the boot loader code comprises reading the boot loader header, extracting processing system settings from the boot loader header, and reading the boot loader body.

2. The method of claim 1, further comprising reading the platform information from a one-time-programmable (OTP) memory area.

3. The method of claim 1, further comprising testing whether a memory platform in a hardcoded sequence of the plurality of memory platforms comprises the boot loader code.

4. The method of claim 3, further comprising selecting the hardcoded sequence of the plurality of memory platforms out of a plurality of hardcoded sequences as a function of user controlled input.

5. The method of claim 1, further comprising storing the boot loader code in a flash memory.

6. A method of setting up a processing system, the method comprising: determining availability of platform information indicative of a first memory platform out of a plurality of memory platforms; in response to determining that the platform information is available at the first memory platform, reading a boot loader code from the first memory platform; and in response to determining that the platform information is not available, testing whether the boot loader code is available from another memory platform of the plurality of memory platforms, and reading the boot loader code from the another memory platform upon testing the availability of the boot loader code in the another memory platform, wherein the boot loader code comprises a boot loader header and a boot loader body, wherein reading the boot loader code comprises reading the boot loader header in a first reading mode and the boot loader body in a second reading mode, the first reading mode being slower than the second reading mode.

7. A processing system comprising: read only memory storing a software code; a processor to execute the software code, the software code comprising instructions that when executed cause the processor to: determine availability of platform information indicative of a first memory platform out of a plurality of memory platforms; in response to determining that the platform information is available at the first memory platform, read a boot loader code from the first memory platform; and in response to determining that the platform information is not available, test whether of the boot loader code is available from another memory platform of the plurality of memory platforms and read the boot loader code from the another memory platform upon testing the availability of the boot loader code in the another memory platform, wherein the boot loader code comprises a boot loader header and a boot loader body, wherein the software code comprises instructions for reading the boot loader code that cause the processor to read the boot loader header, extract processing system settings from the boot loader header, and read the boot loader body.

8. The system of claim 7, wherein the software code comprises further instructions for reading the platform information from a one-time-programmable (OTP) memory area.

9. The system of claim 7, wherein the software code comprises further instructions for testing for availability of the boot loader code in a hardcoded sequence of the plurality of memory platforms.

10. The system of claim 9, wherein the software code comprises further instructions for selecting the hardcoded sequence of the plurality of memory platforms out of a plurality of hardcoded sequences as a function of user controlled input.

11. The system of claim 7, wherein the software code comprises further instructions for storing the boot loader code in a flash memory.

12. A processing system comprising: read only memory storing a software code; a processor to execute the software code, the software code comprising instructions that when executed cause the processor to: determine availability of platform information indicative of a first memory platform out of a plurality of memory platforms; in response to determining that the platform information is available at the first memory platform, read a boot loader code from the first memory platform; and in response to determining that the platform information is not available, test whether of the boot loader code is available from another memory platform of the plurality of memory platforms and read the boot loader code from the another memory platform upon testing the availability of the boot loader code in the another memory platform, wherein the boot loader code comprises a boot loader header and a boot loader body, wherein the software code comprises instructions for reading the boot loader code that cause the processor to read the boot loader header in a first reading mode and the boot loader body in a second reading mode, the first reading mode being slower than the second reading mode.

13. A vehicle comprising: read only memory storing a software code; a processor to execute the software code, the software code comprising instructions that when executed cause the processor to: determine availability of platform information indicative of a first memory platform out of a plurality of memory platforms; in response to determining that the platform information is available at the first memory platform, read a boot loader code from the first memory platform; and in response to determining that the platform information is not available, test whether of the boot loader code is available from another memory platform of the plurality of memory platforms and read the boot loader code from the another memory platform upon testing the availability of the boot loader code in the another memory platform, wherein the boot loader code comprises a boot loader header and a boot loader body, wherein the software code comprises instructions for reading the boot loader code that cause the processor to read the boot loader header, extract processing system settings from the boot loader header, and read the boot loader body.

14. The vehicle of claim 13, wherein the boot loader code comprises a boot loader header and a boot loader body, wherein the software code comprises instructions for reading the boot loader code that cause the processor to read the boot loader header in a first reading mode and the boot loader body in a second reading mode, the first reading mode being slower than the second reading mode.

15. The vehicle of claim 13, wherein the software code comprises further instructions for reading the platform information from a one-time-programmable (OTP) memory area.

16. The vehicle of claim 13, wherein the software code comprises further instructions for testing for availability of the boot loader code in a hardcoded sequence of the plurality of memory platforms.

17. The vehicle of claim 16, wherein the software code comprises further instructions for selecting the hardcoded sequence of the plurality of memory platforms out of a plurality of hardcoded sequences as a function of user controlled input.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) One or more embodiments will now be described, by way of example only, with reference to the annexed figures, wherein:

(2) FIG. 1 depicts a possible context of use of embodiments;

(3) FIG. 2 is a flow chart exemplary of possible operation of embodiments,

(4) FIG. 3 is exemplary of a possible a user one-time-programmable (OTP) layout in embodiments, and

(5) FIG. 4 is exemplary of possible xLoader header management in embodiments.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

(6) In the ensuing description, one or more specific details are illustrated, aimed at providing an in-depth understanding of examples of embodiments of this description. The embodiments may be obtained without one or more of the specific details, or with other methods, components, materials, etc. In other cases, known structures, materials, or operations are not illustrated or described in detail so that certain aspects of embodiments will not be obscured.

(7) Reference to “an embodiment” or “one embodiment” in the framework of the present description is intended to indicate that a particular configuration, structure, or characteristic described in relation to the embodiment is comprised in at least one embodiment. Hence, phrases such as “in an embodiment” or “in one embodiment” that may be present in one or more points of the present description do not necessarily refer to one and the same embodiment. Moreover, particular conformations, structures, or characteristics may be combined in any adequate way in one or more embodiments.

(8) The references used herein are provided merely for convenience and hence do not define the extent of protection or the scope of the embodiments.

(9) FIG. 1 refers, by way of non-limiting example, to the possible application of embodiments in the automotive sector, e.g. in connection with (advanced) microprocessors MP having associated memories comprising a boot ROM, indicated M, plus a set of other memory sources M1, . . . Mn (also referred to as platforms or peripherals) such as e.g. NAND/NOR flash storage, SD or MMC cards adapted to provide boot programs available for loading boot code to the processor MP under the coordination of SW code stored in the boot ROM M.

(10) Secure microprocessors protecting “connected” motor vehicles C such as motor cars may be exemplary of such a context of use.

(11) For instance, one System-on-Chip (SoC) may be used for telematics (or infotainment) high-level services and one companion chip, with a dedicated boot memory (e.g. ROM), may be used for CAN management.

(12) In such arrangements, the Bill of Materials (BoM) may become fairly expensive: it may in fact comprise e.g. a main SoC with associated non-volatile memory (NVM) storage plus a CAN SoC again with associated non-volatile memory.

(13) Such a platform may comprise other smart/early services (e.g. time to first rearview camera frame, time-to-first audio chime) rendered very rapid as a desirable feature.

(14) Certain systems such as the ST Telemaco.sub.3P SoC referred to in the foregoing may offer i.a. a dedicated application CAN subsystem. The capability of loading and setting up a CAN stack in a short time (for instance less than 60 ms), independently of the type(s) of main storage memory involved is a desirable feature for such a system, making it possible for the application layer running on the subsystem to take care of other smart/early services.

(15) As already noted, in such a context, a ROM should desirably load a first piece of software code—oftentimes referred to as xLoader—in a (very) short time to provide a time-to-X feature (e.g. time to first CAN message).

(16) Also, a ROM should desirably be able to load a first piece of software code from any of a variety of types of supported non volatile memory families or platforms (NAND, NOR, SD, MMC).

(17) Briefly, a (boot) ROM should desirably be able to load a first piece of software code from virtually any device, in a short time and relying on adequate timings and functional configurations, possibly by interacting, e.g., with any of: a controller area network (CAN) vehicle bus protocol; a non-volatile flash memory using floating-gate transistors in a way that resembles a NAND gate; a non-volatile flash memory using floating-gate transistors in a way that resembles a NOR gate; a memory card for solid-state storage e.g. based on a NAND device plus an embedded controller (SD/MMC).

(18) The various non-volatile memory (NVM) storage options discussed above are exemplary of various memory devices or platforms (M1, . . . , Mn, as exemplified in FIG. 1) adapted to provide pieces of software code to be loaded into the system in compliance with boot code stored in the boot ROM indicated M.

(19) Notionally, a number of approaches can be envisaged in order to address the issues related to such a booting procedure.

(20) For instance, one may create a list of supported NVM models/types, which however may not match customer expectations.

(21) Also, one may elect to read the SW code in a slower and more basic way from a certain supported memory model and/or perform the loading process by subsequent attempts.

(22) In addition to possibly causing an undesirable waste of time, these solutions may turn out to be unsatisfactory insofar as a desired result may be reached (only) for few storage devices, which may be expensive.

(23) In one or more embodiments, possible operation of a system (e.g. a SoC in a secure microprocessor MP protecting a “connected” car C) comprising, e.g. a boot ROM M and various (different) memory platforms (sources) M1, . . . , Mn may be as exemplified in the flow chart of FIG. 2.

(24) After START, in an act (step) represented by block 100, the ROM starts setting up the system core.

(25) In an act represented by block 102, the ROM reads platform information (more precisely, the ROM code facilitates an attempt to read such information) e.g. from an OTP area which can be written (e.g. “fused”) by the customer/user.

(26) Such platform information (if present) may be indicative of a (first) memory device out of the memory devices (platforms) M1, . . . , Mn from which boot loader code as desired can be read.

(27) In one or more embodiments, such platform information may include e.g. information on the components in the system MP (e.g. a main SoC plus a CAN SoC with associated NVM storage) as well as information on desirable operation features e.g. smart/early services such as first rearview camera frame, time-to-first audio chime, and so on.

(28) In an act represented by block 104, a check is made as to the actual availability of such OTP information which may be provided by the customer, including e.g. an indication of a preferred booting peripheral.

(29) If the check at 104 yields a negative outcome (N), e.g. because the OTP area is empty, with no such information available therein, in an act represented by block 106, a hardcoded (default) sequence of memory platforms (out of M1, . . . , Mn), e.g. NAND first, SDMMC slot 0, SDMMC slot 1, etc. is attempted until a memory platform is located from which boot loader code as desired can be read. Success of such an action is represented by a positive outcome (Y) of block 108.

(30) In one or more embodiments, several (different) default sequences may be hardcoded in the ROM M.

(31) In one or more embodiments a certain sequence can be selected as a function on the status of two or three general purpose input/output pins, which status can be controlled by the user.

(32) In one or more embodiments, whenever the act represented by block 108 yields a negative outcome (N), the act represented by block 106 is attempted again with a next boot platform (peripheral) belonging to a selected hardcoded sequence, looking for a valid piece of SW to be loaded.

(33) In one or more embodiments, such attempts may be repeated with different boot platforms belonging to a selected hardcoded sequence and, possibly, by exploring a plurality such default sequences until the act represented by block 108 yields a positive outcome (Y=success).

(34) As a result of a positive outcome (Y=success) in the act represented by block 108 in FIG. 2, in an act represented by the block 110—which may also be reached from the act 104 in the case of a positive outcome (Y) of the act 104—an xLoader header is read.

(35) In one or more embodiments “optimizing” settings like device timings, fast read features, specific commands and parameters to activate high performance profiles can be extracted from the xLoader header and validated in an act represented by block 112.

(36) In an act represented by block 114 the xLoader body is read after which END of the procedure exemplified in FIG. 2 occurs.

(37) In case the act 114 occurs without optimizing parameters are applied, the xLoader body, which represents the largest portion of code to be loaded, will be loaded by relying on a basic standard configuration, exceeding the time-to-X feature.

(38) If the check at 104 yields a positive outcome (Y) the ROM code may “read” from the user OTP, besides the boot platform identified (e.g. one of M1, . . . , Mn), specific settings from the user OTP in order to identify how to facilitate operation as best suited with a specific platform (e.g. NOR devices, 4-wire mode, high-speed, general purpose input/output—GPIO configuration), e.g. with “useless” configurations (e.g low-speed mode which is not preliminary to time-to-X feature) not taken into account.

(39) In that case, hardcoded sequences are bypassed (going from block 102 to block 110 in FIG. 1 directly through the block 104), the preferred boot source peripheral is immediately identified and configured in the best way to exhaustively satisfy the time-to-X feature, relying on best specificities for the platform which hosts the MP.

(40) In one or more embodiments, the ROM code can read the xLoader header in a standard way, e.g. a chunk of 6.sub.4 bytes at the top of the xLoader containing, in addition to certain integrity information, (all the) specific settings to configure the storage device in an effective way.

(41) Device-dependent settings can be stored in the header and authenticated before usage.

(42) In one or more embodiments, the ROM code can deploy the configuration on a standard configuration template, e.g., so that unauthorized operations are not allowed.

(43) In one or more embodiments, specific boot source commands and parameters or configurations which could lead to a corruption of the loading process may be left out of consideration.

(44) In one or more embodiments, the ROM code may read the xLoader body and certificates, which facilitates reading (almost) the entire xLoader body in an “optimizing” way.

(45) In one or more embodiments, the xLoader header—e.g., 64 bytes—will be the only entity read in slow mode, while the body and appended meta-information are transferred always in the best and optimizing way depending on the context specificities.

(46) FIG. 3 is an example of a possible user OTP layout in one or more embodiments, with exemplary choices for SD/MMC (memory card for solid-state storage based on a NAND device plus an embedded controller) boot source comprising: Boot v. User partition (SD card v. eMMC—embedded MultiMediaCard); Bus width (1-4-8 bit); Speed (low speed vs. high speed); and GPIO configuration.

(47) FIG. 4 is exemplary of a possible approach in xLoader header management.

(48) The following designations may apply.

(49) CID: Command ID. The ID of the command to be used for reading the serial memory in fast mode. This completely defines the type of configuration the memory will use.

(50) RM: Read Mode (SPI-qSPI-QPI)

(51) [1]: SPI mode is used [1-1-1]

(52) [2]: QPI mode is used [4-4-4]

(53) [3]: qSPI mode 1 is used [1-4-4]

(54) [4]: qSPI mode 2 is used [1-1-4]

(55) #DC: Number of Dummy Cycles to be programmed for reading in fast mode

(56) F: frequency divisor to be applied to the serial NOR controller

(57) OPT: option set #1

(58) [7] Write status register before fast read phase

(59) [4] Write VCFGR register before fast read phase

(60) [3] Write EVCFGR register before fast read phase

(61) [4] Issue set dummy cycle command before fast read phase

(62) [3] Issue a custom command before fast read phase

(63) [2] Enable feedback clock, for high speed performances

(64) [1] Status register mask polarity to be checked afte reading the status register

(65) [0] Spare bit

(66) CTM_A: custom command argument

(67) CDC_A: set dummy cycles command argument

(68) EVC_A: enhanced volatile configuration register argument

(69) VC_A: volatile configuration register argument

(70) SR2_A: status register command argument #2

(71) SRI_A: status register command argument #1

(72) CTM_1: custom command argument length (0 or 1)

(73) WM: write mode

(74) [1:0] enhanced volatile configuration register write mode

(75) [3:2] volatile configuration register write mode

(76) [5:4] status register write mode

(77) [7:6] custom command write mode

(78) EVC_M: enhanced volatile configuration register mask

(79) VC_M: volatile configuration register mask

(80) SR_M: status register mask

(81) CTM: custom command ID

(82) SR_R: read status register command ID

(83) SR_W: write status register command ID

(84) CDC: dummy cycle set command ID

(85) xLoader CRC: cyclical redundancy code of xLoader

(86) Header CRC: cyclical redundancy code of Header.

(87) In one or more embodiments, a method of setting up a processing system (e.g., MP) by loading thereto boot loader code read (e.g. under the control of a boot ROM, M) from a memory platform out of a plurality of memory platforms (e.g., M1, . . . , Mn) may comprise: checking (e.g., 104) the availability of user-provided platform information (e.g., 102) indicative of a first memory platform, out of said plurality of memory platforms, adapted to provide said boot loader code; if said checking yields a positive outcome, reading (e.g., 110, 112, 114) said boot loader code from said first memory platform out of said plurality of memory platforms); if said checking yields a negative outcome, testing (e.g., 106, 108) for availability of said boot loader code at least another memory platform out of said plurality of memory platforms and reading said boot loader code from said at least another memory platform out of a plurality of memory platforms.

(88) In one or more embodiments, said boot loader code may comprise a boot loader header and a boot loader body, wherein reading said boot loader code may comprise: reading (e.g., no) said boot loader header, extracting (e.g., 112) processing system settings therefrom, and reading (e.g. 114) the loader body.

(89) In one or more embodiments, said boot loader code may comprise a boot loader header and a boot loader body, wherein reading said boot loader code may comprise reading the boot loader header in a first reading mode and the boot loader body in a second reading mode, the first reading mode slower than the second reading mode.

(90) One or more embodiments may comprise reading said platform information from a one-time-programmable, OTP memory area.

(91) One or more embodiments may comprise testing for availability of said boot loader code at least another memory platform out of said plurality of memory platforms in at least one hardcoded sequence of memory platforms.

(92) One or more embodiments may comprise selecting said at least one hardcoded sequence of boot memory platforms out of a plurality of hardcoded sequences as a function of user controlled input.

(93) One or more embodiments may comprise storing said boot loader code in a flash memory.

(94) A processing system (e.g. MP) according to one or more embodiments may comprise ROM memory (e.g. M) having stored therein software code portions for implementing the steps of the method of one or more embodiments.

(95) One or more embodiments may comprise a vehicle (e.g. V) equipped with a processing system according to one or more embodiments.

(96) Without prejudice to the underlying principles, the details and embodiments may vary, even significantly, with respect to what has been described by way of example only, without departing from the extent of protection.

(97) The extent of protection is defined by the annexed claims.