CN115129421A

CN115129421A - Method for acquiring mirror image file containing root file system and starting method

Info

Publication number: CN115129421A
Application number: CN202210682144.4A
Authority: CN
Inventors: 王东方; 焦进星; 弓羽箭; 韩辉; 徐贵洲
Original assignee: Guangzhou Yihui Information Technology Co ltd
Current assignee: Guangzhou Yihui Information Technology Co ltd
Priority date: 2022-06-15
Filing date: 2022-06-15
Publication date: 2022-09-30

Abstract

The application provides a method for acquiring an image file of a root-containing file system, which comprises the following steps: generating a kernel executable file of the embedded operating system; putting the kernel executable file and the root file system into a folder; and obtaining the mirror image files of the kernel file and the root file system by using a mirror image manufacturing tool. By the method for acquiring the image file, a user can conveniently deploy the newly added file to an external nonvolatile storage medium, and the root file system and the kernel are packaged together to manufacture a single image file for burning.

Description

Method for acquiring mirror image file containing root file system and starting method

Technical Field

The invention belongs to the technical field of electric digital data processing, and particularly relates to a method for acquiring a mirror image file of a root file system and a starting method.

Background

The software mechanism in the operating system that is responsible for managing and storing data information is called the file system (file system). Data is managed in the form of files, files are managed in the form of directories, and directories are managed in the form of directory trees, which is a logical structure organization form of data management. The logical structure organization form of the related information + data is the file system (part of the logic). For UNIX-like file systems, all types of files logically form a directory tree, and the information of the directory tree itself needs to be stored in an external storage, which is a root file system (rootfs) for storing the information of the whole directory tree.

In the embedded application, the Linux system uses the busy box open source component to cooperate with the special tool software mke2fs to make a root directory system, and then the root directory system is deployed in an external storage medium together with a kernel, and the kernel can work only by cooperating with the root file system. The Linux kernel and the busybox root file system need to be compiled and deployed separately, and the busybox is powerful but too complex, which is not beneficial to embedded application development.

Disclosure of Invention

Aiming at the technical problems in the prior art, the invention provides the method for acquiring the mirror image file containing the root file system, so that the root file system and the kernel can be packaged together to be manufactured into a single mirror image file for burning.

The application provides a method for acquiring an image file of a root-containing file system, which comprises the following steps:

generating a kernel executable file of the embedded operating system;

putting the kernel executable file and the root file system into a folder;

and obtaining the mirror image files of the kernel file and the root file system by using a mirror image manufacturing tool.

In a preferred embodiment, the file system logical partition of the embedded operating system includes a kernel logical partition and a root file system logical partition:

the kernel logic partition is used for storing kernel files;

and the root file system logic partition is used for storing the files of the root file system.

In a preferred embodiment, the image files of the kernel file and the root file system are obtained by using an image making tool in the integration stage of the embedded operating system.

In a preferred embodiment, the mirror image making tool generates a single file system mirror image file based on the power-down security file system and divided into a kernel logical partition and a root file system logical partition according to the folder where the kernel executable file and the root file system are located.

In a preferred embodiment, the method for mounting the root file system after the embedded operating system is started includes:

the parameter function started by the kernel is configured with a root file system mapping relation option;

initializing according to configuration parameters transmitted from the mapping relation option of the root file system, and storing the configuration parameters to a global variable;

installing a root file system driver to provide a symbolic link function interface to create root file system equipment and mount the root file system equipment to a root directory;

the embedded operating system establishes a system equipment file directory, a file system equipment automatic mounting directory and a dynamic file system mounting directory;

and calling a root file system mapping function to realize the mapping operation of the standard directory structure of the embedded operating system except for the system equipment file directory, the file system equipment automatic mounting directory and the dynamic file system mounting directory, and calling the symbolic link function to create a symbolic link for the directory according to the configuration parameters stored in the global variable, wherein the symbolic link is a link between a root file system path and the mapping.

In a preferred embodiment, the parameters of the map relation option include an optional map and a must-map to which the root directory belongs.

In a preferred embodiment, the installing the root file system driver includes creating a character device driver, and further provides interfaces for a create function, a release function, an open function, a close function, a read function, a write function, a state acquisition function, and an ioctl operation function.

In a preferred embodiment, when the root file system device is created, the root file system device mount directory address is the root directory.

In a preferred embodiment, creating symbolic links to directories comprises calling functions to create symbolic links to "/var", "/usr", "/tmp", "/sbin", "/root", "/qt", "/lib", "/home", "/etc", "/boot", "/bin", "/apps" directories, respectively.

According to the specific implementation mode provided by the invention, compared with the prior art, the invention discloses the following technical effects:

the method for acquiring the mirror image file of the system containing the root file comprises the following steps: generating a kernel executable file of the embedded operating system; putting the kernel executable file and the root file system into a folder; and obtaining the mirror image files of the kernel file and the root file system by using a mirror image manufacturing tool. By the method for acquiring the image file, a user can conveniently deploy the newly added file to an external nonvolatile storage medium, and the root file system and the kernel are packaged together to manufacture a single image file for burning.

Further, the method for mounting the root file system after the embedded operating system is started comprises the following steps: the parameter function started by the kernel is configured with a root file system mapping relation option; initializing according to configuration parameters transmitted from the mapping relation option of the root file system, and storing the configuration parameters to global variables; installing a root file system driver to provide a symbolic link function interface to create root file system equipment and mount the root file system equipment to a root directory; the embedded operating system establishes a system equipment file directory, a file system equipment automatic mounting directory and a dynamic file system mounting directory; calling a root file system mapping function to realize the mapping operation of a standard directory structure of an embedded operating system except a system equipment file directory, a file system equipment automatic mounting directory and a dynamic file system mounting directory, calling the symbolic link function to create a symbolic link for the directory according to configuration parameters stored in a global variable, wherein the symbolic link is a link between a root file system path and mapping and passes through a mounting method of the root file system, and a user can conveniently deploy a newly-added file to an external nonvolatile storage medium. By the mounting method, the root file system and the kernel are packaged together to be made into a single mirror image file for burning, the mapping configuration parameters of the root directory file system can be dynamically set, other file systems can be conveniently deployed and mounted on the premise of saving hardware resources, the flexibility of the system is improved, and developers can pay more attention to the development of the application program.

Further, with the benefit of the method for acquiring the image file containing the root file system, the present application also provides a starting method for an embedded operating system, where the image file acquired by the method for acquiring the image file in any of the above embodiments is loaded into a storage medium of the embedded operating system, and the embedded operating system runs a kernel file in the image file and loads the root file system in the image file.

Drawings

Fig. 1 is a block diagram of a hardware structure of a computer terminal (or a mobile device) according to an image file obtaining method including a root file system provided in embodiment 1 of the present invention;

FIG. 2 is a diagram of a kernel source directory in SylixOS BASE engineering in embodiment 1 of the present invention;

fig. 3 is a schematic flowchart of an image file obtaining method of a root-containing file system according to embodiment 1 of the present invention;

fig. 4 is a schematic diagram of eMMC partition in embodiment 1 of the present invention;

FIG. 5 is a SylixOS file system logical partition in embodiment 1 of the present invention;

fig. 6 is a schematic diagram of an initialization procedure of startup.s provided in embodiment 2 of the present invention;

fig. 7 is a schematic diagram of an initialization procedure of the halBootThread function provided in embodiment 2 of the present invention;

fig. 8 is a flowchart of root file system mount in the SylixOS boot in embodiment 2 of the present invention.

Detailed Description

The present invention is further described below in conjunction with the appended drawings and specific embodiments so that those skilled in the art may better understand and practice the present invention. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

Example 1

In accordance with an embodiment of the present application, there is provided an embodiment of an image file obtaining method including a root file system, it is noted that the steps shown in the flowchart of the drawings may be executed in a computer system such as a set of computer executable instructions, and that although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in an order different from the order shown.

The method provided by the first embodiment of the present application may be executed in a mobile terminal, a computer terminal, or a similar computing device. Fig. 1 is a block diagram showing a hardware configuration of a computer terminal (or mobile device) including an image file obtaining method of a root file system. As shown in fig. 1, the computer terminal 10 (or mobile device 10) may include one or more (shown as 102a, 102b, … …, 102 n) processors 102 (the processors 102 may include, but are not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. Besides, the method can also comprise the following steps: a display, an input/output interface (I/O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of the I/O interface), a network interface, a power source, and/or a camera. It will be understood by those skilled in the art that the structure shown in fig. 1 is only an illustration and is not intended to limit the structure of the electronic device. For example, the computer terminal 10 may also include more or fewer components than shown in FIG. 1, or have a different configuration than shown in FIG. 1.

It should be noted that the one or more processors 102 and/or other data fusion circuitry described above may be generally referred to herein as "data fusion circuitry". The data fusion circuit may be embodied in whole or in part as software, hardware, firmware, or any combination thereof. Further, the data fusion circuit may be a single stand-alone processing module, or incorporated in whole or in part into any of the other elements in the computer terminal 10 (or mobile device). As referred to in the embodiments of the application, the data fusion circuit acts as a processor control (e.g., selection of variable resistance termination paths connected to the interface).

The memory 104 may be used to store software programs and modules of application software, such as program instructions/data storage devices corresponding to the image file acquiring method in the embodiment of the present application, and the processor 102 executes various functional applications and data fusion by running the software programs and modules stored in the memory 104, so as to implement the image file acquiring method. The memory 104 may include high speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include memory located remotely from the processor 102, which may be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The transmission device 106 is used for receiving or transmitting data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network adapter (NIC) that can be connected to other Network devices through a base station to communicate with the internet. In one example, the transmission device 106 can be a Radio Frequency (RF) module, which is used to communicate with the internet in a wireless manner.

The display may be, for example, a touch screen type Liquid Crystal Display (LCD) that may enable a user to interact with the user interface of the computer terminal 10 (or mobile device).

It should be noted that, in some alternative embodiments, the computer device (or mobile device) shown in fig. 1 may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that fig. 1 is only one example of a particular specific example and is intended to illustrate the types of components that may be present in the computer device (or mobile device) described above.

The present embodiment takes a SylixOS system as an example to describe the method for acquiring an image file including a root file system.

There are 3 important engineering types for developing SylixOS, which are BASE engineering, BSP engineering and APP engineering from bottom to top.

The SylixOS BASE project is a foundation of all other projects, the SylixOS organizes codes which are irrelevant to board levels into a BASE project, and mainly comprises functions of a kernel thread scheduler, a file system, a network protocol stack, a cpu architecture (mmu and cache) and the like, and because the codes are irrelevant to specific boards, the codes are uniformly placed in the BASE project for compiling.

The SylixOS BSP project is mainly responsible for board-level initialization and system boot startup, and different hardware boards all need corresponding BSPs to compile a final system image.

The SylixOS APP project is an application program developed by a user, and can be independently compiled and developed, so that the application and the system are decoupled, and can be respectively developed and maintained, and the maintenance cost is reduced.

The kernel source code (i.e., libsylixos sub-engineering)) directory in SylixOS BASE engineering is shown in fig. 2.

As shown in fig. 2, in the kernel source code (libsylixos child engineering) directory in SylixOS BASE engineering:

the API folder is a user API function source code;

the kernel folder is a kernel source code;

a kmodule folder is a kernel module source code;

the lib folder is a kernel dependency library and standard C library source codes;

cplupplus folder is a C + + operation support library source code;

the fs/rootfs folder is used as a root file system to realize source codes;

and (5) generating a static library file libsylixos.

The basic C library source code libextern sub-project in the SylixOS BASE project generates a static library file libcexter.

In the process of SylixOS BSP engineering compilation, library files of libsylixos.a and libextern.a are linked to generate final.bin and.elf format executable image files.

The root file system (ROOTFS) in SylixOS is a special file system, which is the first file system to mount automatically when the SylixOS kernel is started, and thus includes the directories and critical files necessary for the start of the SylixOS. Such as the etc directory necessary for kernel startup, and the system command bin directory, any files necessary for startup including these SylixOS can be the root file system.

The root file system of SylixOS is designed as a virtual type root file system because the file system does not exist in a specific physical disk, but is dynamically created after the system is booted, and is saved in memory.

Unlike the Linux system, the SylixOS root file system is a virtual file system that does not store modifications to the file system after a power failure, so the SylixOS can operate on machines that do not have non-volatile memory (typically a hard disk or other disk storage).

The standard directory structure used by SylixOS is shown in table 1.

Table 1 table of standard directory structure used by SylixOS

Name of directory	Brief description of the drawings
		qt	Qt graphic system dynamic link library and other Qt resource catalog
tmp	Temporary directory
		var	Directories of files storing variations, e.g. logs, buffer files, etc
root	root user Main directory
		home	Other user home directory
apps	Application catalog
		sbin	System program directory
bin	Generic Shell program catalog
		usr	User library and environment directory
lib	System library and environment directory
		etc	System or other application configuration file directory
boot	Operating system boot image directory
		media	File system equipment automatic mounting catalog (such as USB, SD card and the like)
proc	System kernel information file directory
		mnt	Dynamic file system mount directory
dev	System device file directory

For SylixOS, as shown in fig. 3, the method for acquiring an image file of a system including a root file includes:

generating a kernel executable file of the embedded operating system;

specifically for SylixOS, the SylixOS kernel executable is generated by BASE and BSP engineering using RealEvo-IDE development environment software.

Putting the kernel executable file and the root file system into a folder;

specifically for SylixOS, a folder "SylixOS _ Deploy" is created that holds the SylixOS kernel files and the associated files of the root file system. "SylixOS _ Deploy", creates folders [ boot, var, usr, tmp, sbin, root, qt, lib, home, etc., bin, apps ] shown in the column of "File System Path" in Table 2 below, and stores SylixOS kernel files and related files of the root file system at the head.

Obtaining a kernel file and the mirror image file of the root file system by using a mirror image manufacturing tool;

the SylixOS-based power-down security file system is manufactured and generated by using an mksylixasfs.exe tool, and is divided into a single file system image file Sylixxosfs.img of a Kernel Kernel logical partition and a Root Filesystem Root file system logical partition.

In a general embedded system, NandFlash or eMMC [ NAND Flash + main control IC ] is used as a storage medium. Most eMMC devices have 4 large partitions: BOOT, RPMB, GPP, and UDA, shown in FIG. 4.

Wherein:

the BOOT Area partitions are generally used to place BOOT loaders or related configuration parameters, such as u-BOOT loaders;

the RPMB partition is typically used to hold security related data;

the General Purpose Partitions (GPP) are mainly used to store system and application data;

the User Data Area (UDA) partition is used as the largest partition in the eMMC, and in an actual product, as the most main storage Area, the User Data Area (UDA) partition is subdivided and formatted into different file systems for storing related Data of an operating system.

For eMMC devices, a general embedded operating system is managed using a file system such as FAT or yaffs.

The SylixOS adopts a power-down security file system as a default file system, adopts a transaction submission mechanism to ensure the security of the file system, and can truly prevent data damage caused by power failure or system crash.

The SylixOS file system logical partition comprises a Kernel Kernel logical partition and a Root FileSystemroot file system logical partition. For eMMC devices, the SylixOS file system logical partition is shown in fig. 5.

As shown in fig. 5, the Kernel logical partition [ file system path/root ] is used to store the SylixOS Kernel file, and the corresponding mapping path is/media/sdcard 0; the Root file system logical partition is used for storing related files of the Root file system, and the corresponding mapping path is/media/sdcard 1.

And obtaining the mirror image files of the kernel file and the root file system by using a mirror image manufacturing tool in the integration stage of the embedded operating system.

And the mirror image manufacturing tool generates a single file system mirror image file which is divided into a kernel logic partition and a root file system logic partition based on the power failure security file system according to the file folder where the kernel executable file and the root file system are located.

The mksylixxosfs is a tool for generating a SylixOS file system image (including a kernel executable file and a root file system), and the generated file system image can be written to a disk partition to realize the mounting of the file system.

In the batch production stage, the disk partitioning, the software deployment and the configuration file are manually made for each device, which wastes time and labor and is difficult to ensure the correctness. The SylixOS file system image is made at the system integration stage using mksyyixosfs. During production, the magnetic disk is directly burnt, so that the manual operation step is avoided, and the method is efficient, safe and reliable.

File system image file sysixoss fs.img is made using image making tool mksylixxosfs.exe, an example of a command is as follows:

"mksylixxosfs. exe-b [ eMMC block size parameter ] -s [ sector size ] -c [ block number ] -osylixxofs. img SylixOS _ Deploy"

It should be noted that:

1) an eMMC block size parameter, 4096 bytes by default;

2) sector size, default 512 bytes;

3) number of blocks, User Data Area (UDA) partition capacity size in eMMC/eMMC block size.

By the image file obtaining method, a user can conveniently deploy a newly added file to an external nonvolatile storage medium, and a root file system and a kernel are packaged together to make a single image file for burning.

In the SylixOS system, the method for mounting the root file system after the embedded operating system is started comprises:

and S1, configuring the parameter function started by the kernel to contain a root file system mapping relation option.

In this embodiment, the kernel-initiated parameter function API _ KernelStartParam is configured to include a root file system mapping option rfsmap, and the parameters of the root file system mapping option rfsmap are separated by commas, where "/boot", "/etc.", "/tmp", "/apps" are optional mappings, and the whole root directory "/" is a required mapping.

For example:

"/boot:/media/hdd0" means that the "/boot" directory is mapped to "/media/hdd 0";

"/apps:/media/hdd2" means mapping "/apps" directory to "/media/hdd 2";

"/media/hdd1" indicates that the root directory is mapped to "/media/hdd1" as a whole;

"/dev/ram" indicates that the root directory is mapped to ramfs in its entirety.

Note that the "/dev/ram" type can only be used in the "/: map.

S2: initializing according to configuration parameters transmitted from the mapping relation option of the root file system, and saving the configuration parameters to global variables.

In this embodiment, according to the configuration parameter transmitted by the root file system mapping relationship option rfsmap, the API _ RootFsMapInit function is called to perform initialization operation, the configuration parameter is saved into the global variables _ G _ rfsmaptorpoot and _ G _ rfsmapSubp, and the root directory file system mapping configuration relationship can be dynamically set.

S3, installing a root file system driver to provide a symbolic link function interface to create a root file system device and mount the root file system device to a root directory.

In this embodiment, the rootFsDrv function completes installation of the root file system driver, specifically:

root file system (ROOTFS) related API code bits/libsylxos/SylixOS/fs/ROOTFS directory in SylixOS.

The function API _ rootfsdrvsinstall defined by macro rootFsDrv implements the mount root file system driver. The function creates a character device driver and provides function interfaces of creating, releasing, opening, closing, reading, writing, state acquiring, ioctl operation function, symbolic linking and the like, wherein:

__ rootFsOpen function, ROOTFS file node open or create function. According to different input mark parameters, newly building a file or increasing the reference count of the file, and simultaneously supporting symbolic link;

__ rootFsRemove function, ROOTFS file node delete function;

__ rootFsClose function, ROOTFS file node close function;

__ rootFsRed function, ROOTFS does not support read operations;

__ rootFsWrite function, ROOTFS does not support write operations;

__ rootFsLStatGet function, ROOTFS file state and attribute obtaining function;

__ rootFsIoctl function, and ROOTFS file node Ioctl operation function. The method comprises the functions of obtaining a file state, obtaining a file system state, obtaining directory information, caching and writing back files, changing file access authority, obtaining a file system type and the like;

__ rootFsSymlink function, ROOTFS symbolic link creation function;

__ rootFsReadlink function, ROOTFS link file read function.

In this embodiment, the rootFsDevCreate function completes creation of the root file system device, specifically:

the function API _ rootFsDevCreate defined by macro rootFsDevCreate implements the creation of a root file system device.

Wherein, the address of the mounting directory of the root file system device is root directory '/'.

And S4, the embedded operating system establishes a system device file directory, a file system device automatic mounting directory and a dynamic file system mounting directory.

Specifically, after the root file system device is created, the SylixOS kernel creates a directory such as "/dev", "/dev/pty", "/dev/pipe", "/dev/input", "/dev/blk", "/mnt", "/media".

And S5, calling a root file system mapping function to realize the mapping operation of the standard directory structure of the embedded operating system except the system equipment file directory, the automatic mounting directory of the file system equipment and the mounting directory of the dynamic file system, and calling the symbolic link function to create a symbolic link for the directory according to the configuration parameters stored in the global variables, wherein the symbolic link is a link between a root file system path and mapping.

