CN111767231A - Multi-platform Bootrom verification method, device, system and computer readable medium - Google Patents

Multi-platform Bootrom verification method, device, system and computer readable medium Download PDF

Info

Publication number
CN111767231A
CN111767231A CN202010650873.2A CN202010650873A CN111767231A CN 111767231 A CN111767231 A CN 111767231A CN 202010650873 A CN202010650873 A CN 202010650873A CN 111767231 A CN111767231 A CN 111767231A
Authority
CN
China
Prior art keywords
platform
verification
bootrom
image file
starting mode
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.)
Granted
Application number
CN202010650873.2A
Other languages
Chinese (zh)
Other versions
CN111767231B (en
Inventor
张克宁
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Lusheng Technology Co ltd
Original Assignee
Lusheng Technology Co ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Lusheng Technology Co ltd filed Critical Lusheng Technology Co ltd
Priority to CN202010650873.2A priority Critical patent/CN111767231B/en
Publication of CN111767231A publication Critical patent/CN111767231A/en
Application granted granted Critical
Publication of CN111767231B publication Critical patent/CN111767231B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3676Test management for coverage analysis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3664Environments for testing or debugging software
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3684Test management for test design, e.g. generating new test cases
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3696Methods 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, device, system and computer readable medium. The method comprises the following steps: step 1, receiving information input of a verification platform; 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; step 4, compiling the simulation environment and running a verification program; step 5, generating a log file or counting the coverage rate according to 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, the corresponding verification files are automatically generated and verified according to different verification platforms and different starting modes, so that multi-platform Bootrom automatic verification is realized, the multi-platform Bootrom verification process is simplified, and the multi-platform Bootrom verification efficiency is greatly improved.

Description

Multi-platform Bootrom verification method, device, system and computer readable medium
Technical Field
The application mainly relates to the field of automatic testing, in particular to a multi-platform Bootrom verification method, a multi-platform Bootrom verification device, a multi-platform Bootrom verification system and a computer readable medium.
Background
The Bootrom verification platform has a plurality of, and the starting mode has a plurality of, and still further divide into safe starting mode and non-safe starting mode. The verification personnel not only need to prepare different verification data according to different verification platforms and different starting modes, but also generate the verification data very fussy.
In addition, the simulation time required for verification on some verification platforms is long, and it is difficult for a verifier to view the simulation status at all times. Furthermore, as the hardware and Bootrom source code are modified, the verifier needs to perform regression testing continuously.
The above problems make Bootrom verification extremely cumbersome and difficult to cover in every situation. The method brings great challenges to 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 technical personnel in the field.
Disclosure of Invention
The technical problem to be solved by the application is to provide a multi-platform Bootrom verification method, device, system and computer readable medium, which can automatically generate verification files and verify according to a Bootrom verification platform and a starting mode.
In order to solve the technical problem, the application provides a multi-platform Bootrom verification method, which comprises the following steps: step 1, receiving information input of a verification platform; 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; step 4, compiling the simulation environment and running a verification program; step 5, counting the 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.
Optionally, step 2 is to determine the starting mode according to the SOC chip starting mode pin and/or interrupt type.
Optionally, the verification platform comprises a hardware acceleration platform and a hardware simulation platform; step 5 comprises the following steps: when the verification platform is a hardware acceleration platform, acquiring serial port output information, and counting the coverage rate according to a log file in the serial port output information; and when the verification platform is a hardware simulation platform, acquiring the read-write log file, and counting the coverage rate according to the read-write log file.
Optionally, the starting modes include an embedded multimedia controller, a USB, a UART, a flash memory and other modes, wherein the embedded multimedia controller includes an embedded multimedia controller normal mode and an embedded multimedia controller Boot mode, and the flash memory includes a NOR flash memory and a 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 entry data.
Optionally, step 3 comprises the steps of: when the starting mode is NOR flash memory or NAND flash memory, generating 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 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; randomly modifying one or more of the following: the system comprises a main 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 boot manner may include: when the secure boot is performed, the first image file comprises an image header, a second image file and a hash value of the image header; and when the boot is non-secure boot, 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 NOR flash, the master boot record comprises the type of the NOR flash and time sequence parameters of the NOR flash; when the starting mode is the NAND flash memory, the master boot record comprises a NAND flash memory type, an error check and correction type and a NAND flash memory time sequence parameter; and when the starting mode is the Boot mode of the embedded multimedia controller, the main guide 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 entry data CRC check value, and entry data partition information.
Optionally, the entry data includes a mirror partition location and a mirror partition name.
In order to solve the above technical problem, the present application further provides a multi-platform Bootrom verification device, including: 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 verification module is used for compiling the simulation environment and running a verification program; the statistical module is used for counting the 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, if so, finishing, and if not, informing the starting mode judging module to execute the step of judging the starting mode of the Bootrom.
In order to solve the above technical problem, the present application further provides a multi-platform Bootrom verification system, including: 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 further provides a computer readable medium storing computer program code, which when executed by a processor implements the method as described above.
Compared with the prior art, the multi-platform Bootrom automatic verification method has the advantages that the corresponding verification files are automatically generated and verified according to different verification platforms and different starting modes, multi-platform Bootrom automatic verification is achieved, multi-platform Bootrom verification processes are simplified, and multi-platform Bootrom verification efficiency 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 application, illustrate embodiment(s) of the application and together with the description serve to explain the principle of the application. In the drawings:
fig. 1 is a schematic flowchart illustrating a multi-platform Bootrom verification method according to an embodiment of the present application;
FIG. 2 is a flowchart illustrating a method for generating a one-time programmable ROM and a first image file according to an embodiment of the present application;
FIG. 3 is a block diagram illustrating a multi-platform Bootrom validation apparatus according to an embodiment of the present application;
fig. 4 is a system block diagram illustrating a multi-platform Bootrom validation system according to an embodiment of the present application.
Detailed Description
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings used in the description of the embodiments will be briefly introduced below. It is obvious that the drawings in the following description are only examples or embodiments of the application, from which the application can also be applied to other similar scenarios without inventive effort for a person skilled in the art. Unless otherwise apparent from the context, or otherwise indicated, like reference numbers in the figures refer to the same structure or operation.
As used in this application and the appended claims, the terms "a," "an," "the," and/or "the" are not intended to be inclusive in the singular, but rather are intended to be inclusive in the plural unless the context clearly dictates otherwise. In general, the terms "comprises" and "comprising" merely indicate that steps and elements are included which are explicitly identified, that the steps and elements do not form an exclusive list, and that a method or apparatus may include other steps or elements.
The relative arrangement of the components and steps, the numerical expressions, and numerical values set forth in these embodiments do not limit the scope of the present application unless specifically stated otherwise. Meanwhile, it should be understood that the sizes of the respective portions shown in the drawings are not drawn in an actual proportional relationship for the convenience of description. Techniques, methods, and apparatus known to those of ordinary skill in the relevant art may not be discussed in detail but are intended to be part of the specification where appropriate. In all examples shown and discussed herein, any particular value should be construed as merely illustrative, and not limiting. Thus, other examples of the exemplary embodiments may have different values. It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, further discussion thereof is not required in subsequent figures.
Flow charts are used herein to illustrate operations performed by systems according to embodiments of the present application. It should be understood that the preceding or following operations are not necessarily performed in the exact order in which they are performed. Rather, various steps may be processed in reverse order or simultaneously. Meanwhile, other operations are added to or removed from these processes.
The application provides a multi-platform Bootrom verification method. Fig. 1 is a schematic flowchart of a multi-platform Bootrom verification method according to an embodiment of the present application. As shown in fig. 1, the multi-platform Bootrom verification method of the present embodiment includes the following steps:
step 101, receiving information input of a verification platform;
step 102, judging a boot mode of Bootrom;
103, generating a corresponding one-time programmable ROM and a first image file according to a starting mode;
step 104, compiling a simulation environment and running a verification program;
105, counting the coverage rate according to a log file generated by the simulation environment; and
and step 106, judging whether the coverage rate reaches a preset value, if so, ending, and if not, returning to the step 102.
In step 101, a multi-platform Bootrom verification system receives verification platform information input. The verification platform is 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 judges the starting mode of the Bootrom.
Optionally, the Bootrom may include an Embedded multimedia controller (eMMC), a Universal Serial Bus (USB), a Universal Asynchronous Receiver/Transmitter (UART), a Flash memory (Flash), and other bootable methods. 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; the 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). In one example, the system may determine the starting mode according to an external pin bootctl [1:0] and an interrupt type of the SOC chip, where the specific determination method is as follows:
(a) when the value of an external pin bootctl [1:0] of 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 an external pin bootctl [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 an external pin bootctl [1:0] of the SOC chip is 2, the starting mode is eMMC; then, whether the eMMC normal mode or the eMMCBoot mode is determined according to a certain bit in an OTP (One-Time Programmable) ROM.
(d) When the value of the external pin bootctl [1:0] of the SOC chip is 3, the starting mode is the flash memory.
In step 103, after the boot mode is determined, the multi-platform Bootrom verification system generates a corresponding One-Time Programmable (OTP) ROM and a first image file according to the boot mode. The first Image file at least comprises an Image file (Image Data) and an Image Header (Image Header) for the verification, wherein the Image file for the verification can also be called a second Image file in the subsequent steps.
Optionally, the one-time programmable ROM may include one or more of the following: master Boot Record (MBR), Extensible Firmware Interface (EFI) data, and Entry (Entry) data. Optionally, the EFI data may include a signature, a version number, an EFI CRC Check value, an ingress data CRC (Cyclic Redundancy Check) Check value, and ingress data partition information, where the signature is a string of fixed characters (EFI PART).
Optionally, the entry data may include a mirror partition location and a mirror partition name.
FIG. 2 is a flowchart illustrating a method for 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 and 209:
step 201, when the starting mode is NOR flash memory or NAND flash memory, 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 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 safe starting mode is the non-safe starting mode, the step 207 is entered;
step 206, the system generates a first image file, wherein the first image file comprises 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;
in step 208, the system randomly modifies one or more of the following: MBR, EFI data, Entry data and a first mirror image file; and
in step 209, the system converts the one-time programmable ROM and the first image file to 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 modes according to the different start-up modes.
Optionally, in step 201, when the starting mode is NOR flash, the MBR includes a NOR flash type and a NOR flash timing parameter; when the boot-up mode is NAND flash, the master MBR includes a NAND flash type, an 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 command, and read mode.
Optionally, in step 203, when the booting mode is Boot mode of the embedded multimedia controller, the MBR includes a mirror image storage location.
In step 204, the system selects a second image file from the pre-prepared image files, where the second image file is the image file used for the verification. The size of the second image file may affect boot time. If the verification is to be carried out quickly, the smallest image file can be selected; if the boundary conditions are to be verified, the largest image file may be selected.
In step 207, RSA is an asymmetric encryption algorithm proposed in 1977 by rond listeriost (RonRivest), addi samor (Adi Shamir) and roned aldman (Leonard Adleman) together.
In step 208, the system randomly modifies one or more of the following: MBR, EFI data, Entry data and a first image file. By randomly modifying the data, non-repeated data can be obtained for verification, and the comprehensiveness of Bootrom verification is improved.
In step 209, the data formats required by 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 counts the coverage rate according to a Log file (Log) generated by the simulation environment. Coverage refers to various boundary conditions for Bootrom verification, including but not limited to: (1) the maximum mirror image file length and the minimum mirror image file length supported by Bootrom; (2) condition that Bootrom fails to boot.
Optionally, when the verification platform is a hardware acceleration platform, the system acquires serial port output information, and counts a coverage rate Bootrom program according to a log file in the serial port output information, and a key log is output through the serial port when the coverage rate Bootrom program jumps each time. In one example, 'a' is output when the EMMC is started; will output 'B' when the flash memory starts; will output 'C' while downloading in UART; when jumping to the Hash check, outputting 'q'; when the signature verification is skipped, s' is output; a hash check failure or a signature verification failure outputs 'E'. The system can count serial port output information of all program jumps, including logs of successful start and failed start. For example, the NOR flash memory may output the following log when it is 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 operation process of the Bootrom through key information output by the serial port, so that the coverage rate after the verification can be obtained.
Optionally, when the verification platform is a hardware simulation platform, the system acquires a read-write log file of a specific address, and counts the 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, the method is ended, and if not, the method returns to step 102. When the coverage rate reaches a preset value, Bootrom verification is finished; and when the coverage rate does not reach the preset value, indicating that Bootrom verification is not completed, and returning the system to the step 102 to continue verification.
To sum up with step 101 and step 106, the multi-platform Bootrom verification method of the present embodiment automatically generates and verifies the corresponding verification document according to different verification platforms and different starting modes, thereby implementing multi-platform Bootrom automatic verification, simplifying multi-platform Bootrom verification process, and greatly improving multi-platform Bootrom verification efficiency.
The application also provides a multi-platform Bootrom verification device. Fig. 3 is a block diagram illustrating a multi-platform Bootrom validation apparatus according to an embodiment of the present application. As shown in fig. 3, the multi-platform Bootrom verification apparatus 300 includes a receiving module 301, a starting manner determining module 302, a generating module 303, a compiling and verifying module 304, a counting module 305, and a coverage rate determining module 306.
The receiving module 301 is used for receiving authentication platform information input. The starting mode judging module 302 is used for judging the starting 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 starting manner. The compile-verify module 304 is used to compile the simulation environment and run the verification program. The statistical module 305 is used for counting the coverage rate according to the log file generated by the simulation environment. The coverage rate determining module 306 is configured to determine whether the coverage rate reaches a preset value, and if the coverage rate reaches the preset value, the coverage rate is terminated, and if the coverage rate does not reach the preset value, the starting mode determining module 302 is notified to execute the step of determining the starting mode of the Bootrom.
Optionally, the starting manner determining module 302 determines the starting manner according to the SOC chip starting manner pin and/or the interrupt type.
Optionally, the verification platform includes a hardware acceleration platform and a hardware simulation platform. Optionally, the statistic 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 count the coverage rate according to a log file 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 the hardware simulation platform, and count the coverage rate according to the read-write log file.
Optionally, the starting modes include an embedded multimedia controller, a USB, a UART, a flash memory and other modes, wherein the embedded multimedia controller includes an embedded multimedia controller normal mode and an embedded multimedia controller Boot mode, and the flash memory includes a NOR flash memory and a 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 entry 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 selecting unit 312, a mirror generating unit 313, a modifying unit 314, and a converting unit 315. The first generation unit 309 is configured to generate a master boot record, extensible firmware interface data, and entry data when the boot mode is NOR flash memory or NAND flash memory. The second generating unit 310 is configured to generate the extensible firmware interface data and the entry data when the booting 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 booting 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 boot manner. The modification unit 314 is configured to randomly modify one or more of the following items: the system comprises a master boot record, extensible firmware interface data, entry 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 verification 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 boot mode" executed by the generating module 303 may further include the following steps: when the secure boot is performed, the first image file comprises an image header, a second image file and a hash value of the image header; and when the boot is non-secure boot, 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 starting 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 a NAND flash memory type, an error check and correction type and a NAND flash memory time sequence parameter; and when the starting mode is the Boot mode of the embedded multimedia controller, the main guide 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 entry data CRC check value, and entry data partition information.
Optionally, the entry data includes a mirror partition location and a mirror partition name.
The steps executed by the modules 301-306 can refer to the aforementioned steps 101-106 in the embodiment of fig. 1, and will not be described herein.
The application also provides a multi-platform Bootrom verification system, including: a memory for storing instructions executable by the processor; and a processor for executing the instructions to implement the multi-platform Bootrom validation method of the present application.
Fig. 4 is a system block diagram illustrating a multi-platform Bootrom validation system according to an embodiment of the present application. Multi-platform Bootrom validation 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. When implemented on a personal computer, the multi-platform Bootrom verification system may also include a hard disk 407. Internal communication bus 401 may enable data communication among components of multi-platform Bootrom validation system 400. The processor 402 may make the determination and issue the prompt. In some embodiments, processor 402 may be comprised of one or more processors. Communication port 405 may enable data communication between multi-platform Bootrom authentication system 400 and the outside. In some embodiments, multi-platform Bootrom verification system 400 may send and receive information and data from a network through communication port 405. Multi-platform Bootrom validation system 400 may also include various forms of program storage units and data storage units, such as a hard disk 407, a Read Only Memory (ROM)403, and a Random Access Memory (RAM)404, capable of storing various data files used for computer processing and/or communications, as well as possible program instructions executed by processor 402. The processor executes these instructions to implement the main parts of the method. The results processed by the processor are communicated to the user device 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 in the processor 402 for execution, so as to implement the multi-platform Bootrom verification method in the present application.
The present application also provides a computer readable medium having stored thereon computer program code which, when executed by a processor, implements the multi-platform Bootrom validation method of the present application.
The multi-platform Bootrom validation method, when implemented as a computer program, may also be stored in a computer-readable storage medium as an article of manufacture. For example, computer-readable storage media can 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), card, stick, key drive). In addition, 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 above-described embodiments 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.
Having thus described the basic concept, it will be apparent to those skilled in the art that the foregoing disclosure is by way of example only, and is not intended to limit the present application. Various modifications, improvements and adaptations to the present application may occur to those skilled in the art, although not explicitly described herein. Such modifications, improvements and adaptations are proposed in the present application and thus fall within the spirit and scope of the exemplary embodiments of the present application.
Also, this application uses specific language to describe embodiments of the application. Reference throughout this specification to "one embodiment," "an embodiment," and/or "some embodiments" means that a particular feature, structure, or characteristic described in connection with at least one embodiment of the present application is included in at least one embodiment of the present application. Therefore, it is emphasized and should be appreciated that two or more references to "an embodiment" or "one embodiment" or "an alternative embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, some features, structures, or characteristics of one or more embodiments of the present application may be combined as appropriate.
Aspects of the present application may be embodied entirely in hardware, entirely in software (including firmware, resident software, micro-code, etc.) or in a combination of hardware and software. The above hardware or software may be referred to as "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 present application may be represented as a computer product, including computer readable program code, embodied in one or more computer readable media. For example, computer-readable 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., card, stick, key drive … …).
Similarly, it should be noted that in the preceding description of embodiments of the application, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure aiding in the understanding of one or more of the embodiments. This method of disclosure, however, is not intended to require more features than are expressly recited in the claims. Indeed, the embodiments may be characterized as having less than all of the features of a single embodiment disclosed above.
Although the present application has been described with reference to the present specific embodiments, it will be recognized by those skilled in the art that the foregoing embodiments are merely illustrative of the present application and that various changes and substitutions of equivalents may be made without departing from the spirit of the application, and therefore, it is intended that all changes and modifications to the above-described embodiments that come within the spirit of the application fall within the scope of the claims of the application.

