RISC-V oriented image building method and device, terminal and medium

Abstract

The application discloses a RISC-V-oriented mirror image construction method and device, a terminal and a medium, and belongs to the mirror image field.The method comprises the following steps: constructing an empty universal mirror image, formatting a partition according to a target architecture, forming a to-be-constructed target architecture system mirror image comprising a first boot partition, a second boot partition, a startup partition and a root file system partition; setting the to-be-constructed target architecture system mirror image as a loop device and mounting the root file system partition, mounting a pre-constructed universal complete mirror image, synchronizing files to the root file system partition by using a synchronization command on the premise that the authority is unchanged, and then removing the universal mirror image mounting; copying a boot startup binary file to the two boot partitions, mounting the startup partition, executing chroot to enter a first file directory, installing a kernel, a driver and a startup boot configuration so that the kernel, the driver and the startup boot configuration are automatically loaded into the startup partition; and finally removing related mounting and unbinding the loop device.The method greatly improves the cross-platform mirror image construction efficiency and environment consistency.

Description

Technical Field

[0001] This invention relates to the field of image technology, and in particular to a method, apparatus, terminal and medium for building images for RISC-V. Background Technology

[0002] In recent years, the RISC-V open-source instruction set architecture has developed rapidly, becoming one of the mainstream CPU architectures. However, the definitions of computer hardware interfaces by different RISC-V hardware manufacturers are not uniform, resulting in differences in system images for various hardware platforms in terms of image type, partition format, kernel version, and hardware drivers. Therefore, it is necessary to build unique system images for each hardware platform. The commonly used method for building RISC-V images is to manually or automatically build system images for each hardware platform from scratch. First, an empty image is built according to the image type and partition format requirements of the hardware platform; then, debootstrap is used to build a basic root file system in the image; then, chroot (changing the root directory) is used to enter the image and install system services, display, desktop environment, and other packages that are common to all RISC-V hardware platform system images; finally, the unique kernel, bootloader, hardware drivers, and other packages or basic libraries for the specific hardware platform are installed.

[0003] In the process of developing this invention, the inventors discovered the following technical problems: Since the software packages are pulled and installed from a software source during the individual image building process, and this source is continuously updated, inconsistencies in the package lists and versions of the hardware platform system images built at different times lead to inconsistencies in the software functionality of each hardware platform system image. Furthermore, during the image building process, each hardware platform system image requires repeated execution of debootstrap to build the basic root file system and chroot to install common packages, resulting in a large amount of repetitive work when building multiple hardware platform system images. This leads to an extremely long overall build time, severely restricting the rapid distribution and iteration of RISC-V system images. Summary of the Invention

[0004] This invention provides a method, apparatus, terminal, and storage medium for building RISC-V system images, in order to solve the technical problems of poor consistency and timeliness in building RISC-V system images in the prior art.

[0005] In a first aspect, embodiments of the present invention provide a method for building a RISC-V image, including: An empty target architecture system image is constructed. The empty general image is formatted and partitioned according to the image type and partition format requirements of the target architecture to form the target architecture system image to be constructed. The target architecture system image to be constructed includes at least a first boot partition, a second boot partition, a boot partition, and a root file system partition. Set the target architecture system image to be built as a circular device, mount the root file system partition of the target architecture system image to be built to a preset first file directory, mount the pre-built universal complete image containing cross-hardware platform general software packages to a preset second file directory, and use a synchronization command to synchronize all files in the second file directory to the first file directory while keeping the file permissions unchanged. Remove the mount relationship between the general complete image and the second file directory; Copy the boot binary file corresponding to the target architecture to be built to the first boot partition and the second boot partition respectively. Mount the boot partition of the target architecture system image to be built to the boot subdirectory under the first file directory. Execute chroot to enter the first file directory to change the root directory of the current process and child processes to the first file directory. Install the kernel, boot configuration and hardware driver corresponding to the target architecture hardware to be built in the first file directory so that the kernel and boot configuration are automatically installed to the boot partition. Remove the mount relationship between the first file directory and the partition where the boot files of the target architecture system image to be built are stored, and unbind the circular device from the target architecture system image to be built.

[0006] Secondly, embodiments of the present invention also provide a RISC-V-oriented image building apparatus, comprising: The build module is used to build an empty target architecture system image. It formats and partitions the empty general image according to the image type and partition format requirements of the target architecture to form the target architecture system image to be built. The target architecture system image to be built includes at least a first boot partition, a second boot partition, a boot partition, and a root file system partition. The configuration module is used to set the target architecture system image to be built as a circular device, mount the root file system partition of the target architecture system image to be built to a preset first file directory, mount the pre-built universal complete image containing cross-hardware platform general software packages to a preset second file directory, and use a synchronization command to synchronize all files in the second file directory to the first file directory while keeping the file permissions unchanged. The removal module is used to remove the mount relationship between the general complete image and the second file directory; The copy module is used to copy the boot binary file corresponding to the target architecture to be built to the first boot partition and the second boot partition respectively, mount the boot partition of the target architecture system image to be built to the boot subdirectory under the first file directory, execute chroot to enter the first file directory, change the root directory of the current process and child processes to the first file directory, and install the kernel, boot configuration and hardware driver corresponding to the target architecture hardware to be built in the first file directory, so that the kernel and boot configuration are automatically installed to the boot partition; The removal module is used to remove the mount relationship between the first file directory and the partition where the boot files of the target architecture system image to be built are stored, and to unbind the circular device from the target architecture system image to be built.

