CN111767231B - Multi-platform Bootrom verification method, device and system and computer readable medium - Google Patents
Multi-platform Bootrom verification method, device and system and computer readable medium Download PDFInfo
- Publication number
- CN111767231B CN111767231B CN202010650873.2A CN202010650873A CN111767231B CN 111767231 B CN111767231 B CN 111767231B CN 202010650873 A CN202010650873 A CN 202010650873A CN 111767231 B CN111767231 B CN 111767231B
- Authority
- CN
- China
- Prior art keywords
- platform
- image file
- verification
- mode
- bootrom
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000012795 verification Methods 0.000 title claims abstract description 112
- 238000000034 method Methods 0.000 title claims abstract description 46
- 238000004088 simulation Methods 0.000 claims abstract description 27
- 238000005192 partition Methods 0.000 claims description 12
- 230000001133 acceleration Effects 0.000 claims description 10
- 238000004590 computer program Methods 0.000 claims description 5
- 239000004973 liquid crystal related substance Substances 0.000 claims 4
- 230000008569 process Effects 0.000 abstract description 5
- 238000004891 communication Methods 0.000 description 8
- 238000012986 modification Methods 0.000 description 6
- 230000004048 modification Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 238000003491 array Methods 0.000 description 2
- 238000012937 correction Methods 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 241000283699 Bos indicus Species 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000014509 gene expression Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3676—Test management for coverage analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3664—Environments for testing or debugging software
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3696—Methods or tools to render software testable
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The application provides a multi-platform Bootrom verification method, a device, a system and a computer readable medium. The method comprises the following steps: step 1, receiving verification platform information input; step 2, judging the starting mode of Bootrom; step 3, generating a corresponding one-time programmable ROM and a first mirror image file according to a starting mode; compiling a simulation environment and running a verification program; step 5, according to log files or statistical coverage rate generated by the simulation environment; and step 6, judging whether the coverage rate reaches a preset value, if so, ending, and if not, returning to the step 2. According to the method, corresponding verification files are automatically generated and verified according to different verification platforms and different starting modes, so that the multi-platform Bootrom automatic verification is realized, the multi-platform Bootrom verification process is simplified, and the efficiency of the multi-platform Bootrom verification is greatly improved.
Description
Technical Field
The application relates to the field of automatic testing, in particular to a multi-platform Bootrom verification method, device and system and a computer readable medium.
Background
Bootrom verifies that the platform has a plurality of, and the start-up mode has a plurality of, and still further divide into safe start-up mode and unsafe start-up mode. The verifier not only needs to prepare different verification data according to different verification platforms and different starting modes, but also has very complicated generation of the verification data.
Furthermore, the simulation time required for performing the verification on some verification platforms is long, and it is difficult for the verification personnel to always view the simulation state. Moreover, with the modification of hardware and Bootrom source code, the verifier also needs to continuously perform regression testing.
The above problems make Bootrom verification extremely cumbersome and difficult to cover in every case. The method brings great challenges to the Bootrom verification work, and how to automatically generate verification files and verify according to a Bootrom verification platform and a starting mode is a problem which needs to be solved by the person skilled in the art.
Disclosure of Invention
The application aims to solve the technical problem of providing a multi-platform Bootrom verification method, a device, a system and a computer readable medium, which can automatically generate a verification file and verify according to a Bootrom verification platform and a starting mode.
In order to solve the technical problems, the application provides a multi-platform Bootrom verification method, which comprises the following steps: step 1, receiving verification platform information input; step 2, judging the starting mode of Bootrom; step 3, generating a corresponding one-time programmable ROM and a first mirror image file according to a starting mode; compiling a simulation environment and running a verification program; step 5, counting coverage rate according to log files generated by the simulation environment; and step 6, judging whether the coverage rate reaches a preset value, if so, ending, and if not, returning to the step 2.
Optionally, step 2 is to judge the starting mode according to the SOC chip starting mode pin and/or the interrupt type.
Optionally, the verification platform comprises a hardware acceleration platform and a hardware simulation platform; step 5 comprises the steps of: when the verification platform is a hardware acceleration platform, acquiring serial port output information, and counting coverage rate according to log files in the serial port output information; and when the verification platform is a hardware simulation platform, acquiring the read-write log file, and counting coverage rate according to the read-write log file.
Optionally, the startup mode includes an embedded multimedia controller, USB, UART, flash memory, and other modes, where the embedded multimedia controller includes an embedded multimedia controller normal mode and an embedded multimedia controller Boot mode, and the flash memory includes NOR flash memory and NAND flash memory.
Optionally, the one-time programmable ROM includes one or more of the following data: master boot record, extensible firmware interface data, and portal data.
Optionally, step 3 includes the steps of: when the starting mode is NOR flash memory or NAND flash memory, generating a main boot record, extensible firmware interface data and entry data; when the starting mode is the normal mode of the embedded multimedia controller, generating extensible firmware interface data and entry data; when the starting mode is the Boot mode of the embedded multimedia controller, generating a main guide record; selecting a second image file from the preset image files; generating a corresponding first image file according to the second image file and whether the second image file is in a safe starting mode or not; randomly modifying one or more of the following data: a master boot record, extensible firmware interface data, entry data, and a first image file; and converting the one-time programmable ROM and the first image file into corresponding formats according to the verification platform.
Optionally, generating the corresponding first image file according to the second image file and whether the second image file is in a secure start mode may include: when the safe starting is performed, the first image file comprises an image head, a second image file and a hash value of the image head; and when the first image file is in the non-secure start-up, the first image file comprises an image header, a second image file encrypted by RSA, and an RSA signature of the second image file.
Optionally, the method further comprises: when the starting mode is the NOR flash memory, the master boot record comprises the NOR flash memory type and the NOR flash memory time sequence parameter; when the starting mode is the NAND flash memory, the master boot record comprises the type of the NAND flash memory, the error checking and correcting type and the time sequence parameter of the NAND flash memory; and when the starting mode is the embedded multimedia controller Boot mode, the master Boot record comprises a mirror image storage position.
Optionally, the extensible firmware interface data includes a signature, a version number, an extensible firmware interface data CRC check value, an ingress data CRC check value, and ingress data partition information.
Optionally, the entry data includes a mirrored partition location and a mirrored partition name.
In order to solve the technical problem, the application also provides a multi-platform Bootrom verification device, which comprises: the receiving module is used for receiving information input of the verification platform; the starting mode judging module is used for judging the starting mode of the Bootrom; the generating module is used for generating a corresponding one-time programmable ROM and a first mirror image file according to the starting mode; the compiling and verifying module is used for compiling the simulation environment and running the verifying program; the statistics module is used for counting coverage rate according to the log file generated by the simulation environment; and the coverage rate judging module is used for judging whether the coverage rate reaches a preset numerical value, ending if the coverage rate reaches the preset numerical value, and informing the starting mode judging module to execute the step of judging the starting mode of the Bootrom if the coverage rate does not reach the preset numerical value.
In order to solve the technical problem, the application also provides a multi-platform Bootrom verification system, which comprises: a memory for storing instructions executable by the processor; and a processor for executing the instructions to implement the method as described above.
To solve the above technical problem, the present application also provides a computer readable medium storing computer program code which, when executed by a processor, implements a method as described above.
Compared with the prior art, the method and the device have the advantages that corresponding verification files are automatically generated and verified according to different verification platforms and different starting modes, so that the multi-platform Bootrom automatic verification is realized, the multi-platform Bootrom verification process is simplified, and the efficiency of the multi-platform Bootrom verification is greatly improved.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the description serve to explain the principles of the application. In the accompanying drawings:
FIG. 1 is a flow chart of a multi-platform Bootrom verification method according to an embodiment of the application;
FIG. 2 is a flow chart of a method for generating a one-time programmable ROM and a first image file according to an embodiment of the application;
FIG. 3 is a block diagram illustrating a multi-platform Bootrom verification device according to an embodiment of the application;
FIG. 4 is a system block diagram of a multi-platform Bootrom verification system according to one embodiment of the application.
Detailed Description
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are used in the description of the embodiments will be briefly described below. It is apparent that the drawings in the following description are only some examples or embodiments of the present application, and it is apparent to those of ordinary skill in the art that the present application may be applied to other similar situations according to the drawings without inventive effort. Unless otherwise apparent from the context of the language or otherwise specified, like reference numerals in the figures refer to like structures or operations.
As used in the specification and in the claims, the terms "a," "an," "the," and/or "the" are not specific to a singular, but may include a plurality, unless the context clearly dictates otherwise. In general, the terms "comprises" and "comprising" merely indicate that the steps and elements are explicitly identified, and they do not constitute an exclusive list, as other steps or elements may be included in a method or apparatus.
The relative arrangement of the components and steps, numerical expressions and numerical values set forth in these embodiments do not limit the scope of the present application unless it is specifically stated otherwise. Meanwhile, it should be understood that the sizes of the respective parts shown in the drawings are not drawn in actual scale for convenience of description. Techniques, methods, and apparatus known to one of ordinary skill in the relevant art may not be discussed in detail, but should be considered part of the specification where appropriate. In all examples shown and discussed herein, any specific values should be construed as merely illustrative, and not a limitation. Thus, other examples of the exemplary embodiments may have different values. It should be noted that: like reference numerals and letters denote like items in the following figures, and thus once an item is defined in one figure, no further discussion thereof is necessary in subsequent figures.
A flowchart is used in the present application to describe the operations performed by a system according to embodiments of the present application. It should be understood that the preceding or following operations are not necessarily performed in order precisely. Rather, the various steps may be processed in reverse order or simultaneously. At the same time, other operations are added to or removed from these processes.
The application provides a multi-platform Bootrom verification method. Fig. 1 is a flow chart of a multi-platform Bootrom verification method according to an embodiment of the application. As shown in fig. 1, the multi-platform Bootrom verification method of the present embodiment includes the following steps:
step 101, receiving verification platform information input;
step 102, judging a starting mode of Bootrom;
step 103, generating a corresponding one-time programmable ROM and a first mirror image file according to a starting mode;
104, compiling a simulation environment and running a verification program;
step 105, counting coverage rate according to log files generated by the simulation environment; and
step 106, judging whether the coverage rate reaches a preset value, if so, ending, and if not, returning to step 102.
In step 101, a multi-platform Bootrom verification system receives verification platform information input. The verification platform refers to a verification platform to be used in the Bootrom verification, and can be selected by a user. Alternatively, the verification platform may include a hardware acceleration platform and a hardware simulation platform. In one example, the hardware acceleration platform may be a ZeBu or HAPS platform and the hardware simulation platform may be a VCS platform.
In step 102, the multi-platform Bootrom verification system determines the bootup mode of Bootrom.
Optionally, bootrom booting may include an embedded multimedia controller (Embedded Multi Media Card, eMMC), universal serial bus (Universal Serial Bus, USB), universal asynchronous receiver Transmitter (Universal Asynchronous Receiver/Transmitter, UART), flash memory (Flash), and other booting modes. The embedded multimedia controller can comprise an embedded multimedia controller normal mode and an embedded multimedia controller Boot mode; the flash memory may include NOR flash memory and NAND flash memory; USB may include USB High and USB Full.
Optionally, the System may determine the start mode according to a start mode pin and/or an interrupt type of an SOC (System on Chip, system on Chip or System on Chip) Chip. In one example, the system may determine the start mode according to the external pins bootl [1:0] and the interrupt type of the SOC chip, and the specific judging method is as follows:
(a) When the value of a bootctl [1:0] outside the SOC chip is 0, the starting mode is USB High or UART; then, when the interrupt type is XXX, the starting mode is USB; when the interrupt type is XXX, the starting mode is UART;
(b) When the value of the external pin bootl [1:0] of the SOC chip is 1, the starting mode is USB Full or UART; then, when the interrupt type is XXX, the starting mode is USB; when the interrupt type is XXX, the starting mode is UART;
(c) When the value of the external pin bootl [1:0] of the SOC chip is 2, the starting mode is eMMC; then, whether the normal mode of eMMC or the Boot mode of eMMC is decided according to a certain bit in an OTP (One-Time Programmable ) ROM.
(d) When the value of the external pin bootl [1:0] of the SOC chip is 3, the starting mode is flash memory.
In step 103, after determining the starting mode, the multi-platform Bootrom verification system generates a corresponding One-time programmable (One-Time Programmable, OTP) ROM and a first image file according to the starting mode. The first Image file includes at least an Image file (Image Data) and an Image Header (Image Header) for the present verification, wherein the Image file for the present verification may also be referred to as a second Image file in a subsequent step.
Optionally, the one-time programmable ROM may include one or more of the following data: master boot record (Master Boot Record, MBR), extensible firmware interface (Extensible Firmware Interface, EFI) data, and ingress (Entry) data. Optionally, the EFI data may include a signature, version number, EFI CRC check value, ingress data CRC (Cyclic Redundancy Check ) check value, and ingress data partition information, where the signature is a string of fixed characters (EFI PART).
Alternatively, the entry data may include a mirrored partition location and a mirrored partition name.
Fig. 2 is a flow chart illustrating a method of generating a one-time programmable ROM and a first image file according to an embodiment of the present application. Optionally, as shown in FIG. 2, step 103 may include the following steps 201-209:
step 201, when the boot mode is NOR flash or NAND flash, the system generates MBR, EFI data, and Entry data;
step 202, when the starting mode is the normal mode of the embedded multimedia controller, the system generates EFI data and Entry data;
step 203, when the starting mode is the Boot mode of the embedded multimedia controller, the system generates an MBR;
step 204, the system selects a second image file from the preset image files;
step 205, the system judges the safe starting mode, if the safe starting mode is the safe starting mode, the step 206 is entered, and if the unsafe starting mode is the unsafe starting mode, the step 207 is entered;
step 206, the system generates a first image file, where the first image file includes an image header, a second image file, and a Hash (Hash) value of the image header;
step 207, the system generates a first image file, wherein the first image file comprises an image header, a second image file encrypted by RSA, and an RSA signature of the second image file;
step 208, the system randomly modifies one or more of the following data: MBR, EFI data, entry data and a first mirror file; and
in step 209, the system converts the one-time programmable ROM and the first image file into a format corresponding to the verification platform according to the verification platform.
The system has determined the start-up mode in step 102, and the system performs steps 201, 202 or 203 corresponding to the start-up mode according to different start-up modes.
Optionally, in step 201, when the boot mode is NOR flash, the MBR includes a NOR flash type and NOR flash timing parameters; when the boot mode is NAND flash, the master MBR includes a NAND flash type, an error check and correction (Error Check and Correction, EEC) type, and NAND flash timing parameters. In one example, the timing parameters in the MBR may include parameters such as flash page size configuration, block size configuration, clock configuration, read instructions, and read mode.
Optionally, in step 203, when the startup mode is the embedded multimedia controller Boot mode, the MBR includes a mirror storage location.
In step 204, the system selects a second image file from the image files prepared in advance, where the second image file is the image file used for the verification. The size of the second image file may affect the start-up time. If the verification is to be performed quickly, the smallest image file can be selected; if boundary conditions are to be verified, the largest image file may be selected.
In step 207, RSA is an asymmetric encryption algorithm proposed by Ronand Livist (Ron Rivest), addi Samor (Adi Shamir) and Lonnard Adleman (Lenard Adleman) together in 1977.
In step 208, the system randomly modifies one or more of the following data: MBR, EFI data, entry data, and a first image file. By randomly modifying the data, nonrepeating data can be obtained for verification, and the comprehensiveness of Bootrom verification is improved.
In step 209, the data formats required by the different verification platforms are different, and the system converts the OTP ROM and the first image file into a binary file or plain text corresponding to the verification platform according to the verification platform.
In step 105, the multi-platform Bootrom verification system generates Log file (Log) statistical coverage from the simulation environment. Coverage refers to various boundary conditions for Bootrom validation including, but not limited to: (1) The maximum image file length and the minimum image file length supported by Bootrom; (2) conditions that cause Bootrom to boot failure.
Optionally, when the verification platform is a hardware acceleration platform, the system acquires serial port output information, and outputs a key log through the serial port when the log file statistics coverage rate Bootrom program in the serial port output information jumps each time. In one example, the 'a' is outputted when the EMMC is started; outputting 'B' when the flash memory is started; outputting 'C' when the UART is downloaded; when the hash check is skipped, q' is output; skipping to signature verification will output's'; a hash verification failure or signature verification failure will output 'E'. The system can count the serial port output information of all program jumps, including Log of successful start and failed start. For example, the NOR flash memory can output the following log when in the non-secure boot mode:
X B I J K L c f g d h i k a n l q v w m Y
then, the system can judge the running process of Bootrom through the key information output by the serial port, so that the coverage rate after verification can be obtained.
Optionally, when the verification platform is a hardware simulation platform, the system acquires the read-write log file of the specific address, and calculates coverage rate according to the read-write log file.
In step 106, the multi-platform Bootrom verification system determines whether the coverage rate reaches a preset value, if so, ends, and if not, returns to step 102. When the coverage rate reaches a preset value, the Bootrom verification is completed; when the coverage rate does not reach the preset value, it indicates that Bootrom verification is not completed, and the system returns to step 102 to continue verification.
In summary, in the steps 101-106, the multi-platform Bootrom verification method of the embodiment automatically generates the corresponding verification file and verifies according to different verification platforms and different starting modes, so that the multi-platform Bootrom automatic verification is realized, the multi-platform Bootrom verification process is simplified, and the efficiency of the multi-platform Bootrom verification is greatly improved.
The application also provides a multi-platform Bootrom verification device. Fig. 3 is a block diagram illustrating a multi-platform Bootrom verification device according to an embodiment of the present application. As shown in fig. 3, the multi-platform Bootrom verification device 300 includes a receiving module 301, a startup mode judging module 302, a generating module 303, a compiling verification module 304, a statistics module 305, and a coverage judging module 306.
The receiving module 301 is configured to receive an authentication platform information input. The startup mode judgment module 302 is configured to judge a startup mode of Bootrom. The generating module 303 is configured to generate a corresponding one-time programmable ROM and a first image file according to a startup mode. The compile verification module 304 is used to compile a simulation environment and run a verification program. The statistics module 305 is used for counting coverage rate according to log files generated by the simulation environment. The coverage judging module 306 is configured to judge whether the coverage reaches a preset value, if yes, end, and if not, notify the startup mode judging module 302 to execute the step of judging the startup mode of the Bootrom.
Optionally, the start mode determining module 302 determines a start mode according to the SOC chip start mode pin and/or the interrupt type.
Optionally, the verification platform comprises a hardware acceleration platform and a hardware simulation platform. Alternatively, the statistics module 305 may include a serial port output unit 307 and a read-write log unit 308. The serial port output unit 307 is configured to obtain serial port output information when the verification platform is a hardware acceleration platform, and calculate coverage rate according to log files in the serial port output information. The read-write log unit 308 is configured to obtain a read-write log file when the verification platform is a hardware simulation platform, and to calculate coverage according to the read-write log file.
Optionally, the startup mode includes an embedded multimedia controller, USB, UART, flash memory, and other modes, where the embedded multimedia controller includes an embedded multimedia controller normal mode and an embedded multimedia controller Boot mode, and the flash memory includes NOR flash memory and NAND flash memory.
Optionally, the one-time programmable ROM includes one or more of the following data: master boot record, extensible firmware interface data, and portal data.
Alternatively, the generating module 303 may include a first generating unit 309, a second generating unit 310, a third generating unit 311, a mirror image selecting unit 312, a mirror image generating unit 313, a modifying unit 314, and a converting unit 315. The first generating unit 309 is configured to generate a master boot record, extensible firmware interface data, and entry data when the boot mode is NOR flash or NAND flash. The second generating unit 310 is configured to generate the extensible firmware interface data and the entry data when the startup mode is the normal mode of the embedded multimedia controller. The third generating unit 311 is configured to generate a master Boot record when the startup mode is the Boot mode of the embedded multimedia controller. The image selecting unit 312 is configured to select a second image file from the preset image files. The image generating unit 313 is configured to generate a corresponding first image file according to the second image file and whether the second image file is in a secure startup mode. The modification unit 314 is configured to randomly modify one or more of the following data: a master boot record, extensible firmware interface data, portal data, and a first image file. The conversion unit 315 is configured to convert the one-time programmable ROM and the first image file into corresponding formats according to the authentication platform.
Optionally, the step "generating the corresponding first image file according to the second image file and whether the second image file is in a secure startup mode" performed by the generating module 303 may further include the following steps: when the safe starting is performed, the first image file comprises an image head, a second image file and a hash value of the image head; and when the first image file is in the non-secure start-up, the first image file comprises an image header, a second image file encrypted by RSA, and an RSA signature of the second image file.
Optionally, when the boot mode is NOR flash, the master boot record includes a NOR flash type and a NOR flash timing parameter; when the starting mode is the NAND flash memory, the master boot record comprises the type of the NAND flash memory, the error checking and correcting type and the time sequence parameter of the NAND flash memory; and when the starting mode is the embedded multimedia controller Boot mode, the master Boot record comprises a mirror image storage position.
Optionally, the extensible firmware interface data includes a signature, a version number, an extensible firmware interface data CRC check value, an ingress data CRC check value, and ingress data partition information.
Optionally, the entry data includes a mirrored partition location and a mirrored partition name.
The steps performed by the modules 301-306 described above may refer to steps 101-106 of the embodiment of fig. 1 described above and will not be described again here.
The application also provides a multi-platform Bootrom verification system, which comprises: a memory for storing instructions executable by the processor; and the processor is used for executing the instruction to realize the multi-platform Bootrom verification method.
FIG. 4 is a system block diagram of a multi-platform Bootrom verification system according to one embodiment of the application. The multi-platform Bootrom verification system 400 may include an internal communication bus 401, a Processor (Processor) 402, a Read Only Memory (ROM) 403, a Random Access Memory (RAM) 404, and a communication port 405. The multi-platform Bootrom verification system may also include a hard disk 407 when applied on a personal computer. The internal communication bus 401 may enable data communication between the components of the multi-platform Bootrom verification system 400. The processor 402 may make the determination and issue the prompt. In some embodiments, the processor 402 may be comprised of one or more processors. The communication port 405 may enable the multi-platform Bootrom verification system 400 to communicate data with the outside. In some embodiments, the multi-platform Bootrom verification system 400 may send and receive information and data from a network through the communication port 405. The multi-platform Bootrom verification system 400 may also include various forms of program storage units and data storage units, such as a hard disk 407, read-only memory (ROM) 403, and Random Access Memory (RAM) 404, capable of storing various data files for computer processing and/or communication, and possibly program instructions for execution by the processor 402. The processor executes these instructions to implement the main part of the method. The result processed by the processor is transmitted to the user equipment through the communication port and displayed on the user interface.
The multi-platform Bootrom verification method described above may be implemented as a computer program stored in the hard disk 407 and recorded into the processor 402 for execution, so as to implement the multi-platform Bootrom verification method of the present application.
The application also provides a computer readable medium storing computer program code which, when executed by a processor, implements the multi-platform Bootrom verification method of the application.
When the multi-platform Bootrom verification method is implemented as a computer program, it may also be stored in a computer readable storage medium as an article of manufacture. For example, computer-readable storage media may include, but are not limited to, magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips), optical disks (e.g., compact Disk (CD), digital Versatile Disk (DVD)), smart cards, and flash memory devices (e.g., electrically erasable programmable read-only memory (EPROM), cards, sticks, key drives). Moreover, various storage media described herein can represent one or more devices and/or other machine-readable media for storing information. The term "machine-readable medium" can include, without being limited to, wireless channels and various other media (and/or storage media) capable of storing, containing, and/or carrying code and/or instructions and/or data.
It should be understood that the embodiments described above are illustrative only. The embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or any combination thereof. For a hardware implementation, the processing units may be implemented within one or more Application Specific Integrated Circuits (ASICs), digital Signal Processors (DSPs), digital Signal Processing Devices (DSPDs), programmable Logic Devices (PLDs), field Programmable Gate Arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, and/or other electronic units designed to perform the functions described herein, or a combination thereof.
While the basic concepts have been described above, it will be apparent to those skilled in the art that the foregoing application disclosure is by way of example only and is not intended to be limiting. Although not explicitly described herein, various modifications, improvements and adaptations of the application may occur to one skilled in the art. Such modifications, improvements, and modifications are intended to be within the spirit and scope of exemplary embodiments of the present application.
Meanwhile, the present application uses specific words to describe embodiments of the present application. Reference to "one embodiment," "an embodiment," and/or "some embodiments" means that a particular feature, structure, or characteristic is associated with at least one embodiment of the application. Thus, it should be emphasized and should be appreciated that two or more references to "an embodiment" or "one embodiment" or "an alternative embodiment" in various positions in this specification are not necessarily referring to the same embodiment. Furthermore, certain features, structures, or characteristics of one or more embodiments of the application may be combined as suitable.
Some aspects of the application may be performed entirely by hardware, entirely by software (including firmware, resident software, micro-code, etc.) or by a combination of hardware and software. The above hardware or software may be referred to as a "data block," module, "" engine, "" unit, "" component, "or" system. The processor may be one or more Application Specific Integrated Circuits (ASICs), digital Signal Processors (DSPs), digital signal processing devices (DAPDs), programmable Logic Devices (PLDs), field Programmable Gate Arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, or a combination thereof. Furthermore, aspects of the application may take the form of a computer product, comprising computer-readable program code, embodied in one or more computer-readable media. For example, computer-readable media can include, but are not limited to, magnetic storage devices (e.g., hard disk, floppy disk, tape … …), optical disk (e.g., compact disk CD, digital versatile disk DVD … …), smart card, and flash memory devices (e.g., card, stick, key drive … …).
Similarly, it should be appreciated that in order to simplify the present disclosure and thereby facilitate an understanding of one or more embodiments of the application, various features are sometimes grouped together in a single embodiment, figure, or description thereof. This method of disclosure, however, is not intended to imply that more features than are required by the subject application. Indeed, less than all of the features of a single embodiment disclosed above.
While the application has been described with reference to the specific embodiments presently, it will be appreciated by those skilled in the art that the foregoing embodiments are merely illustrative of the application, and various equivalent changes and substitutions may be made without departing from the spirit of the application, and therefore, all changes and modifications to the embodiments are intended to be within the scope of the appended claims.
Claims (11)
1. A multi-platform Bootrom verification method comprises the following steps:
step 1, receiving verification platform information input;
step 2, judging the starting mode of Bootrom;
step 3, generating a corresponding one-time programmable ROM and a first mirror image file according to the starting mode;
compiling a simulation environment and running a verification program;
step 5, counting coverage rate according to the log file generated by the simulation environment; and
step 6, judging whether the coverage rate reaches a preset value, if so, ending, and if not, returning to the step 2; wherein, the liquid crystal display device comprises a liquid crystal display device,
the verification platform comprises a hardware acceleration platform and a hardware simulation platform;
the starting mode comprises an embedded multimedia controller, a USB, a UART and a flash memory, wherein the embedded multimedia controller comprises an embedded multimedia controller normal mode and an embedded multimedia controller Boot mode, and the flash memory comprises a NOR flash memory and a NAND flash memory;
the step 3 comprises the following steps:
when the starting mode is NOR flash memory or NAND flash memory, generating a main boot record, extensible firmware interface data and entry data;
when the starting mode is the normal mode of the embedded multimedia controller, generating extensible firmware interface data and entry data;
when the starting mode is the Boot mode of the embedded multimedia controller, generating a main guide record;
selecting a second image file from the preset image files;
generating a corresponding first image file according to the second image file and whether the second image file is in a safe starting mode or not;
randomly modifying one or more of the following data: the master boot record, the extensible firmware interface data, the portal data, and the first image file; and
and converting the one-time programmable ROM and the first image file into corresponding formats according to the verification platform.
2. The method according to claim 1, wherein the step 2 is to determine the start mode according to a start mode pin and/or interrupt type of the SOC chip.
3. The method according to claim 1, wherein said step 5 comprises the steps of:
when the verification platform is the hardware acceleration platform, acquiring serial port output information, and counting the coverage rate according to log files in the serial port output information; and
and when the verification platform is the hardware simulation platform, acquiring a read-write log file, and counting the coverage rate according to the read-write log file.
4. The method of claim 1, wherein the one-time programmable ROM includes one or more of the following data: master boot record, extensible firmware interface data, and portal data.
5. The method of claim 1, wherein generating the corresponding first image file according to the second image file and whether the second image file is in a secure boot mode comprises:
when the first image file is safely started, the first image file comprises an image head, the second image file and a hash value of the image head; and
when in an unsecure start, the first image file includes an image header, the second image file encrypted using RSA, and an RSA signature of the second image file.
6. The method as recited in claim 1, further comprising:
when the starting mode is the NOR flash memory, the master boot record comprises a NOR flash memory type and a NOR flash memory time sequence parameter;
when the starting mode is the NAND flash memory, the master boot record comprises a NAND flash memory type, an error checking and correcting type and NAND flash memory time sequence parameters; and
when the starting mode is the Boot mode of the embedded multimedia controller, the master Boot record comprises a mirror image storage position.
7. The method of claim 1, wherein the scalable firmware interface data comprises a signature, a version number, a scalable firmware interface data CRC check value, an ingress data CRC check value, and ingress data partition information.
8. The method of claim 1, wherein the entry data comprises a mirrored partition location and a mirrored partition name.
9. A multi-platform Bootrom verification device, comprising:
the receiving module is used for receiving information input of the verification platform;
the starting mode judging module is used for judging the starting mode of the Bootrom;
the generating module is used for generating a corresponding one-time programmable ROM and a first image file according to the starting mode;
the compiling and verifying module is used for compiling the simulation environment and running the verifying program;
the statistics module is used for counting coverage rate according to the log file generated by the simulation environment; and
the coverage rate judging module is used for judging whether the coverage rate reaches a preset value, ending if the coverage rate reaches the preset value, and informing the starting mode judging module to execute the step of judging the starting mode of Bootrom if the coverage rate does not reach the preset value; wherein, the liquid crystal display device comprises a liquid crystal display device,
the verification platform comprises a hardware acceleration platform and a hardware simulation platform;
the starting mode comprises an embedded multimedia controller, a USB, a UART and a flash memory, wherein the embedded multimedia controller comprises an embedded multimedia controller normal mode and an embedded multimedia controller Boot mode, and the flash memory comprises a NOR flash memory and a NAND flash memory;
when the starting mode is NOR flash memory or NAND flash memory, the generating module is used for generating a main guide record, extensible firmware interface data and entry data;
when the starting mode is the normal mode of the embedded multimedia controller, the generating module is used for generating extensible firmware interface data and entry data;
when the starting mode is the Boot mode of the embedded multimedia controller, the generating module is used for generating a main guide record;
the generating module is further configured to:
selecting a second image file from the preset image files;
generating a corresponding first image file according to the second image file and whether the second image file is in a safe starting mode or not;
randomly modifying one or more of the following data: the master boot record, the extensible firmware interface data, the portal data, and the first image file; and
and converting the one-time programmable ROM and the first image file into corresponding formats according to the verification platform.
10. A multi-platform Bootrom verification system, comprising:
a memory for storing instructions executable by the processor; and a processor for executing the instructions to implement the method of any one of claims 1-8.
11. A computer readable medium storing computer program code which, when executed by a processor, implements the method of any of claims 1-8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010650873.2A CN111767231B (en) | 2020-07-08 | 2020-07-08 | Multi-platform Bootrom verification method, device and system and computer readable medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010650873.2A CN111767231B (en) | 2020-07-08 | 2020-07-08 | Multi-platform Bootrom verification method, device and system and computer readable medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111767231A CN111767231A (en) | 2020-10-13 |
| CN111767231B true CN111767231B (en) | 2023-10-31 |
Family
ID=72725408
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010650873.2A Active CN111767231B (en) | 2020-07-08 | 2020-07-08 | Multi-platform Bootrom verification method, device and system and computer readable medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111767231B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112668262B (en) * | 2020-12-25 | 2023-04-07 | 瓴盛科技有限公司 | SoC verification method, system, device and computer readable medium |
| CN114625639A (en) * | 2022-03-03 | 2022-06-14 | 上海先楫半导体科技有限公司 | Debugging method, system and chip based on system on chip |
Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103246602A (en) * | 2012-02-14 | 2013-08-14 | 阿里巴巴集团控股有限公司 | Code coverage rate confirming method, code coverage rate confirming system, code coverage rate detecting method and code coverage rate detecting system |
| CN106528123A (en) * | 2016-10-26 | 2017-03-22 | 珠海全志科技股份有限公司 | SoC (System on a Chip) startup method and device based on eFuse module |
| CN106598652A (en) * | 2016-11-25 | 2017-04-26 | 湖南国科微电子股份有限公司 | System for rapidly starting Linux core in field programmable gate array (FPGA) environment and starting method |
| US9910676B1 (en) * | 2015-09-22 | 2018-03-06 | Microsemi Solutions (U.S.), Inc. | Hardware based XIP exit sequence to enable XIP mode operation on SPI boot interface |
| CN108399339A (en) * | 2018-02-12 | 2018-08-14 | 广东为辰信息科技有限公司 | A kind of credible startup method based on safety chip |
| CN109542518A (en) * | 2018-10-09 | 2019-03-29 | 华为技术有限公司 | The method of chip and bootrom |
| CN109739769A (en) * | 2019-01-02 | 2019-05-10 | 深圳忆联信息系统有限公司 | BOOTROM loads method for automatically testing functions and device |
| CN109800032A (en) * | 2019-01-31 | 2019-05-24 | 深圳忆联信息系统有限公司 | BOOTROM multicore loading method and device |
| CN109814934A (en) * | 2019-01-31 | 2019-05-28 | 安谋科技（中国）有限公司 | Data processing method, device, readable medium and system |
| CN110362436A (en) * | 2019-07-12 | 2019-10-22 | 深圳忆联信息系统有限公司 | Improve the method and device of Bootrom testing efficiency |
| CN110555309A (en) * | 2019-09-10 | 2019-12-10 | 深圳市英博超算科技有限公司 | Starting method, starting device, terminal and computer readable storage medium |
| CN110874467A (en) * | 2018-08-29 | 2020-03-10 | 阿里巴巴集团控股有限公司 | Information processing method, device, system, processor and storage medium |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9658858B2 (en) * | 2013-10-16 | 2017-05-23 | Xilinx, Inc. | Multi-threaded low-level startup for system boot efficiency |
-
2020
- 2020-07-08 CN CN202010650873.2A patent/CN111767231B/en active Active
Patent Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103246602A (en) * | 2012-02-14 | 2013-08-14 | 阿里巴巴集团控股有限公司 | Code coverage rate confirming method, code coverage rate confirming system, code coverage rate detecting method and code coverage rate detecting system |
| US9910676B1 (en) * | 2015-09-22 | 2018-03-06 | Microsemi Solutions (U.S.), Inc. | Hardware based XIP exit sequence to enable XIP mode operation on SPI boot interface |
| CN106528123A (en) * | 2016-10-26 | 2017-03-22 | 珠海全志科技股份有限公司 | SoC (System on a Chip) startup method and device based on eFuse module |
| CN106598652A (en) * | 2016-11-25 | 2017-04-26 | 湖南国科微电子股份有限公司 | System for rapidly starting Linux core in field programmable gate array (FPGA) environment and starting method |
| CN108399339A (en) * | 2018-02-12 | 2018-08-14 | 广东为辰信息科技有限公司 | A kind of credible startup method based on safety chip |
| CN110874467A (en) * | 2018-08-29 | 2020-03-10 | 阿里巴巴集团控股有限公司 | Information processing method, device, system, processor and storage medium |
| CN109542518A (en) * | 2018-10-09 | 2019-03-29 | 华为技术有限公司 | The method of chip and bootrom |
| CN109739769A (en) * | 2019-01-02 | 2019-05-10 | 深圳忆联信息系统有限公司 | BOOTROM loads method for automatically testing functions and device |
| CN109800032A (en) * | 2019-01-31 | 2019-05-24 | 深圳忆联信息系统有限公司 | BOOTROM multicore loading method and device |
| CN109814934A (en) * | 2019-01-31 | 2019-05-28 | 安谋科技（中国）有限公司 | Data processing method, device, readable medium and system |
| CN110362436A (en) * | 2019-07-12 | 2019-10-22 | 深圳忆联信息系统有限公司 | Improve the method and device of Bootrom testing efficiency |
| CN110555309A (en) * | 2019-09-10 | 2019-12-10 | 深圳市英博超算科技有限公司 | Starting method, starting device, terminal and computer readable storage medium |
Non-Patent Citations (2)
| Title |
|---|
| "A single-phase energy metering SoC with IAS-DSP and ultra low power metering mode";Yan Zhao等;《2011 IEEE International SOC Conference》;全文 * |
| "基于VxWorks车载控制设备基础软件平台设计与实现";周洁;《中国优秀博硕士学位论文全文数据库 信息科技辑》;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111767231A (en) | 2020-10-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106452783B (en) | Computer system and method for secure execution | |
| CN109710315B (en) | BIOS (basic input output System) flash writing method and BIOS mirror image file processing method | |
| WO2018176733A1 (en) | Firmware upgrade method, terminal and computer-readable non-volatile storage medium | |
| CN111767231B (en) | Multi-platform Bootrom verification method, device and system and computer readable medium | |
| US8108536B1 (en) | Systems and methods for determining the trustworthiness of a server in a streaming environment | |
| CN104484592B (en) | The startup method and system of mobile device factory mode | |
| US20190317755A1 (en) | Method for upgrading software of pos terminal, pos terminal, and storage medium | |
| JP2015022521A (en) | Secure boot method, built-in apparatus, secure boot device and secure boot program | |
| CN108108260B (en) | Resource file verification method and device | |
| CN107148010B (en) | Multi-operator implementation method, device, storage medium and computer equipment | |
| WO2009096181A2 (en) | Secure boot with optional components method | |
| US11886593B2 (en) | Verification of a provisioned state of a platform | |
| WO2017133559A1 (en) | Secure boot method and device | |
| CN105488418B (en) | trusted starting method and system of virtualization platform server | |
| CN106548063A (en) | A kind of credible tolerance methods, devices and systems | |
| CN105678162A (en) | TPM-based control method for safe startup of operating system | |
| CN112148314A (en) | Mirror image verification method, device, equipment and storage medium of embedded system | |
| CN103425932B (en) | Signature calibration method and terminal device | |
| CN115168866A (en) | Processor safety starting method and processor | |
| CN109033818B (en) | Terminal, authentication method, and computer-readable storage medium | |
| CN108196975B (en) | Data verification method and device based on multiple checksums and storage medium | |
| JP2012104132A (en) | Information generation system and method thereof | |
| CN111538481B (en) | Application program customization method and system | |
| US20120291019A1 (en) | Program verification apparatus based on model verifying and storage medium | |
| CN109753788B (en) | Integrity checking method and computer readable storage medium during kernel operation |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |