Heterogeneous multi-core simulation system based on qemu and chip verification method

Abstract

The invention relates to a heterogeneous multi-core simulation system based on qemu and a chip verification method. The system comprises a coprocessor, at least one multi-main-core processor, a multi-main-core processor security bus, a multi-main-core processor non-security bus and a coprocessor bus, the coprocessor is used for accessing the hardware reference model mounted on the coprocessor bus so as to control the work of the multi-main-core processor; the multi-main-core processor is used for accessing hardware reference models mounted on the multi-main-core processor security bus and the multi-main-core processor non-security bus, and the access authority of the hardware reference models mounted on the multi-main-core processor security bus is different from the access authority of the hardware reference models mounted on the multi-main-core processor non-security bus; the multi-main-core processor is used for verifying the compatibility of an operating system by executing a software framework to operating system codes. By adopting the method, the function of the hardware chip can be simulated and verified, and a software framework is constructed to verify the compatibility of an operating system.

Description

Technical Field

[0001] The present application relates to the field of chip verification technology, and in particular to a qemu-based heterogeneous multi-core simulation system and a chip verification method. Background Art

[0002] In the early stage of SoC (system on chip) hardware design, it is necessary to simulate and build hardware IP model (Intellectual Property) features that are as consistent as possible with SoC, so that the software team can get involved as early as possible, build the software framework, and verify OS compatibility. Arm SoC is usually a coprocessor SCP (or CM4) (armv7-m) and a multi-core processor AP (armv8 cortex-A) to form a heterogeneous multi-core hardware platform. One of them is a 32-bit coprocessor and the other is a 64-bit processor, and their hardware architecture and instructions are different. They need to cooperate and communicate with each other, and each controls the IP planned.

[0003] In traditional technology, Qemu itself provides its own "Virt" hardware platform virtual machine, but it is not a heterogeneous architecture, so it is different from the actual hardware design and cannot realize the functional simulation of the hardware chip. Summary of the invention

[0004] Based on this, it is necessary to provide a qemu-based heterogeneous multi-core simulation system and chip verification method that can simulate and verify the functions of hardware chips and build a software framework to verify the compatibility of the operating system in response to the above technical problems.

[0005] In a first aspect, the present application provides a qemu-based heterogeneous multi-core simulation system, the system comprising a coprocessor, at least one multi-core processor, a multi-core processor security bus, a multi-core processor non-security bus and a coprocessor bus; the multi-core processor and the coprocessor are heterogeneous processors;

[0006] The hardware reference models are mounted on the multi-core processor secure bus, the multi-core processor non-secure bus and the coprocessor bus;

[0007] The coprocessor is used to access the hardware reference model mounted on the coprocessor bus to control the operation of the multi-core processor;

[0008] The multi-core processor is used to access the hardware reference model mounted on the multi-core processor security bus and the multi-core processor non-security bus, and the access rights of the hardware reference model mounted on the multi-core processor security bus and the multi-core processor non-security bus are different; the multi-core processor is used to verify the compatibility of the operating system by executing the software framework to the operating system code.

[0009] In one embodiment, the system further comprises:

[0010] ROM storage area, the ROM storage area including a multi-core processor ROM storage area mounted on the multi-core processor secure bus, a coprocessor ROM storage area mounted on the coprocessor bus, an efuseROM storage area mounted on the multi-core processor secure bus and the coprocessor bus, a software package image file ROM storage area mounted on the multi-core processor non-secure bus, and a variable ROM storage area mounted on the multi-core processor secure bus;

[0011] The SRAM storage area includes a first SRAM storage area for boot information mounted on the multi-core processor secure bus and the coprocessor bus, a second SRAM storage area for boot information mounted on the coprocessor bus, a third SRAM storage area for boot information mounted on the multi-core processor non-secure bus and the coprocessor bus, and a DDR information SRAM storage area mounted on the multi-core processor non-secure bus and the coprocessor bus;

[0012] The DDR storage area includes a first DDR storage area mounted on the non-secure bus of the multi-core processor and the coprocessor bus and a second DDR storage area mounted on the non-secure bus of the multi-core processor.

[0013] In one embodiment, the system further comprises:

[0014] A first interrupt controller mounted on the multi-core processor secure bus and the multi-core processor non-secure bus, the first interrupt controller being used to provide inter-core communication, internal core interrupt, peripheral interrupt and PCIE device message signal interrupt of the multi-core processor;

[0015] The second interrupt controller mounted on the coprocessor bus is used to provide the coprocessor with a timer interrupt, a heterogeneous core communication interrupt, and an interrupt for waking up a multi-core processor.

[0016] In one embodiment, the system further comprises:

[0017] The heterogeneous inter-core communication model mounted on the non-secure bus of the multi-core processor and the coprocessor bus is used to notify the coprocessor to load the coprocessor startup software during the startup phase; and to notify the power management information of the multi-core processor during the kernel phase.

[0018] In one embodiment, the system further comprises:

[0019] A first power management module mounted on the non-secure bus of the multi-core processor and the coprocessor bus, used to manage the power of the multi-core processor based on the control of the coprocessor to verify the power management software process;

[0020] The second power management module mounted on the multi-core processor security bus and the coprocessor bus is used to provide a block storage area corresponding to the power supply.

[0021] In one embodiment, the system further comprises:

[0022] The serial port models are respectively mounted on the multi-core processor security bus, the multi-core processor non-security bus and the coprocessor bus, and the serial port model is used for input and output console, optee console, software console and debug port.

[0023] In one embodiment, the system further comprises:

[0024] The secure digital input and output interface mounted on the non-secure bus of the multi-core processor is used to load the file system.

[0025] In one embodiment, the system further comprises:

[0026] An input / output control model mounted on the non-secure bus of the multi-core processor, wherein the input / output control model includes a memory management unit model and a PCIERC model of input / output, and the PCIERC model supports an enhanced configuration space access mechanism.

[0027] In one embodiment, the system further comprises:

[0028] The USB models respectively mounted on the multi-core processor secure bus, the multi-core processor non-secure bus and the coprocessor bus are used for being compatible with the USB controller.

[0029] In one embodiment, the system further comprises:

[0030] The VGA model mounted on the coprocessor bus includes a PCIVGA model that discovers the VGA device through the operating system and installs the driver; and a platform VGA model that maps the mmio control register and FBvram frame buffer to the coprocessor bus space and modifies the driver adaptation.

[0031] In one embodiment, the system further comprises:

[0032] Security authentication processor, encryption mechanism for software adaptation.

[0033] In a second aspect, the present application also provides a chip verification method, which is implemented based on the above-mentioned qemu-based heterogeneous multi-core simulation system.

[0034] The above-mentioned heterogeneous multi-core simulation system and chip verification method based on qemu include a coprocessor, at least one multi-main-core processor, a multi-main-core processor security bus, a multi-main-core processor non-security bus and a coprocessor bus; the multi-main-core processor and the coprocessor are heterogeneous processors; each hardware reference model is mounted on the multi-main-core processor security bus, the multi-main-core processor non-security bus and the coprocessor bus; the coprocessor is used to access the hardware reference model mounted on the coprocessor bus; the multi-main-core processor is used to access the hardware reference model mounted on the multi-main-core processor security bus and the multi-main-core processor non-security bus, and the access rights of the hardware reference model mounted on the multi-main-core processor security bus and the multi-main-core processor non-security bus are different. In this way, on the basis of the existing qemu, the existing hardware reference model can be utilized, and the heterogeneous multi-main-core processor and the coprocessor are heterogeneous processors, so that the functions of the hardware chip can be simulated and verified. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0036] FIG1 is a schematic diagram of a heterogeneous multi-core simulation system based on qemu in one embodiment;

[0037] FIG2 is a schematic diagram of a flow chart of power management steps in one embodiment;

[0038] FIG3 is a topological diagram of a PCIE RC in one embodiment;

[0039] FIG4 is a schematic diagram of a secure boot process in one embodiment;

[0040] FIG. 5 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0041] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0042] The hardware reference model of the heterogeneous multi-core simulation system based on qemu provided in the embodiment of the present application includes: Core (A76, v7m) based on ARM, GICv3 (interrupt controller), SmmuV3 (iommu, memory management unit for input and output), UART (serial port), GPIO (general input and output), watchdog and norflash; Usb xhci (a USB standard transmission specification) and PCIE RC (root Complex, a medium for communication between CPU and PCIe bus system) based on the virtual simulation platform; standard interface, which includes I2C interface, SDIO interface, virtio-blk interface, virtio-network interface, ahci sata interface, CRB / TIS TPM (Trusted Platform Module security authentication platform module); PMU (power management unit); mailbox (communication between heterogeneous cores); platform VGA (platform VGA device).

[0043] Among them, SmmuV3 (iommu, memory management unit for input and output), Usb xhci (a USB standard transmission specification), PCIE RC (root Complex, the medium for communication between CPU and PCIe bus system), PMU (power management unit), mailbox (inter-core communication) and platform VGA (platform VGA device) are created or modified based on the actual hardware design requirements of soc. I2C interface, PCIE interface and USB interface can plug and unplug standard device models, so that the simulation system can quickly expand more hardware.

[0044] Among them, in combination with Figure 1, the present application provides a heterogeneous multi-core simulation system based on qemu, the system includes a coprocessor, at least one multi-main-core processor, a multi-main-core processor security bus, a multi-main-core processor non-security bus and a coprocessor bus; the multi-main-core processor and the coprocessor are heterogeneous processors; each hardware reference model is mounted on the multi-main-core processor security bus, the multi-main-core processor non-security bus and the coprocessor bus; the coprocessor is used to access the hardware reference model mounted on the coprocessor bus to control the operation of the multi-main-core processor; the multi-main-core processor is used to access the hardware reference model mounted on the multi-main-core processor security bus and the multi-main-core processor non-security bus, and the access rights of the hardware reference models mounted on the multi-main-core processor security bus and the multi-main-core processor non-security bus are different, and the multi-main-core processor is used to verify the compatibility of the operating system by executing the software framework to the operating system code.

[0045] Among them, the present application builds a simplified hardware heterogeneous multi-core simulation system in qemu, the system includes at least two clusters, such as three clusters in Figure 1, the at least two clusters include a coprocessor and at least one multi-core processor, combined with Figure 3, wherein the coprocessor cm4 is a 32-bit armv7 architecture, responsible for controlling the work of the multi-core processor, including release, sleep, wake-up of the multi-core processor AP, low power consumption and DDR initialization work. The multi-core processor AP is a 64-bit arm v8 architecture, responsible for the code running from the software framework firmware to the operating system OS to verify the compatibility of the software framework firmware and the operating system OS.

[0046] Optionally, each core can be debugged using a debugger connected via a TCP port, and memory data and register status of each hardware reference model IP can be viewed from the perspective of each core, wherein the debugger can be a Linux debugger, such as gdb.

[0047] Among them, the access rights of the hardware reference models mounted on the non-secure bus of the multi-core processor and the coprocessor bus are different to achieve the distinction of access rights to the hardware reference models. For real chips, coprocessor cm4 has the highest authority and can access all hardware reference models of the multi-core processor except the ROM storage area and the spi flash storage area. For the simulation system, it only accesses the hardware reference model IP that is actually controlled. Therefore, coprocessor cm4 can only access the mounted devices on the coprocessor bus. If there is a module that both the multi-core processor and the coprocessor need to access, this module needs to be mounted on at least one of the non-secure bus or the coprocessor bus of the multi-core processor, as well as the coprocessor bus.

[0048] In the above embodiment, low-cost personal computer X86 PC resources are used to simulate a heterogeneous multi-core soc platform, design a hardware reference model IPmodel that is consistent with the hardware, and ensure irq (interrupt) and memory layout that are consistent with the real soc. This allows boot firmware (boot firmware, here refers to ROM storing execution code), secure-os optee (an open source secure operating system), BIOS UEFI (Unified Extensible Firmware Interface, here refers to uboot or edk2, both of which are system boot software), and kernel driver (operating system OS kernel driver, mainly windows or linux) software to be developed in the early stage.

[0049] In one of the optional embodiments, the system also includes: a ROM storage area, the ROM storage area includes a multi-main-core processor ROM storage area mounted on the multi-main-core processor secure bus, a coprocessor ROM storage area mounted on the coprocessor bus, an efuse ROM storage area mounted on the multi-main-core processor secure bus and the coprocessor bus, a software package image file ROM storage area mounted on the multi-main-core processor non-secure bus, and a variable ROM storage area mounted on the multi-main-core processor secure bus; an SRAM storage area, including a first SRAM storage area for boot information mounted on the multi-main-core processor secure bus and the coprocessor bus, a second SRAM storage area for boot information mounted on the coprocessor bus, a third SRAM storage area for boot information mounted on the multi-main-core processor non-secure bus and the coprocessor bus, and a DDR information SRAM storage area mounted on the multi-main-core processor non-secure bus and the coprocessor bus; a DDR storage area, including a first DDR storage area mounted on the multi-main-core processor non-secure bus and the coprocessor bus, and a second DDR storage area mounted on the multi-main-core processor non-secure bus.

[0050] The ROM storage area is mainly used to load the specified startup file, including the multi-core processor ROM storage area (APBOOT ROM 128k), which is mounted on the multi-core processor security bus and is used to load the specified startup file in the first stage of the multi-core processor startup. The coprocessor ROM storage area (SCP BOOT ROM 128k) is mounted on the coprocessor bus and is used to load the specified startup file in the first stage of the coprocessor startup. The efuse ROM storage area (EFUSE) is mounted on the multi-core processor security bus and the coprocessor bus, so that the multi-core processor and the coprocessor can be accessed. It is used to store the root public key and configure hardware information. The software package image file ROM storage area (emmc boot sram 4M) is mounted on the multi-core processor non-secure bus and is used to store firmware packages other than rom. The variable ROM storage area (spi flash 8m) is mounted on the multi-core processor security bus and is used to store variables, such as uefi variables. You can also choose flash to store fip (software package image file) / variable. The above is simulated using the norflash model on a virtual machine.

[0051] The SRAM storage area is used to store files for starting the second stage and the third stage, and to store information of the DDR storage area. The SRAM storage area includes the first SRAM storage area (Trusted RAM 256k+128k), which is mounted on the multi-core processor security bus and the coprocessor bus. The first SRAM storage area is used to store boot information, including the code and data area of ​​the arm bl2 / bl3 (boot level2 / 3 boot second stage and third stage) run by the firmware. The second SRAM storage area (SCP Trusted RAM 128KB) is mounted on the coprocessor bus. The second SRAM storage area is used to store boot information, including the code and data area of ​​the arm bl2 / bl3 (boot level2 / 3 boot second stage and third stage) run by the firmware. The third SRAM storage area (emmc sram 64k) is mounted on the multi-core processor non-secure bus and the coprocessor bus. The DDR information SRAM storage area (sw info) is mounted on the non-secure bus and the coprocessor bus of the multi-core processor. The DDR information SRAM storage area is used to store the range information of the DDR size, the DDR reserved area range and / or the protection area range.

[0052] The DDR storage area includes the first DDR storage area (DDR1), which is mounted on the multi-core processor non-secure bus and coprocessor bus, and the second DDR storage area (DDR0) is mounted on the multi-core processor non-secure bus. The DDR storage area is used for uefi (variables) / uboot (boot code) and the operating system OS running space. Since arm v7 cm4 can only access the 32-bit range. So only DDR0 2G is mounted in the area accessible by SCP and AP bus. The high-end memory DDR1 is only placed on the non-secureAP bus. DDR0 size is 2G, the address is 0x8000 0000–0xFFFF FFFF, which is the highest address that 32bit can access. DDR1 starts at address 0x8 8000 0000, which exceeds 32bit.

[0053] In one of the optional embodiments, the system also includes: a first interrupt controller (GIC V3) mounted on the multi-core processor security bus and the multi-core processor non-security bus, the first interrupt controller is used to provide inter-core communication, internal core interrupts, peripheral interrupts and PCIE device message signal interrupts for the multi-core processor; a second interrupt controller (nvic) mounted on the coprocessor bus is used to provide the coprocessor with timer interrupts, heterogeneous inter-core communication interrupts, and interrupts to wake up the multi-core processor.