[0007] Thirdly, embodiments of the present invention also provide a terminal, including: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement any of the RISC-V-oriented image building methods provided in the above embodiments.

[0008] Fourthly, embodiments of the present invention also provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to execute the RISC-V-oriented image building method provided in the above embodiments.

[0009] The RISC-V-oriented image building method, apparatus, terminal, and storage medium provided in this invention construct an empty target architecture system image. Based on the target architecture's image type and partitioning format requirements, the empty general image is formatted and partitioned to form a target architecture system image to be built. The target architecture system image to be built includes at least a first boot partition, a second boot partition, a startup partition, and a root file system partition. The target architecture system image to be built is set as a circular device. The root file system partition of the target architecture system image to be built is mounted to a preset first file directory. A pre-built general complete image containing cross-hardware platform general software packages is mounted to a preset second file directory. A synchronization command is used to synchronize all files in the second file directory while maintaining file permissions. Navigate to the first file directory; remove the mount relationship between the universal complete image and the second file directory; copy the boot binary file corresponding to the target architecture to be built to the first boot partition and the second boot partition respectively; mount the boot partition of the target architecture system image to be built to the boot subdirectory under the first file directory; execute chroot to enter the first file directory to change the root directory of the current process and child processes to the first file directory; install the kernel, boot configuration, and hardware driver corresponding to the target architecture hardware to be built in the first file directory, so that the kernel and boot configuration are automatically installed to the boot partition; remove the mount relationship between the first file directory and the partition where the boot files of the target architecture system image to be built are stored, and unbind the circular device from the target architecture system image to be built. By mounting the pre-built universal complete image containing cross-hardware platform universal software packages, and using synchronization commands, all files in the universal image are completely synchronized to the target architecture system image to be built. Because all hardware platform images are cloned and synchronized based on the same pre-built universal base, the version inconsistency issues caused by each platform pulling software packages from continuously updated software sources in existing technologies are avoided. This ensures that the vast majority of package lists and versions in the system images of each hardware platform are completely consistent. Instead of building from scratch, file synchronization is used instead of building from scratch. Only one pre-build of the universal image is required, and subsequent builds of each platform directly perform file-level synchronization. This technical feature transforms the most time-consuming step into efficient file copying, significantly reducing the total time for building system images for multiple hardware platforms. Furthermore, before executing chroot, the boot partition is pre-mounted in the boot subdirectory of the root file system. This allows relevant files to be automatically and accurately placed in the boot partition when executing regular kernel and driver installation commands in the chroot environment. This avoids file installation errors or complex secondary manual copying caused by path changes within the chroot environment, effectively improving the automation level of image building and the reliability of system startup. Attached Figure Description

[0010] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart illustrating the RISC-V-oriented image construction method provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart illustrating the RISC-V-oriented image construction method provided in Embodiment 2 of the present invention; Figure 3 This is a schematic diagram of the RISC-V-oriented image building device provided in Embodiment 3 of the present invention; Figure 4 This is a schematic diagram of the terminal provided in Embodiment 4 of the present invention. Detailed Implementation

[0011] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0012] Example 1 Figure 1 This is a flowchart of a RISC-V-oriented image building method provided in Embodiment 1 of the present invention. This embodiment is applicable to the building of RISC-V-oriented images. The method can be executed by a RISC-V-oriented image building device, and specifically includes the following steps: Step 110: Construct an empty target architecture system image. Format and partition the empty general image according to the image type and partition format requirements of the target architecture to form the target architecture system image to be constructed. The target architecture system image to be constructed includes at least a first boot partition, a second boot partition, a boot partition, and a root file system partition.

[0013] In this embodiment, an empty target architecture system image of a preset size is constructed based on the system image size requirements of the target architecture (e.g., RISC-V architecture) hardware platform. The empty target architecture system image is then formatted and partitioned according to the image type and partition format requirements of the target architecture to form the target architecture system image to be built. Because different RISC-V hardware vendors do not have uniform definitions for computer hardware interfaces and boot mechanisms, the target system image needs to have a specific physical partition layout. Therefore, the target architecture system image to be built includes at least a first boot partition, a second boot partition, a boot partition, and a root file system partition.

[0014] For example, when building a system image for the HiFive Unmatched hardware platform suitable for the RISC-V architecture, partitioning and formatting operations can be performed using disk partitioning tools (such as sgdisk) and file system formatting tools (such as mkfs).

[0015] Optionally, the empty generic image can be divided into four partitions: a first boot partition, a second boot partition, a startup partition, and a root file system partition. The first boot partition can be 1MB in size, the second boot partition can be 6MB in size, the startup partition can be 500MB in size and formatted as vfat, and the root file system partition occupies the remaining space and is formatted as ext4. The partition label of the startup partition can be set to bootfs, and the partition label of the root file system partition can be set to rootf.

[0016] For the first boot partition, a 1MB raw partition can be created. This first boot partition is not formatted using a regular file system and is used to directly write the underlying boot binary file corresponding to the target hardware platform in subsequent steps, such as the U-Boot secondary program loader u-boot-spl.bin. The second boot partition can be a 6MB raw partition, also not formatted using a regular file system, and is used to directly write the FIT image file containing the OpenSBI firmware, U-Boot main body, and device tree in subsequent steps. A 500MB partition is created as the boot partition and formatted to vfat format using the mkfs.vfat command. Its partition label can be changed to bootfs using the dosfslabel command. This boot partition is used to store the system kernel image and boot configuration files. The root file system partition can occupy the remaining space of the image. It is formatted to ext4 format using the mkfs.ext4 command and its partition label can be changed to rootfs using the e2label command. The root file system partition is used to mount and store the operating system's root file system and various system software packages. Using the above method, it is possible to accurately adapt to the multi-level boot loading chain specific to RISC-V architecture hardware. The independent division of the first boot partition and the second boot partition provides the basis for the physical addressing and loading of the underlying firmware.

[0017] Step 120: Set the target architecture system image to be built as a circular device, mount the root file system partition of the target architecture system image to be built to a preset first file directory, mount the pre-built universal complete image containing cross-hardware platform universal software packages to a preset second file directory, and use a synchronization command to synchronize all files in the second file directory to the first file directory while keeping the file permissions unchanged.

[0018] After partitioning and formatting the target architecture system image, the basic operating system environment needs to be deployed to the target architecture system image. In this embodiment, file-level synchronization can be used to clone the contents of a pre-built generic complete image into the target image.

[0019] For example, the target architecture system image to be built can be set as a circular device. In a Linux environment, the `losetup` command can be used to map the image file as a virtual block device, i.e., a circular device, allowing the operating system to access the various partitions within the image file as if they were physical hard drives. The root file system partition of the target architecture system image to be built is mounted to a preset first file directory. Taking the aforementioned root file system partition as an example, the `mount` command can be used to mount this partition to a preset directory on the host system, such as the ` / mnt` directory, i.e., the first file directory, serving as a container for subsequently receiving general software packages and root file system files.

[0020] The pre-built universal complete image containing cross-hardware platform common software packages is mounted to a preset second file directory. This universal complete image is built independently beforehand and contains the intersection of system image software packages from various RISC-V hardware platforms. For example, it may include: a basic root file system, system services, display and desktop environments, etc. The universal complete image can be mounted to another preset directory on the host machine, such as the / common-mnt directory (the second file directory), using the mount command with the -o loop parameter, as the source path for file synchronization.

[0021] The system then uses a synchronization command to synchronize all files in the second file directory to the first file directory while maintaining their permissions. Since the normal operation of the Linux operating system highly depends on the accuracy of file permissions and attributes, regular file copy commands may result in permission loss or node errors, causing the built system image to fail to boot or run abnormally. For example, the `rsync` command can be used, such as `rsync -aHAX / common-mnt / / mnt / `, to perform the synchronization operation. By configuring specific parameters, such as `-a` for archive mode, or further using `-A` to preserve ACL permissions and `-X` to preserve extended attributes, it ensures that the original file's owner, group, read / write / execute permissions, symbolic links, and device nodes are strictly preserved during file copying. Using this method, a precise clone of a cross-architecture common basic environment can be completed in a very short time. Compared to pulling and installing packages from scratch using `debootstrap`, this significantly reduces build time and ensures a high degree of consistency in the multi-platform image's basic environment.

[0022] Step 130: Remove the mount relationship between the general complete image and the second file directory.

[0023] The generic full image can be unmounted on the second file directory by executing an unmount command (e.g., `umount / common-mnt`). Timely removal of the mount frees up host system resources, avoiding redundant device usage. The unmount operation triggers the operating system to safely flush dirty data from the memory page cache to the underlying storage medium, ensuring the integrity of the file synchronization process and data consistency, preventing root file system corruption or file loss due to delayed cache writes. Furthermore, it avoids path nesting conflicts or device usage errors when mounting or performing chroot operations on other partitions of the target architecture system image to be built in subsequent steps, thus ensuring the smooth and safe execution of subsequent image building steps.

[0024] Step 140: Copy the boot binary file corresponding to the target architecture to be built to the first boot partition and the second boot partition respectively. Mount the boot partition of the target architecture system image to be built to the boot subdirectory under the first file directory. Execute chroot to enter the first file directory to change the root directory of the current process and child processes to the first file directory. Install the kernel, boot configuration and hardware driver corresponding to the target architecture hardware to be built in the first file directory, so that the kernel and boot configuration are automatically installed to the boot partition.

[0025] For example, copying the boot binary file corresponding to the target architecture to be built to the first boot partition and the second boot partition respectively may include: using the dd command to write the u-boot-spl.bin file to the first boot partition and the u-boot.itb file to the second boot partition; wherein, u-boot-spl.bin is the secondary program loader of U-Boot, and u-boot.itb is a FIT image containing OpenSBI firmware, U-Boot main body and device tree. Installing the kernel, boot configuration and hardware driver corresponding to the target architecture hardware to be built in the first file directory may include: using apt install in the chroot environment to install the kernel deb package and graphics card driver corresponding to the target RISC-V hardware model, modifying the / etc / default / u-boot configuration file and running the u-boot-update command to automatically generate the extlinux.conf boot configuration file, which is then installed to the boot partition mounted in the boot subdirectory under the first file directory.