Claims (13)

1. A multi-platform Bootrom verification method comprises the following steps:
step 1, receiving information input of a verification platform;
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;
step 4, compiling the simulation environment and running a verification program;
step 5, counting the coverage rate according to the log file generated by the simulation environment; and
and 6, judging whether the coverage rate reaches a preset value, if so, ending, and if not, returning to the step 2.
2. The method of claim 1, wherein the step 2 is to determine the starting mode according to a pin and/or interrupt type of the starting mode of the SOC chip.
3. The method of claim 1, wherein the validation platform comprises a hardware acceleration platform and a hardware simulation platform; the step 5 comprises the following steps:
when the verification platform is the hardware acceleration platform, serial port output information is obtained, and the coverage rate is counted according to a log file 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,
the starting mode comprises an embedded multimedia controller, a USB, a UART, a flash memory and other modes, 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.
5. 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 entry data.
6. The method of claim 4, wherein the step 3 comprises the steps of:
when the starting mode is the NOR flash memory or the NAND flash memory, generating a master 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 master Boot record;
selecting a second image file from 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;
randomly modifying one or more of the following: the master boot record, the extensible firmware interface data, the entry 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.
7. The method of claim 6, wherein the 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 secure boot is performed, the first image file comprises an image header, the second image file and a hash value of the image header; and
when the image is non-safe to start, the first image file comprises an image header, the second image file encrypted by RSA and an RSA signature of the second image file.
8. The method of claim 6, further comprising:
when the starting mode is the NOR flash memory, the master boot record comprises a NOR flash memory type and NOR flash memory time sequence parameters;
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 a NAND flash memory time sequence parameter; and
and when the starting mode is the Boot mode of the embedded multimedia controller, the master Boot record comprises a mirror image storage position.
9. The method of claim 6, wherein the extensible firmware interface data includes a signature, a version number, an extensible firmware interface data CRC check value, an entry data CRC check value, and entry data partition information.
10. The method of claim 6, wherein the entry data comprises a mirror partition location and a mirror partition name.
11. A multi-platform Bootrom validation 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 mirror image file according to the starting mode;
the compiling verification module is used for compiling the simulation environment and running a verification program;
the statistical module is used for counting the coverage rate according to the log file generated by the simulation environment; and
and the coverage rate judging module is used for judging whether the coverage rate reaches a preset value or not, if so, ending the process, and if not, informing the starting mode judging module to execute the step of judging the starting mode of the Bootrom.
12. A multi-platform Bootrom validation 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-10.
13. A computer-readable medium having stored thereon computer program code which, when executed by a processor, implements the method of any of claims 1-10.
CN202010650873.2A 2020-07-08 2020-07-08 Multi-platform Bootrom verification method, device and system and computer readable medium Active CN111767231B (en)

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 true CN111767231A (en) 2020-10-13
CN111767231B 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)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112668262A (en) * 2020-12-25 2021-04-16 瓴盛科技有限公司 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 (13)