[0054] Among them, the interrupt controller GIC / nvic is used to interrupt the core. GIC provides multi-core processor AP inter-core communication SGI (0-15), arm core internal interrupt PPI (16-31), peripheral interrupt SPI (32-1024) and PCIE device MSI (Message Signaled Interrupts) (>8192). Nvic mainly provides timers, mailboxes (heterogeneous inter-core communication), wake-up AP multi-core processors and other interrupts for coprocessors.

[0055] In one of the optional embodiments, the system also includes: a heterogeneous inter-core communication model (mailbox) mounted on the non-secure bus and coprocessor bus of the multi-main core processor, used to notify the coprocessor to load the coprocessor startup software during the startup phase; and to notify the power management information of the multi-main core processor during the kernel phase.

[0056] The communication between heterogeneous cores is divided into secure and non-secure channels, which are respectively the communication with the coprocessor cm4 in the first startup phase bl1 / the third startup phase bl3, and the communication between the operating system OS and the coprocessor cm4. Direct / indirect communication is implemented according to hardware, and interrupts are generated to notify each core. In the startup phase, SDS / SCMI (System Control and Management Interface) is used to notify the coprocessor cm4 to load scp-bootfirmware; in the kernel phase, PSCI (Power State Coordination Interface) notifies the management of the power supply of the multi-core processor AP and other domains.

[0057] In one of the optional embodiments, the system also includes: a first power management module (PMU DVFS) mounted on the non-secure bus and coprocessor bus of the multi-core processor, which is used to manage the power of the multi-core processor based on the control of the coprocessor to verify the power management software process; a second power management module (PMU power) mounted on the secure bus and coprocessor bus of the multi-core processor, which is used to provide a block storage area corresponding to the power supply.

[0058] Among them, the coprocessor CM4 controls the power supply of each multi-core processor AP through the power management module PMU. The specific process can be seen in Figure 2, which specifically includes: ACPI (Advanced Configuration and Power Management Interface) is described by EDK, and the PSCI interface supports low power consumption and other modes, which are passed to the operating system OS at startup. When the operating system OS needs to enter low power consumption, it sends a PSCI request to the secure monitor el3.1 (security supervision layer). El3.1 firmware sends a request to the coprocessor cm4 through the mailbox scmi. The coprocessor cm4 then controls the power-related registers of each core in the power management module PMU according to the request.

[0059] The PMU model can more realistically verify software processes such as reboot, suspend, resume, wakeup, and hot plug.

[0060] PMU DVFS (dynamic voltage and frequency regulation) only provides a block storage area to help the driver read and write registers, and does not have the function of actually controlling voltage and frequency.

[0061] In one of the optional embodiments, the system also includes: a serial port model (uart1) mounted on the multi-main core processor security bus, a serial port model (uart2 and uart3) on the multi-main core processor non-security bus and a serial port model (uart0) on the coprocessor bus, and the serial port model is used for input and output console, optee console, software console and debug port.

[0062] Among them, the four serial ports UART are used for scp console (input and output console), optee console, uefi / OS console and debug port respectively. The arm pl011 model is used for simulation on the virtual machine. Among them, the four serial ports are printed output at different software levels in the simulation platform, and are output to the user through the network by the host, so that the user can debug and control the guest host. The console uses TCP network communication to simulate the host terminal. The debug port uses pipe device simulation, which can be mainly used for the host to run windbg (a windows code debugger) and bind it to the virtual machine UART to debug windows, where the console is the input and output text window. The host is the machine where qemu runs, and the guest is the machine simulated and running inside qemu.

[0063] In one of the optional embodiments, the system further includes: a secure digital input and output interface (SDIO controller, Secure Digital Input and Output) mounted on a non-secure bus of the multi-core processor, for loading a file system.

[0064] The SDIO controller backend (backend device) is used to mount the file system, that is, the GPT (GUID Partition Table, Globally Unique Identifier Partition Table) partition Linux ext2 file system. It can simulate the process of UEFI booting the Linux kernel file and load the file system.

[0065] In one of the optional embodiments, the system also includes: an input-output control model mounted on a non-secure bus of a multi-core processor, the input-output control model includes an input-output memory management unit model and a PCIE RC model, and the PCIE RC model supports an enhanced configuration space access mechanism.

[0066] In order to verify the IOMMU function of the SOC (IOMMU is a standardized process, that is, the device as a master accesses the real physical address through mapping), the ARM SMMU and Synopsys PCIE RC model are also created in the simulator. Mounted on the non-secure bus AP of the main core processor. The PCIE RC model is modified to support ECAM (Enhanced Configuration Access Mechanism), and the PCI RC or device configuration space is accessed through ECAM. In this way, the general PCIE host driver can be used without installing a private driver for the operating system OS.

[0067] Specifically, as shown in Figure 3, the PCIe device can be dynamically hot-swapped through a startup command. The PCIe device can implement MSI / MSI-X interrupts through ITS. When the PCIe device is used as a master DMA, SMMU uses bus+devfn as the stream ID to look up the table to obtain the mapping from VA to PA, thereby implementing the DMA IOMMU function.

[0068] Use pcie virtio-blk devices to support large-capacity storage and speed up the virtual machine's access to storage devices. Now install the Win OS GPT / NTFS file system to the area.

[0069] The virtual machine can load the PCIE VGA device and output the OS UI to the host VNC (a virtual display software through network data).

[0070] In one of the optional embodiments, the above system also includes: a USB model mounted on the multi-core processor security bus, the multi-core processor non-security bus and the coprocessor bus respectively, for being compatible with a USB controller.

[0071] Among them, the qemu usb controller model does not fully support synopsys usb3.1. By modifying the original model, you don't need to modify edk and kernel drivers, and it is fully compatible with the real usb controller. Use the platform usb device to mount to the bus, declare it as PNP0D10 according to ACPI CID, and use the standard XHCI driver provided by OS. Now, mount the usb cdrom under Usb control, and its backend is the windows installation disk and driver disk respectively. You can also mount the keyboard and mouse as input devices.

[0072] In one of the optional embodiments, the system also includes: a VGA model mounted on the coprocessor bus, including a PCI VGA model that discovers the VGA device through the operating system and installs the driver; and a platform VGA model that maps the mmio control register and FBvram frame buffer to the coprocessor bus space and modifies the driver adaptation.

[0073] Among them, the display device VGA has two modes mounted to the simulated virtual environment: PCI VGA and platform VGA. In PCI mode, the operating system discovers the VGA device and installs the driver. For platform VGA, native qemu does not support this model, and maps the mmio control register and FB vram (frame buffer) to the bus space. Modify the EDK driver to adapt to this device, and VNC can display the UI. You don't need to describe this platform VGA device in ACPI, you can start Windows directly. It is found that OS uses edk gop (graphics out protocol, equivalent to edk device driver) for display. This verifies that after the real chip soc platform VGA supports edk gop, it is feasible to start Windows.

[0074] In one of the optional embodiments, the system further includes: a security authentication processor for a software-adapted encryption mechanism.

[0075] TPM is a cryptographic coprocessor that includes functions such as random number generation, secure generation of encryption keys, and restrictions on their use, as well as remote attestation and sealed storage. They are specified by the CRB and TIS interface specifications respectively. And the device base address required by Windows is located at 0xFED40000. In the qemu SOC virtual machine, swptm is used to simulate the backend device implementation. In the simulation platform software architecture, this special base address area is opened in optee DDR, the CRB interface is simulated, and the tpm packet is transparently transmitted to TA ftpm for response (a Microsoft software tpm implementation). The support and verification of the simulated tpm has been successfully completed. In the future, optee can also be transparently transmitted to the hardware in real chips

[0076] In the above qemu-based heterogeneous multi-core simulation system, the model provided by qemu may not meet the hardware selection IP. After code modification, it is guaranteed to be compatible with the real chip driver without modification. In a simulation environment closer to the real multi-core heterogeneous soc hardware architecture, most of the boot firmware framework / optee / kernel driver functions of the verification software can be verified in the early stage of the soc chip.

[0077] In addition, based on the original qemu, try to make use of the IP model it has provided, and implement a customized model according to your own hardware IP design, and simulate a more realistic hardware heterogeneous multi-core platform according to the hardware planning interrupt and hardware IP memory distribution. Let the software enter early, verify the software framework, and speed up the software development process. The constructed simulation platform is easy to debug, easy to locate and solve software problems that are incompatible with the OS. In terms of performance, qemu's mature vfio (a technology that passes device control to the guest virtual machine) and virtio (a unified io operation interface from user virtual machines to kernel devices) and other device virtualization technologies are used to improve the operating performance of virtual simulation heterogeneous platforms.