In this embodiment, the root file system mapping function API _ rootFsMap defined by the macro rootFsMap implements mapping operations of other directory structures.

According to the configuration parameters, which are saved in the global variable _ G _ rfsmapSubp and are imported from the mapping relation option of the root file system, the symbolic link function symlink is called to respectively create symbolic links for the directories of "/var", "/usr", "/tmp", "/sbin", "/root", "/qt", "/lib", "/home", "/etc", "/bin", "/apps", as shown in table 2 below.

A file system (file system) is an important component of an operating system, and is a system that organizes and allocates space of a file storage device, and is responsible for storing files and protecting and retrieving stored files.

The root file system (ROOTFS) is the foundation of the file system and provides the most basic system services in coordination with the system kernel.

According to the specific implementation of the mount method of the root file system provided by the embodiment, for the real-time operating system, a user can conveniently deploy a newly added file to an external nonvolatile storage medium. By the mounting method, the root file system and the kernel are packaged together to be manufactured into a single mirror image file for burning, the mapping configuration parameters of the root directory file system can be dynamically set, other file systems can be conveniently deployed and mounted on the premise of saving hardware resources, the flexibility of the system is improved, and development of application programs by developers can be facilitated to pay more attention to.

Example 2

With the benefit of the method for acquiring an image file containing a root file system in embodiment 1, the present application also provides a starting method for an embedded operating system, where the image file acquired by the method for acquiring an image file in embodiment 1 is loaded into a storage medium of the embedded operating system, and the embedded operating system runs a kernel file in the image file and loads the root file system in the image file.

Taking u-boot write eMMC as an example, executing the following example commands in u-boot to complete deployment of an image file containing a sylixos root file system:

img// loading the mirror file into the memory 0x10000000 address by tftp

mmc dev 1/selected mmc 1 device

Img file size/write data in memory into mmc "

It should be noted that:

the memory address is used as a temporary storage mirror image data address, is different on different platforms and different u-boot versions, and needs to be flexibly changed;

the offset is the address offset of the User Data Area (UDA) partition in eMMC.

And after the steps are completed and the equipment is restarted, the u-boot loads the SylixOS kernel to normally run and can normally load the root file system.

The SylixOS supports the function of an FTP server, and after the SylixOS is normally started, the kernel file on the equipment and the file in the root file system can be updated or downloaded through an FTP tool.

The embedded operating system SylixOS is loaded and the following steps are carried out:

s100, receiving an operating system kernel loading instruction, and calling a kernel starting function to trigger the starting of the kernel;

s200, reading a kernel starting parameter function, wherein a root file system mapping relation option is predefined in the kernel starting parameter function;

s300, calling a kernel initialization function, and completing installation of a root file system driver and root file system equipment in the kernel initialization process, wherein a symbolic link function interface is provided in the root file system driver, and the root file system equipment is mounted to a root directory;

s400, calling a root file system mapping function to realize the mapping operation of a directory structure, and calling the symbolic link function to create a symbolic link for the directory according to the configuration parameters stored in the global variables;

s500, calling a user start function to create a user task of the operating system and finish the initialization of the operating system and the application component;

s600, transferring the control right to a user starting function for callback, and initializing an application component function by a user;

s700, a first task is created, which is responsible for initializing all system resources and transferring the control right to the user.

The SylixOS is mainly started by two source code files, i.e. startup. s and bspinit.c.

The startup.s file is located under the bsp project/SylixOS/bsp directory and is mainly responsible for initializing the critical operating environment and undertaking the first two major steps of the startup of the SylixOS, as shown in fig. 6.

The bsplinit. C file is also located under the directory of bsp engineering/SylixOS/bsp, the bsplinit function is the last major step of starting the SylixOS, the function is the jump entry of the C function, and the bsplinit function is mainly divided into several parts:

starting a kernel, and establishing critical operating environment data (an API _ KernelStartParam function and an API _ KernelStart function);

the SylixOS transfers the control right to the usrStartup function for callback, and the user initializes the related functions;

the first task (halBootThread function) is created, which is responsible for initializing all system resources and transferring the SylixOS control to the user.