[0026] Because certain RISC-V architecture hardware, such as HiFive Unmatched, typically requires reading the underlying firmware from a fixed physical offset location in the image, the boot binary must be written directly to the corresponding raw partition before performing the chroot operation. For example, the boot binary corresponding to the target architecture to be built is copied to the first boot partition and the second boot partition, respectively. For instance, the U-Boot secondary program loader is written to the first boot partition using the dd command, and the FIT image containing the OpenSBI firmware, U-Boot main body, and device tree is written to the second boot partition to meet the hardware's low-level physical addressing boot requirements. The system image of the target architecture to be built is mounted to the boot subdirectory under the first file directory. For example, a boot partition previously formatted as vfat is mounted to the boot subdirectory under the first file directory. Using this method, the system in the subsequent chroot environment can recognize the boot subdirectory as the system's standard boot directory when installing the kernel.

[0027] Executing `chroot` allows you to enter the first file system directory, changing the root directory of the current process and its child processes to this directory. Using the `chroot` command, the build environment is securely isolated within the target image's root file system, ensuring that subsequent installation and configuration operations directly affect the target image being built, without impacting the host system.

[0028] In the first directory after chrooting, install the kernel, boot configuration file, and hardware drivers corresponding to the target hardware architecture. For example, this can be done using a package management tool such as `apt install` to install the kernel deb package matching the target RISC-V hardware model, along with hardware drivers such as the graphics card driver. Simultaneously, modify the boot configuration environment files, such as ` / etc / default / u-boot`, and run the boot update command (to automatically generate boot configuration files such as `extlinux.conf`).

[0029] Since the boot partition was mounted to the boot subdirectory before chrooting, the kernel image file and generated boot configuration file will be automatically installed into the boot partition based on the standard Linux file system mount level. By leveraging the pre-mounting and chroot linkage mechanism, the output paths of the package manager and configuration generation tools are cleverly guided, avoiding file installation location errors caused by path changes within the chroot environment, or the tedious steps of manual copying after building. This achieves precise and automated deployment of the kernel and boot configuration.

[0030] Step 150: Remove the mount relationship between the first file directory and the partition where the boot files of the target architecture system image to be built are stored, and unbind the circular device from the target architecture system image to be built.

[0031] Remove the mount relationship between the first file directory and the partition containing the boot files of the target architecture system image to be built. For example, by executing an unmount command, the boot subdirectory under the first file directory is unmounted. The unmount operation triggers the operating system to safely flush the kernel image file, extlinux.conf, and other boot configuration files written by the package manager during the mounting process from the system memory page cache to the underlying boot partition media. This ensures the integrity and consistency of the boot data and prevents boot failures or file corruption on subsequent boots due to data not being promptly written to disk. After unmounting the boot partition, the mount relationship between the first file directory and the root file system partition should also be removed simultaneously to ensure that the file systems of all partitions within the image are in an inactive and stable state.

[0032] Unbind the loop device from the target architecture system image to be built. For example, you can use loop device management commands, such as `losetup -d / dev / loopX`, to delete the mapping between the image file and the virtual block device established during the initial build phase, thereby releasing the loop device resources allocated by the host system.

[0033] Through the above uninstallation and unbinding operations, the target architecture system image to be built is completely and securely removed from the host machine's runtime environment, and all memory cache data generated during the mounting process has been persistently written to disk. The system image file, such as the HiFive Unmatched image file, is independently, completely, and precisely adapted to a specific RISC-V hardware platform. Once built, the image file can be directly burned to the storage medium of the target hardware device, enabling rapid system deployment and startup.

[0034] This embodiment constructs an empty target architecture system image, formats and partitions the empty generic image according to the target architecture's image type and partition format requirements, forming a target architecture system image to be constructed. The target architecture system image to be constructed includes at least a first boot partition, a second boot partition, a boot partition, and a root file system partition. The target architecture system image to be constructed is set as a circular device. The root file system partition of the target architecture system image to be constructed is mounted to a preset first file directory. A pre-built generic complete image containing cross-hardware platform generic software packages is mounted to a preset second file directory. A synchronization command is used to synchronize all files in the second file directory to the first file directory while maintaining file permissions. The generic file system partition is then removed. The mounting relationship between the complete image and the second file directory is established. The boot binary files corresponding to the target architecture to be built are copied to the first boot partition and the second boot partition respectively. The boot partition of the target architecture system image to be built is mounted to the boot subdirectory under the first file directory. `chroot` is executed to enter the first file directory, changing the root directory of the current process and child processes to the first file directory. The kernel, boot configuration, and hardware drivers corresponding to the target architecture hardware to be built are installed in the first file directory, so that the kernel and boot configuration are automatically installed to the boot partition. The mounting relationship between the first file directory and the partition storing the boot files of the target architecture system image to be built is removed, and the circular device is unbound from the target architecture system image to be built. A pre-built universal complete image containing cross-hardware platform common software packages is mounted, and a synchronization command is used to completely synchronize all files in the universal image to the target architecture system image to be built. Since each hardware platform image is cloned and synchronized based on the same pre-built universal base, the version inconsistency problem caused by each platform pulling software packages from continuously updated software sources in the prior art is avoided, thus ensuring that the vast majority of software package lists and versions in each hardware platform system image are completely consistent. Instead of building from scratch, this technique uses file synchronization, requiring only a single pre-build of the universal image. Subsequent builds for each platform directly synchronize files at the file level. This feature transforms the most time-consuming step into efficient file copying, significantly reducing the overall time for building system images for multiple hardware platforms. Furthermore, before executing chroot, the boot partition is pre-mounted in the boot subdirectory of the root filesystem. This ensures that when regular kernel and driver installation commands are executed in the chroot environment, the relevant files are automatically and accurately placed in the boot partition. This avoids file installation errors caused by path changes within the chroot environment or complex secondary manual copying, effectively improving the automation level of image building and the reliability of system startup.

[0035] In a preferred embodiment of this example, the RISC-V-oriented image building method utilizes a first script file and a second script file for collaborative implementation. The first script performs image building, partition formatting, circular device setup, file synchronization, boot binary file writing, and boot partition mounting operations. Before executing chroot, the second script is copied to the first file directory. The second script is automatically invoked in the chroot environment to perform kernel, hardware driver, and boot configuration installation operations. After installation, chroot is exited, and the first script continues to perform mount removal and circular device unbinding operations. To achieve a high degree of automation in the image building process and reduce the reliance on manual intervention and technical personnel experience, the image building method of this embodiment utilizes the collaborative execution of a first script file and a second script file. The first script performs preprocessing, the second script executes within an isolated environment, and the first script completes the final build tasks. Using this method, the entire build process from writing the underlying firmware to installing the upper-layer software can be completed without manual intervention, effectively avoiding omissions or errors in the manual build process and significantly improving the automation and execution efficiency of image building for different RISC-V hardware platforms.

[0036] Example 2 Figure 2 This is a flowchart illustrating the RISC-V image building method provided in Embodiment 2 of the present invention. This embodiment is based on the above embodiment and optimized. The method may also include the following steps: building an empty target architecture system image, setting the empty general image as a loop device and mounting it to a preset third file directory, and using debootstrap to build a basic root file system in the third file directory; executing chroot to enter the third file directory and automatically running the second script in the chroot environment to install the general software packages corresponding to system services, display, and desktop environment in the basic root file system; after exiting chroot, unmounting the general image and removing the loop device to obtain the general complete image.

[0037] See Figure 2 The method for building RISC-V images includes: Step 210: Construct an empty target architecture system image, set the empty general image as a circular device and mount it to a preset third file directory, and use debootstrap to construct a basic root file system in the third file directory.

[0038] Construct an empty target architecture system image. In a Linux host environment, an empty file of a preset size can be created in local storage using the data block copy command. In this embodiment, it can be set to 5GB. This file will then be used as the image carrier for building the general system base environment.

[0039] The empty generic image is set as a circular device and mounted to a preset third file directory. For example, the `losetup` command can be used to establish a mapping association between the empty image file and a circular device allocated by the host system, and the `mount` command can be used to mount the circular device to the host's third file directory. Using this method, the operating system can treat the image file as a regular block device and perform directory-level file read and write operations.

[0040] The base root file system is built using debootstrap in the third file directory. Debootstrap is a tool used to build the base environment of Debian and its derivative systems from software sources. By executing the debootstrap command and specifying the target architecture and target mount path (i.e., the third file directory), the essential software packages that constitute the most basic Linux operating system are automatically pulled and decompressed from the specified software source. These essential software packages may include: core tools, basic C libraries, and package managers. The essential software packages are copied to this directory. Any files modified or added in the third file directory will be persistently saved directly within the empty generic image through the established circular device mapping. Step 220: chroot is executed to enter the third file directory and the second script is automatically run in the chroot environment to install the generic software packages corresponding to system services, display, and desktop environment in the base root file system.

[0041] Since the base root filesystem is mounted under the third file directory, chroot is executed to enter this third file directory, thereby changing the root directory of the current process and its child processes to the third file directory. Through the chroot mechanism, the build environment is logically isolated within the root filesystem of the generic image, ensuring that subsequent installation and configuration operations directly affect this generic image without polluting the host system environment.

[0042] To automate the installation process, the second script will run automatically within the chroot environment. In practice, the second script can be copied to a specific path in a third file directory before entering the chroot environment, and then executed via the chroot command along with the script's execution command, thus enabling automatic invocation of the script in the isolated environment.

[0043] The second script runs in the chroot environment and executes the following: it installs common software packages corresponding to system services, display, and desktop environments in the underlying root file system. For example, the second script can internally call package management tools, such as `apt-get update` and `apt-get install`, to pull and install a large number of common system software packages from a specified software source. These common system software packages do not depend on the underlying interfaces of specific RISC-V hardware and belong to the intersection of system image packages from various hardware platforms. For example, they may include: system service packages such as SSH service and network management tools; display service packages such as X11 or Wayland; and desktop environment packages such as GNOME and KDE. Furthermore, the ratio of the types of common software packages included in the general complete image to the types of software packages in all target architecture hardware platform system images is greater than a preset ratio threshold. This ensures that the general image covers as many common software packages as possible.

[0044] This stage requires pulling and configuring a large number of common software packages from the software source, which can account for approximately 90% of the entire image building process. However, through the aforementioned pre-build mechanism, this time-consuming operation only needs to be executed once to generate a complete common image containing approximately 99% of the software package types. After completing the installation and basic configuration of all common software packages, the second script automatically exits the chroot environment.

[0045] Since the universal complete image already includes common software packages such as system services, display and desktop environment, when building system images for different RISC-V hardware platforms, there is no need to repeatedly perform time-consuming debootstrap initialization and download and install a large number of common software packages for each platform. The deployment of most software environments can be completed simply by file synchronization, which significantly shortens the image building time.

[0046] Step 230: After exiting chroot, unmount the generic image and remove the loop device to obtain the generic complete image.

[0047] After the second script in the chroot environment completes the installation and basic configuration of all common software packages, it automatically exits the chroot environment, returning control to the host system. By executing an uninstallation command to remove the mount relationship between the third file directory and the common image, ensuring complete persistence of the mount point data, the script further executes a circular device management command to remove the mapping relationship between the circular device and the common image file, releasing the virtual block device resources of the host system. Using the above methods, the final common complete image is obtained. This common complete image contains the basic root file system required by various RISC-V hardware platform system images, as well as most cross-platform common software packages.

[0048] System images built for various RISC-V hardware platforms all originate from the same pre-built universal complete image, thereby ensuring that the versions and configurations of common software packages remain highly consistent across system images of different hardware platforms. This effectively solves the software environment fragmentation problem caused by separate independent builds in existing technologies.

[0049] Step 240: Construct an empty target architecture system image. Format and partition the empty general image according to the image type and partition format requirements of the target architecture to form the target architecture system image to be constructed. The target architecture system image to be constructed includes at least a first boot partition, a second boot partition, a boot partition, and a root file system partition frame.

[0050] Step 250: Set the target architecture system image to be built as a circular device, mount the root file system partition of the target architecture system image to be built to a preset first file directory, mount the pre-built universal complete image containing cross-hardware platform universal software packages to a preset second file directory, and use a synchronization command to synchronize all files in the second file directory to the first file directory while keeping the file permissions unchanged.

[0051] Step 260: Remove the mount relationship between the general complete image and the second file directory.

[0052] Step 270: Copy the boot binary file corresponding to the target architecture to be built to the first boot partition and the second boot partition respectively. Mount the boot partition of the target architecture system image to be built to the boot subdirectory under the first file directory. Execute chroot to enter the first file directory to change the root directory of the current process and child processes to the first file directory. Install the kernel, boot configuration and hardware driver corresponding to the target architecture hardware to be built in the first file directory, so that the kernel and boot configuration are automatically installed to the boot partition.

[0053] Step 280: Remove the mount relationship between the first file directory and the partition where the target architecture system image to be built is stored (the partition containing the boot files), and unbind the circular device from the target architecture system image to be built.

[0054] This embodiment adds the following steps: Constructing an empty target architecture system image; setting the empty generic image as a loop device and mounting it to a preset third file directory; using debootstrap to construct a basic root file system in the third file directory; executing chroot to enter the third file directory and automatically running the second script in the chroot environment to install the generic software packages corresponding to system services, display, and desktop environments in the basic root file system; exiting chroot and unmounting the generic image and removing the loop device to obtain the generic complete image. This ensures a high degree of consistency between the basic root file system and most generic software packages in the system images of each hardware platform, effectively solving the software fragmentation and environmental differences caused by the independent construction of each platform in the RISC-V ecosystem. Furthermore, when constructing target images for different hardware platforms, the generic complete image can be reused directly through the aforementioned file synchronization command, completely avoiding the repeated execution of time-consuming software pulling and installation processes for each platform. This results in an exponential decrease in the overall construction time of multi-platform images, significantly improving iteration and distribution efficiency.

[0055] Example 3 Figure 3 This is a schematic diagram of the RISC-V image building device provided in Embodiment 3 of the present invention. See also... Figure 3 The RISC-V-oriented image building apparatus includes: The construction module 310 is used to construct an empty target architecture system image. It formats and partitions the empty general image according to the image type and partition format requirements of the target architecture to form a target architecture system image to be constructed. The target architecture system image to be constructed includes at least a first boot partition, a second boot partition, a boot partition, and a root file system partition. The setting module 320 is used to set the target architecture system image to be built as a circular device, mount the root file system partition of the target architecture system image to be built to a preset first file directory, mount the pre-built universal complete image containing cross-hardware platform general software packages to a preset second file directory, and use a synchronization command to synchronize all files in the second file directory to the first file directory while keeping the file permissions unchanged. Remove module 330, used to remove the mount relationship between the general complete image and the second file directory; The copy module 340 is used to copy the boot binary file corresponding to the target architecture to be built to the first boot partition and the second boot partition respectively, mount the boot partition of the target architecture system image to be built to the boot subdirectory under the first file directory, execute chroot to enter the first file directory, change the root directory of the current process and child processes to the first file directory, and install the kernel, boot configuration and hardware driver corresponding to the target architecture hardware to be built in the first file directory, so that the kernel and boot configuration are automatically installed to the boot partition; The removal module 350 is used to remove the mount relationship between the first file directory and the partition where the boot files of the target architecture system image to be built are stored, and to unbind the circular device from the target architecture system image to be built.

[0056] The RISC-V-oriented image building apparatus provided in this embodiment constructs an empty target architecture system image. Based on the target architecture's image type and partitioning format requirements, it formats and partitions the empty general-purpose image to form a target architecture system image to be built. This target architecture system image includes at least a first boot partition, a second boot partition, a boot partition, and a root file system partition. The target architecture system image is set as a circular device. The root file system partition of the target architecture system image is mounted to a preset first file directory. A pre-built general-purpose complete image containing cross-hardware platform general-purpose software packages is mounted to a preset second file directory. A synchronization command is used to synchronize all files in the second file directory to the first file directory while maintaining file permissions. The process involves: removing the mount relationship between the universal complete image and the second file directory; copying the boot binary file corresponding to the target architecture to be built to the first boot partition and the second boot partition respectively; mounting the boot partition of the target architecture system image to be built to the boot subdirectory under the first file directory; executing chroot to enter the first file directory to change the root directory of the current process and child processes to the first file directory; installing the kernel, boot configuration, and hardware driver corresponding to the target architecture hardware to be built in the first file directory, so that the kernel and boot configuration are automatically installed to the boot partition; removing the mount relationship between the first file directory and the partition where the boot files of the target architecture system image are stored, and unbinding the circular device from the target architecture system image. Finally, mounting a pre-built universal complete image containing cross-hardware platform universal software packages and using synchronization commands to completely synchronize all files in the universal image to the target architecture system image to be built. Because all hardware platform images are cloned and synchronized based on the same pre-built universal base, the version inconsistency issues caused by each platform pulling software packages from continuously updated software sources in existing technologies are avoided. This ensures that the vast majority of package lists and versions in the system images of each hardware platform are completely consistent. Instead of building from scratch, file synchronization is used instead of building from scratch. Only one pre-build of the universal image is required, and subsequent builds of each platform directly perform file-level synchronization. This technical feature transforms the most time-consuming step into efficient file copying, significantly reducing the total time for building system images for multiple hardware platforms. Furthermore, before executing chroot, the boot partition is pre-mounted in the boot subdirectory of the root file system. This allows relevant files to be automatically and accurately placed in the boot partition when executing regular kernel and driver installation commands in the chroot environment. This avoids file installation errors or complex secondary manual copying caused by path changes within the chroot environment, effectively improving the automation level of image building and the reliability of system startup.

[0057] Based on the above embodiments, the building module includes: The mounting unit is used to construct an empty general image of a preset size, set the empty general image as a circular device and mount it to a preset third file directory, and use debootstrap to construct a basic root file system in the third file directory. The execution unit is used to execute chroot to enter the third file directory and automatically run the second script in the chroot environment to install the general software packages corresponding to system services, display and desktop environment in the basic root file system; The exit unit is used to unmount the generic image and remove the loop device after exiting chroot, thus obtaining the generic complete image.

[0058] Based on the above embodiments, the ratio of the common software package types included in the general complete image to the software package types in all target architecture hardware platform system images is greater than a preset ratio threshold.

[0059] Based on the above embodiments, the first boot partition is 1MB in size, the second boot partition is 6MB in size, the startup partition is 500MB in size and formatted as vfat, the root file system partition occupies the remaining space and is formatted as ext4; the partition label of the startup partition is set to bootfs, and the partition label of the root file system partition is set to rootf.

[0060] Based on the above embodiments, the copy module includes: The writing unit is used to write the u-boot-spl.bin file to the first boot partition and the u-boot.itb file to the second boot partition using the dd command; wherein, u-boot-spl.bin is the secondary program loader of U-Boot, and u-boot.itb is a FIT image containing OpenSBI firmware, U-Boot main body and device tree.

[0061] Based on the above embodiments, the copy module includes: The installation unit is used in the chroot environment to install the kernel deb package and graphics card driver corresponding to the target RISC-V hardware model using apt install. After modifying the / etc / default / u-boot configuration file, it runs the u-boot-update command to automatically generate the extlinux.conf boot configuration file. The extlinux.conf file is installed to the boot partition that is mounted in the boot subdirectory under the first file directory.

[0062] Based on the above embodiments, the device further includes: An automatic execution module is implemented using a first script file and a second script file. The first script performs image building, partition formatting, circular device setting, file synchronization, boot binary file writing, and boot partition mounting operations. Before executing chroot, the second script is copied to the first file directory. The second script is automatically called in the chroot environment to perform kernel, hardware driver, and boot configuration installation operations. After installation, chroot is exited, and the first script continues to perform mount removal and circular device unbinding operations.

[0063] The RISC-V-oriented image building apparatus provided in this embodiment of the invention can execute the RISC-V-oriented image building method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0064] Example 4 Figure 4 This is a schematic diagram of an end structure provided in Embodiment 4 of the present invention. Figure 4 A block diagram is shown of an exemplary terminal 12 suitable for implementing embodiments of the present invention. Figure 4 The terminal 12 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0065] like Figure 4 As shown, terminal 12 is presented in the form of a general-purpose computing terminal. The components of terminal 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0066] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0067] Terminal 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by terminal 12, including volatile and non-volatile media, removable and non-removable media.

[0068] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache 32. Terminal 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (… Figure 4 Not shown; usually referred to as a "hard drive"). Although Figure 4 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. Memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0069] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0070] Terminal 12 can also communicate with one or more external terminals 14 (e.g., keyboard, pointing terminal, display 24, etc.), one or more terminals that enable a user to interact with terminal 12, and / or any terminal (e.g., network card, modem, etc.) that enables terminal 12 to communicate with one or more other computing terminals. This communication can be performed via input / output (I / O) interface 22. Furthermore, terminal 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. As shown, network adapter 20 communicates with other modules of terminal 12 via bus 18. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with terminal 12, including but not limited to: microcode, terminal drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0071] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the RISC-V-oriented image building method provided in the embodiments of the present invention.