[0078] Optionally, the present application also provides a chip verification method, which can be applied to the above-mentioned qemu-based heterogeneous multi-core simulation system.

[0079] For ease of understanding, in conjunction with Figure 4, Figure 4 is a multi-core heterogeneous virtual environment startup software framework firmware and a secure boot process in the operating system in an embodiment. The secure boot process can be applied to the above-mentioned qemu-based heterogeneous multi-core simulation system. In this embodiment, the multi-core virtual environment startup process strictly follows the hardware design and arm specifications, which is the same process as the real chip. The coprocessor CM4 core runs scp-bl0 from the ROM storage area to release all multi-core processors AP. AP runs bl1 from its own rom (the first stage of boot level operation), and loads and verifies the bl2 to bl3.3 images in the emmc sram fip package. Until edk loads the OS image. The loader uses X509 to verify the signature for the loader.

[0080] Among them, the heterogeneous multi-core simulation system based on qemu also supports the startup of the following operating systems OS:

[0081] (1) Linux (5.15-LTS)

[0082] The kernel+ext2 file system uses SDIO storage, and the sdio device is selected for booting in the edk stage. The file system needs to be pre-made in GPT+ext4 format. Load from the / EFI / BOOT / BOOTAA64.EFI (kernel image) path, omitting GRUB (a boot multi-kernel management software) to load the kernel. EDK passes the hardware configuration to the kernel through ACPI or devicetree. The whole process can be debugged step by step using gdb connected to the local network port.

[0083] (2) Windows (win10 / win11)

[0084] The Windows installation disk (usb cdrom) needs to be installed first. The installation target storage image file is pre-created using qemu cow2 and mounted as a backend file to the pcie virtio-blk device. During the installation process, the virtio storage storage driver needs to be installed to discover the installation storage disk.

[0085] Like Linux, EDK first loads / EFI / BOOT / BOOTAA64.EFI of the virtio-blk device, and then loads / EFI / Microsoft / Boot / bootmgr.efi to boot the OS. It also passes Windows ACPI information to describe the local device and control method.

[0086] Since Windows has no source code, gdp cannot obtain symbols. You must connect the host windbg to the simulation platform uart through a pipe. In this way, you can obtain symbols from the Microsoft remote symbol server and see the stack.

[0087] In addition, by simulating a real virtual machine model, starting in win10 / win11, using windbg to locate and solve the problem of early incompatible system crashes.

[0088] In summary, now Linux 5.15 LTS and Win10 / Win11 can be started on this heterogeneous multi-core simulation platform. Creating a self-developed IP consistent logic model can verify the hardware and software functions and processes on the simulation platform. According to the hardware plan, the design of the soc simulation platform facilitates software design and debugging, and plays a significant role in allowing project personnel to familiarize themselves with the environment as soon as possible. It can also discover problems of incompatibility between the software and the operating system in the early stage, saving a lot of development time.

[0089] It should be understood that, although the steps in the flowcharts involved in the above embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0090] In an exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be shown in FIG5. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit, and an input device. The processor, the memory, and the input / output interface are connected via a system bus, and the communication interface, the display unit, and the input device are connected to the system bus via the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner may be implemented through WIFI, a mobile cellular network, near field communication (NFC) or other technologies. When the computer program is executed by the processor, a chip verification method is implemented. The display unit of the computer device is used to form a visually visible picture, which may be a display screen, a projection device, or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a button, trackball or touchpad set on the computer device shell, or an external keyboard, touchpad or mouse.

[0091] Those skilled in the art will understand that the structure shown in FIG. 5 is merely a block diagram of a partial structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different arrangement of components.

[0092] In one embodiment, a computer device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above method embodiments when executing the computer program.