* Cited by examiner, † Cited by third party
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
US20150106609A1 (en) * 2013-10-16 2015-04-16 Xilinx, Inc. Multi-threaded low-level startup for system boot efficiency
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

Patent Citations (13)

* Cited by examiner, † Cited by third party
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
US20150106609A1 (en) * 2013-10-16 2015-04-16 Xilinx, Inc. Multi-threaded low-level startup for system boot efficiency
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)

* Cited by examiner, † Cited by third party
Title
YAN ZHAO等: ""A single-phase energy metering SoC with IAS-DSP and ultra low power metering mode"", 《2011 IEEE INTERNATIONAL SOC CONFERENCE》 *
周洁: ""基于VxWorks车载控制设备基础软件平台设计与实现"", 《中国优秀博硕士学位论文全文数据库 信息科技辑》 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112668262A (en) * 2020-12-25 2021-04-16 瓴盛科技有限公司 SoC verification method, system, device and computer readable medium
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
CN114625639B (en) * 2022-03-03 2024-05-28 上海先楫半导体科技有限公司 Debugging method and system based on system on chip and chip

Also Published As

Publication number Publication date
CN111767231B (en) 2023-10-31

Similar Documents

Publication Publication Date Title
CN108108260B (en) Resource file verification method and device
JP2015022521A (en) Secure boot method, built-in apparatus, secure boot device and secure boot program
CN111767231A (en) Multi-platform Bootrom verification method, device, system and computer readable medium
CN104850427B (en) A kind of code upgrade method and device
EP2250609A2 (en) Secure boot with optional components method
CN106548063A (en) A kind of credible tolerance methods, devices and systems
CN111265860B (en) Game archiving processing method and device, terminal equipment and readable storage medium
CN114356680A (en) Verification method and device and electronic equipment
CN103425932B (en) Signature calibration method and terminal device
CN108196975B (en) Data verification method and device based on multiple checksums and storage medium
CN109033818B (en) Terminal, authentication method, and computer-readable storage medium
CN113704126A (en) Verification method and device, computer storage medium and processor
CN113064646A (en) BIOS starting method, system and related device
CN111859402A (en) Safe boot method and device based on UEFI BIOS start
EP2497048A2 (en) Method and apparatus for providing a fast and secure boot process
US20120291019A1 (en) Program verification apparatus based on model verifying and storage medium
CN111737701A (en) Server trusted root system and trusted starting method thereof
CN114995894A (en) Starting control method of operating system, terminal equipment and readable storage medium
CN116305322A (en) Program signature verification method and device, storage medium and electronic equipment
CN111538481B (en) Application program customization method and system
CN115629820A (en) System secure starting method, chip system, storage medium and electronic equipment
US9075737B2 (en) Verification device, verification method and computer program product
CN109426720B (en) Interface parameter verification method and related device
RU2483359C2 (en) Map with integrated circuit having modified operating program and corresponding modification method
CN117609984A (en) Code verification method and device based on RISC-V architecture

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