The API _ KernelStart function is a SylixOS starting kernel function, the function prototype of the API _ KernelPrimaryStart function is API _ KernelHighLevelInit function, kernel high-level initialization is carried out, and the API _ KernelStart function comprises installation of a root file system driver, root file system equipment and the like; the usrStartup function is used as a parameter pffuncStartHook to import API _ KernelStart function to initialize application-dependent components to create the first task of the operating system.

The usrStartup function creates a t _ boot thread, and is used for initializing and starting a task function halBootThread function in a multitask state.

The halBootThread function is responsible for initializing all system resources, including root file system mapping (rootFsMap function), and the program flow is shown in fig. 7.

The SylixOS system is started, and after the root file system is normally loaded, the file system of another nonvolatile memory (in this example, the eMMC memory, the device driver name in the SylixOS is "sdcard") is further loaded, and the mapping relationship of the root directory file system is as shown in table 2.

TABLE 2 root File System mapping relationships

Through the root file system, a user can conveniently deploy the newly added files to the external nonvolatile storage medium.

Referring to fig. 3, a SylixOS kernel executable file is generated through BASE and BSP engineering using RealEvo-IDE development environment software; creating a folder 'SylixOS _ Deploy' for storing SylixOS kernel files and related files of a root file system; an mksylixosfs. exe tool is used for manufacturing and generating a single file system image file sylixosfs. img based on a SylixOS power failure security file system which is divided into a Kernel Kernel logical partition and a Root Filesystem Root file system logical partition; deploying to a UDA partition of the eMMC by using a u-boot tool; after the device is powered on and started, the u-boot loads the SylixOS kernel to normally run and can normally load the root file system.

Referring to fig. 8, the system is reset, and the program starts to run from the reset vector, at this time, the running code startup.s is the start code, and after the C program running environment (such as stack, interrupt, bus, and the like) is initialized, the bspinit function is entered to perform some necessary processing, and the SylixOS initialization work is completed.

In the description herein, references to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., mean that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present technology. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

Although embodiments of the present application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present application, and that variations, modifications, substitutions and alterations may be made to the above embodiments by those of ordinary skill in the art within the scope of the present application.

Claims

1. The method for acquiring the mirror image file of the system containing the root file is characterized by comprising the following steps:

generating a kernel executable file of the embedded operating system;

putting the kernel executable file and the root file system into a folder;

2. The image file acquisition method of claim 1, wherein the file system logical partition of the embedded operating system comprises a kernel logical partition and a root file system logical partition:

the kernel logic partition is used for storing kernel files;

3. The method for obtaining an image file according to claim 2, wherein the image files of the kernel file and the root file system are obtained by using an image making tool in an integration stage of the embedded operating system.

4. The image file obtaining method according to claim 3, wherein the image making tool makes a single file system image file based on the power-down security file system and divided into a kernel logical partition and a root file system logical partition according to the folder where the kernel executable file and the root file system are located.

5. The method for obtaining the image file according to claim 3, wherein the method for mounting the root file system after the embedded operating system is started comprises the following steps:

initializing according to configuration parameters transmitted from the mapping relation option of the root file system, and storing the configuration parameters to global variables;

6. The image file acquiring method according to claim 5, wherein the parameters of the mapping relation option include an optional mapping and a necessary mapping to which a root directory belongs.

7. The method for obtaining the image file according to claim 5, wherein the installing the root file system driver includes creating a character device driver, and further providing interfaces for a create function, a release function, an open function, a close function, a read function, a write function, a status obtain function, and an ioctl operation function.

8. The image file acquisition method according to claim 5, wherein when the root file system device is created, the root file system device mount directory address is a root directory.

9. The image file acquisition method of claim 8, wherein creating a symbolic link to a directory comprises calling a function to create a symbolic link to a directory of "/var", "/usr", "/tmp", "/sbin", "/root", "/qt", "/lib", "/home", "/etc", "/boot", "/bin", "/apps", respectively.

10. The starting method is characterized in that the image file obtained by the image file acquisition method according to any one of claims 1 to 9 is loaded into a storage medium of the embedded operating system, the embedded operating system runs a kernel file in the image file and loads a root file system in the image file.