[0093] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0094] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0095] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0096] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0097] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A heterogeneous multi-core simulation system based on qemu, characterized in that: The system includes a coprocessor, at least one multi-core processor, a multi-core processor secure bus, a multi-core processor non-secure bus and a coprocessor bus; The multi-core processor and the coprocessor are heterogeneous processors; The hardware reference models are mounted on the multi-core processor secure bus, the multi-core processor non-secure bus and the coprocessor bus; The coprocessor is used to access the hardware reference model mounted on the coprocessor bus to control the operation of the multi-core processor; The multi-core processor is used to access a hardware reference model mounted on a secure bus of the multi-core processor and an unsecure bus of the multi-core processor, and the access rights of the hardware reference model mounted on the secure bus of the multi-core processor and the unsecure bus of the multi-core processor are different; The multi-core processor is used to verify the compatibility of the operating system by executing the software framework to the operating system code.

2. The system according to claim 1, characterized in that The system further comprises: ROM storage area, the ROM storage area including a multi-core processor ROM storage area mounted on the multi-core processor secure bus, a coprocessor ROM storage area mounted on the coprocessor bus, an efuse ROM storage area mounted on the multi-core processor secure bus and the coprocessor bus, a software package image file ROM storage area mounted on the multi-core processor non-secure bus, and a variable ROM storage area mounted on the multi-core processor secure bus; The SRAM storage area includes a first SRAM storage area for boot information mounted on the multi-core processor secure bus and the coprocessor bus, a second SRAM storage area for boot information mounted on the coprocessor bus, a third SRAM storage area for boot information mounted on the multi-core processor non-secure bus and the coprocessor bus, and a DDR information SRAM storage area mounted on the multi-core processor non-secure bus and the coprocessor bus; The DDR storage area includes a first DDR storage area mounted on the non-secure bus of the multi-core processor and the coprocessor bus and a second DDR storage area mounted on the non-secure bus of the multi-core processor.

3. The system according to claim 1, characterized in that The system further comprises: A first interrupt controller mounted on the multi-core processor secure bus and the multi-core processor non-secure bus, the first interrupt controller being used to provide inter-core communication, internal core interrupt, peripheral interrupt and PCIE device message signal interrupt of the multi-core processor; The second interrupt controller mounted on the coprocessor bus is used to provide the coprocessor with a timer interrupt, a heterogeneous core communication interrupt, and an interrupt for waking up a multi-core processor.

4. The system according to claim 1, characterized in that The system further comprises: The heterogeneous inter-core communication model mounted on the non-secure bus of the multi-core processor and the coprocessor bus is used to notify the coprocessor to load the coprocessor startup software during the startup phase; and to notify the power management information of the multi-core processor during the kernel phase.

5. The system according to claim 1, characterized in that The system further comprises: A first power management module mounted on the non-secure bus of the multi-core processor and the coprocessor bus, used to manage the power of the multi-core processor based on the control of the coprocessor to verify the power management software process; The second power management module mounted on the multi-core processor security bus and the coprocessor bus is used to provide a block storage area corresponding to the power supply.

6. The system according to claim 1, characterized in that The system further comprises: The serial port models are respectively mounted on the multi-core processor security bus, the multi-core processor non-security bus and the coprocessor bus, and the serial port model is used for input and output console, optee console, software console and debug port.

7. The system according to claim 1, characterized in that The system further comprises: The secure digital input and output interface mounted on the non-secure bus of the multi-core processor is used to load the file system.

8. The system according to claim 1, characterized in that The system further comprises: An input / output control model mounted on the non-secure bus of the multi-core processor, wherein the input / output control model includes an input / output memory management unit model and a PCIE RC model, and the PCIE RC model supports an enhanced configuration space access mechanism.

9. The system according to claim 1, characterized in that The system further comprises: The USB models respectively mounted on the multi-core processor secure bus, the multi-core processor non-secure bus and the coprocessor bus are used for being compatible with the USB controller.

10. The system according to claim 1, characterized in that The system further comprises: The VGA model mounted on the coprocessor bus includes a PCI VGA model that discovers the VGA device through the operating system and installs the driver; and a platform VGA model that maps the mmio control register and FB vram frame buffer to the coprocessor bus space and modifies the driver adaptation.

11. The system according to claim 1, characterized in that The system further comprises: Security authentication processor, encryption mechanism for software adaptation.

12. A chip verification method, characterized in that: The method is implemented based on the qemu-based heterogeneous multi-core simulation system described in any one of claims 1 to 11.

Images