[0072] Example 5 Embodiment 5 of the present invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform any of the RISC-V-oriented image building methods provided in the above embodiments.

[0073] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0074] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0075] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0076] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or terminal. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0077] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A method for building a RISC-V image, characterized in that, include: An empty target architecture system image is constructed. The empty general image is formatted and partitioned according to the image type and partition format requirements of the target architecture to form the target architecture system image to be constructed. The target architecture system image to be constructed includes at least a first boot partition, a second boot partition, a boot partition, and a root file system partition. Set the target architecture system image to be built as a circular device, mount the root file system partition of the target architecture system image to be built to a preset first file directory, mount the pre-built universal complete image containing cross-hardware platform general software packages to a preset second file directory, and use a synchronization command to synchronize all files in the second file directory to the first file directory while keeping the file permissions unchanged. Remove the mount relationship between the general complete image and the second file directory; Copy the boot binary file corresponding to the target architecture to be built to the first boot partition and the second boot partition respectively. Mount the boot partition of the target architecture system image to be built to the boot subdirectory under the first file directory. Execute chroot to enter the first file directory to change the root directory of the current process and child processes to the first file directory. Install the kernel, boot configuration and hardware driver corresponding to the target architecture hardware to be built in the first file directory so that the kernel and boot configuration are automatically installed to the boot partition. Remove the mount relationship between the first file directory and the partition where the boot files of the target architecture system image to be built are stored, and unbind the circular device from the target architecture system image to be built.

2. The method according to claim 1, characterized in that, The method further includes: Construct an empty generic image of a preset size, set the empty generic image as a circular device and mount it to a preset third file directory, and use debootstrap to construct a basic root file system in the third file directory; The script is executed to enter the third file directory and run automatically in the chroot environment to install the general software packages corresponding to system services, display and desktop environment in the base root file system. After exiting chroot, unmount the generic image and unloop the device to obtain the generic complete image.

3. The method according to claim 2, characterized in that, The ratio of the common software package types contained in the general complete image to the software package types in all target architecture hardware platform system images is greater than a preset ratio threshold.

4. The method according to claim 1, characterized in that, The first boot partition is 1MB in size, the second boot partition is 6MB in size, the startup partition is 500MB in size and formatted as vfat, and the root file system partition occupies the remaining space and is formatted as ext4; the partition label of the startup partition is set to bootfs, and the partition label of the root file system partition is set to rootf.

5. The method according to claim 1, characterized in that, The step of copying the boot binary file corresponding to the target architecture to be built to the first boot partition and the second boot partition respectively includes: The u-boot-spl.bin file is written to the first boot partition using the dd command, and the u-boot.itb file is written to the second boot partition; wherein, u-boot-spl.bin is the secondary program loader of U-Boot, and u-boot.itb is a FIT image containing OpenSBI firmware, U-Boot main body and device tree.

6. The method according to claim 5, characterized in that, The step of installing the kernel, boot configuration, and hardware drivers corresponding to the target architecture hardware to be built in the first file directory includes: In the chroot environment, use `apt install` to install the kernel deb package and graphics card driver corresponding to the target RISC-V hardware model. After modifying the ` / etc / default / u-boot` configuration file, run the `u-boot-update` command to automatically generate the `extlinux.conf` boot configuration file. The `extlinux.conf` file is then installed into the boot partition, which is mounted in the boot subdirectory of the first file directory.

7. The method according to claim 1, characterized in that, The RISC-V-oriented image building method utilizes a first script file and a second script file in tandem. The first script performs image building, partition formatting, circular device setup, file synchronization, boot binary file writing, and boot partition mounting operations. Before executing chroot, the second script is copied to the first file directory. The second script is automatically invoked in the chroot environment to perform kernel, hardware driver, and boot configuration installation operations. After installation, chroot is exited, and the first script continues to perform mount removal and circular device unbinding operations.

8. A RISC-V image building apparatus, characterized in that, include: The build module is used to build an empty target architecture system image. It formats and partitions the empty general image according to the image type and partition format requirements of the target architecture to form the target architecture system image to be built. The target architecture system image to be built includes at least a first boot partition, a second boot partition, a boot partition, and a root file system partition. The configuration module is used to set the target architecture system image to be built as a circular device, mount the root file system partition of the target architecture system image to be built to a preset first file directory, mount the pre-built universal complete image containing cross-hardware platform general software packages to a preset second file directory, and use a synchronization command to synchronize all files in the second file directory to the first file directory while keeping the file permissions unchanged. The removal module is used to remove the mount relationship between the general complete image and the second file directory; The copy module is used to copy the boot binary file corresponding to the target architecture to be built to the first boot partition and the second boot partition respectively, mount the boot partition of the target architecture system image to be built to the boot subdirectory under the first file directory, execute chroot to enter the first file directory, change the root directory of the current process and child processes to the first file directory, and install the kernel, boot configuration and hardware driver corresponding to the target architecture hardware to be built in the first file directory, so that the kernel and boot configuration are automatically installed to the boot partition; The removal module is used to remove the mount relationship between the first file directory and the partition where the boot files of the target architecture system image to be built are stored, and to unbind the circular device from the target architecture system image to be built.

9. A terminal, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the RISC-V-oriented image building method as described in any one of claims 1-7.

10. A storage medium containing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a computer processor, are used to perform the RISC-V-oriented image building method as described in any one of claims 1-7.

Images